Zusammenfassung

  • Im Juni 2024 erklärte ARIN, nach Annahme eines gemeinsamen IETF-Standards Geofeed-Unterstützung in RDAP, ARIN Online und Reg-RWS umzusetzen. Der Vorschlag solle bis zu Entwicklung und Bereitstellung Open bleiben.
  • RFC 9877 erschien im Oktober 2025 als Standards Track. Er definiert geofeed1, rel=geofeed und application/geofeed+csv und schafft damit ein maschinenlesbares Leistungsversprechen.
  • Am 12. September 2026 führte ARIN den Vorschlag 2024.10 weiterhin als Open. Die produktive RDAP-help-Antwort enthielt kein geofeed1; ein gezielt ausgewähltes Netzobjekt trug seine Geofeed-URL weiterhin nur in Registration Comments.
  • Das beweist weder technische Untätigkeit noch eine flächendeckende Abwesenheit. Es begründet einen engeren Anspruch: einen datierten Nachweis für Auslöser, Produktoberflächen, Altbestandsmigration, Massenzugriff, Datenschutz, Tests und Rücknahme.

Wenn eine Abhängigkeit endet, beginnt die Übergabe

Auf einen gemeinsamen Standard zu warten, kann gute Ingenieurarbeit sein. Fünf RIR-spezifische Formate würden die Entwicklung beschleunigen, aber die Kosten als dauerhafte Sonderfälle an jeden RDAP-Client weiterreichen. Koordination vermeidet genau diese Schulden.

Eine öffentlich benannte Abhängigkeit ist jedoch keine zeitlose Zustandsbeschreibung. Vor Abschluss der Norm lautet die Frage, welche Semantik noch verhandelt wird. Danach lautet sie, welche Oberfläche diese Semantik implementiert und wie Nutzer den Übergang prüfen können.

ACSP Suggestion 2024.10 wurde am 3. Juni 2024 eingereicht. Gewünscht war ein optionales Geofeed-Attribut für ARIN-Netzobjekte. Die damalige Praxis bestand darin, eine Zeile wie Geofeed [URL] in ein Freitextfeld zu schreiben. Ein Mensch erkennt die Absicht meist. Software muss Wörter durchsuchen, eine URL isolieren und entscheiden, ob sie tatsächlich als kanonischer Verweis gemeint war.

ARIN antwortete am 7. Juni mit einer konkreten Kette. Die fünf RIR arbeiteten in der IETF an einer RDAP-Erweiterung. Sobald der Standard angenommen sei, werde ARIN die Änderung in RDAP implementieren und ARIN Online sowie Reg-RWS um die nötige Funktion ergänzen. Zudem laufe Arbeit an einem RIR-übergreifend einheitlichen RDAP-Massenformat. Bis Entwicklung und Bereitstellung solle der Vorschlag offenbleiben.

Die Antwort enthielt kein Datum und definierte „angenommen“ nicht. Gemeint sein konnten IESG-Zustimmung, RFC-Veröffentlichung, ein NRO-Profil oder ein späterer Betriebsbeschluss. Daraus folgt keine belastbare Frist und erst recht kein Beweis für Verzug. Es folgt aber die Pflicht, nach Eintritt des externen Ereignisses den tatsächlichen nächsten Engpass zu benennen.

RFC 9877 schafft ein begrenztes, prüfbares Versprechen

RFC 9877 wurde im Oktober 2025 als Standards Track veröffentlicht. Er verpflichtet nicht jeden RDAP-Server zur Unterstützung von Geofeeds. Er legt fest, wie ein Server spricht, der sie unterstützt.

Die Linkrelation geofeed benennt den Zweck des Verweises. Der Medientyp application/geofeed+csv beschreibt die Zieldatei. Die Erweiterungskennung geofeed1 signalisiert, dass ein Server Geofeed-URLs für seine IP-Netzobjekte vorhält. IANA hat die Kennung in das Verzeichnis der RDAP Extensions aufgenommen.

Verwendet ein Server geofeed1, muss die Kennung im Array rdapConformance der help-Antwort und in lookup- oder search-Antworten mit IP-Netzobjekten stehen. Besitzt der Server für ein Objekt eine URL und darf er sie ausgeben, muss der entsprechende Link enthalten sein.

Damit bekommt auch das Fehlen eines Links einen Rahmen. Nach der serverweiten Erklärung darf der Client die Abwesenheit innerhalb der RFC-Regeln deuten. Ohne Erklärung bedeutet sie zunächst nur, dass diese eine Antwort keinen solchen Link lieferte.

Der RFC lässt bewusst eine schwächere Variante zu. Ein Server kann registrierte Linkrelation und Medientyp verwenden, ohne geofeed1 zu erklären. RDAP erlaubt registrierte Relationen auch in normalen Antworten. Die Kennung fügt eine Aussage über die Fähigkeit des Servers hinzu; sie ist nicht die einzige zulässige Quelle eines typisierten Links.

Diese Nuance verhindert eine falsche Totalbehauptung. Die help-Antwort kann zeigen, ob ARIN die Erweiterung erklärt. Sie kann nicht beweisen, dass nirgends ein standardisierter Link vorkommt.

Zwei Live-Antworten, zwei eng begrenzte Befunde

Die am 12. September 2026 erfasste RDAP-help-Antwort von ARIN nannte Basis-RDAP, NRO-Profil, CIDR, origin-AS, RIR-Suche und weitere Erweiterungen. geofeed1 fehlte.

Der sichere Befund lautet: Diese Antwort erklärte die RFC-9877-Erweiterung zu diesem Zeitpunkt nicht. Sie sagt nichts über Entwicklungszweige, Pilotprogramme, unveröffentlichte ARIN-Online-Formulare oder weitere Koordinationsschritte aus. Ein Protokollendpunkt ist kein Blick in den internen Arbeitsplan.

Die ausgewählte Antwort für 154.54.100.0/22 macht den Altbestand sichtbar. In Registration Comments steht Geofeed ai.net/geofeed.csv. Auch dort fehlt geofeed1; die Links tragen self, alternate und up, nicht rel=geofeed.

Das Objekt wurde gewählt, weil es die im Vorschlag beschriebene Konvention zeigt. Es ist keine Zufallsstichprobe. Es erlaubt weder eine Häufigkeitsschätzung noch den Ausschluss typisierter Links in anderen Objekten. Auch die Aktualität oder Richtigkeit der Zieldatei lässt sich daraus nicht ableiten. Ein Registry-Verweis ist ein Entdeckungsweg, kein Beweis für Standort, Routing, Identität oder Rechtsposition.

Der Befund reicht dennoch für die zentrale Produktfrage: Wie soll ein neuer strukturierter Pfad mit vorhandenen Kommentaren umgehen?

Eine Formulierung von ARIN 57 verlangt Abgleich

Beim ARIN 57 im April 2026 nannte der Engineering Report RDAP-Verbesserungen für Geofeed und RPKI Directory Services. Die Arbeit gehe „gerade durch die IETF“. Zu diesem Zeitpunkt war RFC 9877 seit ungefähr sechs Monaten veröffentlicht.

Das kann vernünftige Gründe haben. Vielleicht ging es um ein verwandtes Dokument, ein NRO-Profil, Implementierungsabsprachen oder eine nicht aktualisierte Folie. Das Transkript belegt keine Stilllegung der Arbeit und keinen privaten Projektstatus.

Es belegt nur, dass die beiden öffentlichen Zeitangaben nicht von selbst zusammenpassen. Eine Korrektur könnte den RFC als abgeschlossen und die aktuelle Abhängigkeit als Profil, Migration, Datenschutzprüfung oder Produktpriorität benennen. Das wäre keine Schuldanerkennung, sondern saubere Versionspflege der institutionellen Erklärung.

Die eigentliche Komplexität steckt im Altbestand

ARIN Online ist die menschliche Schreiboberfläche. Reg-RWS ist die automatisierte Schreiboberfläche. RDAP publiziert. Ein Massenprodukt bedient Nutzer, die nicht jedes Netzobjekt einzeln abrufen sollen. Eine Migration entscheidet über bereits vorhandene Kommentare.

Diese Teile können verschiedene Zustände haben. Das Webformular kann vor Reg-RWS verfügbar sein. Einzelne Antworten können eine registrierte Relation liefern, bevor help die Erweiterung erklärt. Ein Bulk-Snapshot kann zeitversetzt folgen. Eine einzige Launch-Meldung würde diese betrieblich wichtigen Unterschiede verdecken.

Freitext lässt sich nicht gefahrlos per regulärem Ausdruck befördern. Manche Kommentare enthalten genau eine klare URL. Andere enthalten zwei Adressen, erläuternden Text, ein veraltetes Ziel oder lediglich das Wort Geofeed. Eine automatische Übernahme würde altem Text strukturierte Autorität verleihen, die sein Autor nicht ausdrücklich vergeben hat.

Vollständiges Nichtstun erzeugt ebenfalls Kosten. Zwei Entdeckungswege bleiben bestehen. Ein Client folgt dem Link, ein anderer parst den Kommentar, beide speichern unterschiedliche Kopien.

Die Migration sollte mit einem Inventar beginnen: eindeutig, mehrdeutig, mehrfach, unerreichbar und nicht einschlägig. Wo sich der Autoritätsstatus ändert, bestätigt der Ressourcenhalter. Ursprungstext und Entscheidung bleiben erhalten. Die Priorität zwischen Kommentar und Feld wird definiert; eine fehlerhafte Beförderung kann zurückgenommen werden. Spezifischere Netzobjekte gehören in die Tests, damit ein breiter Verweis keine engere Aussage verdrängt.

Authentische Herkunft ist keine gemessene Geografie

RFC 9632 beschreibt die Entdeckung über RPSL und eine optionale Authentisierung mittels RPKI. Diese kann belegen helfen, dass der Herausgeber für die abgedeckten Ressourcen autorisiert ist. Sie misst nicht den Standort von Geräten, Nutzern oder Verkehr.

Vier Aussagen brauchen vier Subjekte. Der Ressourcenhalter liefert die URL. ARIN veröffentlicht den Verweis. Eine optionale Signatur stärkt die Herkunft. Der Verbraucher entscheidet über die Nutzung der Ortsangabe. Link und Signatur machen aus der Behauptung keine physische Beobachtung.

Maschinenlesbarkeit vergrößert die Reichweite. Das ist ihr Zweck, erhöht aber die Bedeutung von Cache-Alter, Rücknahme, Spezifität und Datenschutz. RFC 9632 rät davon ab, gewöhnliches RDAP zur Massenabholung zu verwenden. ARINs Hinweis von 2024 auf ein gemeinsames Bulk-Format erkannte die Trennung zwischen Transaktion und Distribution bereits an.

Ein Massenprodukt braucht Snapshot-Zeit, Umfang, Integritäts-Hash, Aufbewahrung und Löschverhalten. Sonst kann ein Nutzer eine alte Kopie nicht von einer weiterhin gültigen Veröffentlichung unterscheiden.

Die Felder eines belastbaren Übergabenachweises

Zuerst steht der Auslöser: RFC 9877, relevante Errata, erforderliche NRO- oder RIR-Profile und das Datum, an dem ARIN die Bedingung von 2024 als erfüllt betrachtete. Verbleibende Abhängigkeiten erhalten Namen und Geltungsbereich.

Danach folgt eine Produktmatrix. ARIN Online, Reg-RWS, RDAP help, Netz-lookup/search und Bulk-Ausgabe bekommen definierte Zustände wie Entwurf, Test, verfügbar, Standard, veraltet oder abgeschlossen. Erwartete Kennung, Relation und Medientyp sowie ein sicherer positiver und negativer Testfall gehören dazu.

Die Schreibregeln nennen berechtigte Rollen, URL-Schema, Normalisierung, Entfernung, Vorschau und Verhalten bei vorübergehender Unerreichbarkeit. Ein kurzer Ausfall des Zielservers darf nicht unbemerkt eine Entscheidung des Halters löschen.

Das Migrationsbuch veröffentlicht aggregierte Kandidatenzahlen und Entscheidungsklassen, nicht die einzelnen URLs. Es zeigt, wann eine Bestätigung nötig ist, welche Quelle Vorrang hat und wie ein Fehler zurückgerollt wird.

Die Zeiten bleiben getrennt: Annahme der Änderung, Rücklesung in ARIN Online, Rücklesung in Reg-RWS, RDAP-Sichtbarkeit und Aufnahme in den Bulk-Snapshot. Eventual Consistency ist beherrschbar, wenn ihr Fenster dokumentiert ist.

Schließlich kommen Tests und Governance: gültiger Link, fehlender Link, fehlerhafte URL, spezifischeres Objekt, mehrere Sprachen, Unterdrückung und Löschung; Deployment- und Rollback-Datum; Erklärung der ARIN-57-Formulierung; abschließender ACSP-Status mit Link auf die Belege.

Der Nachweis begrenzt Behauptungen auf beiden Seiten

Ohne Nachweis können Kritiker ein fehlendes geofeed1 als Beweis fehlender Arbeit lesen. ARIN kann internen Fortschritt mit öffentlicher Fertigstellung verwechseln. Beide machen aus einem Zustand einen Stellvertreter für einen anderen.

Ein Übergabenachweis ermöglicht eine schmale, starke Aussage: Diese Oberflächen unterstützen an diesem Datum diese Elemente nach diesen Regeln. Nutzer können dieselbe Grenze prüfen. Open bleibt ein Prozessstatus, ein Objekt bleibt ein Beispiel, eine URL bleibt ein Hinweis, eine Signatur bleibt Herkunftsschutz.

Vielleicht wartet ARIN tatsächlich auf ein weiteres Profil. Vielleicht ist ein Teil bereits fertig und nur die Dokumentation hinkt nach. Klarheit verlangt keine vorgegebene Antwort. Sie verlangt, dass Norm, Produkt und öffentlicher Datensatz nicht länger auf getrennten Uhren laufen.

Quellen