Zusammenfassung

  • LACNICs Registrierungs-API-Seite verweist für die aktuellste v3-Dokumentation auf Postman. Ihre eigene Tabelle beschreibt Änderung und Entfernung dennoch unter /rpki/roas/{serialNumber}.
  • Die verlinkte Sammlung verwendet organizationId: GET, Anlegen und PUT beziehen sich auf die Liste der Organisation, wobei PUT die vorhandene Liste durch eine aktualisierte Version ersetzt.
  • Ein vollständiger Sollzustand kann atomar und idempotent sein. Öffentlich nachvollziehbar wird er durch Basisversion, beabsichtigten Diff, Preflight, atomaren Ausgang und eine Korrekturverknüpfung.

Auf der Seite zur Registrierungs-API ordnet LACNIC die Dokumente selbst. Für Version 3 liege die aktuellste Beschreibung in Postman. Auch /lacnic/v3/info leitet auf das veröffentlichte Dokument weiter. Ein Integrator soll also nicht bei einer alten PDF stehen bleiben, sondern der ausführbaren Sammlung folgen.

Die Endpunkttabelle auf derselben Seite vermittelt trotzdem ein objektbezogenes Modell. Unter /rpki/roas werden ROAs erstellt und abgefragt. Änderung und Entfernung hängen /{serialNumber} an. Die Seriennummer begrenzt den Auftrag: Dieser Datensatz soll sich ändern, über die übrigen wird nichts gesagt.

In API Registro v3 Prod ist die Organisation die Grenze. GET und POST liegen unter /lacnic/v3/rpki/roas/{organizationId}. PUT verwendet denselben Pfad und soll die vorhandene Liste durch eine aktualisierte Version ersetzen. Widerrufe werden als Liste an /lacnic/v3/rpki/roas-delete/{organizationId} gesendet.

Damit wechselt nicht nur der Bezeichner. Die Website beschreibt ein Element, die Sammlung einen gesamten Zustand. Bei einem Zustand kann auch ein fehlendes Element Teil der Anweisung sein.

Warum ein Sollzustand die richtige Wahl sein kann

Die vollständige Liste ist für Automatisierung attraktiv. Ein Client liest, berechnet und sendet ein konsistentes Ziel. Der Server kann alle Einträge zusammen validieren und atomar übernehmen. Bei einer Folge einzelner Befehle kann ein Fehler nach mehreren erfolgreichen Änderungen einen Zwischenzustand hinterlassen, den der Client erst aufwendig erkennen und reparieren muss.

Zudem lässt sich derselbe Sollzustand wiederholen. Geht nur die Antwort verloren, kann ein erneutes PUT zum gleichen Ergebnis konvergieren. Für IPAM-Systeme und periodische Routing-Security-Abgleiche ist diese deklarative Form oft verständlicher als eine Warteschlange kleiner Mutationen.

Die öffentliche Sammlung zeigt nicht alle denkbaren Schutzmechanismen. LACNIC könnte Schreibvorgänge pro Organisation serialisieren, interne Revisionen vergleichen, Konflikte verwerfen, eine geschützte Historie führen oder angemeldeten Nutzern eine Vorschau bieten. Für diese Untersuchung wurde kein authentifizierter Aufruf ausgeführt und kein ROA verändert. Aus einem nicht dokumentierten Feld folgt nicht, dass die Produktion es intern nicht kennt.

Die belastbare Beobachtung ist enger: Der öffentliche Vertrag zeigt nicht, auf welchen gelesenen Zustand sich die vollständige Ersetzung bezieht.

Eine alte Liste kann Unwissen in Löschabsicht verwandeln

Zwei berechtigte Systeme können eine Organisation verwalten. Das erste liest die Liste, um einen neuen Präfix einzutragen. Das zweite hatte früher gelesen und bereitet eine Änderung von maxLength an einem anderen ROA vor. Beide lokalen Listen sind für sich korrekt.

Nach dem ersten PUT enthält der Registry-Zustand den neuen Eintrag. Sendet das zweite System anschließend seine ältere Gesamtliste, muss der Server zwischen mehreren Regeln wählen. Er kann wegen einer veralteten Basis ablehnen, neu lesen lassen, kontrolliert zusammenführen oder die später gesendete Liste vollständig übernehmen. Die geprüften Beispiele sagen nicht, welche Regel gilt.

In den öffentlichen Request- und Response-Feldern wurde kein ETag, If-Match, Revisionstoken, Basislisten-Hash oder vergleichbare Vorbedingung gefunden. Auch dry-run, preview und erwarteter Diff fehlen. Das GET-Beispiel gibt eine nackte Liste zurück; beim Update-Beispiel sind weder Response-Header noch -Body dokumentiert.

Das belegt keinen verlorenen Schreibvorgang. Es belegt eine Dokumentationsgrenze. Wer den Client ohne Produktionsversuch baut, erfährt nicht, wie eine veraltete Gesamtliste erkannt oder behandelt wird.

ROAs machen diese Frage folgenreich. RFC 9582 bindet IP-Ressourcen an eine Origin-AS und kann eine maximale Präfixlänge enthalten. RFC 9319 erläutert, weshalb maxLength die Abdeckung spezifischerer Ankündigungen verändert.

Ein hinzugefügter, engerer oder fehlender ROA verändert die Belege, die eine Route-Origin-Validierung auswertet. Daraus folgt nicht, dass LACNIC die Entscheidung eines Routers steuert. Repository, Validator und Netzwerk bleiben getrennte Empfänger. Die Registrierungs-API muss nur ihren eigenen Schritt präzise nachweisen — aber genau diesen Schritt.

Eine ausführbare Definition statt paralleler Wahrheiten

Der erste Baustein ist eine gemeinsame, versionierte Definition für Website-Tabelle, /info-Ziel und Postman-Sammlung. Wenn das aktuelle Update eine organisationsweite Listenersetzung ist, muss die Kurztabelle das sagen. Besteht der Seriennummernpfad weiter, muss seine Rolle als Einzeloperation, Kompatibilität oder Übersetzung in einen Mengenauftrag beschrieben werden.

Die Postman-Metadaten enthalten ein Veröffentlichungsdatum im Juni 2023. Das ist kein verifiziertes letztes Änderungsdatum. Abgerufen wurde der aktive Tag latest. Ein Vertrag sollte seine Autorität nicht aus Datumsvermutungen beziehen, sondern auf allen Flächen dieselbe Versionskennung tragen.

Als Nächstes braucht GET eine Basisidentität: ETag, opake Revision oder kanonischer Hash. PUT bedeutet dann: Ersetze nur, wenn die aktuelle Liste noch dieser Basis entspricht. Ist sie weitergelaufen, garantiert die Konfliktantwort, dass nichts verändert wurde.

Ein Preflight macht die Absicht sichtbar. Er zeigt Hinzufügungen, Änderungen und Entfernungen mit Präfix, Origin-AS und maxLength. Ein durch unvollständige Serialisierung verschwundener Eintrag erscheint vor dem Schreiben als Entfernung. Auch Validierungsfehler und veraltete Basis werden vor der Mutation festgestellt.

Schließlich erhält der Versuch eine Operations-ID. Vertragsversion, akzeptierte Basis, resultierende Zustandskennung und atomarer Ausgang gehören zusammen. Nach einem Timeout kann derselbe Vorgang abgefragt werden. Eine spätere Korrektur verweist auf den ersetzten Vorgang und radiert dessen Erklärung nicht aus.

Vertragselement Geschlossene Frage
Pfad- und Schemaversion Welche Schreibsemantik galt?
Organisation und Basisidentität Welchen Zustand hatte der Client gesehen?
Add/Change/Remove-Diff Welche Wirkung sollte die Gesamtliste haben?
Preflight Wurden Fehler und Veraltung vorab erkannt?
Atomare Operation und Ergebnis Wurde der Übergang angenommen, verworfen oder nur erneut abgefragt?
Korrekturzeiger Welche spätere Entscheidung ersetzte welche frühere?

Eine solche Quittung muss keine persönlichen Namen, API-Schlüssel oder internen Sicherheitskontrollen veröffentlichen. Schema und Garantien sind öffentlich; der detaillierte Nachweis bleibt bei der berechtigten Organisation. Die Forderung ist nicht mehr Verwaltung, sondern eine kleinere, überprüfbare Grenze um den tatsächlich ausgeführten Übergang.

LACNIC ermöglicht es, ROAs zu pflegen und fehlerhafte Autorisierungen zu korrigieren. Die API macht diesen Prozess skalierbar. Damit Skalierung nicht zur stillen Mehrdeutigkeit wird, sollten Wegweiser und ausführbarer Vertrag dasselbe Objekt benennen. Und wenn dieses Objekt die ganze Liste ist, sollte jede neue Liste beweisen, welche alte sie kennt.

Quellen