Zusammenfassung

  • AFRINICs offizielles Archiv und die maßgebliche Richtlinienseite führen AFPUB-2009-ASN-001 mit dem Status „Implemented“ und dem Datum 26. Mai 2010. Ein kurz darauf bei AFRINIC-12 vorgelegter offizieller Bericht hielt jedoch fest, dass der Vorschlag noch nicht förmlich vom NRO Executive Council an den ASO Address Council weitergegeben worden war. ICANN ratifizierte die globale Richtlinie erst am 21. September. Der 26. Mai belegt somit den Abschluss eines regionalen Lebenszyklusschritts, nicht die damalige Änderung der globalen IANA-Zuteilung.
  • Die sachliche Änderung war eng: IANA und die regionalen Register sollten Bestände von 16-Bit- und ausschließlich 32-Bit-ASNs bis zum 31. Dezember 2010 weiter getrennt behandeln; ab dem 1. Januar 2011 sollte ein undifferenzierter 32-Bit-Bestand gelten. Der öffentliche Nachweis enthält für den 26. Mai weder ein Änderungsticket noch einen Systemvergleich, einen Test, eine IANA-Transaktion oder einen anders bearbeiteten Mitgliederantrag.
  • Die stärkste Lesart zugunsten AFRINICs ist regional: Das Register hatte seinen internen Richtlinienzyklus beendet, den Text veröffentlicht und seine Bereitschaft kenntlich gemacht. Die stärkste Einwendung ist ebenfalls präzise: Ohne Ebenenkennzeichnung lässt „Implemented“ regionale Vorbereitung, globale Ratifikation, Upstream-Umstellung und beobachtbare Dienständerung ineinanderfallen. Beides lässt sich durch ein öffentliches Umsetzungsjournal versöhnen, das Instrument, Zuständigkeit, Zeitpunkt, betroffenen Ablauf, Tests, Transaktionsspuren, Ausnahmen und Rückfalloptionen verbindet.
  • AFRINIC ist bei dieser Prüfung als privater Buchhalter und Koordinator zu behandeln. Es kann eindeutige Registrierungen führen, begrenzte Dienstverfahren organisieren und globale Konsistenz koordinieren. Es besitzt weder die Netze noch die Nummernressourcen und verfügt über keine souveräne, gesetzgeberische, regulatorische, polizeiliche, staatsanwaltschaftliche, richterliche, strafende oder konfiskatorische Gewalt. Technischer Konsens ist ein nützlicher Input, aber kein Mandat eines Prinzipals und keine Herrschaftsvollmacht über Afrika.

Analyse

Das Wort, das der Zeitachse vorauslief

Die Beweisspannung liegt offen in drei amtlichen Zeitmarken. AFRINICs Monatsarchiv für 2010 führt am 26. Mai den Vorschlag AFPUB-2009-ASN-001. Sowohl dieses Archiv als auch die kanonische Richtlinienseite zeigen den Status „Implemented“ und dasselbe Datum. Wenige Tage später erklärte eine offizielle NRO-NC/ASO-AC-Präsentation bei AFRINIC-12, der Vorschlag sei zwar in allen Regionen angenommen und im Mai vom AFRINIC Board ratifiziert worden, habe den förmlichen Schritt vom NRO Executive Council zum ASO Address Council aber noch nicht vollzogen. ICANN gab die Ratifikation durch sein Board Executive Committee erst am 21. September bekannt.

Diese Abfolge ist kein nebensächliches Datumsproblem. Sie bestimmt, was mit gutem Grund über den 26. Mai gesagt werden kann. Das AFRINIC-Datum beweist eine veröffentlichte Klassifikation und einen regionalen institutionellen Akt. Die Juni-Präsentation beweist zugleich, dass die globale Kette noch offen war. Die September-Mitteilung beweist einen späteren globalen Ratifikationsakt und kündigt weitere Umsetzungsschritte durch ICANN-Mitarbeiter an. Keine dieser Quellen allein macht aus dem regionalen Datum eine weltweite Wirksamkeitsmarke. Ebenso wenig erlaubt die spätere globale Ratifikation die Behauptung, am 26. Mai sei nichts geschehen.

Gerade deshalb ist „Implemented“ als Beweisstück wertvoll. Das Wort zwingt zur Frage nach seiner Reichweite. Es kann bedeuten, dass eine Organisation ihren eigenen Beschlussweg abgeschlossen hat. Es kann die Veröffentlichung eines gültigen Textes meinen, die Einsatzbereitschaft einer internen Prozedur, das Inkrafttreten einer gemeinsamen Regel, die Änderung eines Upstream-Dienstes oder die erfolgreiche Abwicklung einer ersten realen Transaktion. Diese Bedeutungen sind nicht austauschbar. In einem mehrstufig koordinierten Nummernsystem können sie Monate auseinanderliegen, ohne dass eine einzelne Stelle notwendigerweise falsch handelt.

Die richtige Ausgangsposition ist daher weder Anklage noch institutionelle Gefälligkeit. AFRINIC hat den Status und das Datum öffentlich festgehalten; das ist ein bewiesener Governance-Schritt. Aber der öffentlich zugängliche Nachweis benennt nicht den konkreten Produktionszustand, der an diesem Tag umsprang. Die analytische Aufgabe besteht darin, den belegten regionalen Akt vollständig anzuerkennen und jede nicht belegte Vergrößerung zurückzuweisen.

Die Änderung war schmal, ihre Betriebsfrage konkret

AFPUB-2009-ASN-001 änderte nicht die gesamte Architektur der Vergabe autonomer Systemnummern. Ein ASN kennzeichnet knapp gesagt ein Netz, das mit mehr als einem anderen Netz verbunden ist und seine eigene Routingpolitik steuert. Für diese Untersuchung genügt die Unterscheidung zwischen Beständen, die mit 16-Bit-Systemen kompatibel waren, und solchen ASNs, die nur im 32-Bit-Bereich lagen. Der Vorschlag verlängerte um ein Jahr den Zeitraum, in dem IANA und die regionalen Register diese Bestandsklassen unterscheiden sollten: nicht nur bis Ende 2009, sondern bis zum 31. Dezember 2010. Vom 1.

Januar 2011 an sollte die Zuteilung aus einem undifferenzierten 32-Bit-Pool erfolgen.

Die AFRINIC-Seite nennt Andrew de la Haye vom RIPE NCC und Stacy Hughes von ARIN als Autoren. Sie veröffentlicht den geänderten Text, seine Begründung, ein Gegenargument und die regionale Verlaufsgeschichte. Als betroffene Richtlinie weist sie „NA“ aus. Das ist wichtig, weil es die Art des regionalen Akts eingrenzt: AFRINIC stellte keine umfangreiche neue regionale Sachregel neben eine bestehende. Es bearbeitete innerhalb eines global koordinierten Vorschlags die zeitliche Trennung zweier Inventarklassen und dokumentierte seinen regionalen Status.

Der operative Anlass war dennoch real. Die Ausgabe ausschließlich 32-Bit-fähiger ASNs verlief langsamer als erwartet, während die Kompatibilität in eingesetzten Netzen nicht durch eine Erklärung hergestellt werden konnte. Ein nominell großer Nummernbestand kann betrieblich knapp sein, wenn ein Teil davon in vorhandenen Umgebungen nicht zuverlässig verwendbar ist. Das ökonomische Risiko lag somit nicht bloß in der Zahl freier Einträge, sondern in der Menge tatsächlich einsetzbarer, legacy-kompatibler Ressourcen während einer unvollständigen Umstellung.

Das erklärt, warum eine regionale Organisation nicht bis zum letzten globalen Zeremonienschritt untätig bleiben sollte. Sie muss Personal, Abläufe und Erwartungen vorbereiten können, bevor eine gemeinsame Regel vollständig durch alle Institutionen gelaufen ist. Zugleich erklärt es, warum Vorbereitung nicht mit globaler Wirksamkeit gleichgesetzt werden darf. AFRINIC konnte seine eigene Dienstposition festlegen und regionale Unsicherheit beseitigen. Es konnte nicht einseitig den IANA-Zufluss zu allen regionalen Registern ändern.

Die technischen Einzelheiten der älteren Grundregel sind für diese Beweisfrage nicht erforderlich. Blockgrößen, Auffüllschwellen, Bedarfshorizonte, Protokollbrücken, Notationsfragen und Werkzeugkataloge würden den Blick vom Gegenstand ablenken. Entscheidend ist nur der enge zeitliche Aufschub der Bestandsunterscheidung und die Frage, auf welcher Ebene er am 26. Mai nachweisbar umgesetzt war.

Vier Akte, die nicht zu einem einzigen Ereignis verschmolzen werden dürfen

Die regionale Vorgeschichte beginnt im hier nötigen Mindestumfang am 28. August 2009, als die AFRINIC-Historie die Einreichung an die RPD-Mailingliste verzeichnet. Am 27. November hielt AFRINIC-11 regionalen Konsens zur Annahme des Vorschlags fest. Dieser Konsens ist für die vorliegende Zeitachse ein früher technischer Bewertungsschritt, nicht das Zentrum der Untersuchung. Er beweist weder ein einstimmiges Votum aller Betreiber noch eine demokratische oder rechtlich bindende Vertretung der Region.

Schon bei der nachfolgenden letzten Kommentierungsphase zeigen die institutionellen Aufzeichnungen Differenzen. AFRINIC nennt den 4. bis 19. Dezember 2009; ICANN verzeichnet den 2. bis 17. Dezember. Der Grund für diese Abweichung ist unbekannt. Sie ist nicht als Fehlverhalten zu deuten, aber sie zeigt, weshalb eine belastbare Chronologie Quelle, Ereignisart und Datum zusammen festhalten muss. Wer unterschiedliche institutionelle Aufzeichnungen glattzieht, erzeugt Gewissheit, die das Material nicht trägt.

Der zweite notwendige Akt ist die regionale Unternehmensgenehmigung im Mai 2010. Auch hier gibt es keine einheitliche Datumszeile. ICANN verzeichnet die Annahme durch das AFRINIC Board am 24. Mai. AFRINICs eigene Richtlinienhistorie nennt die Zustimmung durch das Board am 25. Mai. Die Differenz beträgt einen Tag; ihre Ursache ist nicht dokumentiert. Beide Angaben müssen mit ihrer jeweiligen Zuschreibung bestehen bleiben. Man darf daraus weder ein austauschbares Datum machen noch eine Absicht ableiten.

Der dritte Akt ist der öffentliche AFRINIC-Status vom 26. Mai. Er folgt nach AFRINICs eigener Historie einen Tag auf die Board-Zustimmung und zwei Tage nach ICANNs Datum. Der Status „Implemented“ und das Datum sind direkt belegt. Dieser Schritt schließt sinnvollerweise den regionalen Lebenszyklus: technischer Konsens war zuvor festgestellt, die Unternehmensgenehmigung war im Mai erteilt, der Text lag öffentlich vor, und AFRINIC kennzeichnete die Richtlinie als implementiert. So verstanden ist der Eintrag weder leer noch bloße Dekoration. Er macht die regionale Position bestimmt und für andere Beteiligte sichtbar.

Der vierte Akt ist die noch ausstehende globale Weiterleitung und Ratifikation. Während AFRINIC-12, das vom 23. Mai bis 4. Juni stattfand, hielt die offizielle Präsentation fest, dass der Vorschlag zwar alle Regionen passiert und das AFRINIC Board ihn ratifiziert hatte, die formelle Weitergabe vom NRO Executive Council an den ASO Address Council jedoch noch nicht erfolgt war. Diese zeitnahe Aussage ist besonders aussagekräftig, weil sie nicht rückblickend eine vereinfachte Endgeschichte erzählt. Sie beschreibt die Kette kurz nach dem 26. Mai als unvollständig.

Die späteren Daten bestätigen diese Grenze. Am 13. Juli übermittelte das NRO Executive Council den endgültigen Vorschlag an den ASO Address Council zur prozeduralen Prüfung. Am 22. Juli leitete der ASO Address Council ihn an das ICANN Board weiter. Zwischen dem 23. Juli und 13. August führte ICANN eine abschließende öffentliche Kommentierungsphase durch. Erst am 21. September teilte ICANN die Ratifikation durch das Board Executive Committee mit und erklärte, die Mitarbeiter würden die nötigen Umsetzungsschritte unternehmen.

Damit stehen mindestens vier getrennte Akte fest: regionale technische Beurteilung im November 2009, regionale Board-Genehmigung im Mai 2010, AFRINICs regionaler Implementierungsstatus am 26. Mai und globale ICANN-Ratifikation im September mit anschließender Umsetzungsarbeit. Dazwischen liegen NRO- und ASO-Verfahrensschritte. Eine Chronik, die sie zu einem einzigen Datum zusammendrückt, verliert gerade die verteilte Verantwortungsstruktur, die globale Nummernkoordination ausmacht.

Eine Prüfung in sechs Ebenen

Für eine belastbare Einordnung lässt sich „Implementierung“ in sechs Ebenen zerlegen. Die erste Ebene ist der Abschluss regionaler Governance. Hier gibt es einen belegten regionalen Konsens vom November 2009, die im Mai verzeichnete Board-Genehmigung und den veröffentlichten Status vom 26. Mai. Nicht belegt sind damit eine Zustimmung aller Betreiber, ein souveränes Mandat oder eine Vertretungsmacht für einen Kontinent.

Die zweite Ebene ist die Bereitschaft des regionalen Betriebsverfahrens. Ein implementierter Status kann vernünftigerweise signalisieren, dass AFRINIC seine eigenen administrativen Abläufe auf den verlängerten Zeitraum eingestellt hatte. Diese Lesart ist institutionell plausibel, aber der konkrete Beleg fehlt: Das Material nennt weder eine geänderte Arbeitsanweisung noch ein Formular, eine Datenbanktabelle, eine Softwareversion, ein Schulungsdokument oder einen verantwortlichen Mitarbeiter. Plausibilität ist hier eine Hypothese, kein Transaktionsnachweis.

Die dritte Ebene ist die globale Ratifikation. Für sie ist der 21. September belegt. Der NRO-EC-Transfer vom 13. Juli, die ASO-AC-Weitergabe vom 22. Juli und die abschließende Kommentierungsphase zeigen, dass die notwendige Kette am 26. Mai noch nicht vollzogen war. Eine regionale Klassifikation kann diesen globalen Schritt weder ersetzen noch rückwirkend vorwegnehmen.

Die vierte Ebene ist die Änderung des Upstream-Verfahrens bei IANA. ICANN kündigte im September notwendige Umsetzungsschritte an und veröffentlichte den endgültigen Richtlinientext. Das belegt, dass eine operative Folge vorgesehen war. Es belegt im vorliegenden Nachweisbestand jedoch nicht das genaue Abschlussdatum, den konkreten Prozesswechsel oder eine einzelne IANA-zu-RIR-Zuteilung, die nach der neuen Regel abgewickelt wurde. Erst eine solche Spur würde die globale Dienstumstellung zeitlich verankern.

Die fünfte Ebene ist eine beobachtete Transaktion. Dafür wäre beispielsweise ein anonymisierter, datierter Vorgang nötig, der zeigt, dass ein Antrag vor und nach der Umstellung nach unterschiedlichen Bestandsregeln bearbeitet wurde. Weder eine AFRINIC-Mitgliederanfrage noch eine IANA-Zuteilung ist für den 26. Mai als veränderte Transaktion nachgewiesen. Auch ist nicht belegt, dass Veröffentlichungsdatum und effektives Dienstdatum identisch waren.

Die sechste Ebene ist das Ergebnis im Betreiberbetrieb. Selbst eine korrekt geänderte Verwaltungsprozedur garantiert nicht, dass Router, Anbieterprodukte und operative Abläufe ein zugeteiltes ASN verwenden können. Ein verifiziertes Ergebnis würde zeigen, welcher Betreiber eine Nummer erfolgreich einsetzte, welcher Kompatibilitätsfehler vermieden wurde oder welche knappe legacy-kompatible Ressource tatsächlich verfügbar blieb. Der Richtliniengrund nennt ein Risiko; er identifiziert aber kein afrikanisches Netz, dessen Verhalten oder Ergebnis sich wegen des 26. Mai änderte.

Diese sechs Ebenen ergeben kein Misstrauensritual, sondern eine faire Beweisordnung. AFRINIC erhält volle Anerkennung für den nachgewiesenen regionalen Abschluss. NRO, ASO, ICANN und IANA werden nicht aus der globalen Kette gelöscht. Betreiberergebnisse werden nicht aus Verwaltungsworten erfunden. Jede Institution wird an dem Akt gemessen, den ihre Unterlagen tatsächlich dokumentieren.

Was der 26. Mai belegt – und was offenbleibt

Unmittelbar belegt sind drei Dinge. Erstens trägt AFRINICs Monatsarchiv einen Eintrag vom 26. Mai 2010 für AFPUB-2009-ASN-001. Zweitens zeigen Archiv und kanonische Richtlinienseite übereinstimmend „Implemented“ und das Datum. Drittens veröffentlicht die Richtlinienseite den geänderten Text und die regionale Geschichte, einschließlich der AFRINIC-Angabe einer Board-Genehmigung am 25. Mai. Zusammengenommen tragen diese Elemente die Aussage, dass AFRINIC seinen regionalen Richtlinienlebenszyklus öffentlich als abgeschlossen behandelte.

Ebenso klar ist, was sie nicht belegen. Es gibt keinen öffentlich nachgewiesenen internen Änderungsschein für den 26. Mai, keine Bereitstellungscheckliste, keinen Vergleich einer Konfiguration vor und nach dem Datum, kein Testergebnis und keinen Rückfallplan. Es ist keine Mitarbeiteranweisung identifiziert. Es gibt keine Spur eines geänderten Antragsformulars, einer Software- oder Datenbankänderung, einer Schulung oder eines abweichend bearbeiteten Mitgliederantrags.

Auf der globalen Ebene fehlt eine IANA-Transaktion, die durch die Änderung ausgelöst und auf diesen Tag datiert wäre. Unbekannt ist auch, wann genau das Produktionsverfahren von IANA den im September endgültig ratifizierten Text abbildete. Die ICANN-Formulierung, Mitarbeiter würden die nötigen Umsetzungsschritte unternehmen, beweist Absicht und Zuständigkeit für weitere Arbeit, aber keinen bereits vollzogenen Produktionswechsel im Mai.

Auch die Wirkung auf den regionalen Bestand bleibt unquantifiziert. Der Nachweis beziffert nicht die Nachfrage nach legacy-kompatiblen ASNs im AFRINIC-Dienstgebiet. Er zeigt nicht, wie viele Anträge ohne Verlängerung hätten scheitern oder sich verzögern können. Es gibt keine Vorher-nachher-Kennzahl für Bearbeitungszeiten, verfügbare Klassen oder Fehlerraten. Diese Lücken entwerten die Änderung nicht; sie begrenzen lediglich die Aussagen über ihren unmittelbaren Effekt.

Schließlich bleibt die Semantik des Datums offen. Der 26. Mai könnte Veröffentlichungsdatum, internes Wirksamkeitsdatum, Bereitschaftsmarke, Statusänderung oder eine Kombination daraus gewesen sein. Der zugängliche Eintrag definiert das nicht. Wer eine dieser Bedeutungen auswählt, muss sie als Schlussfolgerung kennzeichnen und den fehlenden Beleg offenlassen.

Die spätere Begriffsklärung ist Kontext, kein rückwirkendes Regelbuch

AFRINIC veröffentlichte später im Jahr 2010 einen Richtlinienentwicklungsprozess, der Genehmigung und Implementierung ausdrücklich voneinander unterschied und die Bekanntgabe von Annahme- und Implementierungsdaten verlangte. Dieses Dokument wurde am 11. November 2010 implementiert. Es zeigt, dass AFRINIC im weiteren Verlauf des Jahres öffentlich einen feineren begrifflichen Unterschied verwendete.

Es darf jedoch nicht als nachgewiesene Regel für den Mai zurückprojiziert werden. Seine spätere Implementierung bedeutet gerade, dass es den 26.-Mai-Akt nicht ohne zusätzlichen Beleg regierte. Es ist nur ein Kontextsignal: AFRINIC erkannte in seiner späteren öffentlichen Verfahrenssprache, dass Zustimmung und Implementierung verschiedene Zustände sind und dass beide Daten genannt werden sollten. Was der ältere Eintrag intern genau meinte, bleibt dadurch offen.

Diese zeitliche Disziplin schützt vor zwei entgegengesetzten Fehlern. Einerseits darf die spätere Definition nicht verwendet werden, um dem Mai-Eintrag nachträglich eine spezifische technische Bedeutung zuzuschreiben. Andererseits darf der ältere Eintrag nicht so behandelt werden, als hätte AFRINIC nie zwischen Genehmigung und Implementierung unterschieden. Belegt ist eine Entwicklung der veröffentlichten Verfahrenssprache, nicht die rückwirkende Auflösung aller früheren Mehrdeutigkeiten.

Die stärkste Verteidigung des AFRINIC-Eintrags

Die überzeugendste Verteidigung beginnt mit der Arbeitsteilung eines koordinierten Systems. Ein regionales Register muss seine eigene Voraussetzung abschließen können, bevor der letzte globale Schritt fällt. Wenn jede Organisation erst nach ICANNs Ratifikation mit interner Vorbereitung beginnen dürfte, würde die praktische Umsetzung nach der globalen Entscheidung unnötig verzögert. Personal müsste erst dann informiert, Inventar erst dann geprüft und Verfahren erst dann angepasst werden. Eine rechtzeitige regionale Bereitschaft kann daher ein verantwortungsvoller Beitrag zur Gesamtkoordination sein.

Der 26.-Mai-Status kann in diesem Sinne eine legitime regionale Bedeutung haben. AFRINIC hatte den Vorschlag in seinem Verfahren behandelt, das Board hatte ihn im Mai genehmigt, der Text war öffentlich, und das Register konnte den regionalen Teil als erledigt markieren. Andere Institutionen erhielten damit ein klares Signal: AFRINIC stand in der globalen Kette nicht mehr als offener regionaler Entscheidungspunkt aus. Das reduzierte Koordinationsunsicherheit, auch wenn NRO, ASO und ICANN ihre eigenen Akte noch durchführen mussten.

Diese Verteidigung verdient vollständige Anerkennung, weil die Chronologie weder Täuschung noch operative Unfähigkeit oder eine unzulässige globale Machtergreifung beweist. Lokale Implementierung vor dem endgültigen Inkrafttreten eines Mehrparteieninstruments ist in vielen technischen Systemen normal. Ein Teil kann bereit sein, während die gemeinsame Schaltung noch aussteht.

Gerade die Verteidigung macht aber eine Ebenenangabe notwendig. Wenn „Implemented“ regional gemeint war, hätte eine Bezeichnung wie „regionaler Richtlinienzyklus abgeschlossen“, „interne Betriebsbereitschaft“ oder „wirksam vorbehaltlich globaler Ratifikation“ die Leistung genauer beschrieben. Präzision wäre keine Herabsetzung AFRINICs gewesen. Sie hätte verhindert, dass spätere Leser dem Register einen globalen Akt zuschreiben, den es weder beanspruchen musste noch allein vollziehen konnte.

Die stärkste Einwendung gegen das Etikett

Die stärkste Einwendung lautet nicht, das Etikett sei falsch. Sie lautet, dass ein unqualifiziertes Implementierungswort institutionelle Ebenen zusammenzieht, die nachweislich getrennt waren. Wer den Archiveintrag ohne die Juni-Präsentation und die Juli- und September-Schritte liest, könnte annehmen, die geänderte IANA-zu-RIR-Regel sei am 26. Mai global wirksam geworden. Diese Lesart würde die noch ausstehende formelle Weitergabe, ICANNs spätere Ratifikation und die angekündigte Umsetzungsarbeit unsichtbar machen.

Ein zweites Risiko liegt in der Substitution von Sprache für Beobachtung. Ein Statusfeld kann Erwartungen verändern: Mitarbeiter könnten einen Vorschlag als operativ behandeln, Mitglieder könnten die weitere Verfügbarkeit kompatibler Ressourcen erwarten, und Partner könnten AFRINIC als fertigen regionalen Baustein verbuchen. Doch aus diesen möglichen Erwartungswirkungen folgt nicht, dass eine Datenbank, ein Formular, ein IANA-Zufluss oder ein Mitgliederergebnis am selben Tag anders war. Ohne eine Zustands- oder Transaktionsspur bleibt die operative Reichweite unbestimmt.

Das ist besonders wichtig, wenn knappe, technisch unterschiedlich brauchbare Bestände betroffen sind. Ein Register kann auf dem Papier genügend Nummern haben und dennoch mit einer betrieblichen Knappheit konfrontiert sein, wenn vorhandene Systeme einen Teil nicht verwenden können. Umgekehrt kann ein verlängertes Verwaltungsfenster auf dem Papier beruhigen, ohne die Produkte oder Konfigurationen der Betreiber zu reparieren. Das Etikett darf deshalb weder reale Vorbereitungsarbeit unsichtbar machen noch technische Wirkung simulieren.

Die angemessene Antwort ist keine Schuldzuweisung, sondern bessere Rechenschaft. Ein genauer Implementierungsnachweis würde zeigen, welcher Zustand auf welcher Ebene geändert wurde. Dann könnte die Öffentlichkeit regionale Bereitschaft, globale Wirksamkeit und reale Betreiberwirkung auseinanderhalten, ohne über die Lauterkeit einer Institution zu spekulieren.

Ein öffentliches Umsetzungsjournal als fehlendes Bindeglied

Ein belastbarer Eintrag sollte zuerst das Entscheidungsinstrument und den entscheidenden Träger nennen. Im vorliegenden Fall wären regionale technische Feststellung, Board-Genehmigung, regionale Statussetzung, NRO-Weitergabe, ASO-Prüfung, ICANN-Ratifikation und IANA-Umsetzung als getrennte Zeilen zu führen. Zu jeder Zeile gehören Quelle, Datum, Umfang und der Satz, was gerade noch nicht bewiesen ist.

Zweitens müssen Veröffentlichungs-, Genehmigungs-, Wirksamkeits- und Produktionszeitpunkte getrennt ausgewiesen werden. Wenn der 26. Mai nur das Datum der öffentlichen Archivänderung war, sollte das so stehen. Wenn er zugleich interne Wirksamkeit bedeutete, braucht es den autorisierenden Beschluss oder die Arbeitsanweisung. Wenn ein System erst später bereitgestellt wurde, ist auch dieses Datum eigenständig zu nennen. Eine einzige Spalte „Implemented“ kann diese Zustände nicht zuverlässig tragen.

Drittens gehört der konkrete Dienstumfang in das Journal. Betroffen sein könnten eine Arbeitsanweisung, ein Antragsformular, eine Bestandsklassifikation, eine Datenbanktabelle, ein API-Verhalten oder eine Schulungsunterlage. Das Journal muss nicht sensible Details oder personenbezogene Daten veröffentlichen. Es kann eine versionsbezogene Beschreibung und eine Prüfsumme des Änderungspakets liefern, aus der hervorgeht, dass eine bestimmte Prozedur zu einem bestimmten Zeitpunkt verändert wurde.

Viertens sind Abhängigkeiten nach oben sichtbar zu machen. Eine regionale Bereitschaftsmarke sollte den damaligen Status bei IANA, NRO, ASO und ICANN nennen. Ein einfacher Hinweis „regional abgeschlossen; globale Ratifikation ausstehend“ hätte die historische Mehrdeutigkeit weitgehend beseitigt. Nach der globalen Ratifikation müsste eine zweite Zeile dokumentieren, wann die Upstream-Bedingung erfüllt und mit dem regionalen Verfahren abgeglichen wurde.

Fünftens braucht die technische Begründung Tests. Für beide Kompatibilitätsklassen sollten Prüffälle, erwartete Ergebnisse und tatsächliche Resultate festgehalten werden. Bei einer administrativen Regel kann ein Test etwa zeigen, ob ein zulässiger Antrag aus der vorgesehenen Klasse ausgewählt, korrekt protokolliert und ohne falsche Bestandsvermischung abgeschlossen wird. Ein bestandenes Testprotokoll beweist noch keine Betreiberkompatibilität, aber es verbindet den Richtlinientext mit einem überprüfbaren Dienstzustand.

Sechstens sollten anonymisierte Transaktionsbeispiele und Kennzahlen folgen. Ein Beispiel vor und nach der Änderung kann zeigen, welche Verfahrensentscheidung tatsächlich anders ausfiel. Aggregierte Bearbeitungszeiten, Ergebnisgruppen und Bestände nach Kompatibilitätsklasse würden den Effekt sichtbar machen, ohne Halter zu identifizieren. Fehlen solche Fälle, sollte das Journal ausdrücklich sagen, dass die Änderung bereitstand, aber noch nicht an einer realen Transaktion beobachtet wurde.

Siebtens gehören Ausnahmen, Übergangsregeln, Rückfallbedingungen und das Auslaufen der Sonderbehandlung hinein. Die Änderung hatte einen klaren Endpunkt am 31. Dezember 2010. Deshalb musste nicht nur der verlängerte Zustand, sondern auch der Übergang zum undifferenzierten Pool ab 1. Januar 2011 vorbereitet werden. Ein Rückfallplan wäre relevant gewesen, falls Upstream-Verfahren oder regionale Systeme nicht rechtzeitig übereinstimmten.

Achtens sollten Betreiberprobleme und Abhilfekosten erfasst werden. Die Richtlinienbegründung beruht auf praktischer Kompatibilität, also muss der Erfolg an laufender Infrastruktur gemessen werden. Meldungen über unbrauchbare ASNs, erforderliche Geräte- oder Softwareanpassungen, Verzögerungen und Ersatzmaßnahmen wären die Belege, die eine Verwaltungsentscheidung mit ihrer wirtschaftlichen Wirkung verbinden.

Neuntens ist ein öffentliches Abweichungsregister nötig. Die Differenz zwischen dem ICANN-Datum 24. Mai und dem AFRINIC-Datum 25. Mai muss nicht dramatisiert werden. Sie sollte aber sichtbar bleiben, mit Quellenzuordnung und dem Hinweis, dass die Ursache unbekannt ist. Dasselbe gilt für die unterschiedlichen Dezember-Zeiträume. Korrekte Buchführung bedeutet nicht, jede Differenz sofort erklären zu können; sie bedeutet, sie nicht zu verbergen.

Zehntens vervollständigt eine unabhängige Prüfspur das Bild. Sie sollte die angekündigte Statusänderung mit einem beobachtbaren Zustand verbinden, die Grenzen der Prüfung nennen und ausdrücklich zwischen Dokumentenprüfung, Systemprüfung und Transaktionsprüfung unterscheiden. Eine solche Quittung würde AFRINIC vor überzogenen Zuschreibungen schützen und Betreibern zugleich eine belastbare Grundlage für Erwartungen geben.

Running Code setzt der Verwaltungssprache eine Grenze

Die Verlängerung reagierte auf die reale Differenz zwischen formal verfügbarem und praktisch nutzbarem Bestand. Das ist der Punkt, an dem laufende Systeme Vorrang vor institutioneller Sprache haben. Kein Implementierungsdatum kann die Bereitschaft eines Routers, einer Plattform oder eines betrieblichen Ablaufs herbeierklären. Eine zugeteilte Nummer, die in der tatsächlichen Umgebung nicht zuverlässig einsetzbar ist, erfüllt den Koordinationszweck nicht allein dadurch, dass sie in einem Register korrekt erscheint.

Umgekehrt ist die Registerarbeit nicht bedeutungslos. Eindeutigkeit, genaue Aufzeichnungen und ein abgestimmter Bestandsfluss sind Voraussetzungen dafür, dass Betreiber miteinander routen können. Ein privater Buchhalter erfüllt eine wichtige technische Aufgabe, wenn er Doppelvergabe verhindert, Daten korrekt führt und kompatible Verfahren zeitgerecht organisiert. Seine Leistung wird stärker, nicht schwächer, wenn sie an beobachtbare Ergebnisse gebunden wird.

Der Primat laufender Infrastruktur verlangt daher zwei getrennte Erfolgsfragen. Erstens: Hat AFRINIC seine eigenen Unterlagen und Verfahren so vorbereitet, dass die verlängerte Bestandsunterscheidung administrativ angewendet werden konnte? Zweitens: Hat diese Vorbereitung in realen Transaktionen und Netzen den beabsichtigten Nutzen erzeugt? Für den ersten Punkt ist der Status ein Indiz, aber kein vollständiger technischer Beleg. Für den zweiten Punkt fehlt im direkten Ereignisnachweis eine konkrete Betreiberquittung.

Diese Unterscheidung verhindert auch eine falsche ökonomische Schlussfolgerung. Man darf nicht aus dem Wort „Implemented“ ableiten, das Risiko legacy-kompatibler Knappheit sei gelöst gewesen. Die Verlängerung veränderte den Zeitrahmen der Inventarbehandlung; sie konnte den Übergang erleichtern. Ob und wie stark sie Kosten, Ausfälle oder Verzögerungen vermied, müsste durch Bestands- und Betreiberbelege gezeigt werden.

Konsens ist technischer Input, kein Souveränitätsersatz

Der 2009 festgestellte regionale Konsens war ein sinnvoller Bestandteil technischer Koordination. Er half, eine gemeinsame Problembeschreibung und einen Vorschlag zu formen. Daraus folgt aber kein Prinzipal, der AFRINIC eine allgemeine Herrschaftsvollmacht übertragen hätte. Der Konsens darf weder als einstimmige Zustimmung aller Mitglieder oder Betreiber noch als demokratische Vertretung Afrikas oder als rechtlich bindendes Mandat bezeichnet werden.

AFRINICs robuste Rolle ist enger und praktisch bedeutender: Es ist privater Buchhalter und Koordinator eindeutiger Nummernregistrierung. Es darf Aufzeichnungen pflegen, einen begrenzten Registrierungsdienst verwalten, Einzigartigkeit sichern und seine Verfahren mit anderen Stellen abstimmen. Es besitzt nicht die Netze der Betreiber und nicht die Nummernressourcen. Es kann für Afrika keine Gesetze erlassen, nicht als Staat regulieren, nicht polizeilich ermitteln, nicht anklagen, richten, bestrafen oder konfiszieren.

Diese Grenze verändert die Bewertung des 26. Mai. Ein privater Gesetzgeber, der eine globale Regel vorzeitig in Kraft setzte, wäre eine falsche Beschreibung. Ein regionaler Koordinator, der seinen eigenen Teil der gemeinsamen Buchführung abschloss und veröffentlichte, ist eine tragfähige Beschreibung. Der Wert des Akts liegt in Koordination und überprüfbarer Dienstbereitschaft, nicht in einem erfundenen Zwangsanspruch.

Auch die offiziellen Selbstauskünfte anderer Institutionen sind begrenzt zu verwenden. AFRINICs Status beweist, dass AFRINIC diesen Status veröffentlichte. Die ASO/NRO-Präsentation beweist den dort verzeichneten Verfahrensstand. ICANNs Mitteilung beweist die eigene Ratifikation und die angekündigten Schritte. Keine institutionelle Bezeichnung beweist aus sich heraus eine darüber hinausgehende Legitimität oder Befugnis. Für jede behauptete Macht ist das konkrete Instrument maßgeblich.

Fünf Gegenproben für die Reichweite

Eine erste Gegenprobe fragt, was geschehen wäre, wenn AFRINIC bis zur ICANN-Ratifikation jede interne Vorbereitung unterlassen hätte. In diesem Fall hätte der regionale Dienst nach dem globalen Abschluss erst mit Verfahrensprüfung, Schulung und Systemanpassung beginnen können. Eine Verzögerung wäre möglich gewesen, obwohl die sachliche Richtung regional längst geklärt war. Dieses Gegenbild stützt frühe Bereitschaft als legitime Koordinationsarbeit. Es stützt nicht die Behauptung, dass der globale Schritt dadurch früher wirksam wurde.

Die zweite Gegenprobe nimmt das andere Extrem: Alle Beobachter behandeln den 26. Mai als globales Inkrafttreten. Dann werden der NRO-EC-Transfer im Juli, die Prüfung und Weitergabe durch den ASO Address Council, ICANNs Schlusskommentierung und die Ratifikation im September zu scheinbar überflüssigen Nachspielen. Vor allem lässt sich die offizielle AFRINIC-12-Aussage nicht mehr sinnvoll erklären, wonach die formelle Weitergabe noch ausstand. Eine Deutung, die belegte Zwischenschritte unverständlich macht, ist schwächer als die schichtenspezifische Lesart.

Die dritte Gegenprobe setzt ein Ebenenetikett und eine Transaktionsspur gedanklich in den damaligen Eintrag ein. Hätte dort „regionaler Zyklus abgeschlossen; globale Weitergabe ausstehend“ gestanden und hätte eine zweite Zeile den ersten veränderten Dienstvorgang dokumentiert, gäbe es kaum Streit über das Wort. Regionale Leistung und globale Wirksamkeit könnten gleichzeitig anerkannt werden. Das zeigt, dass der Konflikt nicht zwangsläufig aus der Koordinationsarchitektur stammt. Er entsteht aus fehlenden Metadaten zwischen Entscheidung und beobachtbarem Zustand.

Die vierte Gegenprobe unterstellt, der 26. Mai habe keinerlei operative Änderung jenseits der Veröffentlichung gebracht. Selbst dann wäre der Eintrag nicht bedeutungslos. Eine öffentliche Statusänderung ordnet Erwartungen, signalisiert den Abschluss des regionalen Prozesses und gibt den anderen Beteiligten einen eindeutigen Bezugspunkt. Sie wäre aber eine schwache Quittung für technische Implementierung. Die korrekte Reaktion bestünde darin, den Governance-Akt zu würdigen und eine gesonderte Betriebsquittung zu verlangen, nicht darin, den historischen Eintrag als wertlos oder täuschend zu verurteilen.

Die fünfte Gegenprobe richtet den Blick auf eine spätere Machtbehauptung. Sollte ein heutiger Akteur aus der früheren Praxis ableiten, AFRINIC könne allein durch Statussetzung weitreichende Pflichten, Sanktionen oder Verfügungsrechte schaffen, bricht die Analogie zusammen. Der historische Fall trägt nur einen begrenzten Koordinations- und Buchführungsakt. Für jede heutige Befugnis bleibt das aktuelle Instrument erforderlich. Vergangene Verfahrenspraxis kann technische Erfahrung zeigen; sie ersetzt weder Autorisierung noch Gerichtsbeschluss, Vertrag oder Satzungsgrundlage.

Zusammen sichern die Gegenproben die Mitte gegen beide Übertreibungen. Sie verhindern, dass vorsorgliche regionale Arbeit als nichts abgetan wird, und sie verhindern, dass dieselbe Arbeit zur globalen oder hoheitlichen Wirkung aufgeblasen wird. Der beweisbare Wert des 26. Mai liegt genau in dieser begrenzten Zone.

Ein begrenztes, aber reales Urteil

Der 26. Mai 2010 ist als AFRINICs regionaler Implementierungsakt anzuerkennen. An diesem Tag war der Vorschlag in AFRINICs öffentlichem System nicht mehr bloß diskutiert oder genehmigt, sondern als implementiert klassifiziert. Damit hatte der regionale Koordinator seine Position in der globalen Kette festgelegt und den geänderten Text mit einem Datum versehen. Wer diesen Schritt als „nichts“ behandelt, übersieht die Fähigkeit institutioneller Buchführung, Erwartungen zu ordnen und Abhängigkeiten zu klären.

Das Urteil bleibt aber bewusst schmal. Der Eintrag ratifizierte die globale Richtlinie nicht. Er änderte nicht nachweislich das IANA-Verfahren, dokumentierte keine bestimmte Produktionsbereitstellung und zeigt keinen Antrag, der am 26. Mai anders behandelt wurde. Er beweist auch keinen Routererfolg und keine vermiedene Betreiberstörung. Für diese Aussagen fehlen die direkten Quittungen.

Die zeitliche Spannung ist somit keine Grundlage für eine Anschuldigung. Sie ist ein Lehrstück in sauberer Ebenenzuordnung. AFRINIC konnte regional fertig sein, während die globale Kette noch lief. Der Fehler entsteht erst, wenn ein Leser oder eine Institution aus dem regionalen Status einen umfassenderen Akt macht, als die Dokumente tragen.

Die faire Schlussformel lautet: Der private Buchhalter hat seinen eigenen Richtlinienzyklus abgeschlossen und öffentlich markiert; der globale Koordinationsprozess war noch nicht abgeschlossen. Was in AFRINICs Verfahren, Systemen oder einzelnen Transaktionen am 26. Mai technisch verändert wurde, bleibt unbewiesen. Eine präzise Umsetzungsakte könnte diese drei Sätze nebeneinanderstellen, statt sie in einem einzigen Statuswort zu verstecken.