Zusammenfassung

  • Der offizielle AFRINIC-Datenbankdump vom 30. August 2026 enthält 3.790 RPSL-Objekte mit der exakten Form remarks: Geofeed HTTPS-URL; 3.573 davon sind die für RFC 9632 relevanten Adressobjekte inetnum und inet6num.
  • Das Remarks-Verfahren ist kein Standardverstoß. RFC 9632 definiert es ausdrücklich für Datenbanken ohne geofeed: und verlangt während der Migration Unterstützung für beide Formen.
  • Die aktiven AFRINIC-Schemata führen remarks:, aber kein geofeed:. Im öffentlichen DBWG-Archiv stehen eine Aufforderung zur Aufnahme als Arbeitspunkt, eine Folgenabschätzung und mehrere Nachfragen, jedoch keine später gefundene öffentliche Disposition bis August 2026.
  • Ein begrenzter Migrationsbeleg könnte Status, Schreibrechte, Syntax, Konfliktregeln, Altdaten, WHOIS/RDAP-Abbildung, Authentifizierungs- und Datenschutzgrenzen, Tests sowie Rollback festhalten.

Die Datenbank besitzt längst einen Geofeed-Mechanismus. Sie besitzt nur keinen Datentyp dafür.

Eine exakte Textsuche im offiziellen Dump zählt 3.790 RPSL-Objekte, in denen auf remarks: das groß- und kleinschreibungssensitive Wort Geofeed und eine HTTPS-URL folgen. Das entspricht der Ausweichform aus RFC 9632. Eine objektbezogene Auswertung trennt 3.483 inetnum- und 90 inet6num-Objekte ab. Zusammen ergeben sie 3.573 Adressobjekte.

Die Differenz von 217 verteilt sich auf 168 route, 41 route6, fünf domain, zwei as-set und ein organisation. Die Zeichenfolge ist formal exakt; die Objektklasse liegt außerhalb des Adressobjekt-Kontexts, in dem die RFC die Ermittlung beschreibt.

Das ist keine Liste von 217 Störungen. Es ist ein Lehrstück über freie Textfelder. remarks: kann einen Geofeed-Verweis, einen Supporthinweis, ein Zertifikat oder beliebige Erläuterungen tragen. Operative Bedeutung entsteht durch die Konvention zwischen Eintragendem und Leser. Das Schema selbst kennt diese Bedeutung nicht.

Darum steht 3.573 im Titel. 3.790 misst die Verbreitung der Zeichenfolge über alle RPSL-Klassen. 3.573 misst die Adressobjekte im normativen Ermittlungspfad. Wer beide Zahlen vermischt, ist rechnerisch präzise und sachlich ungenau.

Das Provisorium ist ein Interoperabilitätsvertrag

Die stärkste Verteidigung des heutigen Zustands lautet: Er ist genau für die ungleichzeitige Migration verschiedener Register gebaut.

RFC 9632 erwartet nicht, dass alle RIR-Datenbanken gleichzeitig ein neues Attribut einführen. Fehlt geofeed:, definiert sie die strikte Remarks-Form. Bis alle Produzenten die Unterstützung des Feldes erklärt und die Registranten ihre Objekte umgestellt haben, müssen Verbraucher beide Darstellungen lesen. Ein Client, der AFRINICs Remarks verwirft, weil ein anderes RIR ein eigenes Feld anbietet, würde die vorgesehene Kompatibilität brechen.

Das Verfahren wird ernsthaft genutzt. Die 3.573 Adressobjekte verweisen auf 106 unterschiedliche HTTPS-URLs. Darunter sind 3.461 ASSIGNED PA, 71 ALLOCATED PA, 17 ALLOCATED-BY-RIR, 13 ASSIGNED PI und 11 SUB-ALLOCATED PA. Dass dieselbe URL mehrfach vorkommt, ist plausibel, wenn ein Betreiber mehrere Präfixe in einer Datei beschreibt.

Aus diesen Zahlen folgt nicht, dass jede URL erreichbar, jeder Ort korrekt oder jeder Datensatz von Plattformen übernommen wird. Sie zeigen installierte Nutzung. Eine schlecht vorbereitete Migration könnte reale Interoperabilität zerstören, nur um das Datenmodell sauberer aussehen zu lassen.

Auch institutionelle Vorsicht ist nachvollziehbar. Ein neues Attribut betrifft Update-Authentisierung, Webformulare, Mail-Updates, Bulk-Daten, WHOIS-Clients, RDAP, Validatoren, Dokumentation und Support. Es braucht Regeln für Objekte mit beiden Formen, für alte Varianten und für Verbraucher mit unterschiedlichen Releasezyklen. Aus einer zusätzlichen Schemazeile wird schnell ein dienstübergreifendes Projekt.

Die belastbare Forderung ist deshalb nicht „sofort implementieren“, sondern „den geprüften Zustand und die Entscheidung öffentlich benennen“.

Struktur, Autorität und Wirklichkeit

RFC 9632 sagt ausdrücklich, dass das RIR die Remarks-Form nicht formal prüfen kann. Deshalb lässt sich auch die Empfehlung, höchstens einen Geofeed-Verweis pro Objekt zu führen, dort nicht sauber erzwingen. Ein eigenes Feld könnte HTTPS-Syntax, Anzahl, Duplikate und Konflikte prüfen und den Wert strukturiert exportieren.

Die Abweichungen sind messbar. 3.592 Adressobjekte enthalten bei fallunabhängiger Suche eine Geofeed-ähnliche Bemerkung. 106 Zeilen weichen von der strikten Form ab, etwa durch einen Doppelpunkt, Kleinschreibung oder HTTP. Das beweist nicht, dass jeder Collector diese Varianten ablehnt. Es zeigt, dass ein Textvertrag ohne Schemafehler driften kann.

Ein Feld darf jedoch nicht mehr versprechen, als es prüfen kann. Vier Ebenen bleiben getrennt:

Ebene Möglicher Nachweis Nicht nachgewiesen
Datenbankschema Der Wert ist syntaktisch als Geofeed-Verweis zugelassen Verfügungsgewalt über den Adressraum
HTTPS Der benannte Web-Endpunkt und der Transport sind geschützt Ressourcenautorität des Betreibers
Optionale RPKI-Signatur Die Datei ist mit einem abdeckenden Ressourcenzertifikat verknüpft Richtigkeit jeder Ortsangabe
Operative Pflege Aktualisierung und Plausibilisierung der Ortsdaten Eine zeitlose, vom Register garantierte Geografie

HTTPS authentisiert den Endpunkt, nicht die Zuteilung des IP-Adressraums. Die optionale RPKI-Signatur aus RFC 9632 adressiert einen Teil dieser Lücke. Auch sie garantiert nicht, dass jede Stadt oder jeder Ländercode im Betrieb stimmt oder datenschutzgerecht granular ist.

Das eigene Feld kann also den Zeiger strukturieren, nicht die Welt zertifizieren. Diese Begrenzung schützt AFRINIC vor einer überdehnten Rolle und die Nutzer vor falscher Sicherheit.

Ein bestehender APNIC-Beitrag untersuchte bereits, warum ein authentisierter Link nicht jede Ortsangabe beweist. Hier liegt der exklusive Gegenstand früher: AFRINICs Schema erkennt den Link noch nicht als eigenen Datentyp.

Eine öffentliche Vorgeschichte ohne sichtbaren Abschluss

Am 27. Oktober 2025 schlug ein Teilnehmer der Database Working Group vor, geofeed: einzuführen und Ressourceninhabern die Aktualisierung zu ermöglichen. Er beschrieb Remarks als bisherigen Weg und berichtete für seine PI-Ressourcen von nötiger Hostmaster-Unterstützung.

Am folgenden Tag eröffnete der DBWG-Co-Chair eine zweiwöchige Diskussionsfrist und bat das Personal um eine Folgenabschätzung. Am 14. November stellte er fest, dass kein Widerspruch vorlag, und forderte AFRINIC auf, den Vorschlag als Arbeitspunkt zu behandeln und Umsetzung einschließlich Impact Assessment zu erläutern.

Der Antragsteller fragte am 6. April 2026 nach einem Bericht. Am 16. April bat der Co-Chair erneut um Bestätigung des aktiven Arbeitspunkts und die angeforderte Bewertung. Am 17. April unterstützte ein weiterer Teilnehmer das Anliegen.

Der offizielle Archivindex enthält Nachrichtenmonate Januar, Februar, März, April und August 2026, aber keine Monatsarchive für Mai, Juni oder Juli. In den geprüften Threads bis August erscheint nach dem 17. April kein neuer Geofeed-Betreff.

Die belastbare Aussage ist eng: Im geprüften öffentlichen DBWG-Archiv wurde keine spätere Antwort oder Disposition gefunden. Daraus folgt nicht, dass AFRINIC intern untätig war. Ein Ticket, technische Prüfung, private Kommunikation oder Abhängigkeit kann existieren. Ein Mailarchiv zeigt nicht sämtliche Arbeit.

Was fehlt, ist ein öffentlicher Abschlusszustand für eine öffentliche Bitte: angenommen, verschoben, abgelehnt, ersetzt oder abhängig. Governance verlangt nicht die Annahme jedes Vorschlags. Sie verlangt, dass der Weg vom benannten Anliegen zur benannten Entscheidung nachvollziehbar wird.

Was die 13 PI-Objekte tatsächlich aussagen

Die PI-Erfahrung des Antragstellers ist weder zu verwerfen noch zu verallgemeinern. Im Dump gibt es 13 strikte Geofeed-Adressobjekte mit Status ASSIGNED PI. Alle führen AFRINIC-HM-MNT unter mnt-by; ressourcenspezifische Maintainer erscheinen in tieferen Attributen.

Das passt zu einer Trennung zwischen Schutz des Objekts und Verwaltung spezifischerer Daten. Es belegt nicht alle Supportwege, Authentisierungsregeln oder Ausnahmen. Dreizehn Beobachtungen machen keine universelle Aussage über jeden PI-Inhaber.

Stattdessen braucht es eine Autorisierungsmatrix. Für jede Objektklasse, jeden Status und jede Beziehung von mnt-by und mnt-lower: Wer darf einen Verweis anlegen, ändern, löschen oder berichtigen? Über welche Oberfläche und mit welcher Authentisierung? Wenn Direktschreiben nicht möglich ist, welcher Supportpfad übernimmt und welcher Beleg verfolgt das Ergebnis?

Transparente Rechte bedeuten keine unkontrollierte Selbstbedienung. Sie schaffen gleichzeitig Schutz gegen unbefugte Änderungen und einen sichtbaren Weg zur Korrektur veralteter Angaben.

RDAP trägt den Text weiter, aber nicht seinen Typ

Die AFRINIC-RDAP-Antwort für 160.115.0.0 enthält eine Geofeed-URL in einer allgemeinen Remarks-Beschreibung. Ihre Konformitätsliste nennt rdap_level_0, nro_rdap_profile_0 und cidr0, jedoch weder geofeed1 noch einen strukturierten Geofeed-Link.

RFC 9877 definiert die Relation rel: geofeed und die optionale Erweiterung geofeed1. Ein Server darf solche Links liefern. Kündigt er die Erweiterung an, muss er für vorhandene und veröffentlichbare URLs den entsprechenden Link liefern. AFRINIC kündigt sie im geprüften Beispiel nicht an; ein RFC-Verstoß ist damit nicht belegt.

Offen bleibt eine Strukturierungsoption. Menschen und spezialisierte Parser erkennen die Bemerkung. Ein allgemeiner RDAP-Client kann aus der Konformitätsliste keine strukturierte Geofeed-Fähigkeit ableiten und muss erneut Text interpretieren. Der Wert ist über die Schnittstelle gereist, sein Datentyp nicht.

Ein Entscheidungsbeleg ohne Vorentscheidung

Der kleinste nützliche Beleg umfasst:

  1. ID, Verantwortliche, Aufnahmedatum, Zustand und nächsten Prüftermin;
  2. heutige und angestrebte Schemaversion;
  3. Folgen für Updates, Bulk-Daten, WHOIS, RDAP und Collector;
  4. Schreibrechte nach Klasse, Status und Maintainer-Beziehung;
  5. HTTPS-Syntax, Kardinalität und Fehler;
  6. Koexistenz und Vorrang bei beiden Darstellungen;
  7. Inventar und Umgang mit strikten, abweichenden und klassenfremden Einträgen;
  8. Entscheidung zu geofeed1 und RDAP-Projektion;
  9. klare Trennung von Syntax, HTTPS, RPKI-Autorität und Ortsrichtigkeit;
  10. Datenschutz- und Granularitätshinweise;
  11. Testgruppe, Kompatibilität, Korrektur und Rollback-Auslöser;
  12. Implementierungs- oder Abschlussbeleg mit Version, Datum, Metriken und Ausnahmen.

Ein solcher Beleg kann eine Verschiebung begründen. Er kann Remarks zunächst nur strenger dokumentieren, das Feld ohne automatische Migration einführen oder RDAP später behandeln. Rechenschaft bedeutet nicht, dass der Vorschlag gewinnt. Sie bedeutet, dass Entscheidung und Begründung auffindbar sind.

Ein Register ist dann vertrauenswürdig, wenn es genau sagt, welche Struktur es prüft, welche Behauptung es nur transportiert und welche Wahrheit es nicht garantieren kann. Das eigene Feld wäre keine Ausweitung dieser Autorität. Es könnte ihre Grenze endlich maschinenlesbar machen.