Zusammenfassung

  • Der Versionssprung war eng und beweisbar. Die Revisionshistorie von AFPUB-2019-V4-003-DRAFT03 nennt für Version 3 ausschließlich die Abschnitte 5.7.3.2 und 5.7.4.3. Die erste Änderung legte nach einer genehmigten Übertragung eine zwölfmonatige Phase fest, in der die Quelle keine weiteren AFRINIC-IPv4-Zuteilungen oder -Zuweisungen erhalten sollte. Die zweite kehrte die in Draft 2 vorgesehene Folge um, nach der übertragene Legacy-Ressourcen ihren Legacy-Status verloren hätten. Änderungen an der Compliance-Klausel für die Quelle in 5.7.3.1 oder an der Bedarfsprüfung in 5.7.4.1 gehörten dagegen zu Draft 2 und dürfen nicht Draft 3 zugerechnet werden.

  • Die beiden Korrekturen lösten nicht das Interoperabilitätsproblem. Draft 3 verlangte weiterhin, dass die übertragende Quelle als rechtmäßiger, bei irgendeinem RIR registrierter Halter die Regeln des empfangenden RIR erfüllt und nicht in einen Streit über die Ressourcen verwickelt ist. Das Verfahren wies die Quelle zudem an, den Antrag beim empfangenden RIR einzureichen. Damit sollte eine private Einrichtung eine auswärtige Partei prüfen, zu der sie möglicherweise keine Dienstbeziehung, keine vertragliche Grundlage und keinen vollständigen Nachweiszugang hatte. Das war nicht bloß eine andere Formulierung desselben Ablaufs, sondern eine abweichende Zuordnung von Prüfverantwortung.

  • Die offizielle Mitarbeiterbewertung dokumentierte den Bruch über alle vier Gegenregister hinweg. AFRINIC hielt am 13. Oktober 2020 fest, dass ARIN und APNIC die Quellen-Compliance als inkompatibel einstuften, LACNIC keine Pflicht seiner Quelle kannte, die Regeln des anderen RIR einzuhalten, und RIPE NCC den in 5.7.5 beschriebenen Beginn beim empfangenden RIR als inkompatibel und nicht umsetzbar ansah. Die Mitarbeiter erklärten den praktisch üblichen Zuschnitt: Jedes RIR bearbeitet die übertragende oder empfangende Partei innerhalb seiner eigenen Beziehung; die Register kommunizieren miteinander. Diese Befunde sind dokumentierte Verfahrenseinschätzungen, keine universelle Rechtsentscheidung.

  • Der wirtschaftliche Schaden entsteht an der Abwicklungsgrenze. Globales Routing, private Vereinbarung und Registeranerkennung sind unterschiedliche Ebenen. Wenn die operative Kontrolle wechselt, die Register aber keine gemeinsame wirksame Änderung darstellen können, entstehen Risiken für Registrierung, Reverse DNS, RPKI-ROAs, Transferprotokolle, Vertragsprüfung und Betriebskontinuität. Mehr Ungewissheit bedeutet mehr Zeit für Rechtsprüfung, Vermittlung und Treuhandabwicklung sowie einen Abschlag auf unklare anerkannte Kontrolle. Die vorhandenen Unterlagen messen für Draft 3 allerdings weder Preis- noch Mengen-, Verzögerungs- oder Schadenseffekte; der Mechanismus ist plausibel, sein Umfang bleibt unbelegt.

  • Der stärkste wohlwollende Fall verdient eine echte Antwort. AFRINIC und die anderen RIRs mussten Betrug, doppelte Ansprüche, umstrittene Ressourcen und widersprüchliche Datensätze vermeiden. Eine Sperrfrist konnte als Schutz gegen sofortige Rückkehr zum knappen freien Bestand gedacht sein; eine Bedarfsprüfung konnte aus Sicht des Empfängerregisters dessen eigene Vergaberegeln schützen; Reziprozität konnte verhindern, dass nur eines von zwei Büchern eine Veränderung anerkennt. Aber Anti-Zyklen-Regel, Empfängerberechtigung, Legacy-Status und bilaterales Datenaustauschprotokoll sind vier verschiedene Kontrollen. Ihre Zwecke dürfen nicht zu einer grenzenlosen Zuständigkeit verschmolzen werden.

  • Die minimale legitime Architektur ist bilateral und beziehungsnah. Das Quellregister prüft Identität, anerkannte Kontrolle, Ressourcenbezug und bekannte Konfliktmerkmale seiner eigenen Partei. Das Zielregister prüft die Angaben, die es für die freiwillige Dienstbeziehung mit dem Empfänger benötigt. Beide Register tauschen authentisierte Bestätigungen und einen gemeinsamen Wirksamkeitszeitpunkt aus und aktualisieren Registrierung, Reverse DNS, RPKI sowie Transferhistorie konsistent. Mängel brauchen Gründe und einen Heilungsweg; echte konkurrierende Ansprüche brauchen einen transparenten Halt und einen unabhängigen Klärungsweg. Diese technische Koordination erzeugt weder Eigentum noch Hoheitsgewalt.

Der enge Gegenstand: Was Version 3 tatsächlich beanspruchen darf

Der Name „Resource Transfer Policy Draft 3“ lädt zu einer zu großen Erzählung ein. Er klingt nach einer vollständigen dritten Architektur, vielleicht sogar nach einem reifen Wendepunkt in der Geschichte regionalübergreifender IPv4-Übertragungen. Die Revisionshistorie erlaubt eine solche Lesart nicht. Version 3 war ein gezielter Eingriff in zwei Stellen eines bereits bestehenden Entwurfs. Gerade diese Enge macht den Vorgang analytisch wertvoll: Man kann beobachten, welche unmittelbaren Folgen korrigiert wurden und welche strukturelle Fehlzuordnung unangetastet blieb.

Die offizielle Archivseite bezeichnet den Text als AFPUB-2019-V4-003-DRAFT03, Version 3.0, verfasst von Anthony Ikechukwu Ubah und Taiwo Oyewande, und ordnet ihn einer vorgeschlagenen Änderung von CPM 5.7 zu. Schon beim Datum ist Genauigkeit wichtiger als eine glatte Erzählung. Das Feld „Details“ nennt den 22. September 2020 als Einreichungsdatum; die Revisionshistorie datiert Version 3 auf den 21. September. Die überlieferten Unterlagen lösen diese Abweichung von einem Tag nicht auf. Ein seriöser Bericht bewahrt deshalb beide Angaben, statt sich scheinpräzise für eines zu entscheiden.

Ebenso klar ist die sachliche Begrenzung. Die Revisionshistorie sagt, Version 3 habe nur 5.7.3.2 und 5.7.4.3 aktualisiert. Andere Teile des Textes waren für die spätere Kompatibilitätsbewertung entscheidend, aber sie waren keine Änderungen von Draft 3. Das betrifft insbesondere 5.7.3.1, wo die Quelle als rechtmäßiger, bei einem RIR registrierter Halter beschrieben wurde, die Regeln des empfangenden RIR erfüllen sollte und keinem Streit über die Ressourcen ausgesetzt sein durfte. Es betrifft auch 5.7.4.1, das für eingehende Übertragungen eine Bedarfsprüfung vorsah und ausgehende Übertragungen nach der Politik des empfangenden RIR behandelte.

Nach der offiziellen Versionsgeschichte waren diese Elemente in Draft 2 verändert worden.

Diese Unterscheidung ist mehr als pedantische Versionspflege. Wer die später als inkompatibel bewertete Compliance-Klausel zu einer Neuerung von Draft 3 erklärt, erweckt den Eindruck, Version 3 habe den Bruch erst hergestellt. Wer die Bedarfsprüfung als neue Reaktion von Version 3 schildert, konstruiert eine politische Ursache, die die Quellen nicht belegen. Tatsächlich erbte Draft 3 die problematische Zuordnung aus seinem unmittelbaren Vorgänger und veränderte zwei andere Folgen. Der analytische Befund lautet deshalb nicht, dass zwei neue Regeln die Brücke zerstörten.

Er lautet, dass zwei erkennbare Korrekturen vorgenommen wurden, ohne die bereits sichtbare Fehlverdrahtung der Brücke zu beheben.

Auch der Status des Textes muss schmal bleiben. Die Unterlagen belegen seine Veröffentlichung, den Wortlaut, die Revisionsangaben und die Mitarbeiterbewertung. Sie belegen keine Annahme, Ratifikation oder Implementierung. Sie weisen keine abgeschlossene oder abgelehnte Transaktion nach, die nach Draft 3 bearbeitet worden wäre. Sie zeigen keinen Preis, der durch den Entwurf stieg oder fiel, keinen Halter, der einen Vermögensverlust erlitt, und kein Gericht, das eine Eigentumsfrage entschied.

Die Reichweite der Analyse entsteht aus dem Design und den dokumentierten Rückmeldungen, nicht aus einem nachträglich behaupteten Erfolg oder Scheitern im Markt.

Damit steht die Leitfrage fest. Draft 3 ist weder als umfassende Transfergeschichte noch als späteres institutionelles Drama zu lesen. Zu prüfen sind allein der Wechsel von Draft 2 zu Version 3 und die Frage, ob diese beiden Veränderungen den reziproken Übergang zwischen privaten Registern funktionsfähig machten. Der Maßstab dafür ist nicht politische Einigkeit, sondern praktische Kompatibilität: Kann jedes Register die Partei prüfen, zu der es Zugang und eine Dienstbeziehung hat? Können beide Register dieselbe Ressourcenänderung authentisiert bestätigen?

Können ihre Systeme zu einem gemeinsamen Zeitpunkt konsistente, nicht doppelte und nicht veraltete Datensätze führen?

Die unmittelbare Vorgeschichte: ein Draft-2-Protokoll, kein Draft-3-Votum

Am 13. August 2020 wurde Draft 2 eingereicht. Seine Revisionshistorie nennt Änderungen an 5.7.3.1, 5.7.4.1 und 5.7.4.3. Am 16. und 17. September befasste sich AFRINIC-32 mit diesem Draft 2. Das zeitliche Zusammentreffen mit Version 3 wenige Tage später ist auffällig, erlaubt aber nur Chronologie. Die Sitzungsminuten dokumentieren keine Debatte über Draft 3, denn dieser Text lag dort nicht als Gegenstand vor. Ebenso wenig lässt sich aus der zeitlichen Nähe ableiten, dass eine bestimmte Wortmeldung eine der beiden späteren Änderungen verursacht habe.

Was die Minuten leisten, ist dennoch wichtig. Sie machen sichtbar, welche praktischen Fragen bereits an der Draft-2-Architektur hafteten. Die Autoren erklärten die Notwendigkeit von Reziprozität. Teilnehmer fragten nach der Pflicht einer Quelle, Regeln eines ausländischen RIR einzuhalten, nach dem direkten Kontakt mit dem empfangenden RIR, nach einer angeblich standardisierten Vorlage, nach Bedarfsanforderungen, umstrittenen Ressourcen, dem Umfang in Bezug auf ASN und der Behandlung von Legacy-Ressourcen. Die Minuten halten zudem fest, dass der veröffentlichte Text in Punkten nicht mit mündlichen Erläuterungen oder Folien übereinstimmte.

Diese Beobachtung verschärft die Notwendigkeit, den geschriebenen Wortlaut und nicht eine vermutete Absicht zum Maßstab zu nehmen.

„Reziprozität“ war in diesem Kontext ein sinnvolles Zielwort, aber kein fertiges Protokoll. Für einen regionalübergreifenden Transfer genügt es nicht, dass beide RIRs grundsätzlich Transferpolitik kennen oder einander abstrakt anerkennen. Sie müssen kompatibel festlegen, wer wen prüft, wohin der Antrag gelangt, welche Belege zwischen den Registern ausgetauscht werden und wann die Änderung für beide Bücher wirksam wird. Wenn ein Text diese Verantwortlichkeiten anders verteilt als die Gegenstelle, ist die Beziehung nicht allein deshalb reziprok, weil beide Seiten dasselbe Endergebnis wünschen.

Die Draft-2-Minuten zeigen genau diese Spannung zwischen Ziel und Schnittstelle. Die Quelle stand in der Beziehung zu ihrem bisherigen Register. Das empfangende RIR stand in der Beziehung zum künftigen Empfänger. Ein Verfahren, das die Quelle direkt an das Zielregister verweist oder ihr die Regeln dieses Registers auferlegt, überspringt den institutionellen Anschluss, an dem Identität, Kontohistorie, bestehende Registrierung und Konflikthinweise am verlässlichsten geprüft werden können. Das ist keine Frage, ob das eine RIR moralisch vertrauenswürdiger oder politisch repräsentativer ist als das andere.

Es ist eine Frage des Nachweiszugangs und der vertraglichen Beziehung.

Gleichzeitig enthalten die Einwände keinen Beweis dafür, dass jede Bedarfsprüfung, jede Sperrfrist oder jede Statusregel unzulässig wäre. Ein Zielregister kann für seine eigene freiwillige Dienstleistung Angaben vom Empfänger verlangen. Ein Quellregister kann eine prospektive Regel für den erneuten Zugang zu seinem noch verfügbaren Bestand definieren. Beide können prüfen, ob dieselben Adressen doppelt beansprucht werden oder ein offener Konflikt vorliegt.

Problematisch wird es, wenn solche voneinander verschiedenen Zwecke in einer vermeintlichen interregionalen Zuständigkeit aufgehen: Dann soll das Zielregister nicht nur seinen Empfänger prüfen, sondern auch eine fremde Quelle beherrschen, oder das Quellregister soll nicht nur sein Buch korrigieren, sondern über eine private Transaktion jenseits technischer Konsistenz urteilen.

Die kurze Septemberfolge ist deshalb mit Disziplin zu lesen. Draft 2 war am 13. August eingereicht worden. AFRINIC-32 erörterte ihn am 16. und 17. September. Das Archiv versieht Version 3 mit dem 21. September, während das Detailfeld den 22. September nennt. Mehr lässt sich zur Kausalität nicht sicher sagen. Die Minuten geben Kontext für bereits erkannte Reibungen und helfen zu verstehen, warum die später beibehaltenen Klauseln wichtig waren. Sie sind aber weder ein Abstimmungsprotokoll über Version 3 noch ein Beleg dafür, dass ein bestimmter Teilnehmer die Zwölfmonatsregel oder die Legacy-Korrektur hervorgebracht hätte.

Zwei Änderungen: Sperrfrist und Erhalt des Legacy-Status

Die erste tatsächliche Änderung lag in 5.7.3.2. Draft 2 hatte vorgesehen, dass eine Quelle für weitere AFRINIC-IPv4-Zuteilungen oder -Zuweisungen sofort wieder in Betracht kommen konnte, solange sie die geltende Politik erfüllte. Draft 3 ersetzte diesen Ansatz durch eine zwölfmonatige Phase der Nichtberechtigung nach einer genehmigten Übertragung. Im praktischen Bild sollte eine Partei nicht Ressourcen übertragen und unmittelbar danach wieder auf AFRINICs Zuteilungsdienst zugreifen können.

Der wohlwollende Zweck ist leicht zu erkennen, auch wenn seine tatsächliche Wirkung nicht gemessen wurde. Solange ein Register noch knappen freien Bestand verteilt, könnte eine sofortige Rückkehr nach einer Übertragung als unerwünschter Kreislauf erscheinen: Eine Organisation gibt Adressen in einer privaten Transaktion weiter und beantragt kurz danach erneut Ressourcen aus einem zugeteilten Pool. Eine zeitliche Sperre trennt diese Schritte und erhöht die Kosten eines solchen Musters. Als prospektive Bedingung für einen späteren AFRINIC-Dienst kann sie enger verstanden werden als ein Verbot der Transaktion selbst.

Doch diese Unterscheidung muss im Text und in der Anwendung bestehen bleiben. Die Sperre betrifft die erneute Berechtigung für AFRINIC-Zuteilungen oder -Zuweisungen; sie schafft weder ein Eigentumsrecht des Registers an den übertragenen Adressen noch eine Strafgewalt über die Quelle. Ohne Daten ist nicht belegt, wie häufig der befürchtete Kreislauf war, ob zwölf Monate die richtige Frist darstellten oder welche betrieblichen Kosten legitime Quellen dadurch tragen würden.

Eine technisch und institutionell verantwortbare Regel müsste ihren Zweck benennen, prospektiv gelten, vorhersehbar angewendet werden und einen nachvollziehbaren Weg für die Korrektur gewöhnlicher Fehler bieten. Sie dürfte nicht als moralische Sanktion gegen Marktteilnahme umgedeutet werden.

Die zweite Änderung lag in 5.7.4.3. Draft 2 hatte erklärt, dass übertragene IPv4-Legacy-Ressourcen nach der Übertragung nicht länger als Legacy gelten würden. Draft 3 kehrte diese Folge um: Übertragene Legacy-Ressourcen sollten Legacy-Ressourcen bleiben. Damit beseitigte Version 3 einen unmittelbaren Statusverlust, der allein an die Übertragung geknüpft gewesen wäre.

Auch diese Korrektur hatte einen klaren begrenzten Sinn. Ein historischer Status beschreibt, unter welchen Umständen Ressourcen ursprünglich registriert oder verwaltet wurden. Wenn eine Transaktion diesen Status automatisch auslöscht, kann sie zusätzliche Unsicherheit über Dienstbedingungen, Dokumentation und Behandlung beim Gegenregister erzeugen. Die Bewahrung des Status nimmt eine solche automatische Folge aus dem Weg. Sie verhindert, dass Portabilität allein deshalb mit einem Identitätswechsel des Ressourcenbestands erkauft werden muss.

Aber Legacy-Erhalt ist nicht dasselbe wie Interoperabilität. Er beantwortet nicht, welches Register die Quelle authentisiert, welche Empfängeranforderungen gelten, wie ein Konflikt gekennzeichnet wird, wie die Register ihre Zustimmung austauschen oder wann RPKI- und Reverse-DNS-Daten umgestellt werden. Er beweist auch nicht, wie ein anderes RIR eine tatsächlich abgeschlossene Übertragung behandelt hätte. Draft 3 beseitigte eine statusbezogene Hürde, ließ aber die verfahrensbezogene Zuordnung bestehen.

Die beiden Änderungen stehen somit auf unterschiedlichen Kontrollflächen. Die Zwölfmonatsregel betrifft den späteren Zugang der Quelle zu einem AFRINIC-Dienst. Die Legacy-Klausel betrifft die Fortdauer einer historischen Kennzeichnung. Keine von beiden ordnet die bilaterale Prüfung neu. Keine weist das Quellregister ausdrücklich an, seine eigene Partei zu prüfen und eine authentisierte Bestätigung an das Zielregister zu senden. Keine ersetzt die direkte Initiierung beim empfangenden RIR durch einen Anschluss am Register der Quelle.

Daher konnten beide Änderungen vernünftig oder zumindest nachvollziehbar sein und die Brücke trotzdem unbrauchbar lassen.

Gerade hier liegt der Wert einer klauselscharfen Analyse. Politische Texte werden häufig als Paket verteidigt: Betrugsprävention, Knappheitsschutz, Statuskontinuität und Reziprozität erscheinen dann als ein gemeinsames Gemeinwohlziel. Doch ein gutes Ziel in einer Klausel heilt keine falsche Zuständigkeitsverteilung in einer anderen. Draft 3 reduzierte zwei konkrete Belastungen beziehungsweise Risiken. Ob die Register denselben Transfer tatsächlich abbilden konnten, hing weiterhin von den geerbten Klauseln ab.

Der Befund vom 13. Oktober: vier Gegenstellen, ein Zuordnungsfehler

Die Mitarbeiterbewertung auf der offiziellen Draft-3-Seite ist auf den 13. Oktober 2020 datiert. Sie enthält Fragen zur Klarstellung, Umsetzungsaspekte und Rückmeldungen zur Kompatibilität. Ihr besonderer Wert besteht darin, dass sie nicht nur abstrakt vor unterschiedlichen RIR-Regeln warnt, sondern die Reaktionen der vier möglichen Gegenregister nennt.

ARIN und APNIC stuften nach der von AFRINIC festgehaltenen Rückmeldung die Quellen-Compliance-Klausel als inkompatibel ein. LACNIC erklärte, seine Politik verlange von der Quelle nicht, die Regeln des anderen RIR zu erfüllen. RIPE NCC sah das in Abschnitt 5.7.5 beschriebene Verfahren, bei dem die übertragende Partei den Antrag an das empfangende RIR senden sollte, als inkompatibel und nicht umsetzbar an. Damit lag keine Randabweichung mit einem einzelnen Gegenüber vor. Die Mitarbeiterakte dokumentierte materielle Brüche mit ARIN, APNIC, LACNIC und RIPE NCC, also allen vier genannten regionalen Gegenstellen.

Diese Rückmeldungen sollten weder verkleinert noch überhöht werden. Sie beweisen, dass AFRINICs Mitarbeiter bei den Gegenregistern konkrete Unvereinbarkeiten ermittelten und festhielten. Sie sind kein Gerichtsurteil und keine universelle rechtliche Bestimmung darüber, welche Institution „zuständig“ sein müsse. Ihr Gewicht ist operativ: Die Stellen, mit denen die Brücke verbunden werden sollte, sagten, dass die vorgesehenen Anschlüsse nicht zu ihren Verfahren passten.

Die Erklärung der AFRINIC-Mitarbeiter benennt die praktische Alternative. Jedes RIR befasst sich mit der übertragenden Partei in seiner eigenen Region beziehungsweise Dienstbeziehung, und die RIRs kommunizieren miteinander. AFRINIC würde eine externe Quelle, zu der keine Beziehung besteht, nicht direkt prüfen. Dieser Satz bringt das Architekturproblem auf den Punkt. Identitäts- und Kontrollnachweise sind nicht beliebig im globalen System verteilt. Das bisherige Register besitzt Kontohistorie, Registrierungsdaten, Kontaktwege und Hinweise auf Konflikte für seine Quelle.

Das neue Register besitzt entsprechende Möglichkeiten für seinen Empfänger. Ein bilaterales Protokoll nutzt diese komplementären Informationspositionen; ein direktes Fremdprüfungsmodell ignoriert sie.

Draft 3 hielt hingegen an einer Klausel fest, nach der die Quelle der rechtmäßige, bei irgendeinem RIR registrierte Halter sein, die Politik des empfangenden RIR erfüllen und frei von Ressourcenstreit sein sollte. Einige dieser Prüfpunkte sind sinnvoll. Ressourcenidentität, anerkannte Kontrolle und ein bekannter Streitstatus gehören zu den Tatsachen, die vor einem konsistenten Registerwechsel geklärt werden müssen. Die Schwierigkeit liegt nicht in der Existenz einer Prüfung, sondern in ihrer Zuweisung. Das empfangende RIR kann nicht allein durch den Wunsch nach korrekten Daten die Beziehung und den Belegbestand des Quellregisters ersetzen.

Daneben blieb eine weitere Spannung bestehen. Draft 3 sah für eine Übertragung nach AFRINIC eine Bedarfsprüfung vor, erklärte aber zugleich, Empfänger könne jede Partei sein, die eine Vereinbarung mit dem Sender habe. Die Mitarbeiter lasen dies in bestimmten Fällen als praktischen Konflikt mit der vorausgehenden Bedarfsanforderung. Auch hier ist der Befund kein allgemeines Urteil gegen Empfängerprüfungen. Er zeigt, dass ein Text seine eigenen Zulässigkeitsbegriffe so ordnen muss, dass die ausführende Stelle weiß, ob die private Vereinbarung genügt, welche zusätzlichen Angaben erforderlich sind und was bei einem Widerspruch geschieht.

Abschnitt 5.7.5 verlegte den Beginn des Vorgangs zum empfangenden RIR: Die übertragende Partei sollte dort ihren Antrag einreichen; nach Genehmigung sollte das empfangende RIR das übertragende Register und die Parteien benachrichtigen. Dieses Modell dreht die natürliche Beweiskette um. Bevor die Quelle gegenüber ihrer bisherigen Registerstelle authentisiert wurde, soll das Zielregister einen Antrag von ihr annehmen und beurteilen. Erst anschließend erscheint das Quellregister als zu benachrichtigende Stelle.

Ein kompatibler Ablauf würde dagegen die Quelle beim Quellregister beginnen lassen, den Empfänger beim Zielregister prüfen und die beiden Entscheidungen über einen authentisierten Registerkanal zusammenführen.

Die Mitarbeiterbewertung machte außerdem deutlich, dass „Registeränderung“ keine einzelne Datenbankzeile meint. Betroffen sein konnten MyAFRINIC, Reverse DNS, RPKI-ROAs, Transferprotokolle und Ticketing-Systeme. Hinzu kamen Prozessprüfung, Koordination zwischen RIRs, Verträge, Personal und Softwareentwicklung. Diese Liste zeigt die materielle Seite technischer Buchführung. Ein Eintrag ist nicht deshalb hoheitlich, weil viele Systeme von ihm abhängen. Aber gerade weil Abhängigkeiten bestehen, muss die Koordination genau, sicher und zeitlich konsistent sein.

Auch finanzielle Folgen wurden nur als Einschätzung festgehalten. Eingehende Legacy-Übertragungen würden nach der damaligen Beurteilung die Mitgliedschaft nicht erhöhen; ausgehende Übertragungen von AFRINIC-Ressourcenmitgliedern könnten sie verringern. Das ist eine institutionelle Erwartung, keine gemessene Entwicklung. Sie darf nicht in eine Behauptung verwandelt werden, Draft 3 habe tatsächlich Mitglieder oder Einnahmen verloren. Gleichwohl weist sie auf einen Interessenkontext hin: Ein Register kann von den Bewegungen betroffen sein, die es verbucht. Gerade dann ist eine schmale, überprüfbare Rolle besser als ein offener Ermessensanspruch.

Der Oktoberbefund war somit eindeutig genug für eine Designanalyse und begrenzt genug für Vorsicht. Version 3 hatte den Legacy-Status erhalten und eine Sperrfrist eingeführt. Doch ARIN, APNIC, LACNIC und RIPE NCC passten an entscheidenden Stellen nicht zu dem verbliebenen Verfahren. Die Ursache lag in der Zuordnung von Partei, Prüfung und Kommunikationsweg. Reziprozität war als Ziel benannt, aber nicht als kompatible Schnittstelle ausgearbeitet.