Zusammenfassung

  • AFRINICs Vorstand ratifizierte AFPUB-2018-V6-004-DRAFT01 am 8. August 2018, doch das aktuelle Beschlussregister nennt dafür 201808.448, während die genehmigten Protokolle denselben Vorgang als 201808.449 ausweisen. Keine der geprüften Primärunterlagen stützt die gelegentlich genannte Nummer 201809.448.
  • Die Ratifikation war kein selbstvollziehender Betriebszustand. Die Protokolle trennten Benachrichtigung und Umsetzung in den Action Items 201808.22 und 201808.23 ab; das CPM v1.3 nahm die Abschnitte 6.8–6.8.4 am 1. November auf; AFRINIC-29 meldete die Aktualisierung Ende November dennoch als noch in Umsetzung, weil Prüfungen zu Routing und Nicht-Disaggregation automatisiert werden sollten.
  • Inhaltlich eröffnete die Änderung Endstandorten einen IPv6-PI-Weg ohne frühere IPv4-PI-Zuteilung, hielt eine anfängliche Zuteilung von /48 oder bei Begründung eines kürzeren Präfixes fest und schuf eine einmalige Berichtigung. Das sind nachvollziehbare Regeln eines privaten, freiwilligen Registrierungsdienstes, aber keine Grundlage für Souveränität, Regulierung, Polizeigewalt, Bestrafung, Konfiskation oder öffentlich-rechtliche Rechtsprechung.

Analyse: Der Beschluss, dessen Akte sich selbst widerspricht

Wer den Vorgang auf eine einzige Nummer reduzieren will, scheitert bereits an AFRINICs eigenen veröffentlichten Unterlagen. Im heute zugänglichen Register für die Vorstandssitzungen des Jahres 2018 steht die Ratifikation des „IPv6 PI Update“ AFPUB-2018-V6-004-DRAFT01 unter Resolution 201808.448. Das genehmigte Protokoll der Sitzung vom 7. und 8. August in Mauritius ordnet demselben Tagesordnungspunkt 9.3 dagegen Resolution 201808.449 zu. Im aktuellen Register ist 201808.449 wiederum kein zweites Etikett für die PI-Aktualisierung, sondern die Ermächtigung des CEO, eine Gastgebervereinbarung für AFRINIC-29 zu unterzeichnen.

Beide Darstellungen können in ihrer gedruckten Zuordnung nicht gleichzeitig richtig sein.

Der Widerspruch lässt sich mit den vorliegenden Belegen nicht seriös wegredigieren. Im September billigte Resolution 201809.450 die August-Protokolle „mit Änderungen“. Welche Änderungen vorgenommen wurden, legt der untersuchte öffentliche Datensatz nicht offen. Deshalb darf weder angenommen werden, dass die spätere Genehmigung die Nummer im Protokoll stillschweigend korrigierte, noch dass sie die Registernummer bestätigte. Ebenso wenig existiert in den geprüften Primärquellen ein Beleg für „Resolution 201809.448“.

Diese Bezeichnung kombiniert offenbar einen Septembercode mit der Endziffer des Registereintrags, ohne dass ein entsprechendes Instrument nachgewiesen wäre. Eine saubere Darstellung muss die zwei vorhandenen Nummern nebeneinander stehen lassen und die nicht belegte dritte ausdrücklich verwerfen.

Für einen Betreiber ist diese Genauigkeit keine Archivarromantik. Eine Beschlussnummer dient als stabiler Zeiger: Sie soll erkennen lassen, welcher Text von welchem Organ zu welchem Zeitpunkt angenommen wurde. Wenn Register und genehmigtes Protokoll verschiedene Zeiger für denselben Vorgang setzen, kann ein Antragsteller nicht aus der Nummer allein ableiten, welcher Stand für eine Bestellung, eine Adressplanung oder einen internen Genehmigungsprozess galt.

Der vernünftige Weg führt deshalb über die gesamte Dokumentenkette: eindeutige Proposal-Kennung, Datum und Tagesordnungspunkt des Vorstandsakts, nachgelagerte Action Items, datierte Fassung des Handbuchs und dokumentierter Umsetzungsstand. Gerade weil diese Kette mehr als ein Dokument umfasst, gibt es hier kein magisches Stichtagsartefakt.

Die erste Stufe dieser Kette war der Vorschlag, nicht der Vorstandsbeschluss. AFPUB-2018-V6-004-DRAFT01 wurde am 28. März 2018 als „IPv6 PI Update“ veröffentlicht und zielte auf Artikel 6.8 des Consolidated Policy Manual. Bei AFRINIC-28 am 9. Mai wurde festgehalten, dass der Entwurf die bisherige Abhängigkeit von einer IPv4-PI-Vergangenheit beseitigen und eine Berichtigung der anfänglichen IPv6-PI-Zuteilung ermöglichen sollte. Der Autor erklärte dort außerdem, das Material zum HD-Ratio bleibe erhalten und die Mitarbeiter würden nicht angewiesen, das Routing zu überwachen.

Eine Wortmeldung widersprach der damaligen Fassung; die Co-Chairs leiteten den Vorschlag anschließend in den Last Call weiter.

Diese Ereignisse beschrieben einen privaten Verfahrensweg. Die Veröffentlichung machte Text prüfbar, die Sitzung machte Einwände sichtbar und der Last Call markierte eine weitere Prozessphase. Keines dieser Ereignisse war bereits die Ratifikation, keines war die Aufnahme in das Handbuch, und keines belegte, dass eine betriebliche Anwendung verfügbar war. Auch die Weiterleitung durch die PDWG-Co-Chairs war nicht mit einer Entscheidung eines öffentlichen Gesetzgebers gleichzusetzen. Sie war eine Handlung innerhalb des von AFRINIC dokumentierten Policy-Prozesses, deren Bedeutung sich auf die Organisation und ihren angebotenen Dienst beschränkte.

Die zweite Stufe war der Vorstandsvorgang am 8. August. Das Protokoll zeigt, dass der Vorstand den Vorschlag unter Tagesordnungspunkt 9.3 behandelte. Die veröffentlichte operative Formulierung bleibt eng: Nach Erwägungen über den Abschluss des PDP, einen festgestellten Konsens und die Weiterleitung durch die PDWG-Co-Chairs ratifizierte der Vorstand den Vorschlag. Das Protokoll nennt SO als Antragsteller und SI als Unterstützer. Es enthält nach diesem Punkt jedoch weder eine Abstimmungszahl noch den ausdrücklichen Satz über eine einstimmige Annahme, der bei den zwei unmittelbar vorangehenden Policy-Punkten auftaucht.

Daraus folgt keine Behauptung über Dissens; es folgt lediglich, dass Einstimmigkeit für diesen Punkt nicht als erwiesene Tatsache ausgegeben werden darf.

Entscheidender als eine spekulative Abstimmungsarithmetik ist die Struktur der Folgeaufträge. Action Item 201808.22 beauftragte den Vorsitz, die PDWG-Co-Chairs über die Ratifikation zu informieren. Action Item 201808.23 beauftragte die Mitarbeiter, die ratifizierten Policies umzusetzen. Schon die Existenz dieser gesonderten Aufgaben widerlegt die Vorstellung, der Abstimmungsakt habe den gesamten technischen und administrativen Zustand in derselben Sekunde hergestellt. Der Vorstand konnte den Text als interne Unternehmensentscheidung annehmen; die Organisation musste die Annahme danach kommunizieren und in ihre Dienstleistung überführen.

Die Mitteilung des Vorsitzenden vom 21. August macht diese Trennung noch deutlicher. Sie bestätigte, dass V6-004 bei der Sitzung vom 8. August ratifiziert worden war, und kündigte an, die Mitarbeiter würden mit der Umsetzung fortfahren und die Community nach erfolgter Implementierung informieren. Das Futur zählt. Wer sagt, die Regel sei mit der Ratifikation vollständig wirksam geworden, muss erklären, warum die Organisation knapp zwei Wochen später ihre Implementierung als folgende Arbeit und eine spätere Vollzugsmeldung ankündigte.

Die belastbare Antwort lautet: Der Unternehmensakt war notwendig für den internen Prozess, aber nicht identisch mit der abgeschlossenen betrieblichen Ausführung.

Die dritte Stufe erschien am 1. November. Die Versionsgeschichte des CPM v1.3 verzeichnet an diesem Datum die Aufnahme des IPv6 PI Update. Die Änderung betraf die Abschnitte 6.8, 6.8.1, 6.8.2 und 6.8.3 und fügte Abschnitt 6.8.4 hinzu. Damit war der Regeltext nicht mehr nur als Proposal und ratifizierter Gegenstand auffindbar, sondern in einer datierten, konsolidierten Manualfassung. Für Betreiber war das ein wesentlicher Fortschritt: Eine Version des Handbuchs kann zitiert, archiviert und gegen frühere oder spätere Fassungen abgegrenzt werden. Sie macht die interne Dienstregel lesbarer als eine lose Folge von Sitzungsdokumenten.

Doch auch die Handbuchaufnahme war nicht das Ende der Kette. Die vierte Stufe ist der Bericht von AFRINIC-29 Ende November. Dort wurde das IPv6 PI Update weiterhin als „under implementation“ beschrieben. Ausstehend war die Automatisierung von Policy-Anforderungen, die Prüfungen betrafen, ob zugeteilter PI-Raum geroutet und nicht disaggregiert werde. Sowohl die Veranstaltungszusammenfassung als auch ihre PDF-Fassung tragen diese Qualifikation.

Der Bericht nennt jedoch nicht, welche Klauseln zu diesem Zeitpunkt bereits manuell bearbeitet werden konnten, welche Antragsarten warten mussten oder an welchem späteren Datum die Automatisierung fertiggestellt wurde. Deshalb darf die Lücke weder dramatisiert noch geschlossen werden. Bewiesen ist ein noch unvollständiger Automatisierungsstand; nicht bewiesen ist ein totaler Stillstand des Dienstes.

Aus diesen vier Stufen ergibt sich eine nüchterne Zustandslehre. Ein Proposal ist ein vorgeschlagener Text. Last Call ist eine dokumentierte Prozessphase. Eine Empfehlung oder Weiterleitung der Co-Chairs ist ein interner Verfahrensschritt. Eine Vorstandsratifikation ist eine körperschaftliche Annahme. Ein Action Item ist ein Arbeitsauftrag. Eine neue CPM-Version ist ein veröffentlichter Textzustand. Ein Implementierungsbericht beschreibt einen betrieblichen Reifegrad.

Erst wenn diese Kategorien getrennt bleiben, können Antragsteller, Netzplaner, Auditoren und Gegenparteien verstehen, was zu einem bestimmten Zeitpunkt tatsächlich belastbar war.

Das bedeutet nicht, dass jeder Unterschied zwangsläufig einen Schaden verursachte. Die Quellen enthalten keine Antragsdaten, mit denen sich Verzögerungen, Ablehnungen oder Mehrkosten einem konkreten Unternehmen zuordnen ließen. Sie quantifizieren auch weder Bearbeitungszeiten noch Gebühren, Zahl der Berichtigungen oder vermiedene Umnummerierungen. Der saubere Befund ist enger: Die veröffentlichte Dokumentenkette lässt mehrere Statusschritte erkennen, der Nummernkonflikt bleibt ungelöst, und die Automatisierung war Ende November noch nicht abgeschlossen.

Diese drei Tatsachen reichen aus, um pauschale Aussagen über ein einziges vollwirksames Datum zurückzuweisen, ohne eine Absicht, Manipulation oder konkrete Schädigung zu unterstellen.

Das Jahresberichtsmaterial für 2018 ändert daran nichts. Es verbindet das IPv6 PI Update mit der Ratifikation im August und den CPM-Abschnitten 6.8–6.8.4. Als Jahreszusammenfassung bestätigt es damit den allgemeinen Pfad. Es löst aber weder den Gegensatz zwischen 201808.448 und 201808.449 noch die Frage, wann die noch ausstehende Automatisierung abgeschlossen wurde. Ein Rückblick kann die Existenz eines Vorgangs bestätigen, ohne die feineren Zustände seiner Ausführung zu beweisen.

Auch spätere Erläuterungen dürfen nicht rückwärts in das Jahr 2018 projiziert werden. Ab 2019 und besonders durch die spätere IPv6 PI Clarification wurden Teile des Regimes weiter beschrieben oder verändert. Solche späteren Texte mögen für einen späteren Antrag wichtig sein. Sie sind aber kein Beleg dafür, was genau am 8. August beschlossen, am 1. November in v1.3 aufgenommen oder Ende November technisch verfügbar war. Versionstreue bedeutet, den jeweils datierten Text in seinem eigenen Zeitraum zu lesen. Ohne sie verwandelt sich eine nachvollziehbare Entwicklung in eine künstlich glatte Gegenwartserzählung.

Für die praktische Prüfung eines historischen Antrags wären deshalb mindestens fünf Fragen getrennt zu beantworten. Erstens: Welcher Proposal-Text war Gegenstand der Behandlung? Zweitens: Welcher Unternehmensakt nahm ihn an, und wie ist der Nummernkonflikt zu kennzeichnen? Drittens: Welche Manualversion enthielt welche Klauseln? Viertens: Welche Funktionen waren zum fraglichen Zeitpunkt manuell oder automatisiert verfügbar? Fünftens: Welche spätere Erläuterung gehört nicht in die frühere Beurteilung? Der vorliegende Datensatz beantwortet die ersten drei weitgehend, die vierte nur teilweise und zwingt bei der fünften zur Zurückhaltung.

Gerade diese Begrenzung ist ein Zeichen belastbarer Analyse.