Zusammenfassung

  • Das Protokoll von AFRINIC-37 ordnet die vollständige AS0-ROA-Umsetzung, das technische Transfersystem und die interne Umsetzung der Abuse-Contact-Regel hinter oder in Abhängigkeit von MyAFRINIC v2 ein; eine AS-SET-Folgenabschätzung setzt auch einen noch im Last Call befindlichen Vorschlag dahinter.
  • Der gemeinsame Termin macht aus den vier Pfaden keine gemeinsame Funktion. Drei Regeln sind ratifiziert, AS-SET nicht; betroffen sind RPKI, Verfahren zwischen RIRs, interne Validierung, WHOIS und IRR.
  • Ein erreichbares Portal beweist nur Portalverfügbarkeit. Policy-Abnahme verlangt eine Bindung zwischen Regelversion, Release-Baseline, Testfällen, Teil-/Vollzustand, Aktivierung, Ausnahme und Korrektur.
  • Gemeinsame Infrastruktur kann alte Widersprüche abbauen und redundante Entwicklung vermeiden. Zum Risiko wird sie, wenn ein allgemeines live die getrennten Zustände Awaiting Implementation, intern getestet, teilweise, verfahrensbereit oder noch nicht ratifiziert sprachlich verdrängt.

Bei einem Portal lässt sich Fortschritt leicht zeigen. Eine Anmeldeseite erscheint, ein Nutzer erreicht eine Funktion, ein Release trägt eine Versionsnummer. Bei einer Policy ist Sichtbarkeit schwieriger. Ihr Vollzug besteht nicht darin, dass irgendwo eine Schaltfläche vorhanden ist.

Der maßgebliche Text muss Autorität besitzen, die richtige Version muss in ein System übersetzt sein, der vorgesehene Nutzer muss den Weg durchlaufen können, und ein Fehler muss korrigierbar bleiben, ohne die erste Entscheidung unsichtbar zu machen.

MyAFRINIC v2 bringt diese beiden Formen von Fortschritt zusammen. AFRINICs öffentliche Unterlagen beschreiben vier Policy-Pfade, die nach demselben Portalmeilenstein eingeordnet sind. Diese Gemeinsamkeit ist für die Planung real. Für die Abnahme ist sie unzureichend.

Ein Pfad betrifft AS0-ROAs für nicht zugeteilten und nicht zugewiesenen Adressraum. Ein zweiter betrifft Transfers von Nummernressourcen, darunter Vorgänge mit einem anderen Regional Internet Registry. Ein dritter betrifft die Validierung von Missbrauchskontakten. Der vierte betrifft hierarchische Namen neu angelegter AS-SETs. Die ersten drei Texte sind im geprüften Bestand ratifiziert. Der vierte stand im Last Call.

Deshalb ist die Behauptung „MyAFRINIC v2 implementiert vier Policies“ nicht einmal dann präzise, wenn alle vier Arbeiten im selben Programm stattfinden. Sie überspringt den Rechtsstatus, die jeweiligen Systeme, Nutzer und Prüfkriterien. Der angemessene Gegenstand ist enger: Welche öffentliche Evidenz muss jeder Pfad liefern, bevor aus einer Release-Abhängigkeit ein abgenommener, zurechenbarer und korrigierbarer Betrieb wird?

Ein Programm mit zwei Terminformulierungen

Das Protokoll von AFRINIC-37, einer Sitzung am 24. Juni 2026, sagt, die Arbeit an MyAFRINIC v2 habe 2020 begonnen. Mehrjährige Budget- und andere Ressourcenbeschränkungen hätten verzögert, später sei das Projekt wieder aufgenommen worden. Im Juni wurde ein Go-live bis Ende 2026 erwartet. Um das Ziel zu erreichen, müsse der Umfang begrenzt werden, damit kein scope creep entstehe.

Umfangskontrolle ist kein Eingeständnis eines Defekts. Bei einem Mitgliederportal, das Identität, Berechtigungen und Nummernressourcen berührt, kann ein kleiner, kohärenter und rücksetzbarer Release verantwortlicher sein als ein großer, ungetesteter. Eine Plattform kann zudem verhindern, dass dieselbe Policy-Regel in mehreren Altsystemen verschieden interpretiert wird. Das Protokoll benennt jedoch keine gestrichene Funktion. Es erlaubt nicht, einen der vier Pfade als herausgenommen darzustellen.

Die AfPIF-Seite von AFRINIC nennt MyAFRINIC v2 einen umfassenden Neuaufbau des Self-Service-Portals. Vor User Acceptance Testing und live beta bat AFRINIC um Testkontakte und kurze Gespräche über Arbeitsabläufe. Das ist Evidenz für Vorbereitung und Beteiligungsgewinnung. Es ist keine Evidenz dafür, dass UAT oder Beta abgeschlossen wurden oder die Produktion geöffnet ist.

Eine genauere Terminangabe steht in der Staff Assessment des AS-SET-Vorschlags: 15. November 2026. Der dortige Implementierungsplan sagt, die verfügbaren Ressourcen seien auf MyAFRINIC v2 konzentriert; der Vorschlag solle nach Abschluss des Portals priorisiert werden. Im Sitzungsprotokoll steht allgemeiner Ende 2026. Beide Aussagen sollten mit ihrer Quelle erhalten bleiben. Der 15. November darf nicht zu einem Liefertermin für alle vier Policies erweitert werden.

Am Evidenzstichtag lag dieses Datum noch in der Zukunft. Weder ein Start noch ein Terminverzug sind bewiesen. Der Kalender zeigt eine Planungsabhängigkeit. Er ersetzt keinen Abnahmezustand.

AS0: Der partielle Zustand braucht einen Inhalt

Das aktuelle Policy-Verzeichnis führt AFPUB-2019-GEN-006-DRAFT03, RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space, als ratifiziert und Awaiting Implementation. AFRINIC-37 beschreibt weitere Schritte. Die Umsetzung befand sich mit einer weiterentwickelten KRILL-Software im internen Test. Bis Monatsende wurde eine Beta erwartet, die als partly implemented angekündigt werden sollte.

Die vollständige Umsetzung des Policy-Textes hing von MyAFRINIC v2 ab.

Damit existieren mindestens vier Zustände: ratifiziert, intern getestet, teilweise umgesetzt und vollständig wie geschrieben umgesetzt. Es wäre ein Informationsverlust, sie in vorhanden zusammenzufassen.

Für die Abnahme genügt nicht, dass ein RPKI-bezogenes Element im Portal sichtbar ist. Zu nennen sind die erfassten Objekte und Ressourcen, ausgeschlossene Fälle, Publikations- und Fehlerzustände, Korrekturverfahren sowie der Übergang vom Teil- zum Vollzustand. Die geprüften Quellen liefern diese Matrix nicht und belegen nicht, dass die erwartete Beta tatsächlich erschien.

Eine spätere Abnahme sollte den ratifizierten Text, eine MyAFRINIC-v2-Baseline, die einschlägige KRILL-Laufzeit, Testfälle und Publikationsergebnisse verbinden. Interne Tests können Logik prüfen. Sie beweisen nicht automatisch repräsentative Nutzung, Berechtigungswege und dauerhafte Korrekturfähigkeit. Partly implemented bleibt nur dann eine aussagekräftige Kategorie, wenn sie auch das Fehlende und ein Austrittskriterium nennt.

Transfers: Das andere Ende liegt außerhalb

Die Übersicht ratifizierter Policies datiert die Ratifikation der Number Resources Transfer Policy AFPUB-2020-GEN-006-DRAFT03 auf den 4. Februar 2026. Laut Sitzungsprotokoll umfasst sie intra-RIR- und inter-RIR-Transfers. Die Gegenseitigkeit mit den vier anderen RIRs sei im April bestätigt gewesen. Member Services bildete mit den Gegenstellen die nötigen Verfahren ab; die technische Systemumsetzung sollte nach MyAFRINIC v2 priorisiert werden.

Ein Transferformular ist nur ein Ende dieses Pfades. Eine zulässige Anfrage muss geprüft, mit einer Gegenstelle koordiniert, in Statusschritten verarbeitet und schließlich in Registry-Daten sowie Mitteilungen umgesetzt werden. Eine funktionierende Oberfläche beweist nicht, dass jede zulässige Route den Weg bis zum zurechenbaren Ergebnis durchlaufen kann.

Umgekehrt kann ein Verfahren bereits intern oder manuell möglich sein, obwohl die allgemeine Portaloberfläche fehlt. Auch deshalb ist die binäre Kategorie nicht implementiert zu grob. Ein belastbarer Eintrag darf lauten: Verfahren abgebildet, Gegenstelle bestätigt, technischer Test offen; bestimmte Kategorie nutzbar, andere noch nicht; interner Weg vorhanden, Mitgliederzugang noch im Test.

Die Abnahme muss pro Route den Auslöser, die Voraussetzung, die Gegenstelle, den Test, den maßgeblichen Entscheidungszeitpunkt, das Registry-Ergebnis, die Benachrichtigung und die Wiederaufnahme oder Korrektur belegen. Ein später öffentlich gemachter erfolgreicher Transfer würde diesen Fall belegen, nicht zwangsläufig alle anderen.

Hier geht es nicht erneut um die materiellen Ausstiegsbeschränkungen der Policy. Der ausschließliche Gegenstand ist die Evidenz, die einen Antragseingang von einem vollständig nutzbaren und reparierbaren Transferweg trennt.

Abuse Contact: Eine E-Mail ist noch kein abgenommenes Verfahren

Dieselbe Übersicht datiert das Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT07 ebenfalls auf den 4. Februar 2026. Das AFRINIC-37-Protokoll sagt, seine technische Umsetzung in internen Systemen solle nach Abschluss des MyAFRINIC-v2-Deployments priorisiert werden.

Das Vorhandensein eines abuse-c-Attributs ist keine vollständige Umsetzung. Ein Validierungsverfahren braucht ein geprüftes Objekt, einen Auslöser, Zustell- und Antwortzustände, eine Mitteilung, eine Korrekturfrist, Ausnahmen und eine klare Grenze möglicher Folgen. Jeder Übergang muss zum maßgeblichen Text gehören.

Gerade die Versionsbindung schützt vor einer historischen Verwechslung. BTW hat zuvor einen älteren Draft 2 und dessen Folgenkette analysiert. Diese kann nicht als Implementierungsvorgabe in Draft 7 übernommen werden. Interne Verfahren dürfen den ratifizierten Text konkretisieren; sie dürfen ihn nicht ohne sichtbare Spur durch eine frühere oder informelle Interpretation ersetzen.

Teilvollzug kann hier vieles bedeuten: nur neue Datensätze, ein Versand ohne abgenommenen Korrekturweg, ein internes Verfahren ohne Mitgliederoberfläche. Solche Stufen können vernünftig sein, wenn sie mit Umfang und Exit-Kriterium veröffentlicht werden. Das Wort implementiert allein lässt sie nicht unterscheiden.

AS-SET: Softwareplanung überschreitet keine Autoritätsschwelle

AFPUB-2026-ASN-001-DRAFT02 hatte im geprüften Verzeichnis Last-Call-Status. Eine Ratifikation ist nicht belegt. Die Staff Assessment beschreibt Änderungen an allen WHOIS-Erstellungspfaden und an der IRR-Oberfläche von MyAFRINIC, um neue nicht hierarchische AS-SET-Namen zu verhindern. Bestehende Objekte sollten nicht umbenannt werden.

Eine technische Folgenabschätzung vor der Entscheidung ist sinnvoll. Ohne sie könnte die Gemeinschaft Machbarkeit, Systemwirkung und Aufwand nicht bewerten. Doch Machbarkeit ist keine Regelungsautorität. Vor Ratifikation ist der richtige Zustand Vorschlag bewertet, nicht Policy umgesetzt.

Kommt es später zur Ratifikation, beginnt die Abnahme mit dem finalen Text und seinem Wirksamkeitszeitpunkt. Danach muss jeder Erstellungspfad getestet werden. Eine Ablehnung in MyAFRINIC beweist nicht dieselbe Regel in einem anderen WHOIS-Zugang. Ein korrekt erstelltes neues Objekt beweist nicht, dass alte Objekte unverändert bleiben. Der Vorschlag enthält zwei Grenzen, und beide brauchen eigene Tests.

Policy-Pfad Geprüfter Zustand Beziehung zu MyAFRINIC v2 Noch erforderliche Abnahme
AS0-ROAs Ratifiziert, Awaiting Implementation, interner Test und geplante Teil-Beta Vollständiger Textvollzug abhängig vom Portal Objekte, Abdeckung, Teil-/Vollgrenze, Korrektur, Aktivierung und laufende Publikation
Transfers Ratifiziert am 4. Februar 2026; Verfahrensabbildung im Gang Technisches System nach dem Portal Route, Gegenstelle, End-to-End-Test, Registry-Ergebnis, Mitteilung und Reparatur
Abuse Contact Ratifiziert am 4. Februar 2026 Interne Technik nach Portalabschluss Draft-7-Bindung, Validierung, Mitteilung, Korrektur, Ausnahmen und Folgengrenze
Hierarchische AS-SET-Namen Last-Call-Vorschlag WHOIS/Portal bewertet; Priorität danach Ratifikation, finaler Text, alle Erstellungspfade, Schutz und Korrektur alter Objekte

Ein Abnahmebuch statt einer Fortschrittsfolie

Das nötige öffentliche Objekt muss weder Quellcode noch interne Tickets oder Mitgliedernachweise offenlegen. Es kann eine kompakte Tabelle sein, sofern jede Zustandsänderung angehängt und nicht überschrieben wird.

Zuerst kommen Policy-Titel, Kennung, Version und Autoritätszustand. Diese Felder verhindern, dass Software später dem falschen Entwurf zugerechnet wird. Sie halten AS-SET bis zu einer möglichen Ratifikation im Zustand der Vorschlagsprüfung.

Danach folgt die Release-Baseline. MyAFRINIC v2 bezeichnet ein Programm, nicht den testbaren Zustand. Eine Version, eine datierte Lieferung oder ein ähnlicher Identifikator muss zeigen, welches Verhalten abgenommen wurde. Verändert ein Patch dieses Verhalten, entsteht ein neuer Eintrag.

Die Abhängigkeitsklasse trennt Oberfläche, WHOIS, IRR, RPKI, internen Workflow, Datenmigration und externes RIR-Verfahren. Dadurch kann ein sichtbarer Frontend-Erfolg keinen ungetesteten Hintergrundpfad für erledigt erklären.

Voraussetzung, Verantwortlicher, Testfall und Kriterium schaffen Zurechenbarkeit. Sie ist keine Schuldzuweisung. Registry Products kann die Release-Baseline attestieren, Member Services ein Transferverfahren, ein Betriebsteam eine Publikation oder Validierung, das zuständige Policy-Verfahren die Autorität des Textes.

Auch die Testpopulation gehört hinein. Interne Prüfung, Mitglieder-UAT und Beta beantworten verschiedene Fragen. Die erste prüft Regel und Technik, UAT die gewöhnlichen Rollen und Abläufe, Beta die Interaktion in realitätsnäheren Zuständen. Eine Einladung ist kein Ergebnis; ein Labortest keine Mitgliederabnahme.

Schließlich braucht der Eintrag Definitionen für teilweise und vollständig, Mitteilung und Aktivierungszeit, Ausnahme, Rollback, Korrektur und Nachbeobachtung. Portalverfügbarkeit ist eine Plattformmetrik. Policy-Ergebnis verlangt ein eigenes Signal.

Vier verschiedene Fehlersprachen

Eine gemeinsame Plattform verleitet dazu, Fehler in einer gemeinsamen Sprache zu melden: verfügbar, eingeschränkt, gestört. Für die vier Policy-Pfade reicht das nicht. Ein AS0-Problem kann bedeuten, dass ein erwartetes Objekt nicht veröffentlicht, eine Abdeckung falsch bestimmt oder eine Korrektur nicht fortgeschrieben wurde. Die Plattform kann währenddessen vollständig erreichbar sein.

Der Nachweis muss deshalb die erwartete Publikation und ihre Beobachtungszeit nennen, nicht nur die Verfügbarkeit des Portals.

Bei einem Transfer kann derselbe sichtbare Zustand — eine Anfrage wartet — mehrere Ursachen haben. Die Unterlagen können unvollständig sein, die AFRINIC-Prüfung kann laufen, eine Gegenstelle kann noch keinen abgestimmten Status geliefert haben oder die technische Aktualisierung kann ausstehen. Ein allgemeiner Wartestatus hilft dem Nutzer, belegt aber nicht, an welcher institutionellen Grenze die Route steht.

Die Abnahme muss daher Zustände definieren, die an eine verantwortliche Stelle und eine nächste zulässige Aktion gebunden sind.

Beim Abuse-Contact-Pfad ist die Unterscheidung zwischen Zustellung und Erfüllung wichtig. Eine versandte Nachricht kann unzustellbar sein; eine zugestellte Nachricht kann unbeantwortet bleiben; eine Antwort kann die geforderte Korrektur noch nicht enthalten. Der Workflow muss diese Ereignisse trennen, sonst wird ein technisches Signal zur Policy-Entscheidung.

Gleichzeitig darf die öffentliche Evidenz keine persönlichen Kontaktdaten oder Sicherheitsdetails offenlegen. Aggregierte Zustandszahlen und stabile Ereignisdefinitionen reichen aus.

AS-SET hat wiederum eine andere Fehlersprache. Vor Ratifikation wäre die Aktivierung der vorgeschlagenen Regel kein Implementierungsfehler, sondern eine Autoritätsüberschreitung. Nach einer Ratifikation kann ein Fehler darin bestehen, dass ein Erstellungspfad die neue Regel nicht anwendet oder dass ein bestehendes Objekt entgegen dem Text verändert wird. Der gleiche HTTP-Erfolg oder die gleiche Formularmeldung sagt darüber wenig aus.

Diese Unterschiede erklären, warum ein Portal-Dashboard mit vier grünen Punkten noch keine Abnahme wäre. Grün kann für jede Zeile etwas anderes bedeuten, solange Kriterien und Evidenz fehlen. Das Abnahmebuch muss nicht alle technischen Einzelheiten veröffentlichen. Es muss aber für jede Zeile die Sprache definieren, in der Erfolg, Teilzustand, Ausnahme und Korrektur überhaupt festgestellt werden können.

Die Grenze der Aussage

Die Quellen beweisen keinen heutigen Produktivstart, kein abgeschlossenes UAT oder Beta, keine AS-SET-Ratifikation und keine vollständige Umsetzung von AS0, Transfers oder Abuse Contact. Sie belegen auch keinen Ausfall, keinen verpassten Termin, keinen fehlgeschlagenen Test, keinen abgewiesenen Transfer, keinen ungültigen Kontakt, keine AS-SET-Kollision und keine RPKI-Routingwirkung.

Es gibt in diesem Bestand kein Mitglied, dessen Schaden aus der gemeinsamen Abhängigkeit folgt. Eine solche Figur wäre erfunden.

AFRINIC verwendet bereits nützliche Zustandswörter: Awaiting Implementation, interner Test, partly implemented, Verfahrensabbildung, Priorisierung nach dem Portal, Last Call. Diese Wörter sind das Gerüst eines Abnahmebuchs. Sie müssen nur mit Version, Evidenz und Korrektur verbunden werden.

Dann kann MyAFRINIC v2 eine gemeinsame Grundlage bleiben, ohne vier getrennten Policies eine gemeinsame Schlussfolgerung aufzuzwingen. Nach dem Portalstart beginnt erst ihre jeweilige Abnahme.

Quellen