Zusammenfassung

  • Entwurf 6 verlangte einen abuse-c-Verweis mit einem erreichbaren, überwachten und aktiv verwalteten abuse-mailbox, setzte zunächst höchstens 15 Tage für die Validierung und nach einem Fehlschlag eine Eskalation an andere LIR-Kontakte mit einem zweiten Zeitraum von höchstens 15 Tagen fest. Hinzu kamen Prüfungen bei Erstellung oder Änderung, mindestens halbjährlich, nach Ermessen AFRINICs und auf bestimmte Hinweise hin.
  • Der operative Text enthielt keine Regel, nach der ein Fehlschlag Support sperren, andere Registerleistungen blockieren oder Nummernressourcen entziehen sollte. Aussagen über Support nur für regelkonforme Mitglieder und eine mögliche Kündigung des RSA bei fortdauernder Nichtbefolgung standen in gesonderten Mitarbeiter- beziehungsweise Rechtsfolgenabschätzungen.
  • Die virtuelle Erörterung lieferte verwertbare Einwände, aber weder Teilnehmerzahl noch Nachrichtenaufkommen ergeben einen repräsentativen Nenner. Die fünf Einwandskomplexe müssen deshalb einzeln am Text geprüft werden: Altressourcen, Datenschutz, fehlende Missbrauchsdefinition, Antwortpflicht und unbestimmte Folgen.
  • Eine private technische Registrierungsstelle kann Erreichbarkeit, Abweichung, Mitteilung, Korrektur und erneute Prüfung dokumentieren. Sie kann nicht feststellen, ob behaupteter Missbrauch stattgefunden hat, ob eine inhaltliche Antwort richtig war oder ob eine Strafe verdient ist.

L3 — Was Entwurf 6 von einem Beschwerdepostfach tatsächlich beweisen ließ

Am 5. August 2020 wurde Version 6.0 des Vorschlags mit der Kennung AFPUB-2018-GEN-001-DRAFT06 eingereicht. Der Entwurf sollte Artikel 8.0 des Consolidated Policy Manual ändern. Sechs Wochen später, am 17. September, wurde er während des online abgehaltenen AFRINIC32-Treffens diskutiert. Weitere vier Tage später hielten die Co-Vorsitzenden in der RPD-Mailingliste fest, dass kein grober Konsens erreicht worden sei. Diese Abfolge ist mehr als eine chronologische Einleitung. Sie zeigt, wie ein normativer Text in ein neues Beteiligungsmedium eintrat und dort in mehrere, zum Teil gegensätzliche Lesarten zerfiel.

Für eine belastbare Analyse ist der operative Text der Ausgangspunkt. Entwurf 6 verlangte bei inetnum-, inet6num- und aut-num-Objekten ein abuse-c-Attribut. Das von diesem Attribut bezeichnete Personen- oder Rollenobjekt sollte seinerseits ein gültiges Beschwerdepostfach enthalten. Dieses abuse-mailbox sollte überwacht und aktiv verwaltet werden. Meldende Personen durften nicht gezwungen werden, ein vorgeschriebenes Formular zu verwenden. Das Postfach musste Berichte und dazugehöriges Material wie Protokolle, Kopfzeilen und Beispiele empfangen können.

Damit verband der Entwurf eine maschinenauffindbare Registerangabe mit der praktischen Erwartung, dass an die angegebene Adresse tatsächlich eine Meldung zugestellt werden konnte.

In diesem schmalen Sinn ist der Zweck unmittelbar nachvollziehbar. Wer einen Netzvorfall melden will, soll nicht erst Organisationsdiagramme durchsuchen, veraltete Webseiten prüfen oder mehrere allgemeine Adressen ausprobieren müssen. Ein eindeutiger Kontakt im Register senkt Suchkosten. Ein regelmäßig geprüfter Kontakt vermindert das Risiko, dass eine Meldung an einer nicht mehr bedienten Mailbox hängen bleibt.

Auch die Ressourceninhaber profitieren: Eine einheitliche Adresse kann Meldungen bündeln, intern zuständige Teams erreichbar machen und verhindern, dass technische Hinweise in Verkaufs-, Rechnungs- oder allgemeinen Supportkanälen versanden. Ein objektiv gepflegtes Kontaktfeld ist daher keine bloße Formalie, sondern nützliche Koordinationsinfrastruktur.

Entwurf 6 beließ es jedoch nicht bei der Feststellung, dass eine Nachricht zugestellt werden konnte. Unter seinen Validierungszielen nannte er auch, der Inhaber müsse das Verfahren und die Regel gelesen haben, das Postfach regelmäßig überwachen, Maßnahmen ergreifen und auf Berichte antworten. In diesem Bündel liegen verschiedene Beweisarten nebeneinander. Ob eine Adresse technisch erreichbar ist, lässt sich durch einen definierten Versand und einen protokollierten Empfang oder eine eindeutige Antwort auf eine Prüfanforderung feststellen.

Ob ein Mitarbeiter ein Dokument gelesen hat, ob eine Organisation einen realen Bericht angemessen behandelt hat und ob die Antwort inhaltlich genügte, sind dagegen keine bloßen Eigenschaften eines Registerfelds.

Diese Differenz ist nicht semantische Spitzfindigkeit. Eine Zustellbestätigung beantwortet die Frage, ob der Kanal funktioniert. Eine inhaltliche Bewertung beantwortet die Frage, ob ein bestimmtes Verhalten angemessen war. Für die zweite Frage muss zunächst geklärt werden, was geschehen ist, welche Tatsachen verlässlich sind, welche Pflichten aus anwendbarem Recht oder Vertrag folgen und wer zur Entscheidung befugt ist.

Selbst ein höflicher, schneller Eingangshinweis kann in der Sache unzureichend sein; umgekehrt kann eine knappe oder verspätete Antwort durch eine komplexe Untersuchung, fehlende Informationen oder einen unzutreffenden Bericht erklärbar sein. Ein Registertest liefert keinen Maßstab für diese Bewertung.

Der Takt des Entwurfs war genauer. Für die erste Validierung sah Entwurf 6 einen Zeitraum von höchstens 15 Tagen vor. Schlug diese Phase fehl, sollte AFRINIC andere Kontakte des Local Internet Registry ansprechen und eine weitere Validierungsphase von höchstens 15 Tagen eröffnen. Es handelte sich somit nicht um einen einzigen stillen Test mit sofortiger Endwirkung. Der Wortlaut legte eine erste Gelegenheit und anschließend eine Eskalation an weitere registrierte Kontaktwege an.

Darin steckt der Ansatz eines Heilungsverfahrens: Ein Fehler wird nicht nur entdeckt, sondern an eine zweite Kontaktfläche gemeldet, bevor der Vorgang abgeschlossen wird.

Gleichwohl lässt die Angabe eines Zeitraums wichtige Verfahrensfragen offen. Ein Fenster von höchstens 15 Tagen ist nur dann fair und prüfbar, wenn der Anfang eindeutig feststeht. Dazu gehören Testdatum, verwendete Adresse, Übertragungsweg und der genaue Erfolgsmaßstab. Bei einem Fehlschlag muss erkennbar sein, ob die Nachricht dauerhaft unzustellbar war, ob eine technische Antwort ausblieb oder ob AFRINIC eine inhaltlich falsche Reaktion annahm. Ebenso muss die Mitteilung an die weiteren LIR-Kontakte datiert und nachweisbar sein.

Ohne diese Angaben bleibt zwar eine Zahl im Text, aber kein vollständiger Nachweis, wann die Frist lief und was innerhalb dieser Frist hätte geschehen müssen.

Die Validierung sollte nicht einmalig bleiben. Der Entwurf verlangte eine Prüfung bei der Erstellung oder Aktualisierung des abuse-c, mindestens einmal in sechs Monaten und außerdem immer dann, wenn AFRINIC eine Validierung für angemessen hielt. Die ersten beiden Anlässe lassen sich objektiv beschreiben. Eine neue oder geänderte Kontaktangabe kann unmittelbar getestet werden; eine halbjährliche Wiedervorlage folgt einem nachvollziehbaren Kalender. Die dritte Kategorie eröffnet dagegen Ermessen.

Der Entwurf gestattete AFRINIC zudem, die anfänglichen und eskalierten Zeiträume sowie die Häufigkeit der regelmäßigen Prüfung zu ändern, sofern Gründe erläutert und die Gemeinschaft benachrichtigt würden. Begründung und Bekanntgabe sind wertvolle Sicherungen, ersetzen aber keine eng formulierten Auslösekriterien.

Besonders sensibel war die beschwerdebezogene Revalidierung. Angeblich betrügerisches Verhalten sowie eine unrichtige oder ausbleibende Antwort auf einen Missbrauchsbericht konnten AFRINIC gemeldet werden, damit erneut validiert wurde. Das kann eng verstanden werden: Eine Meldung, die darauf hindeutet, dass eine Adresse nicht funktioniert, löst einen neuen Erreichbarkeitstest aus. Dann bleibt die Registry auf ihrem eigenen Feld. Die Formulierung kann aber weiter gelesen werden: AFRINIC soll beurteilen, ob eine Antwort auf den ursprünglichen Bericht richtig war oder ob der Inhaber das Verfahren manipuliert hat.

Dann würde ein Kontaktcheck zum Eingangstor für eine Entscheidung über das Beschwerdevorbringen.

Genau hier muss der Beweisgegenstand ausdrücklich begrenzt werden. AFRINIC kann eine standardisierte Prüfnachricht an die registrierte Adresse senden. Es kann Zeitpunkt, Zieladresse, technische Zustellantwort und eine definierte Challenge-Antwort protokollieren. Es kann eine Abweichung zwischen Registereintrag und tatsächlicher Erreichbarkeit feststellen. Es kann den Inhaber benachrichtigen, eine Korrektur entgegennehmen und die berichtigte Adresse erneut testen. Diese Schritte erzeugen überprüfbare Tatsachen über die Datenqualität. Sie beweisen nicht, dass der Inhalt einer fremden Missbrauchsbeschwerde wahr oder falsch ist.

Sie beweisen auch nicht, dass Gegenmaßnahmen ausreichend waren oder dass die Reaktion der Organisation rechtlich oder sachlich richtig war.

Ein zweiter harter Rand betrifft die Folgen. Im operativen Wortlaut von Entwurf 6 stand keine Sperr-, Blockierungs- oder Entzugsklausel für eine gescheiterte Validierung. Es wäre daher falsch, dem Entwurf selbst eine solche Sanktion zuzuschreiben. Auf derselben archivierten Vorschlagsseite waren jedoch gesonderte Mitarbeiter- und Rechtsbewertungen wiedergegeben. Nach der Mitarbeiterabschätzung sollte Support nur einem regelkonformen Mitglied gewährt werden; die rechtliche Analyse verwies darauf, dass fortdauernde Nichtbefolgung eine Kündigung des Registration Service Agreement nach sich ziehen könnte.

Das waren Deutungen möglicher Auswirkungen. Sie waren nicht identisch mit den operativen Sätzen des Entwurfs.

Diese Trennung ist institutionell entscheidend. Wenn ein Regeltext einen genauen Prüftakt festlegt, die Konsequenz aber unausgesprochen lässt, entsteht ein Deutungsraum außerhalb des eigentlichen Instruments. Wer nur die Folgenabschätzung liest, könnte annehmen, Supportbeschränkung oder RSA-Kündigung seien bereits Bestandteil der Regel. Wer nur den Entwurf liest, könnte den Eindruck gewinnen, ein Fehlschlag habe überhaupt keine Folge. Beides verwischt die tatsächliche Architektur. Der Text definierte Prüfungen und Zeiträume; andere institutionelle Stimmen beschrieben mögliche Auswirkungen.

Ein auditierbares Verfahren muss beides sichtbar auseinanderhalten.

Auch „Reaktion“ darf nicht mit „Zustellung“ gleichgesetzt werden. Ein Challenge-Response-Verfahren kann beispielsweise verlangen, dass eine zufällige Kennung über einen festgelegten Kanal zurückgegeben wird. Gelingt dies, ist belegt, dass jemand oder ein automatisiertes System Zugang zur Mailbox hat. Es ist damit noch nicht bewiesen, dass reale Berichte regelmäßig gelesen, richtig klassifiziert oder abschließend bearbeitet werden. Umgekehrt sollte eine Registry nicht aus einer umstrittenen sachlichen Antwort folgern, die Mailbox sei ungültig. Datenfeld und Fallbearbeitung sind zwei getrennte Systeme, auch wenn beide dieselbe Adresse berühren.

Die stärkste wohlwollende Lesart von Entwurf 6 verdient ernsthafte Beachtung. Ein veröffentlichtes, validiertes Beschwerdepostfach kann Bounces verringern, Zuständigkeiten klären und die Zeit zwischen Beobachtung und Information des Operators verkürzen. Ein halbjährlicher Rhythmus entdeckt veraltete Adressen, bevor ein konkreter Vorfall eintritt. Die Eskalation zu anderen LIR-Kontakten verhindert, dass ein einzelner technischer Fehler sofort als endgültige Nichtbefolgung gilt. Und die Möglichkeit einer anlassbezogenen Wiederholung kann berechtigt sein, wenn konkrete Hinweise nahelegen, dass der gespeicherte Kontakt nicht mehr erreichbar ist.

Doch gerade der Nutzen dieses Modells verlangt eine enge Grenze. Je glaubwürdiger das Prüfsiegel wirkt, desto größer ist die Versuchung, ihm Aussagen zuzuschreiben, die es nicht tragen kann. Ein Status „validiert“ darf heißen, dass ein definierter technischer Test zu einem bestimmten Zeitpunkt gelang. Er darf nicht besagen, dass der Ressourceninhaber jeden Bericht akzeptiert, alle Vorwürfe anerkennt oder jede verlangte Maßnahme ergriffen hat. Ein Status „fehlgeschlagen“ darf auf einen protokollierten Kontaktfehler hinweisen. Er darf nicht als öffentliches Schuldsiegel für Missbrauch verwendet werden.

Die sinnvolle operative Folge bleibt deshalb beim Registereintrag. Nach einem gescheiterten Test kann der Status als überfällig oder nicht validiert markiert werden. Der Testnachweis bleibt erhalten. Der Inhaber erhält eine datierte Mitteilung und eine klar definierte Gelegenheit zur Berichtigung. Nach der Korrektur findet ein neuer Test statt, dessen Ergebnis getrennt vom ursprünglichen Fehler dokumentiert wird. Damit wird der Datensatz zuverlässiger, ohne Support zu einem Druckmittel zu machen oder Nummernressourcen für eine nicht entschiedene Beschwerdesache einzusetzen.

Entwurf 6 machte den richtigen Gegenstand sichtbar, band ihn aber nicht durchgehend an die richtige Art von Nachweis. Pflichtkontakt, zwei Validierungsfenster, halbjährliche Wiederholung und Eskalation sind Elemente eines Datenqualitätsverfahrens. Aussagen über gelesene Regeln, ergriffene Maßnahmen oder die Richtigkeit einer Antwort reichen in eine andere Sphäre. Der Kern der Prüfung besteht daher nicht darin, das Postfachprinzip zu verwerfen.

Er besteht darin, für jeden Satz zu fragen: Welche objektive Tatsache kann AFRINIC hier feststellen, und an welcher Stelle beginnt eine Entscheidung, für die eine private technische Registrierungsstelle weder Beweismittel noch Mandat besitzt?