Zusammenfassung

  • AFRINIC-34 behandelte am 17. und 18. November 2021 offiziell sechs nummerierte Vorlagen, nicht fünf. Vier gingen mangels Konsens zurück an die Mailingliste; das Compliance Dashboard und die AFRINIC Number Resources Transfer Policy gelangten in den Last Call.
  • Zusammengenommen bildeten die Vorlagen eine Landkarte privater Verwaltungsfunktionen: Leitung und Moderation der Arbeitsgruppe, Bedeutung von Konsens und Verfahrensstufen, Veröffentlichung von Antragsinformationen, Hinweise auf mögliche Regelverstöße sowie die Portabilität registrierter Nummernressourcen.
  • Der zeitgleiche Rechtsstreit mit Cloud Innovation schärfte die Bedeutung von Registerkontrolle und Betriebskontinuität, beweist aber weder einen ursächlichen Zusammenhang mit den Vorlagen noch Motive einzelner Beteiligter.
  • Der stärkste Nutzen des Treffens lag in der Offenlegung von Einwänden, Abhängigkeiten und Kosten. Daraus entstand jedoch kein hoheitliches Mandat: AFRINIC bleibt ein privater technischer Buchhalter, Dienstleister und Koordinator.
  • Ein besseres Modell wäre ein einseitiges, versioniertes Funktionsdossier für jede Vorlage, das technische Notwendigkeit, betroffene Auftraggeber, Daten- und Rechtsgrundlage, Einwände, Kosten, Entscheidung und spätere Entwicklung nachvollziehbar miteinander verknüpft.

Zwei Tage, sechs Fragen nach Kontrolle

Am 17. November 2021 öffnete sich ein virtueller Raum für die 34. öffentliche Policy-Sitzung von AFRINIC. Vier Stunden lang ging es zunächst um die Regeln der Arbeitsgruppe, um Transfers zwischen regionalen Registern und um die mögliche Veröffentlichung von Angaben aus Ressourcenanträgen. Am folgenden Morgen kamen in weiteren vier Stunden eine umfassendere Überarbeitung des Entwicklungsverfahrens, ein privates Compliance Dashboard und eine zweite Transferarchitektur hinzu. Vincent Ngundi und Darwin Da Costa sind im offiziellen Protokoll als Ko-Vorsitzende der Policy Development Working Group, kurz PDWG, verzeichnet.

Autoren stellten ihre Texte vor, Mitarbeiter erläuterten Folgen und offene Fragen, Teilnehmende widersprachen oder unterstützten, und die Vorsitzenden hielten den jeweiligen Stand fest.

Das Protokoll nummeriert sechs Vorlagen von 1 bis 6. Eine frühere Kurzbezeichnung des Themenkomplexes sprach irrtümlich von fünf; für die Analyse gilt die offizielle Zahl sechs. Die Korrektur ist mehr als Buchhaltung, weil gerade das Nebeneinander aller sechs Texte den entscheidenden Befund trägt. Es ging nicht bloß um ein Transfermodell oder um eine einzelne Transparenzregel.

In demselben Sitzungsdossier standen Fragen darüber, wer die Arbeitsgruppe leitet, wann ein Einwand als beantwortet gelten kann, was aus Kundenunterlagen öffentlich werden darf, wie mutmaßliche Abweichungen sichtbar gemacht werden und ob registrierte Ressourcen eine regionale Grenze überschreiten können.

Zu diesem Zeitpunkt befand sich AFRINIC bereits in einem aktiven Rechtsstreit mit Cloud Innovation über Registermaßnahmen, die registrierte Ressourcen berührten. Der Konflikt machte die Folgen privater Registerentscheidungen für Verfügungsfähigkeit und Kontinuität greifbar. Er darf dennoch nicht als Universalerklärung für das Treffen dienen. Die belegte Aussage ist enger: Während die institutionelle Umgebung durch eine Auseinandersetzung über Ressourcenkontrolle belastet war, versuchten sechs Vorlagen, zentrale Schnittstellen privater Verwaltung genauer zu beschreiben.

Das Protokoll zeigt nicht, dass der Rechtsstreit eine Vorlage verursachte, eine Wortmeldung lenkte oder eine Entscheidung bestimmte. Ebenso wenig erlaubt es Rückschlüsse auf persönliche Absichten.

Gerade diese Begrenzung macht AFRINIC-34 analytisch ergiebig. Das Treffen war eine Art institutioneller Triage-Tisch. Auf ihm lagen sechs Texte mit unterschiedlichen Diagnosen, aber verwandten Risiken. Manche wollten Unklarheiten innerhalb des Verfahrens beseitigen. Andere wollten Informationen freigeben, Mitglieder früher warnen oder Mobilität zwischen Registern ermöglichen. Überall stellte sich dieselbe Grundfrage: Welche Funktion muss eine gemeinsame Registerstelle übernehmen, damit eindeutige Zuordnung, korrekte Aufzeichnungen, Interoperabilität, Sicherheitsintegrität oder Betriebskontinuität erhalten bleiben?

Und an welchem Punkt wird aus dieser notwendigen Koordination eine weitergehende Kontrolle über Verträge, Offenlegung, Geschäftsmodelle oder Rechte, für die einem privaten Forum das Mandat fehlt?

Die erste Funktionsfamilie: Wer hält das Verfahren arbeitsfähig?

Vorlage 1 trug die Kennung AFPUB-2020-GEN-002-DRAFT04 und den Titel „PDP Working Group Guidelines and Procedures“. Als Autoren verzeichnete das Protokoll Alain Aina und Maina Noah. Ihr Gegenstand war die innere Funktionsfähigkeit der PDWG: Auswahl und Kontinuität der Ko-Vorsitzenden, Möglichkeiten ihres Rückrufs, Moderation, Beschwerdewege und die praktische Organisation der Arbeitsgruppe. Das sind auf den ersten Blick Verfahrensdetails. Tatsächlich bestimmen sie, wer eine Diskussion ordnet, wie eine Leitungslücke geschlossen wird und wie eine private Gruppe mit Streit über ihre eigenen Rollen umgeht.

Eine solche Ordnung kann einen legitimen Zweck erfüllen. Ohne benannte Moderation zerfällt eine offene Diskussion leicht in Wiederholung, persönliche Konflikte oder unklare Zuständigkeit. Ohne Kontinuitätsregel kann ein Ausfall der Vorsitzenden die Bearbeitung blockieren. Ohne Rückruf- und Beschwerdeweg besteht das Risiko, dass Verfahrensmacht ohne nachvollziehbare Kontrolle ausgeübt wird. Diese Probleme rechtfertigen aber nur eine begrenzte organisatorische Funktion. Die Vorsitzenden können beurteilen, ob die Arbeitsgruppe ihre eigenen Schwellen erreicht hat. Sie werden dadurch nicht zu Richtern über Rechte außerhalb dieser privaten Ordnung.

Im November 2021 hielten die Ko-Vorsitzenden fest, dass für Vorlage 1 kein Rough Consensus bestand. Bedenken waren nach ihrer Einschätzung nicht ausgeräumt; der Text ging zurück an die Mailingliste. Dieser Ausgang ist kein Scheitern, wenn man den Wert des Verfahrens an seiner Fähigkeit misst, unaufgelöste Fragen sichtbar zu halten. Ein privater Koordinationsraum beweist seine Nützlichkeit nicht nur durch angenommene Texte. Er kann ebenso nützlich sein, wenn er eine unklare Regel nicht weiterbefördert. Zugleich ist „kein Konsens“ lediglich eine Prozessentscheidung für diese Fassung und diesen Zeitpunkt.

Es ist weder ein Urteil über die Rechtslage noch ein Beweis dafür, wie alle betroffenen Betreiber dachten.

Vorlage 4, AFPUB-2021-GEN-002-DRAFT02 „Update of PDP“, gehörte zur gleichen Funktionsfamilie, griff aber breiter aus. Jordi Palet Martinez wird als Autor genannt. Der Text befasste sich mit der Bedeutung von Rough Consensus, dem Verhältnis zwischen Mailingliste und Sitzung, Folgenabschätzungen, Last Call, Ablauf von Vorlagen, Onlinesitzungen, Funktionen des Board und Moderation. Während Vorlage 1 stärker auf die Arbeitsgruppe und ihre Leitung zielte, wollte Vorlage 4 die Stationen und Schnittstellen des gesamten Entwicklungsverfahrens genauer ordnen.

Das ist eine anspruchsvollere Machtfrage, als die technische Sprache vermuten lässt. Wer festlegt, wann Konsens besteht, entscheidet darüber, welche ungelösten Einwände eine Vorlage stoppen. Wer bestimmt, welches Gewicht die Mailingliste gegenüber einer Sitzung hat, legt indirekt fest, ob zeitlich, finanziell oder sprachlich unterschiedlich ausgestattete Beteiligte überhaupt wirksam gehört werden. Wer einen Ablaufzeitpunkt definiert, entscheidet, wann ein alter Text seine Trägheit verliert. Wer dem Board eine spätere Rolle zuweist, muss zugleich erklären, ob diese Rolle administrativ, vertraglich oder gesellschaftsrechtlich begründet ist.

Jede dieser Funktionen kann Klarheit schaffen; jede kann aber auch eine bloße Teilnahmeordnung als umfassenderes Mandat erscheinen lassen.

Auch Vorlage 4 erhielt im Sitzungsprotokoll keinen Konsens. Gültige Bedenken und Einwände blieben bestehen, daher ging sie zurück an die Liste. Damit endeten beide Versuche, die Verfahrensmaschine neu zu ordnen, auf derselben Stufe. Das bedeutet nicht, dass die angesprochenen Funktionen unnötig waren. Es bedeutet, dass ihre konkrete Zuordnung von Rollen, Schwellen und Folgewirkungen noch nicht tragfähig genug dokumentiert war. Gerade in dieser Rückgabe zeigt sich eine wichtige Schranke: Eine Regel darüber, wie Regeln entstehen, darf ihre eigene Autorität nicht voraussetzen.

Zwei Transferarchitekturen und die Frage der Beweglichkeit

Die zweite große Spannung verlief zwischen zwei Transferentwürfen. Vorlage 2, AFPUB-2019-IPv4-002-DRAFT07, hieß „IPv4 Inter-RIR Resource Transfers—Comprehensive Scope“ und wurde Jordi Palet Martinez zugeschrieben. Sie sollte Transfers innerhalb der AFRINIC-Region bewahren und zugleich bidirektionale, kompatible und reziproke Transfers zwischen regionalen Internetregistern ermöglichen. Ihre funktionale Behauptung war klar: Registrierte IPv4-Ressourcen sollten unter festgelegten Bedingungen auch über regionale Registergrenzen hinweg beweglich sein, während die beteiligten Systeme die Änderung übereinstimmend abbilden.

Das Protokoll bewahrte jedoch eine Reihe ungelöster Einwände. Sie betrafen den Zeitpunkt, die Berechtigung der Quelle, Knappheit, mögliche Eingriffe AFRINICs, unklare Definitionen und die gebotene Sorgfalt. Hinter dieser Liste standen mehrere verschiedene Probleme. Eine Transferroute braucht präzise Antworten darauf, wer übertragen darf, welche Prüfung erforderlich ist, wann beide Register denselben Zustand anerkennen und was geschieht, wenn ihre Regeln nicht zusammenpassen. Fehlende Klarheit kann die Portabilität mindern, aber eine zu weit gehende Prüfung kann ebenfalls Verzögerung und Unsicherheit erzeugen.

Die Vorsitzenden stellten keinen Konsens fest und schickten die Vorlage zurück an die Mailingliste.

Vorlage 6, AFPUB-2020-GEN-006-DRAFT02 „AFRINIC Number Resources Transfer Policy“, wurde Gregoire Ehoumi, Noah Maina und Alain Aina zugeschrieben. Sie schlug Ressourcenkennzeichnungen, eingehende Transfers zwischen regionalen Registern und einen konservativen Umgang mit dem AFRINIC-Pool vor. Die Mitarbeiterbewertung nannte Fragen zu Werkzeugen, Personal, Vereinbarungen, Altbeständen, Sorgfaltsprüfung und Umsetzung. Außerdem hielt das Protokoll fest, ARIN habe bestätigt, dass diese Fassung damals nicht reziprok zu ARIN war.

Trotz dieser offenen Umsetzungspunkte sahen die Ko-Vorsitzenden für Vorlage 6 Rough Consensus. Sie stützten sich dabei laut Protokoll auf den vorliegenden Text, die Beratung in der Sitzung und redaktionelle Änderungen, welche die Autoren zugesagt hatten. Die Vorlage gelangte in den Last Call. Auch hier ist die Stufe entscheidend. Der Last Call war keine Verabschiedung, kein Nachweis späterer Umsetzung und keine Bestätigung rechtlicher Wirksamkeit. Er bedeutete, dass der Entwurf nach der Einschätzung der Vorsitzenden die nächste private Prüfphase erreichte.

Die beiden Transfertexte zeigen, warum eine rein binäre Erzählung von „offen“ gegen „geschlossen“ zu kurz greift. Transferierbarkeit kann Betriebskontinuität und die Fähigkeit eines Betreibers schützen, auf geänderte Umstände zu reagieren. Zugleich müssen mehrere Register denselben Wechsel verlässlich abbilden; sonst drohen widersprüchliche Aufzeichnungen. Reziprozität, Datenabgleich und Sorgfaltsprüfung können deshalb technisch notwendig sein.

Doch eine regionale Stelle darf aus dieser Notwendigkeit keine allgemeine Befugnis ableiten, Geschäftsmodelle zu billigen, wirtschaftliche Zwecke zu bestrafen oder über Eigentums- und Rechtsfragen wie ein öffentliches Gericht zu entscheiden. Die gemeinsame Schicht muss den anerkannten Kontrollwechsel sauber verzeichnen, nicht selbst eine umfassende Wirtschaftsordnung schaffen.

Die protokollierte Nichtreziprozität mit ARIN verschärft diese Trennung. Sie ist ein konkreter Hinweis auf eine damals offene Kompatibilitätsfrage, kein Beleg dafür, wie der Zustand später aussah. Ebenso beweist der Übergang in den Last Call weder, dass die erforderlichen Werkzeuge bereitstanden, noch dass Personal, Vereinbarungen und Altbestände abschließend geklärt waren. Das Sitzungsdossier hält einen Prüfpunkt fest. Wer daraus eine spätere Erfolgsgeschichte oder ein Scheitern ableiten möchte, bräuchte zusätzliche, hier nicht vorliegende Nachweise.

Veröffentlichung und Compliance: Transparenz für wen, Eingriff in was?

Vorlage 3, AFPUB-2021-GEN-001-DRAFT02 „Publication of Information“, ebenfalls Jordi Palet Martinez zugeschrieben, wollte Zusammenfassungen der Begründungen für Ressourcenanträge zu einem späteren Zeitpunkt veröffentlichen. Die beabsichtigte Funktion war Transparenz: Andere sollten nachvollziehen können, auf welcher Grundlage eine knappe Ressource beantragt worden war. Doch Antragsunterlagen entstehen nicht als abstraktes öffentliches Gut. Sie können betriebliche, vertragliche oder anderweitig geschützte Angaben enthalten.

Daher hängt die Legitimität einer Veröffentlichung nicht nur von einem allgemeinen Wunsch nach Offenheit ab, sondern von Zweckbindung, Mindestumfang, Zustimmung und einer klaren Datenbegrenzung.

Die Mitarbeiter erhoben laut Protokoll Einwände zu Vertraulichkeit, Einwilligung, Arbeitsaufwand, Abschnitt 4(d) des RSA und vertraulichkeitsbezogenen Regeln des Common Law. Das sind keine austauschbaren Bedenken. Ein Arbeitsaufwand kann die Umsetzbarkeit betreffen; eine vertragliche Bestimmung kann die zugesagte Behandlung von Daten begrenzen; Einwilligung betrifft die betroffene Partei; allgemeine Vertraulichkeit kann eine eigenständige rechtliche Schranke bilden. Wenn all dies unter dem einzigen Schlagwort Transparenz zusammengezogen wird, verschwindet gerade jene Zuordnung, die eine verantwortliche Entscheidung erst ermöglicht.

Für Vorlage 3 fanden die Vorsitzenden keinen Konsens und verwiesen sie zurück an die Liste. Das Sitzungsprotokoll belegt damit, dass die Konflikte zum damaligen Zeitpunkt nicht als gelöst galten. Es beweist weder, dass jede Veröffentlichung unzulässig gewesen wäre, noch dass Transparenz in jedem Umfang Vorrang gehabt hätte. Die funktionale Frage bleibt enger: Welche minimale, bereits rechtmäßig verwendbare Information braucht das gemeinsame Register, um Genauigkeit und Nachprüfbarkeit seiner Einträge zu sichern?

Alles darüber Hinausgehende verlangt eine gesonderte Grundlage und darf nicht allein aus dem Wunsch des Forums nach Öffentlichkeit folgen.

Vorlage 5, AFPUB-2021-GEN-003-DRAFT02 „Policy Compliance Dashboard“, wiederum Jordi Palet Martinez zugeschrieben, verfolgte eine andere Sichtbarkeitsidee. In MyAFRINIC sollte eine überwiegend automatisierte, private Ansicht mögliche Abweichungen anzeigen, Hinweise geben, Korrekturmöglichkeiten eröffnen und Ausnahmen bei der zeitlichen Behandlung berücksichtigen. Im besten Fall würde ein Mitglied nicht erst durch eine überraschende Maßnahme erfahren, dass das Register ein Problem vermutet. Es könnte den zugrunde liegenden Eintrag prüfen, einen Fehler berichtigen oder eine abweichende Einschätzung erklären.

Das Protokoll enthält genau diese wohlwollende Begründung: Mitglieder warnen und Überraschungen vermeiden. Es hält zugleich Sorgen zu Datenschutz, Reichweite des Policy-Verfahrens, Verwaltung des RSA, Unterschieden zwischen verschiedenen Verstößen und Ermessensspielräumen der Mitarbeiter fest. Damit berührte die Vorlage eine gefährliche Schwelle. Eine private Benachrichtigung über inkonsistente Daten kann die Qualität der Aufzeichnungen verbessern.

Ein System, das unklare Kategorien als festgestellte Schuld präsentiert oder automatisch nachteilige Folgen auslöst, würde hingegen Beobachtung mit Entscheidung und Dienstleistung mit Vollstreckung vermischen.

Die Vorsitzenden stellten für Vorlage 5 Konsens fest und schickten sie in den Last Call. Auch diese Entscheidung blieb eine Sitzungsstufe. Das Protokoll belegt keine spätere Einführung, keinen konkreten Funktionsumfang und keine tatsächliche Wirkung auf ein Mitglied. Dennoch zeigt der Gegensatz zu Vorlage 3 etwas Wichtiges: Die Teilnehmenden behandelten öffentliche Offenlegung und private Rückmeldung nicht als dieselbe Funktion. Dass eine private Warn- und Korrekturmöglichkeit weiterkam, während die Veröffentlichung von Antragsbegründungen zurückging, lässt sich als vorläufige Präferenz für begrenzte Sichtbarkeit lesen.

Es ist aber keine allgemeine Ermächtigung zur Compliance-Durchsetzung.

Vier Funktionsfamilien statt sechs isolierter Texte

In der Zusammenschau zerfällt das Dossier in vier Familien. Die Vorlagen 1 und 4 wollten die Arbeitsgruppe und das Policy-Verfahren ordnen. Vorlage 3 behandelte die Veröffentlichung von Informationen. Vorlage 5 behandelte private Sichtbarkeit, Warnung und Korrektur bei behaupteten Regelabweichungen. Die Vorlagen 2 und 6 entwarfen verschiedene Wege für Transfers und damit für Portabilität. Diese Gruppierung macht verständlich, weshalb die Sitzung mehr war als eine Folge einzelner Präsentationen.

Die Verfahrensvorlagen fragten, wer sprechen, moderieren, fortsetzen, zurückrufen, bewerten und einen Übergang zur nächsten Stufe feststellen darf. Die Veröffentlichungsvorlage fragte, wer über Daten aus einem Ressourcenantrag verfügen darf. Das Dashboard fragte, wer eine Abweichung erkennt, wie sie dem Mitglied angezeigt wird und ob Korrektur möglich ist, bevor Folgen eintreten. Die Transfervorlagen fragten, wer einen Kontrollwechsel anerkennt, wie mehrere Register ihn abstimmen und welche Prüfungen vor der Änderung stehen.

In allen vier Familien ging es um die Zuweisung einer Funktion an einen Akteur, die dafür benötigten Informationen und die Folgen für den Betroffenen.

Auch die Ausgänge ergeben erst in dieser Karte ihren Sinn. Vier Vorlagen gingen mangels Konsens zurück an die Liste: beide Verfahrensentwürfe, die Veröffentlichungsvorlage und der umfassende bidirektionale Transferentwurf. Zwei kamen weiter: das private Compliance Dashboard und die AFRINIC Number Resources Transfer Policy. Das Verhältnis vier zu zwei darf nicht als Abstimmung über eine große politische Richtung missverstanden werden. Das Protokoll nennt keine allgemeine Rangordnung der Themen.

Es dokumentiert nur, welche konkreten Fassungen die Ko-Vorsitzenden nach den damaligen Beratungen als noch ungeklärt oder für den Last Call bereit einstuften.

Die Sitzung hielt außerdem Unbehagen über die Menge der Vorlagen, Konflikte zwischen Texten, spät gebündelte Diskussionen, den Aufwand für Folgenabschätzungen, unklare Problembeschreibungen und die Grenze zwischen Policy und Administration fest. Das sind nicht bloß Begleitgeräusche. Wenn viele umfangreiche Entwürfe in einem engen Zeitfenster zusammentreffen, wächst das Risiko, dass die sichtbare Wortmeldung zum Ersatz für gründliche Prüfung wird. Wenn konkurrierende Vorschläge dieselbe Funktion verschieden zuweisen, braucht die Entscheidung eine explizite Vergleichsgrundlage.

Wenn Mitarbeiter die Umsetzbarkeit prüfen, muss klar sein, ob sie eine technische Abhängigkeit benennen oder durch unbestimmte Verwaltungsvorbehalte den Inhalt steuern. Das Dossier legte all diese Spannungen offen, löste sie aber nicht vollständig.