Zusammenfassung

  • AFPUB-2026-ASN-001-DRAFT02 würde für neu angelegte AFRINIC-AS-SETs eine enge, sachgerechte Registerprüfung schaffen: Der Name muss in einer ASN verwurzelt sein, und der Ersteller muss sich mit den Authentifizierungsdaten dieses ASN-Objekts ausweisen. Bei tieferen Namen liegt die Anlegeberechtigung beim Maintainer des unmittelbaren Eltern-Sets. Das kann Registergenauigkeit, Einzigartigkeit, Kontrollnachweis und Routingkoordination schützen. Es beweist nur die Berechtigung zur Namensanlage im AFRINIC-Register, nicht Eigentum an einem Netz, Richtigkeit der Mitglieder, Gültigkeit einer Routingpolitik oder Herrschaft über die betriebliche Realität.
  • Die Grenze ist absolut. AFRINIC ist Buchhalter und Registerführer. Sein Eintrag beschreibt Realität; er schafft sie nicht. Weder Konsens im Richtlinienprozess noch Board, Mitarbeitende oder ein Registration Service Agreement können aus einer technischen Anlegeprüfung Souveränität, Strafgewalt, Ermessensvollzug oder Autorität über laufende Netze herstellen. Bestehende flache Namen bleiben nach dem Entwurf bestehen, andere Register bleiben autonom und Verbraucher wählen ihre Quellen selbst. Für versehentlich gelöschte flache Namen verlangt der Text allerdings Einzelfallausnahmen, ohne Entscheider, Kriterien, Beweisschwelle, Einspruch oder Audit festzulegen. Zum Stichtag 9. August 2026 war außerdem weder die Annahme noch die technische Durchsetzung des Entwurfs belegt.

Die kleine Wahrheit eines hierarchischen Namens

Der gewöhnliche Fall beginnt nicht mit einem politischen Mandat, sondern mit einer Datenbankoperation. Ein Maintainer möchte einen AS-SET-Namen in der AFRINIC Internet Routing Registry anlegen. Ein Netzbetreiber kann diesen Namen später in Peering-Angaben verwenden; ein Resolver kann seine Mitglieder auflösen; ein Werkzeug kann daraus Filter erzeugen. Der Eintrag dient damit einer realen Koordinationsaufgabe. Er ist nützlich, weil andere Akteure ihn lesen können. Er ist nicht die Quelle ihrer Routingentscheidung.

Bei einem flachen Namen wie AS-KUNDEN beweist ein gültiges Maintainer-Passwort, dass jemand eine Objektoperation authentifizieren darf. Der frei gewählte Name sagt aber nicht, zu welcher ASN sein Anspruch gehört. Mehrere voneinander unabhängige IRRs können dieselbe lesbare Zeichenfolge führen. Ein Verbraucher muss dann zusätzlich wissen, aus welcher Quelle das Objekt stammt und welche Kontrollbeziehung hinter seiner Anlage stand.

Der von James Bensley von Inter.link GmbH eingereichte DRAFT02 vom 8. Juni 2026 setzt an genau dieser schmalen Lücke an. Der vorgeschlagene Abschnitt 7.8 verlangt für jeden neuen AFRINIC-AS-SET-Namen eine Hierarchie. Der erste Bestandteil muss AS plus eine ASN sein, die der authentifizierte Ersteller kontrolliert. Der zweite Bestandteil muss ein AS-SET-Name sein, der mit AS- beginnt. AS65000:AS-KUNDEN ist ein Syntaxbeispiel; die Beispielzahl bezeichnet keinen behaupteten Betreiber.

Der Doppelpunkt trennt nicht bloß Zeichenfolgen. Links steht die Wurzel, deren Kontrolle AFRINIC anhand der bei diesem ASN-Objekt hinterlegten Authentifizierung prüfen soll. Rechts beginnt ein Namenszweig. Wer irgendein anderes Maintainer-Konto kontrolliert, aber nicht die Authentifizierung von AS65000, könnte auf dem gewöhnlichen Weg kein neues AS65000:AS-KUNDEN anlegen. Das Register würde damit einen unberechtigten Eintrag zurückweisen, bevor ein Resolver das Objekt liest.

Diese Zurückweisung ist keine Strafe. Sie erklärt weder den Antragsteller noch dessen Netz für illegitim. Sie sagt nur: Für diesen neuen Eintrag ist der verlangte Kontrollnachweis nicht erbracht. Das ist die Arbeit eines Buchhalters. Ein Buchhalter darf eine Buchung ablehnen, deren Zuordnung nicht belegt ist. Er erhält dadurch kein Eigentum am verbuchten Gegenstand und keine Gerichtsbarkeit über dessen Nutzer.

Bei tieferen Namen setzt sich die Kontrollkette fort. Nach RFC 2622 darf der Maintainer der Wurzel-ASN das erste Kind anlegen; über einen weiteren Kindnamen entscheidet der Maintainer des unmittelbaren Eltern-Sets. Soll unter AS65000:AS-KUNDEN beispielsweise AS65000:AS-KUNDEN:AS-WEST entstehen, muss der Eltern-Maintainer die Anlage authentifizieren. Spätere Bestandteile dürfen nach dem Entwurf ASNs oder AS-SET-Namen sein. Auf diese Weise kann eine Organisation Unterstrukturen delegieren, ohne die im Namen sichtbare Herkunftskette aufzugeben.

Die Aussage des Ergebnisses bleibt eng: Zum Zeitpunkt der Anlage erfüllte der Ersteller die für die Wurzel oder den unmittelbaren Elternknoten verlangte Authentifizierung. Der Name ist keine Eigentumsurkunde. Er beweist nicht, dass jedes Mitglied im Set richtig ist. Er sagt nicht, welche Route angenommen werden soll. Er macht aus AFRINIC keinen Schiedsrichter über Peering, Filter oder Geschäftsbeziehungen. Er macht einen Registereintrag nachvollziehbarer.

Registergenauigkeit ist keine Souveränität

Die leitende Wahrheit ist nicht eine Perspektive unter mehreren. Sie ordnet die Belege: Ein Register existiert, um Einzigartigkeit, genaue Aufzeichnungen, Kontrollnachweise, Sicherheitsassertionen und betriebliche Kontinuität zu schützen. Es darf aufzeichnen. Es darf koordinieren. Es darf die Einzigartigkeit seines Namensraums sichern. Es darf nicht herrschen.

Note 72 fasst diese Grenze als Bill of Rights of Uniqueness Coordination. Der Registereintrag beschreibt die betriebliche, rechtliche und wirtschaftliche Wirklichkeit; er erzeugt sie nicht. Der Betreiber hat Anspruch auf ein genaues Buch und auf Kontinuität seines laufenden Netzes. Der Buchhalter darf aus der Nähe zum Buch kein Eigentum, keine geografische Herrschaft und keine Strafgewalt ableiten. Die gemeinsame Schicht bleibt dünn: Einzigartigkeit, Kontrollnachweis, Registergenauigkeit, Sicherheitsassertionen, nachvollziehbare Zustandsänderungen, Auditierbarkeit und Auswege aus einem versagenden System.

Auf DRAFT02 angewandt ist das Ergebnis eindeutig. Eine ASN-verankerte Anlegeprüfung gehört in diese dünne Schicht, weil sie einen objektiven Zusammenhang zwischen Name und Kontrollnachweis herstellt. Sie kann die Genauigkeit des AFRINIC-Registers verbessern und die Routingkoordination erleichtern. Sie darf nicht zum Ausgangspunkt einer umfassenden Aussage werden, wonach AFRINIC die Routingrealität erschaffe, eine Routingpolitik genehmige oder einen Betreiber disziplinieren dürfe.

Note 71 zeigt im Policy Mirror, wie ein Register die Grenze überschreitet: Der Buchhalter beschreibt dann nicht mehr, wer welchen Eintrag kontrolliert, sondern beginnt über zulässige Nutzung, Handel, Geografie oder Sanktion zu urteilen. Bei der hier untersuchten Regel ist diese Unterscheidung besonders wichtig. Die normale Authentifizierungsprüfung kann ihrem engen Zweck entsprechen. Daraus folgt nicht, dass alles, was in einem Richtlinientext steht, zur notwendigen Registerfunktion wird.

Note 65 setzt Running-Code Primacy an die Stelle institutioneller Selbstbestätigung. Ein Entwurf, ein Konsensruf, eine Billigung, eine interne Einschätzung oder eine Vertragsklausel ist noch keine technische Wirklichkeit. Wirklichkeit entsteht hier erst, wenn jeder relevante Anlageweg denselben deterministischen Test tatsächlich ausführt und Betreiber das Ergebnis in ihren eigenen Werkzeugen verwenden. Der Text kann eine Prüfung beschreiben; der laufende Code muss sie durchführen.

Note 64 liefert die Konstruktionsregel: Minimum Initial Specification, Localized Future Decision und Voluntary Adoption. In die gemeinsame Schicht gehören Syntax, Einzigartigkeit und ein lokal verifizierbarer Kontrollnachweis. Bei den Betreibern verbleiben Quellenwahl, Set-Auswertung, Filtererzeugung, Peering und Geschäftsmodell. Eine spätere institutionelle Erklärung kann diese Verteilung nicht umkehren.

Notes 63, 49 und 42 beschreiben denselben Irrtum aus drei Richtungen. Der Buchhalter beginnt für den Olymp vorzusprechen, wenn er das Buch nicht mehr als Dienst an der Realität, sondern die Realität als Geschöpf des Buches versteht. Sein Einfluss beruht auf Vertrauen in die Genauigkeit des Registers, nicht auf physischer Kontrolle über Netze. Je höher der wirtschaftliche und betriebliche Wert der Einträge, desto gefährlicher wird die Verwechslung von Datennähe und Herrschaft.

Note 52 ergänzt die Haftungsseite: Macht, die hohe Folgen auslösen kann, ohne entsprechende Verantwortung zu tragen, erzeugt eine strukturelle Schieflage. Note 28 zieht deshalb die nicht verhandelbare Trennlinie zwischen Administration und Strafe. Note 19 verwirft die Vorstellung, freiwillige Kooperation könne nachträglich Souveränität erzeugen. Ein Richtlinienprozess kann einen engen technischen Standard koordinieren. Er kann nicht über Abstimmung oder Gewohnheit eine Regierung über Netze erschaffen.

Diese Doktrin macht die AS-SET-Regel nicht schwächer. Sie macht ihren zulässigen Kern sichtbar. AFRINIC darf im eigenen Register prüfen, ob die behauptete Namenswurzel authentifiziert wurde. Es darf keinen allgemeinen Anspruch daraus ableiten, die Wirklichkeit hinter dem Eintrag zu besitzen, politische oder wirtschaftliche Entscheidungen zu beurteilen, Betreiber zu bestrafen oder laufende Netze zu Geiseln zu machen.

RFC-Syntax, AFRINIC-Text und laufender Code

Hierarchische Set-Namen stammen nicht aus dem Jahr 2026. RFC 2622 definierte 1999 in der Routing Policy Specification Language eine durch Doppelpunkte gegliederte Namenshierarchie sowie die Autorisierung durch ASN- und Eltern-Maintainer. Der Standard beschreibt Grammatik und Elternprinzip. Den Registrierungsprozess eines Registers nimmt er ausdrücklich aus seinem Geltungsbereich. Er entscheidet nicht, ob ein RIR flache Neuanlagen verbietet, wie es Altobjekte behandelt oder ob es Wiederherstellungen zulässt.

Drei Ebenen dürfen deshalb nicht ineinanderfallen. RFC 2622 ermöglicht die Syntax und das Hierarchiemodell. Das AFRINIC-Verfahren kann einen vorgeschlagenen Abschnitt 7.8 als Verwaltungsregel für das eigene Register behandeln. WHOIS, MyAFRINIC und APIs müssen eine angenommene Regel anschließend in identische Annahmetests übersetzen. Weder die Standardisierung der Syntax noch die Veröffentlichung des Vorschlags beweist die produktive Durchsetzung.

AFRINICs veröffentlichte MyAFRINIC-Anleitung macht die bestehende Lücke anschaulich. Sie beschreibt flache AS-SET-Namen, die mit AS- beginnen, und eine Autorisierung über ein Maintainer-Passwort. Daraus folgt als strukturelle Beobachtung: Eine Person kann sich für eine Objektoperation ausweisen, ohne dass der frei gewählte Name selbst eine Beziehung zu einer ASN ausweist. DRAFT02 würde die Prüfung für neue Namen enger machen. Nicht irgendeine erfolgreiche Maintainer-Authentifizierung genügte, sondern die Authentifizierung der im Namen verankerten ASN oder des unmittelbaren Eltern-Sets.

Auch hier gilt Running-Code Primacy. Ein Formular, das die neue Regel anzeigt, reicht nicht, wenn ein WHOIS-Update oder ein API-Aufruf sie umgehen kann. Eine Serverprüfung reicht nicht, wenn die Oberfläche irreführende Möglichkeiten anbietet. RDAP kann gespeicherte Daten wiedergeben, aber nicht beweisen, welche Authentifizierung bei ihrer Anlage geprüft wurde. Die behauptete Registerwahrheit muss an jeder Eingangstür mit denselben Eingaben zum selben Ergebnis führen.

Was DRAFT02 nicht entscheidet

Die Reichweite lässt sich präzise begrenzen: Bei Annahme und konsequenter Umsetzung würde DRAFT02 die gewöhnliche Neuanlage eines AFRINIC-AS-SET-Zweigs ohne nachgewiesene Kontrolle seiner ASN-Wurzel oder seines Eltern-Sets verhindern. Es würde vorhandene flache Namen nicht nachträglich authentifizieren. Es würde fremde IRRs nicht binden. Es würde AS-SET-Mitglieder, Resolverquellen, Spiegelungen, Filter, Route-Sets, andere RPSL-Set-Typen, RPKI oder ROAs nicht validieren.

Damit endet auch AFRINICs zulässige Aussage. Ein akzeptierter hierarchischer Name darf als Beleg einer erfolgreich geprüften Anlegeberechtigung gelesen werden. Er darf nicht als Urteil über die Richtigkeit des gesamten Sets, die Sicherheit einer Route, die Berechtigung eines Geschäftsmodells oder die Zuverlässigkeit eines Netzbetreibers ausgegeben werden. Die Routingrealität entsteht aus laufenden Netzen und den Entscheidungen ihrer Betreiber. Das Register kann diese Realität koordinierend beschreiben. Es kann sie nicht durch einen Datenbankstatus erschaffen.

Ein von MANRS beschriebener Versuch stützt den engen Mechanismus. Ein nicht zugehöriger Maintainer konnte dort einen flachen AS-SET-Namen anlegen, während die ASN-verankerte hierarchische Form ohne passende Autorisierung scheiterte. Der Beitrag dokumentiert außerdem gleichlautende AS-AMAZON-Bezeichnungen in RADB und der RIPE Database. Das zeigt einen Kollisionsmechanismus. Es belegt weder böse Absicht noch die Häufigkeit solcher Fälle bei AFRINIC. Aus einem Beispiel darf keine erfundene Vorfallsstatistik werden.

Auch die weiter reichende Aussage des Vorschlagsautors bleibt eine zugeschriebene Aussage. Der Autor folgert, nach einer AFRINIC-Umsetzung sei AS-SET-Squatting über alle fünf großen regionalen Register hinweg nicht mehr möglich. Die geprüften Belege tragen diese globale Schlussfolgerung nicht. APNIC und RIPE NCC dokumentieren offiziell Beschränkungen neuer flacher Namen. LACNICs offizielle Beiträge zeigen ASN-verankerte Praxis, aber nicht für jeden Anlageweg eine vollständig dokumentierte Zurückweisung. ARIN hatte die Funktion am Stichtag lediglich auf eine Liste künftiger Funktionen gesetzt.

Drittanbieter-IRRs sind vom AFRINIC-Entwurf nicht erfasst, und flache Altnamen bestehen fort.

Der belastbare Befund ist kleiner und gerade deshalb stark: AFRINIC könnte einen bestimmten vorgelagerten Entstehungsfehler im eigenen Namensraum verhindern. Ein formal richtig angelegtes Set kann weiterhin falsch oder veraltet gepflegt sein. Ein Verbraucher kann weiterhin die falsche Quelle wählen. Doch ein sachfremdes Maintainer-Konto könnte nicht mehr über den gewöhnlichen Weg einen neuen Zweig unter einer fremden ASN eröffnen.

Zwei amtliche Statusangaben sind kein Vollzug

Zum Stichtag 9. August 2026 war weder Annahme noch technische Umsetzung belegt. AFRINICs offizieller Index laufender Vorschläge führte DRAFT02 als „Under Discussion“. Die Einzelseite zeigte zugleich „Last Call“ und vermerkte die Präsentation bei AF37 am 24. Juni 2026. Beide Angaben stammen von AFRINIC. Die geprüften Veröffentlichungen erklären den Widerspruch nicht. Deshalb muss er sichtbar bleiben.

Offizielles Material beweist an dieser Stelle nur die jeweils zugeschriebene Aussage oder Handlung. Der Index beweist, welches Etikett AFRINIC dort anzeigte. Die Einzelseite beweist ihr anderes Etikett und die dort vermerkte Präsentation. Die Folgenabschätzung beweist, was Mitarbeitende einschätzten. Nichts davon beweist für sich Annahme, Ratifikation, produktiven Code oder eine souveräne Befugnis.

Der Vorschlagsautor kann den Text einreichen und ändern. Mitarbeitende können technische, personelle, rechtliche und finanzielle Folgen beschreiben. Ein Richtlinienprozess kann über einen Regeltext beraten. Ein Board kann gesellschaftsinterne Entscheidungen treffen. Ein RSA kann Vertragsbeziehungen ordnen. Keine dieser Rollen erzeugt aus der Registerfunktion politische Herrschaft über Netze. Selbst ein formal angenommener Text wäre nur eine Regel für die administrative Leistung des Registers und müsste an der dünnen technischen Aufgabe gemessen werden.

Die veröffentlichte Chronologie zeigt Verfahrensschritte, keinen Vollzug. DRAFT01 wurde laut Revisionsgeschichte am 15. Mai 2026 eingereicht. DRAFT02 folgte 24 Kalendertage später am 8. Juni, nachdem Rückmeldungen aus der Mailingliste eingearbeitet und die ausdrückliche Wiederherstellungsausnahme ergänzt worden waren. Die Folgenabschätzung datiert vom 15. Juni, sieben Tage nach DRAFT02. Neun Tage später folgte die Präsentation bei AF37. Diese Abstände messen Zeit zwischen dokumentierten Ereignissen. Sie beweisen weder Konsens noch Gesamtdauer, Produktionsreife oder Berechtigung zur Machtausweitung.

Für die Behauptung, die Regel gelte, fehlten eine Annahme- oder Ratifikationsmitteilung, ein endgültiger veröffentlichter Regeltext, ein Release-Hinweis und überprüfbare Tests der produktiven Anlagewege. Daraus folgt weder eine verdeckte Umsetzung noch ein Scheitern. Es folgt, dass der Mechanismus im Konjunktiv beschrieben werden muss.

Sechs Systeme und eine einzige zulässige Prüfung

Die AFRINIC-Folgenabschätzung nennt sechs Systeme. WHOIS-Software und die IRR-Benutzeroberfläche von MyAFRINIC benötigten nach Einschätzung der Mitarbeitenden direkte Änderungen. RDAP würde den aus WHOIS stammenden Zustand wiedergeben. Für NetSuite, NMRP und RPKI wurde kein Änderungsbedarf angegeben. Das sind zwei direkte Eingriffe, ein spiegelndes System und drei nach der veröffentlichten Einschätzung unberührte Systeme. Es ist keine unabhängig vermessene Aufwandsstudie.

Die Anlegeprüfung muss überall gleich sein. Ein MyAFRINIC-Formular darf eine fremde ASN-Wurzel nicht anders behandeln als ein WHOIS-Update oder ein API-Aufruf. Eine Abnahmematrix muss mindestens eine gültige Wurzel mit passender Authentifizierung, eine fremde Wurzel, einen tieferen Namen mit berechtigtem Eltern-Maintainer, einen flachen Neunamen, die Bearbeitung und Löschung eines flachen Altobjekts sowie den Wiederherstellungsversuch unterscheiden. Diese Fälle prüfen Registerkonsistenz. Sie beurteilen keinen Betreiber.

Mitarbeitende erwarteten für Mitglieder nur eine kleine Lernkurve und mögliche Änderungen an Automatisierung oder Werkzeugen. Diese Erwartung ist nachvollziehbar, weil keine allgemeine Umbenennung verlangt wird und hierarchische Syntax bereits bekannt ist. Sie bleibt eine Einschätzung von AFRINIC-Mitarbeitenden, keine Mitgliederbefragung und keine Kostenerhebung. Es gibt keine veröffentlichten Zahlen zu Arbeitsstunden, Budgets oder zur Verbreitung betroffener Skripte, Vorlagen, Peering-Einträge und Dokumentationsabläufe.

Auch der Zeitplan war eine zugeschriebene Erwartung. Verfügbare Entwicklungskapazität sollte zunächst MyAFRINIC v2 zugutekommen, damals für den 15. November 2026 vorgesehen; die Umsetzung der AS-SET-Regel sollte danach priorisiert werden. Vom Stichtag bis zu diesem v2-Termin lagen 98 Kalendertage. Weder diese Spanne noch eine mögliche Auslieferung von MyAFRINIC v2 wäre ein Liefernachweis für die Namensprüfung.

Kontinuität ohne nachträgliche Herrschaft

DRAFT02 schützt den Bestand mit drei ausdrücklichen Regeln: Vorhandene AS-SETs müssen nicht umbenannt werden, flache Namen dürfen weiter genutzt werden, und eine gewöhnliche Bearbeitung löst keine Umbenennung aus. Dadurch bleiben Referenzen in Konfigurationen, Werkzeugen, Dokumentation und Absprachen zunächst intakt. Eine rückwirkende Migration könnte weit über das Registerobjekt hinausreichen, weil derselbe Name in Provisionierung, Peering-Daten, Partnerkommunikation und Filterprozessen hinterlegt sein kann. Die tatsächliche Reichweite wurde nicht erhoben.

Der Bestandsschutz folgt einer grundlegenden Grenze. Eine neue Registerregel darf laufende betriebliche Wirklichkeit nicht einfach auslöschen, nur weil das Buch künftig ein anderes Format bevorzugt. Das Register beschreibt den vorgefundenen und nachweisbaren Zustand. Es darf ihn berichtigen, wenn der Eintrag falsch ist. Es darf nicht so tun, als habe die Veröffentlichung einer neuen Namensregel bestehende Netze, Absprachen oder Referenzen rückwirkend neu erschaffen.

Die Schonung hat einen erkennbaren Preis. Ein flacher Altname erhält keine ASN-Wurzel und wird nicht nachträglich gegen eine solche authentifiziert. Der gewöhnliche Eingang für neue flache Namen wäre geschlossen, der vorhandene Bestand bliebe gültig und editierbar. Die Regel verbessert den künftigen Bestand, ohne den alten automatisch zu bereinigen.

Wie groß der alte Bestand und sein Schadenspotenzial sind, bleibt unbekannt. In den geprüften Quellen findet sich kein veröffentlichtes AFRINIC-Inventar flacher AS-SETs, keine gesicherte Zahl registerübergreifender Kollisionen, kein Häufigkeitsnenner und keine validierte Reihe betrieblicher Schäden. Der Entwurf dokumentiert einen plausiblen Mechanismus und einzelne Vergleichsfälle, keine gemessene Schadensrate. Daher darf weder jeder Altname als problematisch noch der neue Kontrollnachweis als belanglos dargestellt werden.

APNIC und RIPE NCC zeigen begrenzt, dass eine Vorwärtsregel mit Bestandsschutz technisch umgesetzt werden kann. Diese Vergleiche liefern Tatsachen über ihre eigenen Systeme. Sie erteilen AFRINIC keine Autorität und bestimmen nicht, welchen Übergang AFRINIC wählen muss. Die eigentliche Grenzfrage beginnt, wenn ein geschütztes flaches Objekt gelöscht wird.

Wiederherstellung darf nur Registerkorrektur sein

Angenommen, ein flaches AS-SET wird versehentlich gelöscht. Nach der neuen Normalregel wäre seine Wiederanlage als flacher Name unzulässig. DRAFT02 verlangt jedoch Einzelfallausnahmen und nennt die Wiederherstellung nach irrtümlicher Löschung als Beispiel. Der frühere Maintainer könnte den Namen nicht einfach über die normale technische Anlegeprüfung zurückholen. Eine im Text nicht bezeichnete AFRINIC-Stelle müsste den Ausnahmefall behandeln.

Das Problem ist nicht, dass ein Register einen belegten eigenen Fehlerzustand korrigiert. Die Korrektur eines Buches gehört zur Buchführung. Wenn dasselbe Objekt zuvor existierte, die damalige Kontrollkette nachweisbar fortbesteht und ein Löschvorgang rekonstruiert werden kann, kann eine Wiederherstellung die Aufzeichnung wieder mit der fortbestehenden Realität in Einklang bringen. Eine solche Korrektur schafft kein neues Recht. Sie beschreibt einen nachgewiesenen früheren Zustand wieder.

Problematisch ist das Wort „Einzelfall“, sobald es nicht durch deterministische Tatbestände gebunden ist. Der Entwurf sagt nicht, wer entscheidet, welche Belege einen Irrtum beweisen, ob derselbe frühere Maintainer handeln muss, welche Frist gilt, ob die Wiederherstellung befristet ist oder wie frühere Erstellungs- und Änderungsdaten behandelt werden. Einspruch und Audit sind ebenfalls nicht festgelegt. Ohne diese Grenzen droht aus Registerkorrektur eine Erlaubnisordnung zu werden.

AFRINICs Mitarbeitende warnten selbst, die Wiederherstellungs- oder Rückrufmöglichkeit könne zum operativen Schlupfloch werden und das Ziel der Regel untergraben. Sie schlugen vor, den Grund jeder Ausnahme zu dokumentieren. Diese Warnung und dieser Vorschlag sind zugeschriebene Mitarbeiteräußerungen. Eine Begründungsnotiz verbessert den Prüfpfad. Sie ersetzt keinen objektiven Tatbestand.

Die doktrinäre Grenze ist härter: Mitarbeitende dürfen nicht nach Zweckmäßigkeit, Sympathie, vermuteter Routingpolitik oder institutionellem Interesse entscheiden, wer einen flachen Namen zurückerhält. Ein Board kann ein solches Ermessen nicht durch Billigung in Souveränität verwandeln. Ein Konsens kann es nicht legitimieren. Ein RSA kann es nicht zum Hoheitsrecht machen.

Zulässig ist nur eine eng regelgebundene Korrektur nachweisbarer Registerhistorie; wo der Nachweis fehlt, muss der Registerstatus als ungeklärt oder der Neuantrag als nicht regelkonform behandelt werden, ohne das dahinter laufende Netz für illegitim zu erklären oder zu bestrafen.

Der RIPE-Vergleich zeigt eine strengere Alternative. Nach der veröffentlichten Folgenanalyse der RIPE Database durften alte flache Objekte weiter bearbeitet oder gelöscht werden; nach einer Löschung konnten sie nicht neu entstehen. Diese Grenze ist vorhersehbar und lässt den Altbestand nur in eine Richtung schrumpfen. Sie macht einen Löschfehler allerdings irreversibel. AFRINICs Text bewahrt die Möglichkeit der Wiederherstellung, muss dafür aber die Korrektur so eng an historische Fakten binden, dass sie kein zweiter, ermessensabhängiger Anlageweg wird.

Vier Register, vier begrenzte Belege

Andere regionale Register sind Vergleichsfälle, keine Quellen afrikanischer Souveränität. Bei APNIC ist prop-151 offiziell als umgesetzt verzeichnet: Konsens am 2. März 2023, Billigung am 21. April und Umsetzung am 20. Juli. Bestehende AS-SETs blieben erhalten. Das belegt eine produktive Vorwärtsregel ohne allgemeine Bestandsmigration.

RIPE NCC dokumentiert ebenfalls den Vollzug. Release 1.105 vom 13. Dezember 2022 beschränkte neue nicht hierarchische AS-SETs; NWI-19 wurde abgeschlossen. Der für diese Untersuchung wichtige Unterschied ist die bereits beschriebene Löschgrenze. Sie zeigt eine technisch und administrativ mögliche Alternative. Sie schreibt AFRINIC nichts vor.

LACNICs offizielle technische Beiträge zeigen ASN-verankerte hierarchische Beispiele. Die geprüften LACNIC-Unterlagen belegen jedoch nicht eigenständig, dass jeder Anlageweg jeden flachen Neunamen abweist. Diese Aussage markiert eine Beweisgrenze; sie behauptet nicht das Gegenteil einer Durchsetzung.

ARIN trennte Richtlinienzuständigkeit und Produktentwicklung. Im Frühjahr 2025 konsultierte die Organisation über die Beschränkung nicht hierarchischer Neuanlagen; bestehende Einträge und Drittanbieter-IRRs waren ausgenommen. Der Advisory Council lehnte einen parallelen Nummernressourcen-Richtlinienvorschlag als außerhalb dieses Richtlinienbereichs liegend ab und verwies auf den Dienstleistungsvorschlagsweg. Am 30. Mai 2025 gelangte die Funktion auf eine Liste künftiger Funktionen zur Priorisierung. Das war kein Produktionsrelease.

Direkt verifiziert sind damit durchgesetzte Beschränkungen bei APNIC und RIPE NCC. LACNIC belegt in den geprüften Quellen hierarchische Nutzung; ARIN belegt Zukunftsarbeit. Der uneinheitliche Stand widerlegt den engen Nutzen einer AFRINIC-Prüfung am eigenen Eingang nicht. Er verbietet die Behauptung, AFRINIC vollende damit einen bereits einheitlichen globalen Zustand.

Der stärkste Einwand: Quelle statt Hierarchie

Der stärkste Einwand ist betrieblich ernst zu nehmen. Hierarchie ist weder notwendig noch hinreichend, um jede Mehrdeutigkeit zu beherrschen. Netzbetreiber können einen Objektnamen zusammen mit seiner Quelle führen. PeeringDB zeigt beim öffentlichen Eintrag für Google LLC neben ASN 15169 die qualifizierte Referenz RADB::AS-GOOGLE. Das belegt, dass eine operative Angabe Quelle und Namen gemeinsam transportieren kann. Es belegt weder den aktuellen Inhalt noch die Eigentümerschaft eines gleichnamigen Objekts in einer anderen Datenbank.

Resolver können ausdrückliche Quellenreihenfolgen verwenden. Betreiber können Quellen auswählen, Spiegelungen begrenzen und Mitgliedschaften prüfen. RPKI behandelt getrennt die kryptografische Autorisierung eines Routenursprungs. Ohne Bestands- und Vorfallszahlen lässt sich nicht messen, wie viele Schäden eine Namensregel vermeiden würde. Der Anpassungsaufwand ist ebenfalls nicht erhoben. Der Einwand trifft deshalb jede Behauptung einer umfassenden oder quantifizierten Sicherheitswirkung.

Er widerlegt den engen Kontrollnachweis nicht. Quellenqualifizierung wirkt erst, wenn ein Verbraucher die beabsichtigte Quelle erfasst, durch seine Werkzeugkette bewahrt und bei Auflösung, Cache und Filtererzeugung richtig behandelt. Die ASN-Wurzelprüfung setzt bei der Anlage an. Sie verhindert eine Klasse nicht zuordenbarer Neuanlagen, bevor eine Verbraucherentscheidung erfolgt. Die Quellenangabe ordnet den Leseweg; die Wurzelprüfung ordnet den Registereintrag. Beide bleiben voneinander verschieden.

Gerade diese Trennung verhindert eine neue Herrschaftsbehauptung. AFRINIC darf seinen Eingang genauer machen. Es darf den Verbrauchern nicht vorschreiben, welche Quelle sie glauben, welches Set sie auswerten oder welchen Filter sie installieren. Ein Betreiber kann einen hierarchischen Namen verwenden, einen flachen Altnamen weiterführen, eine Quelle qualifizieren oder eine lokale Vertrauensentscheidung treffen. Die Registrierung erleichtert Koordination; sie ersetzt nicht die Entscheidung des laufenden Netzes.

Was Betreiber umstellen müssten

Wer ein neues AFRINIC-AS-SET anlegt, müsste Namensvorlagen und Skripte auf die Hierarchie umstellen. Peering-Angaben, Dokumentation und Partnerkommunikation müssten die neue Referenz übernehmen. Die zuständige Person benötigte Zugriff auf die Authentifizierung der Wurzel-ASN oder einen kontrollierten Prozess, der das erste Eltern-Set anlegt und tiefere Zweige delegiert.

Diese Delegation kann sensible Zugangsdaten schützen. Der ASN-Maintainer kann den ersten Zweig selbst eröffnen und dessen Maintainer anschließend Kinder verwalten lassen. DRAFT02 ermöglicht diese Arbeitsteilung, regelt intern aber weder Übergabe noch Widerruf oder Verantwortungsnachweis. Organisationen müssen selbst entscheiden, ob sie Wurzelzugänge in Automatisierung einbinden oder eine getrennte Freigabe vorsehen. Diese Entscheidungen gehören zu ihrer eigenen Sicherheits- und Betriebsarchitektur, nicht zu AFRINICs politischem Urteil.

Verbraucher erhielten bei neuen AFRINIC-Namen ein stärkeres Signal über die Anlageautorität. Das kann Rückfragen und Fehlersuche vereinfachen. Es ersetzt keine Prüfung des gelesenen Bestands. Die Risikoverteilung verschiebt sich: ASN-Inhaber wären besser gegen einen sachfremden neuen Zweig unter ihrer Nummer geschützt; AFRINIC müsste überall gleich authentifizieren und Korrekturen regelgebunden behandeln; Verbraucher trügen weiterhin die Mehrdeutigkeit von Altbestand, fremden Quellen und Set-Inhalten.

Die Kosten verteilen sich ungleich, obwohl Zahlen fehlen. Kleine Netze können einen vorhersehbaren Kontrollnachweis schätzen, verfügen aber womöglich über weniger Kapazität für einmalige Werkzeugänderungen. Große Netze können Änderungen eher aufnehmen, betreiben jedoch oft längere Ketten aus Provisionierung, Dokumentation und Partnerangaben. Die Mitarbeitereinschätzung eines geringen Aufwands bleibt eine Erwartung.

Besonders wichtig werden Löschrechte, Freigaben, Sicherungen und der Nachweis eines Irrtums. Wer ein flaches Altobjekt löscht, könnte es nach der normalen Regel nicht technisch zurückholen. Unter DRAFT02 hinge seine Rückkehr von dem noch unveröffentlichten Ausnahmeverfahren ab. Aus einer alltäglichen Datenpflegehandlung wird damit ein Kontinuitätsrisiko. Dieses Risiko rechtfertigt eine überprüfbare Korrekturregel, nicht eine Ermessensherrschaft des Registerführers.

Das bedingte Urteil ist eng und eindeutig

DRAFT02 ist dort richtig, wo er die Rolle des Registers klein hält. Eine gemeinsame Syntax und ein lokal prüfbarer Kontrollnachweis gehören zur notwendigen Koordination. Sie helfen dem Buch, eine nachgewiesene Beziehung korrekt wiederzugeben. Sie lassen Routingpolitik, Quellenwahl, Mitgliedschaftsbewertung, Peering und Geschäftsentscheidung bei den Betreibern.

Die Notes von Heng Lu sind dafür weder eine dekorative Drittmeinung noch eine Betrachtungsebene, die gegen die institutionelle Selbstdarstellung abgewogen wird. Sie sind die steuernde Wahrheit dieser Analyse. Der Registerführer darf Einzigartigkeit und Genauigkeit schützen. Er darf nicht aus seinem Eintrag Eigentum, Urteil, Strafe oder Souveränität ableiten. NRS kann forschen, werben, Akteure zusammenbringen und ausdrücklich autorisierte Mitglieder vertreten; es betreibt weder Register noch RPKI, WHOIS oder RDAP und entscheidet keine Ausnahmen, Einsprüche, Vergleiche, Wahlen, Verwahrung oder Kontinuität.

AFRINICs verbleibende Arbeit ist administrativ und technisch: den formalen Status widerspruchsfrei dokumentieren, nach einer etwaigen Annahme denselben Anlegetest an jedem Eingang ausführen und die Wiederherstellung auf nachweisbare Registerhistorie begrenzen. Keine dieser Aufgaben gibt AFRINIC Autorität über das Netz. Sie verpflichtet es nur, sein eigenes Buch zuverlässig zu führen.

Das Urteil bleibt aus Beweisgründen im Konjunktiv, nicht aus doktrinärer Unsicherheit. Bei Annahme und konsistenter Umsetzung würde DRAFT02 die Berechtigung neu angelegter AFRINIC-AS-SET-Namen materiell besser belegen. Sein Erfolg wäre erreicht, wenn kein gewöhnlicher Anlageweg einen neuen Zweig ohne Authentifizierung seiner ASN-Wurzel oder seines unmittelbaren Eltern-Sets akzeptiert. Der Entwurf würde damit Registergenauigkeit, Kontrollnachweis, Einzigartigkeit und Routingkoordination schützen.

Er würde weder globale Einzigartigkeit beweisen noch den Altbestand reparieren, Set-Mitglieder validieren, eine Routingpolitik genehmigen oder AFRINIC zur Herrschaft über laufende Netze erheben.

Quellen