Zusammenfassung

  • AFPUB-2020-GEN-001-DRAFT01 schlug am 17. Februar 2020 ein weitgehend automatisiertes, mitgliederspezifisches Dashboard in MyAFRINIC vor. Sein sinnvoller Kern lag in privater Sichtbarkeit, nachvollziehbaren Hinweisen, gleichen Benachrichtigungen und einer überprüfbaren Korrekturgeschichte.
  • Zahlungsfragen, Vertragsunterlagen, WHOIS-Aktualität, Reverse DNS, Routenankündigungen, Unterzuweisungen, Transfers und Wiederholungszähler sind keine einheitliche Beweiskategorie. Ein gemeinsames Farbsignal kann Suchkosten senken, darf die Unterschiede zwischen diesen Sachverhalten aber nicht in einen scheinbaren Schuldspruch verwandeln.
  • Weder Automatisierung noch Wiederholung, Community-Konsens, menschliche Prüfung, ein interner Rechtsbehelf oder eine Board-Ausnahme können eine Befugnis zu Leistungsvorenthaltung, Entzug, Schließung oder Rückholung erschaffen. Auch ein RSA trägt nur soweit, wie eine konkrete, gültige und anwendbare privatrechtliche Grundlage für Partei, Beleg und Folge tatsächlich nachgewiesen ist.
  • Der Entwurf erreichte bei AFRINIC-32 im September 2020 keinen Konsens und wird auf der offiziellen Seite als abgelaufen geführt. Er belegt einen Gestaltungsversuch, nicht dessen Annahme, Umsetzung oder Anwendung gegen ein reales Mitglied.

L3 — Ein Bildschirm, verschiedene Arten von Belegen

Die Verlockung einer einzigen Ansicht

Das stärkste Argument für das vorgeschlagene Policy Compliance Dashboard war nicht Zwang, sondern Orientierung. Mitgliedschaftsverträge, Registerdaten und technische Pflichten erzeugen über die Zeit zahlreiche Berührungspunkte. Ansprechpartner wechseln. Unterlagen veralten. Reverse-DNS-Zonen werden umgebaut. Ressourcen, die in einem internen Bestand geführt werden, erscheinen nicht immer so in extern beobachtbaren Ankündigungen, wie eine automatisierte Regel es erwartet. Selbst sorgfältige Betreiber können eine Änderung übersehen oder eine Benachrichtigung an ein nicht mehr betreutes Postfach verlieren.

Wer alle einschlägigen Hinweise in einer privaten MyAFRINIC-Ansicht zusammenführt, kann Überraschungen verringern.

AFPUB-2020-GEN-001-DRAFT01, eingereicht am 17. Februar 2020 in Version 1.0, setzte genau an dieser praktischen Erfahrung an. Die Autoren Jordi Palet Martinez, Frank Habicht, Mark Elkins und Haitham El Nakhal schlugen regelmäßige Überprüfungen vor, soweit möglich automatisiert. Nach einer Prüfung oder Aktualisierung sollte das Mitglied benachrichtigt werden; bei einer angezeigten Abweichung waren Erinnerungen vorgesehen. Auch Mitarbeitende sollten Warnungen erhalten.

Aus Sicht eines Mitglieds hätte daraus ein Frühwarnsystem entstehen können: nicht erst beim nächsten Servicewunsch feststellen, dass eine Angabe fraglich ist, sondern den betreffenden Datensatz rechtzeitig sehen und berichtigen.

Diese Funktion ist legitim, solange der Bildschirm als Arbeitsfläche verstanden wird. Er kann anzeigen, welches Feld nicht zu welcher genau benannten Anforderung passt. Er kann festhalten, aus welcher Datenquelle eine Feststellung stammt, zu welchem Zeitpunkt die Messung erfolgte und welche Fassung einer Regel oder Vertragsbestimmung herangezogen wurde. Er kann die ursprüngliche Anzeige, die Antwort des Mitglieds und den korrigierten Zustand nebeneinander bewahren. Er kann sichtbar machen, ob eine Maschine den Hinweis erzeugt hat oder ob ein Mensch einen mehrdeutigen Sachverhalt betrachtet. All das dient der Genauigkeit des Registers.

Der Entwurf ging jedoch über diese nützliche Arbeitsfläche hinaus. Seine Beispiele legten sehr verschiedene Sachverhalte in denselben begrifflichen Korb. Zahlung oder Unterlagen, ausbleibende Antworten, nicht genutzte oder nicht angekündigte Ressourcen, veraltete WHOIS-Angaben, Reverse-DNS-Pflege, unzulässige Unterzuweisungen aus PI-Zuweisungen, nicht autorisierte Transfers und wiederholte oder fortdauernde Verstöße sollten als Statusbestandteile erscheinen. Die Oberfläche hätte damit nicht nur Daten gesammelt. Sie hätte entschieden, wie unterschiedliche Beobachtungen benannt, gewichtet und visuell zusammengezogen werden.

Genau dort beginnt die eigentliche Governance-Frage. Ein Dashboard wirkt neutral, weil es aus Tabellen, Symbolen und Zeitstempeln besteht. Doch die Wahl der Datenquelle, der Prüffrequenz, des Schwellenwerts, der Statusbezeichnung und des Empfängerkreises ist nicht neutral. Wer ein Feld rot färbt, bestimmt noch nicht die Rechtslage, beeinflusst aber, was Mitarbeitende zuerst untersuchen und was ein Mitglied zuerst für gefährlich hält. Wer verschiedene Abweichungen zu einem Gesamtstatus verdichtet, erzeugt den Eindruck, sie seien austauschbar.

Wer einen Wiederholungszähler nicht nach einer Korrektur zurücksetzt, lässt einen bereinigten Fehler als fortdauernden Charakterzug erscheinen.

Kein einheitliches „Compliance-Objekt“

Ein Zahlungsstand ist zunächst eine Buchungsfrage. Er kann durch einen Zahlungseingang, eine Zuordnung oder einen Streit über eine Rechnung geklärt werden. Ein fehlendes Dokument kann bedeuten, dass die Datei nie eingereicht wurde, dass sie nicht richtig zugeordnet ist oder dass ihre Echtheit beziehungsweise Aktualität menschlich geprüft werden muss. Eine ausbleibende Antwort hängt davon ab, ob die Nachricht den richtigen Empfänger erreichte, was gefragt wurde und welche Frist überhaupt galt. Schon diese drei Beispiele verlangen verschiedene Belege und verschiedene Wege zur Korrektur.

Bei technischen Angaben wird die Heterogenität noch deutlicher. Die Aktualität von WHOIS-Daten betrifft den Zustand eines Registereintrags und die Frage, welches Feld sachlich falsch oder veraltet ist. Reverse DNS betrifft eine andere Betriebsfunktion und kann von Wartungsabläufen abhängen. Eine beobachtete Ressourcenankündigung ist nicht dasselbe wie die Berechtigung, die Zuordnung oder die tatsächliche Nutzung einer Ressource. Das Fehlen eines beobachtbaren Signals erklärt allein nicht, weshalb es fehlt.

Eine PI-Unterzuweisung oder ein Transfer verlangt wiederum Tatsachen über konkrete Handlungen und Befugnisse, die nicht aus einer simplen Abweichung in einem Datenabgleich folgen.

Auch Wiederholung ist keine eigene Schuldquelle. Ein Zähler kann nützlich sein, um Supportaufwand zu priorisieren oder zu erkennen, dass ein technischer Prozess regelmäßig scheitert. Er muss jedoch offenlegen, was gezählt wird, wann ein Ereignis als beendet gilt und wann der Zähler nach einer Berichtigung zurückgesetzt wird. Drei identische Maschinenmeldungen über denselben inzwischen behobenen Datensatz sind nicht drei unabhängig bewiesene Verstöße. Drei unterschiedliche Hinweise können drei verschiedene Ursachen haben. Die Zahl allein kann weder Vorsatz noch Fahrlässigkeit, Vertragsbruch oder die Berechtigung zu einer Folge beweisen.

Ein sorgfältig gebauter Bildschirm braucht deshalb keine einzige Ampel für das Mitglied. Er braucht getrennte Karten oder Zeilen, die jede Beobachtung in ihrer eigenen Beweiskategorie halten. Bei objektiven Registerdifferenzen sollte er den Sollwert, den beobachteten Wert, die Quelle, den Messzeitpunkt und die verwendete Fassung nennen. Bei qualitativen Fragen sollte er ausdrücklich sagen, dass eine Prüfung offen ist und keine Feststellung getroffen wurde. Bei Daten, die von Dritten beeinflusst werden können, sollte er diese Abhängigkeit kenntlich machen. Die Unsicherheit gehört in die Anzeige, nicht in eine unsichtbare Fußnote.

Diese Trennung schützt nicht nur das Mitglied. Sie verbessert die Arbeit von AFRINIC. Mitarbeitende können eine Zahlungszuordnung an die zuständige Stelle geben, eine WHOIS-Korrektur direkt begleiten und eine komplexe Transferfrage gesondert behandeln. Das verhindert, dass ein pauschaler Status eine Warteschlange dominiert, obwohl nur ein einzelner Datensatz unklar ist. Es schafft außerdem eine bessere Grundlage für spätere Kontrolle: Außenstehende müssen nicht glauben, dass ein grünes oder rotes Symbol die ganze Wahrheit enthält, wenn die einzelnen Schritte dokumentiert bleiben.

Sichtbar für das betroffene Mitglied, nicht für die Öffentlichkeit

Der vorgeschlagene Nutzen war mitgliederspezifisch. Jedes Mitglied sollte seinen eigenen Stand sehen. Daraus folgt keine Grundlage für eine öffentliche Liste, auf der Organisationen nach vermeintlicher Regelkonformität sortiert werden. Diese Privatsphäregrenze ist wesentlich. Eine öffentliche Behauptung kann Reputations- und Sicherheitsfolgen auslösen, bevor geklärt ist, ob die Daten richtig waren, die Regel passte oder eine dritte Partei die Abweichung verursachte. Selbst ein späterer Widerruf erreicht nicht automatisch alle, die den ersten Status gesehen haben.

Ein privater Hinweis vermeidet nicht jedes Risiko, aber er begrenzt die Übertragung. Das Mitglied kann den Beleg prüfen, eine falsche Zuordnung erklären und eine Korrektur vornehmen, ohne dass eine vorläufige Maschinenfeststellung bereits in die Außenwelt gelangt. Mitarbeitende können sehen, dass eine Antwort einging, ohne daraus öffentlich eine Niederlage oder ein Eingeständnis zu machen. Wenn ein Fall ungeklärt bleibt, kann der Status weiterhin „Prüfung offen“ lauten, statt einen endgültigen Befund vorzutäuschen.

Die Privatsphäre muss auch innerhalb der Organisation praktisch begrenzt werden. Nicht jede Warnung gehört in jede interne Warteschlange. Ein Zahlungsproblem benötigt möglicherweise andere Empfänger als eine technische Registerdifferenz. Der Entwurf erwähnte Mitarbeitendenwarnungen, doch eine belastbare Gestaltung müsste bestimmen, wer welche Information wann sieht und warum. Die Zugriffsspur sollte erkennen lassen, ob eine Anzeige bearbeitet, korrigiert oder nur betrachtet wurde. Sichtbarkeit ist ein Werkzeug; sie darf nicht durch unbestimmte Verteilung zum reputationsähnlichen Druckmittel werden.

Die Chronologie, die jede Übertreibung stoppt

Die tatsächliche Geschichte des Entwurfs ist klar begrenzt. Auf die Einreichung vom 17. Februar 2020 folgte im August eine Folgenabschätzung durch AFRINIC. Sie verstand den Vorschlag als Mischung aus Policy- und Vertragsstatus und empfahl, beides voneinander zu unterscheiden. Sie verwies auf bereits bestehende automatisierte Werkzeuge unter anderem für Zahlungsstatus und Reverse DNS, stellte aber fest, dass diese nicht in einem Dashboard zusammengeführt waren. Außerdem erwartete sie erhebliche Entwicklung in MyAFRINIC, Arbeitsaufwand für Member Services und möglicherweise zusätzliches Personal.

Die Folgenabschätzung stellte konkrete Fragen, die den unfertigen Charakter des Designs zeigen. Ab welchem Schwellenwert sollte eine wiederholte oder fortdauernde Abweichung angenommen werden? Wann sollte ein Zähler zurückgesetzt werden? Wo würde eine geplante Veröffentlichung erscheinen? Was war mit der Löschung eines Domain-Objekts gemeint? Wie sollte eine Quarantäne funktionieren? Solche Fragen sind keine Details nach einer bereits getroffenen Entscheidung. Sie betreffen die Bedeutung, Reichweite und betriebliche Wirkung des vorgeschlagenen Systems selbst.

Bei AFRINIC-32 im September 2020 wurden sowohl Unterstützung als auch Einwände festgehalten. Befürworter sahen Wert in Sichtbarkeit und Benachrichtigung. Andere hielten Teile für operativ oder redundant, warnten vor Kosten und Ressourcenbelastung oder bezweifelten, dass automatisierte Nachrichten die gewünschte Aufmerksamkeit erhielten. Die Co-Vorsitzenden stellten keinen Konsens fest und verwiesen den Vorschlag zurück an die Diskussion auf der Mailingliste. Die offizielle Seite führt Draft 1 heute als Expired.

Damit ist ausgeschlossen, aus dem Dokument eine tatsächlich eingeführte Ordnung zu machen. Es gibt in den vorliegenden Belegen keine Annahme, keine Ratifizierung, keine Umsetzung und keinen Fall, in dem ein Mitglied aufgrund dieses Dashboards behandelt wurde. Es ist ebenso wenig belegt, dass irgendein automatischer Hinweis richtig oder falsch war, dass eine konkrete Sanktion erfolgte oder dass ein bezifferbarer wirtschaftlicher Schaden entstand. Der Entwurf zeigt, welche Gestaltung erwogen wurde. Er zeigt nicht, dass sie operative Wirklichkeit wurde.

Der gute Entwurf, der möglich gewesen wäre

Eine begrenzte Alternative hätte mit einem reinen Sichtbarkeitsmodus begonnen. Das Dashboard hätte jede Beobachtung getrennt dargestellt und ausdrücklich darauf verzichtet, einen Gesamtstatus als Rechtsurteil auszugeben. Neben jedem Hinweis hätten die genaue Datenquelle, die einschlägige Regel- oder Vertragsfassung, der Zeitpunkt der Prüfung, die Sicherheit der Aussage und die bekannte Rolle Dritter stehen können. Ein Mitglied hätte den Originaldatensatz sehen, antworten, Belege ergänzen und eine Korrektur beantragen können.

Nach einer Korrektur hätte das System nicht einfach den alten Eintrag verschwinden lassen. Eine Revisionsgeschichte hätte gezeigt, was ursprünglich beobachtet wurde, was das Mitglied erklärte, welche Änderung erfolgte und ob die Maschine bei der nächsten Prüfung einen passenden Zustand erkannte. Diese Geschichte wäre nicht als Schuldregister geführt worden, sondern als Nachweis dafür, dass Registerpflege funktioniert. Ein Wiederholungszähler hätte nach nachgewiesener Korrektur entweder zurückgesetzt oder zumindest so aufgeschlüsselt werden müssen, dass alte und neue Ursachen nicht vermischt werden.

Mehrdeutige Hinweise wären an eine begrenzte menschliche Prüfung gegangen. Der Mensch hätte Quellen vergleichen, mögliche Fehlalarme erkennen und Gründe dokumentieren können. Er hätte aber nicht aus seiner Beteiligung eine neue Befugnis abgeleitet. Seine Aufgabe wäre epistemisch: besser verstehen, ob und welcher Unterschied besteht. Die Anzeige hätte weiterhin zwischen Beobachtung, Rückfrage, Antwort, Korrektur und ungelöster Frage unterschieden.

Am wichtigsten wäre eine technische Sperre gegen automatische Folgen gewesen. Kein rotes Feld, kein Zeitablauf, keine Zahl von Erinnerungen und kein interner Bearbeitungsstatus dürfte unmittelbar Leistungsvorenthaltung, Veröffentlichung, Löschung, Rückholung, Entzug oder Schließung auslösen. Falls AFRINIC jemals eine belastende Maßnahme erwägen wollte, müsste dieser Vorgang das Dashboard verlassen.

Dann wäre getrennt nachzuweisen, welche gültige und anwendbare privatrechtliche Grundlage gegenüber genau dieser Partei besteht, welche Tatsachen sie erfüllt, welche Mitteilung erging, welche Antwort und Abhilfe möglich waren, wie Verhältnismäßigkeit und Betriebskontinuität gewahrt werden und welche Überprüfung offensteht.

In dieser begrenzten Form wäre die Oberfläche weder kraftlos noch bloße Dekoration. Sie könnte die Qualität von Registerdaten erhöhen, Supportkosten senken, gleichmäßige Benachrichtigungen ermöglichen und Missverständnisse früh aufdecken. Ihre Stärke läge gerade darin, dass sie sich nicht als Gericht ausgibt. Ein guter Registerdienst beweist seine Zuverlässigkeit nicht durch möglichst scharfe Symbole, sondern dadurch, dass Betroffene verstehen können, was beobachtet wurde und wie eine falsche oder veraltete Beobachtung berichtigt wird.