Zusammenfassung

  • AFRINICs am 25. September 2026 eingereichte DRAFT02 sagt, automatische Prüfungen könnten mögliche Anzeichen einer Nichteinhaltung aufzeigen. Das Personal soll die Informationen verifizieren, bevor eine Untersuchung oder Maßnahme nach RSA oder Satzung folgt.
  • Gegenüber DRAFT01 verändert sich damit die Bedeutung eines automatischen Ergebnisses: Es ist kein Compliance-Urteil, sondern ein Hinweis für die Prüfung durch Menschen.
  • Eine versionierte Zuordnung von Richtlinie und Test sollte Regel, Fassung, Gültigkeitsdatum, Ressourcenumfang, Datenquelle und Testversion nennen – und die Grenzen des Ergebnisses offenlegen.
  • Der Vorschlag steht weiterhin auf in Diskussion. Öffentliche Quellen belegen weder ein laufendes Dashboard noch eine Mitgliedermeldung, einen Verstoß oder eine Sanktion.

Ein Datenvergleich entscheidet nicht, welche Regel gilt

Angenommen, ein Ressourceninhaber erhält einen Hinweis, dass ein Registereintrag von einem erwarteten Zustand abweicht. Die Software kann ein Kontaktfeld lesen, ein Route-Objekt vergleichen oder eine Ressource gegen eine Regel prüfen. Der Vergleich lässt sich wiederholen. Er beweist aber nicht, dass die richtige Richtlinie für dieses Mitglied gilt, die Quelle aktuell ist oder eine Verpflichtung verletzt wurde.

Genau diese Grenze behandelt AFRINICs Entwurf eines Policy Compliance Dashboard, AFPUB-2026-GEN-002-DRAFT02. Die am 25. September eingereichte Fassung will vor allem Bedingungen automatisieren, die sich möglichst objektiv messen lassen, und nur mögliche Anzeichen einer Nichteinhaltung melden. Das Dashboard soll nicht selbst über den Fall entscheiden: Mitarbeitende müssen Informationen aus automatisierten Tests verifizieren. Erst wenn Belege auf eine Nichteinhaltung hindeuten, beschreibt der Text eine gründlichere Untersuchung und mögliche Maßnahmen nach RSA oder Satzung.

Das ist keine Beschreibung eines laufenden Produkts. Die aktuelle Vorschlagsübersicht führt DRAFT02 weiterhin als in Diskussion. Es geht hier um die Grenze, die der Entwurf zieht, und um die Belege, die ein künftiges System nachvollziehbar machen müssten.

DRAFT02 weist einem Testergebnis eine andere Bedeutung zu

Die archivierte DRAFT01 war bestimmter formuliert. Sie sah Meldungen vor, sobald eine Nichteinhaltung erkannt würde, außerdem Erinnerungen, eine vom Personal festgelegte Dauer anhaltender Nichteinhaltung, spätere Verfahren und erst noch zu definierende Regeln für das Aussetzen von Diensten, den Entzug von Ressourcen oder die Beendigung einer Mitgliedschaft. Für bestimmte Fälle mit kritischer Infrastruktur oder außergewöhnlichen Umständen war zudem eine Ausnahmebefugnis des Boards vorgesehen.

DRAFT02 ist nicht bloß dieselbe Regel mit kürzerem Zeitplan. Die gesonderten Bestimmungen zur Dauer und zu späteren Sanktionsregeln entfallen. Stattdessen hält der Text ausdrücklich fest, dass Compliance nicht vollständig objektiv messbar ist und automatische Prüfungen nur mögliche Anzeichen liefern können. Die Verifikation durch das Personal steht nun im vorgeschlagenen Regeltext. Weitere Maßnahmen nach RSA oder Satzung bleiben möglich, darunter Dienstsperre, Ressourcenentzug oder Mitgliederschließung.

Damit ändert sich die Aufgabe der Software. Die ältere Fassung begann mit einem erkannten Zustand namens Nichteinhaltung. DRAFT02 beginnt mit einem Hinweis, der falsch, unvollständig oder außerhalb des Anwendungsbereichs liegen kann. Die menschliche Prüfung soll beide Schritte verbinden. Dazu müssen die Prüfenden die Grundlage sehen und das Mitglied denselben Befund nachvollziehen können.

Die Richtlinienfassung gehört zum Testergebnis

Der Entwurf sagt, dass die Automatisierung mit Änderungen des Konsolidiertes Richtlinienhandbuch (CPM) fortentwickelt werden muss. Das ist mehr als Wartung. Ein Test, der gestern die Regel korrekt abbildete, kann eine Ressource nach einer Änderung falsch einstufen oder ein neues Kriterium vor seinem Gültigkeitsdatum anwenden. Eine rote oder grüne Anzeige ohne Referenzfassung verschleiert diesen Unterschied.

Die zur DRAFT01 gehörende Folgenabschätzung nannte als Beispiele Kontaktgenauigkeit, die Gültigkeit des Abuse-Kontakts, die Konsistenz von Route-Objekten, RPKI-Abdeckung, soweit relevant, und Reverse-DNS-Anforderungen. Das sind Beispiele aus der Bewertung der Vorfassung, kein endgültiger Testkatalog für DRAFT02 und kein Nachweis, dass diese Prüfungen bereits eingesetzt werden. Sie zeigen, warum „automatisiert“ nicht „selbsterklärend“ bedeutet. Ein fehlendes Feld lässt sich beobachten; ob die geltende Richtlinie dieses Feld für genau diese Ressource verlangt, ist eine andere Frage.

Auch ein Route- oder RPKI-Abgleich braucht eine benannte Quelle, einen Beobachtungszeitpunkt und einen Geltungsbereich.

Jede Prüfung sollte zwei Aufzeichnungen verbinden. Die erste ist die Regelzuordnung: Richtlinienkennung, Fassung, Gültigkeitsdatum, betroffene Ressourcengruppe und Anwendungsbedingungen. Die zweite ist der Testbeleg: Datenquelle, Erhebungszeit, Verarbeitung, Testversion, Ergebnis und bekannte Grenzen. Damit kann das Personal zur Quelle zurückgehen und begründen, warum die Regel gilt – oder warum der Hinweis aufgehoben wird. Das Mitglied kann dieselbe Grundlage nachvollziehen, ohne vertrauliche Betriebsdaten anderer Organisationen zu erhalten.

Das ist eine redaktionelle Empfehlung und keine von AFRINIC angekündigte Funktion. DRAFT02 legt weder einen vollständigen Testkatalog noch ein Versionsverfahren, eine Genauigkeitskennzahl oder ein Verifikationsprotokoll des Personals fest. Wenn das automatische Ergebnis bis zur Prüfung nur ein möglicher Hinweis ist, müssen die dabei geprüfte Regel und ihre Datenbasis sichtbar sein.

Daten, Hinweis und Maßnahme sind getrennte Schritte

Eine nachvollziehbare Kette unterscheidet mindestens vier Zustände: ein Register- oder Netzwerkdatensatz; ein automatischer Vergleich mit einem möglichen Hinweis; die Prüfung der Quelle und der anwendbaren Regel durch das Personal; und gegebenenfalls eine gesonderte Maßnahme nach RSA oder Satzung. Das sind unterschiedliche Aussagen. Ein Dashboard-Label sollte den ersten Zustand nicht stillschweigend in den letzten verwandeln.

Diese Trennung schützt beide Seiten. Ein Mitglied kann einen falschen Eintrag korrigieren oder erläutern, warum eine Regel nicht greift. Das Personal kann Datenqualität von einer Auslegungsfrage trennen. AFRINIC kann dokumentieren, welche Belege eine spätere Untersuchung tragen würden. War der Test falsch, lässt sich der Hinweis berichtigen, ohne einen unerklärten Compliance-Status in der Mitgliederhistorie stehenzulassen.

Der wirtschaftliche Übertragungsweg ist vorausschauend, aber im Entwurf angelegt: Künftige Anträge, Dienste und die Mitgliedschaft könnten nach RSA betroffen sein. Ein irreführender Status kann die Zeit eines Netzbetreibers beanspruchen oder eine spätere Prüfung beeinflussen; eine zutreffende Warnung kann eine frühere Korrektur ermöglichen. Die öffentlichen Quellen zeigen heute keines dieser Ergebnisse. Sie werfen die Designfrage auf: Wie lässt sich ein nützlicher Hinweis von einem veralteten oder falsch angewandten Test unterscheiden?

Die Vorgeschichte erklärt die Revision, nicht den Ausgang von DRAFT02

AFRINIC-37 beriet DRAFT01 am 24. Juni. Laut Protokoll sahen die Co-Chairs keinen groben Konsens und verwiesen diese Fassung an die Mailingliste zurück; eine Mitteilung vom August hält dasselbe Ergebnis fest. DRAFT02 wurde am 25. September eingereicht. Ihre Änderungshistorie sagt, die Fassung reagiere auf RPD-Diskussionen und eine Folgenabschätzung. Das Ergebnis vom Juni betrifft DRAFT01, nicht die aktuelle Fassung.

Die Überarbeitung grenzt ein, was die Automatisierung entscheiden soll, und ergänzt die Prüfung durch Mitarbeitende. Das macht die Beweisgrenze klarer, ist aber keine im Betrieb getestete Schutzmaßnahme. Als nächster Schritt sollte der Testkatalog zusammen mit der Richtlinie überprüfbar werden: Fassung, Gültigkeit, Umfang, Quelle, Logik, Grenzen und Verifikationsvermerk. So könnten Mitglieder und Betreiber den Mechanismus prüfen, bevor ein Hinweis als mehr als eine Spur behandelt wird.

Quellen und Umfang. Der DRAFT02-Vorschlag und die aktuelle Vorschlagsübersicht belegen Wortlaut und Status. Die archivierte DRAFT01 samt Folgenabschätzung dokumentiert Vorgängertext und Prüfbeispiele. Das Protokoll von AFRINIC-37 und die Mitteilung der Co-Chairs vom 12. August belegen die Rückgabe von DRAFT01 an die Mailingliste. Keine dieser Quellen belegt eine Inbetriebnahme oder ein Ergebnis für ein bestimmtes Mitglied.