Zusammenfassung

  • Die öffentliche NIR-API-Dokumentation von APNIC zeigt einen asynchronen Aufruf an /nir-delegations/asn, beschreibt ihn aber als Delegation aus einem NIR-Pool und nicht als Nachweis für die später geplante Direktdelegation.
  • Im September 2024 waren Änderungen am Kernregister und an der NIR API in Arbeit; im Dezember befand sich „NIR ASN Direct Assignments“ in der abschließenden Qualitätssicherung. Der aktuelle Eintrag für 2025 hat weder Zieltermin noch Changelog.
  • Ein knapper Release- und Prüfnachweis könnte Schema, Umstellungszeitpunkt, teilnehmende NIRs, Altbestände und den Abgleich von Whois und RDAP verbinden, ohne Antragsunterlagen offenzulegen.

Wer ein System betreibt, braucht eine Anleitung. Wer später eine Registerentscheidung nachvollziehen muss, braucht etwas anderes: einen Beleg dafür, welche Fassung des Systems zu welchem Zeitpunkt maßgeblich war. Bei APNIC lässt sich die erste Art von Wissen finden. Die zweite muss aus mehreren Dokumenten rekonstruiert werden.

Die Dokumentation der Nballs? Actually must correct: NIR API. (Oops don't include English self correction.) Need patch text clean. We must ensure no typo. Let's produce entire German carefully.

Die Dokumentation der NIR API erklärt, dass Nationale Internet-Register die Registrierungsdaten ihrer Unterkonten verwalten können. Ein Tutorial zeigt den Aufruf /nir-delegations/asn. Vorher müssen Kontaktdaten hinterlegt werden, weil daraus Teile der Einträge in Whois und RDAP entstehen. Schreibvorgänge laufen asynchron: Die erste Antwort verweist auf eine Aufgabe, deren späterer Zustand im Beispiel SUCCESSFUL lautet. Für Wiederholungen nach einem Verbindungsabbruch unterstützt die API eine Idempotency-Key; derselbe Auftrag soll dadurch nicht zweimal ausgeführt werden.

Das ist eine brauchbare Betriebsbeschreibung. Sie sagt, welche Nachricht ein Client sendet und wie er deren Verarbeitung verfolgt. Sie sagt nicht, welches institutionelle Modell hinter dem Endpunkt lag, als eine bestimmte ASN-Delegation vorgenommen wurde.

Derselbe Pfad kann eine andere Regel ausführen

Der Wortlaut des Tutorials ist bemerkenswert. Es beschreibt Ressourcen, die aus den Pool-Delegationen eines NIR an ein Unterkonto weitergegeben werden. APNICs Produktfahrplan beschreibt dagegen „NIR ASN Direct Assignments“: ASN sollten direkt an Inhaber von NIR-Konten delegiert werden; die Funktion sollte im Register entwickelt und über MyAPNIC sowie die NIR API angeboten werden. Das erklärte Ziel war eine höhere Konsistenz und Gültigkeit der Daten.

Möglicherweise führt der dokumentierte Endpunkt heute genau diese neue Funktion aus. Möglicherweise blieb seine Adresse stabil, während APNIC die Herkunft des ASN oder die interne Buchungslogik änderte. Vielleicht zeigt das Tutorial noch den vorherigen Poolpfad. Oder „direkt“ bezeichnet lediglich das unmittelbare Schreiben in das APNIC-Kernregister, nicht die Abschaffung jeder NIR-bezogenen Reserve. Die veröffentlichten Unterlagen entscheiden diese Frage nicht.

Daraus folgt ausdrücklich nicht, dass APNIC die Funktion nicht bereitgestellt hat. Ein dokumentierter Endpunkt ist ein Beleg für eine technische Oberfläche. Er ist kein datierter Beleg dafür, welche Produktänderung in dieser Oberfläche steckt. Gerade gute APIs behalten ihre URLs bei, wenn sich interne Abläufe verändern. Deshalb muss die Release-Geschichte an anderer Stelle stabiler sein als der Pfadname.

Die öffentliche Spur endet nach dem finalen QA

Das Vorhaben lässt sich über mehrere Berichtszeitpunkte verfolgen. Im September 2024 meldete APNIC laufende Arbeiten am Kernregister und an der NIR API. Im Dezember war die direkte ASN-Zuweisung für NIR-Konten in der finalen Qualitätssicherung. In den Anfang 2025 veröffentlichten Unterlagen stand das Vorhaben weiterhin unter den laufenden Zielen.

Der aktuelle Fahrplandatensatz ordnet es dem Jahr 2025 und dem Registry-Team zu und nennt ARMS und MyAPNIC als betroffene Produkte. Die Beschreibung ist noch vorhanden. Doch das Zielfeld ist leer, und auch das Änderungsprotokoll enthält keinen Eintrag.

Der APNIC-Jahresbericht 2025 formuliert, die vierteljährlichen Ziele des Produktfahrplans seien erreicht worden. Er hebt mehrere Ergebnisse hervor: geänderte Whois-Autorisierung, RPKI Signed Checklists und einen Proof of Concept für die RDAP-Neuarchitektur. „NIR ASN Direct Assignments“ wird im vollständig erfassten Bericht nicht genannt.

Ein fehlender Name ist keine Absage. Ein leeres öffentliches Changelog beweist nicht, dass intern keine Freigabeakte existiert. Eine Anleitung unter einer Testbed-Domain belegt keine produktive Transaktion. Die belastbare Aussage ist enger: Die Öffentlichkeit erhält keine gemeinsame Kennung, die das finale QA mit einer produktiven Version, einem Umstellungsdatum und einem Einführungsumfang verbindet.

Jedes Dokument erfüllt für sich einen Zweck. Der Fahrplan beschreibt Absicht. Der Bericht nennt den Arbeitsstand. Das Tutorial zeigt die Form des Aufrufs. Problematisch wird es erst beim Verbinden. Der Leser nimmt an, dass ähnliche Bezeichnungen dieselbe Auslieferung meinen. In einem Register, dessen Einträge Rechte, Pflichten und technische Identität abbilden, sollte dieser Join nicht von sprachlicher Ähnlichkeit abhängen.

SUCCESSFUL ist ein Transaktionszustand

Ein erfolgreicher Task besagt zunächst, dass der Dienst einen Auftrag abgearbeitet hat. Er beantwortet nicht, aus welchem Pool das ASN kam, wer die Berechtigung prüfte, welche Schemaversion die Felder validierte oder ob die resultierenden Ansichten in Whois und RDAP exakt übereinstimmten. Auch die Gebühren- und Kontobehandlung ist nicht Bestandteil dieses einen Zustands.

Das ist kein Fehler des Taskmodells. Asynchrone Schnittstellen brauchen eindeutige, kleine Zustände. Die Überforderung beginnt, wenn dieser Transaktionsbeleg zugleich als Release-, Richtlinien- und Registerbeleg gelesen wird.

Ein ASN identifiziert ein autonomes System, das Routinginformationen nach einer eigenen Richtlinie austauscht. Nach APNICs aktueller Ressourcenrichtlinie kann eine Organisation ein ASN bei APNIC oder beim zuständigen NIR beantragen. Jede Zuweisung muss öffentlich in der Whois-Datenbank von APNIC oder des betreffenden NIR registriert werden. Wird ein ASN für einen Kunden beantragt, bleiben Qualifikation, Pflege des Eintrags sowie Rückgabe oder Transfer bei einem Providerwechsel zusätzliche Teile der Kette.

Die API-Operation verbindet somit eine lokale Antragsprüfung, eine regionale Ressource, ein Konto, öffentliche Kontaktdaten und eine weltweit sichtbare Routingkennung. Eine direkte Buchung im Kernregister kann Übertragungsfehler und Doppelpflege verringern. Gleichzeitig wird wichtiger, nachvollziehen zu können, welcher Akteur an welcher Stelle entschied und welche Fassung der Software diese Entscheidung in Registerzustand verwandelte.

Die Idempotency-Key schützt dabei vor einer doppelten Ausführung. Sie schützt nicht vor einer falschen Zuordnung der Semantik. Ein Auftrag kann genau einmal unter einer alten Regel ausgeführt werden. Ein NIR kann bereits migriert sein, während ein anderer noch den alten Pfad nutzt. Der Task kann erfolgreich sein und dennoch eine spätere Korrektur der öffentlichen Projektion erfordern. Ausführungssicherheit und Regelklarheit sind zwei getrennte Kontrollen.

Direkt im Register heißt nicht ohne NIR

APNICs NIR-Rahmen soll Registrierungsdienste in lokaler Sprache und im jeweiligen institutionellen Umfeld ermöglichen. NIRs tragen Verantwortung für die Einhaltung der anwendbaren Regeln und dürfen ergänzende lokale Vorgaben erlassen, solange sie regionalen und globalen Regeln nicht widersprechen. APNIC muss zugleich direkte Mitgliedschaft offenhalten. Selbst eine Organisation mit beiden Mitgliedschaften kann Ressourcendienste jeweils nur aus einer Quelle beziehen.

Eine direkte Buchung in APNICs Register muss daher keine Zentralisierung der Antragsentscheidung bedeuten. Der NIR kann Ansprechpartner, Prüfer und Dienstleister bleiben, während seine genehmigte Entscheidung ohne Zwischenbestand oder manuelle Zweiteingabe in den regionalen Zustand gelangt. Genau darin könnte der Qualitätsgewinn liegen.

Damit dieser Gewinn prüfbar ist, muss „direkt“ zerlegt werden. Bezieht sich der Begriff auf den Herkunftspool, auf den Datenbankzugriff, auf den Genehmigungsakt, auf die Mitgliedschaftsbeziehung oder auf mehrere dieser Ebenen? Wurden Altbestände in Unterkonten überführt? Blieb ein Poolmodell parallel aktiv? Wurde die Umstellung für alle NIRs gleichzeitig vorgenommen? Eine Release-Notiz könnte diese Fragen beantworten, ohne den eigentlichen Antrag öffentlich zu machen.

APNICs eigene IPv4-Geschichte zeigt, weshalb diese Genauigkeit nötig ist. In einem Bericht von 2019 erklärte APNIC, dass NIR-Zuteilungen seit 2004 aus dem gemeinsamen regionalen IPv4-Pool kamen und direkt im APNIC-Register erfasst wurden, statt dem älteren Konföderationsmodell zu folgen. Historische Blöcke bestanden weiter. Spätere Abstimmungen korrigierten Zuteilungsdaten, Inhaberidentitäten und Transfers.

Diese IPv4-Entwicklung ist kein Beleg für die ASN-Implementierung. Sie zeigt vielmehr, dass Poolherkunft, Registerabbild und Dienstverantwortung getrennt verändert werden können. Wer das Wort „direkt“ aus der einen Reform in die andere überträgt, benötigt eine ausdrückliche Versionsdefinition.

Die öffentliche Prüfung hat einen anderen Nenner

Parallel betreibt APNIC ein Programm zur Überprüfung von Ressourcendelegationen. Dazu gehören Datenanalysen, Stichproben, Prozess- und Kontoprüfungen, Unterstützung der NIRs und eine geplante Überarbeitung ihrer Vereinbarungen. Im zweiten Quartal 2026 waren die Überprüfungen für JPNIC, TWNIC und KRNIC abgeschlossen; andere liefen weiter.

Der öffentlich beschriebene Hauptumfang ist jedoch eindeutig: zehn Jahre IPv4-Delegationen und -Transfers. Diese Ergebnisse sind kein Nachweis für die Einführung des ASN-Pfads. Sie liefern weder eine Zahl direkter ASN-Operationen noch eine Liste teilnehmender NIRs oder eine Fehlerquote der neuen Schnittstelle. Ebenso wenig beweist der enge öffentliche Umfang, dass APNIC intern keine ASN-Kontrollen hat.

Es bleiben zwei nicht verbundene Prüfebenen. Die API erzeugt einen Taskbeleg für eine einzelne Operation. Das Prüfprogramm bewertet einen historischen IPv4-Bestand. Dazwischen liegt eine ASN-Produktänderung, deren Release-Identität öffentlich nicht festgeschrieben ist.

Ein kleiner Nachweis genügt

APNIC müsste keine Mitgliederdossiers, Zugangsdaten oder internen Prüfanmerkungen veröffentlichen. Ein Release- und Prüfnachweis könnte mit einem unveränderlichen Projektcode, API- und Schemaversion, produktivem Umschaltzeitpunkt, Rollback-Status und einer Definition der neuen Delegationssemantik beginnen.

Danach käme der Einführungsumfang: beteiligte NIRs, stufenweise oder gemeinsame Aktivierung, Fortbestand des Poolpfads und Abschalttermin alter Verfahren. Ein Migrationsabschnitt würde nennen, welche Gruppen bestehender ASN-Datensätze in neue Unterkonten überführt wurden, welche bewusst außerhalb blieben und wie Ausnahmen behandelt wurden.

Schließlich reichen aggregierte Kontrollen für einen begrenzten Zeitraum: versuchte, erfolgreiche, abgelehnte, rückgängig gemachte und abgestimmte Vorgänge; Übereinstimmung zwischen Kernregister, Whois und RDAP; durch Idempotenz abgefangene Wiederholungen; offene Abweichungen. Kein Antragsteller muss dabei sichtbar werden.

Der entscheidende Gewinn liegt in der Trennung. Release-Wahrheit sagt, welche Regeln bereitgestellt wurden. Transaktionswahrheit sagt, was ein Auftrag tat. Zustandswahrheit sagt, was das öffentliche Register heute zeigt. Erst gemeinsame Versionen, Zeitangaben und Verweise machen aus drei plausiblen Dokumenten eine belastbare Kette.

Quellen