Zusammenfassung

  • ICANN kündigte am 28. August 2026 das Registrar Accreditation Agreement mit IPIP INC. gemäß Abschnitt 5.5.4; wirksam werden soll die Kündigung am 13. September.
  • Als Grundlage nennt das Schreiben vier bis zum 26. August nicht behobene Verstöße: RDAP-Betrieb, Registrar Data Escrow, fällige Akkreditierungsgebühren und den Link zum Verfahren für die Offenlegung nicht öffentlicher Registrierungsdaten.
  • Weitere Punkte bezeichnet ICANN in einem eigenen Absatz als „zusätzliche Bedenken“. Transfer, Entzug der Logo-Lizenz und fortgeltende Vertragspflichten bilden nochmals eine andere Gruppe.
  • Eine öffentliche Vorgangszeile für jeden Punkt könnte Rechtsgrundlage, Beleg, Abhilfe, Frist, Antwort und Entscheidung nachvollziehbar halten, ohne vertrauliches Fallmaterial offenzulegen.

Das Schreiben steht im Futur

Am 28. August fiel eine Entscheidung. Am 13. September soll sie wirksam werden. Für eine Meldung zwei Tage nach dem Schreiben ist dieser Tempusunterschied wesentlich.

ICANN teilte IPIP INC., IANA-Registrar Nummer 3774, mit, dass das Registrar Accreditation Agreement von 2013 nach Abschnitt 5.5.4 beendet werde. Unmittelbar danach nennt das Schreiben gemäß Abschnitt 5.6 den 13. September als Wirksamkeitsdatum, 16 Kalendertage nach der Mitteilung.

Mit Stand vom 30. August ist die Kündigung daher ausgesprochen, der operative Wechsel aber nicht als vollzogen belegt. Die öffentlichen Unterlagen nennen noch keinen übernehmenden Registrar, keine Zahl betroffener Domains, keinen Termin eines Bulk-Transfers und keinen Abschlussnachweis. Ebenso wenig ist öffentlich dokumentiert, dass ein Schiedsverfahren, eine Aussetzung, eine spätere Abhilfe oder eine Korrektur erfolgt wäre.

Die ICANN-Übersicht der Compliance Notices verbindet die Vertragsverletzungsanzeige vom 5. August mit der Kündigung vom 28. August. Sie dokumentiert den Verfahrensstand der Durchsetzung. Sie ist kein Beleg dafür, dass alle daraus folgenden Betriebsmaßnahmen bereits abgeschlossen sind.

Vier Verstöße sind nicht ein und dieselbe Störung

Laut Kündigung beseitigte IPIP die am 5. August mitgeteilten Verstöße nicht bis zur Frist am 26. August. Anschließend bezeichnet das Dokument vier Punkte als weiterhin bestehende Verstöße.

Erstens habe IPIP keinen RDAP Directory Service betrieben, der für alle aktiven, vom Registrar gesponserten gTLD-Domainnamen die erforderlichen Registrierungsdaten zurückgibt und dem geltenden Implementierungsleitfaden sowie Response Profile entspricht. In der früheren Anzeige heißt es, IPIP habe zwar eine RDAP-Basis-URL registriert, die von ICANN getesteten Domainabfragen hätten jedoch keine Registrierungsdaten geliefert.

Zweitens seien Registrar-Daten nicht rechtzeitig nach dem vorgeschriebenen Zeitplan, den Bedingungen und dem Format bei einem zugelassenen Escrow-Agenten hinterlegt worden. Drittens seien Akkreditierungsgebühren überfällig. Viertens habe auf der Startseite ein direkter Link zum Mechanismus und Verfahren gefehlt, über das die Offenlegung nicht öffentlicher Registrierungsdaten beantragt werden kann.

Die gemeinsame Überschrift „Compliance“ darf die Unterschiede nicht verdecken. RDAP ist ein öffentlich erreichbarer Registrierungsdatendienst. Data Escrow ist eine Kontinuitätssicherung bei einem zugelassenen Verwahrer. Gebühren sind eine vertragliche Zahlung. Der Offenlegungslink ist der nach Abschnitt 10.1 der Registration Data Policy vorgesehene öffentliche Zugang für Anträge. Für jeden Punkt gelten andere Beobachtungen, Abhilfen und betroffene Nutzer.

Die zugrunde liegenden Anforderungen sind öffentlich nachprüfbar. ICANN bezeichnet das gTLD RDAP Profile vom Februar 2024 seit dem 21. August 2025 als verbindlich. Die Registrar-Data-Escrow-Spezifikation 2025 trat am selben Tag in Kraft. Die Registration Data Policy verlangt Angaben zu Antragsformat, Antwortweg und erwarteter Bearbeitungszeit.

Die konkreten IPIP-Feststellungen stammen gleichwohl von ICANN. BTW hat weder den gesamten gesponserten Namensbestand erneut abgefragt noch Escrow-Konto oder Rechnungen geprüft. Die saubere Zuschreibung lautet deshalb: ICANN stellte vier fortbestehende Verstöße fest.

Der zweite Absatz benutzt einen anderen Begriff

Nach dieser Viererliste wechselt das Schreiben seine Sprache. Mit „In addition“ leitet es Punkte ein, die IPIP als „additional concerns“ nicht angesprochen oder gelöst habe.

Genannt werden ein öffentliches Missbrauchsformular oder eine eigens dafür bestimmte E-Mail-Adresse, Verfahren zur Entgegennahme, Bearbeitung und Nachverfolgung von Missbrauchsmeldungen, Namen und Funktionen von leitenden Personen, eine Postanschrift, Regeln zur Löschung und automatischen Verlängerung, Wiederherstellungsgebühren, die Wege für Verlängerungsmitteilungen sowie zugesagte Abhilfemaßnahmen mit Umsetzungsterminen.

Die Bezeichnung als Bedenken macht diese Fragen weder banal noch vertragsfremd. Mehrere berühren ausdrückliche Informations- oder Betriebspflichten des RAA. Auch können sie später formale Folgen haben. Im vorliegenden Schreiben stehen sie aber nicht in dem vorausgehenden Satz, der die vier verbleibenden Verstöße als Grundlage dieser Kündigung benennt.

Damit sind zwei Übertreibungen ausgeschlossen. Es wäre falsch zu behaupten, die zusätzlichen Bedenken hätten keinerlei rechtliche Relevanz. Ebenso falsch wäre es, jeden Unterpunkt rückwirkend als eigenständig festgestellten Kündigungsgrund zu zählen. Die öffentliche Entscheidung hat eine Grenze gezogen; ihre Wiedergabe muss sie behalten.

Auch unter den vier Verstößen veröffentlicht ICANN keine Rangfolge. Abschnitt 5.5.4 erlaubt die Kündigung, wenn ein Registrar einen Verstoß nicht innerhalb von 21 Tagen nach Mitteilung behebt. Das Schreiben sagt, alle vier seien offen geblieben. Es sagt nicht, welcher Punkt ausschlaggebend war oder ob ICANN einen davon allein für ausreichend hielt. Eine Kausalität, die der Entscheider nicht offenlegt, darf die Berichterstattung nicht ergänzen.

Kontaktversuche belegen Ablauf, nicht Absicht

Die beiden Dokumente enthalten mehrere, im März und Juni beginnende Kontaktverläufe. ICANN beschreibt eskalierte oder aufeinanderfolgende Mitteilungen, abgewiesene E-Mails, ausbleibende Antworten, Telefonversuche und eine Antwort vom 2. April, die nach ihrer Bewertung keinen ausreichenden Compliance-Nachweis lieferte. Am 5. August ging die formale Anzeige per E-Mail und Kurier heraus. Die Zustellung des Kuriers wurde am 7. August bestätigt. Erinnerungen folgten am 19. August, die Abhilfefrist endete am 26. August. Am 28. August erklärte ICANN die geforderte Abhilfe für ausgeblieben.

Daraus lässt sich ableiten, dass ICANN Benachrichtigungsversuche, eine Heilungsfrist und ihre Bewertung des Antwortstands dokumentiert hat. Nicht ableiten lässt sich, warum Nachrichten abgewiesen oder unbeantwortet blieben. Der Verlauf belegt weder Aufgabe des Geschäfts noch Insolvenz, Betrug, einen Cybervorfall oder bewusste Umgehung.

Ein Vertragsvollzug muss nicht die gesamte Fallakte veröffentlichen. Private Kontaktdaten, Kundendaten, Sicherheitsinformationen oder interner Rechtsrat dürfen geschützt bleiben. Diese legitime Knappheit zwingt aber nicht dazu, Beobachtung, Informationsersuchen, formalen Verstoß, Bedenken, Kündigungsfolge und fortgeltende Pflicht sprachlich zu verschmelzen.

Nach den Gründen folgen Auswirkungen

Im nächsten Teil spricht das Schreiben nicht mehr darüber, warum gekündigt wird, sondern was daraus folgt. ICANN werde nach dem De-Accredited Registrar Transition Procedure die von IPIP verwalteten Namen auf einen qualifizierten akkreditierten Registrar übertragen. Die ICANN-Logo-Lizenz werde zum 13. September widerrufen. Bestimmungen über Aufbewahrung von Registrierungsdaten, Gebühren, Streitbeilegung und Grenzen finanzieller Ansprüche wirkten nach; offene und weitere bezeichnete Gebühren blieben zahlbar.

Diese Sätze erhöhen nicht die Zahl der Verstöße. Sie beantworten andere Fragen: Wie wird das Portfolio weitergeführt? Wann endet die Markenberechtigung? Welche Pflichten überdauern die Akkreditierung?

BTW hat die Auswahl eines übernehmenden Registrars und die Grenzen eines Escrow-Datensatzes als Ersatz für einen laufenden Kundenbetrieb bereits separat behandelt. Die erneute Ausführung dieser Mechanik wäre keine neue Analyse. Hier geht es um den früheren Kontrollpunkt: Ist im öffentlichen Vollzugsakt erkennbar, welche Aussage Befund, Bedenken oder Folge ist?

Ein öffentliches Dispositionsregister pro Punkt

Die Notice-Übersicht von ICANN liefert einen brauchbaren Status auf Fallebene. Ergänzend könnte eine kompakte Tabelle jeden Punkt durch das Verfahren führen und so spätere Fehlzitate erschweren.

Eine Zeile sollte Kennung und Klasse, die genaue Vertrags-, Spezifikations- oder Policy-Bestimmung, eine öffentliche Belegquelle mit Beobachtungsdatum, verlangte Abhilfe oder Information, Frist und Verlängerung, Antwortstatus, Disposition in jeder Mitteilung, die ausdrücklich erklärte Rolle im aktuellen Schritt sowie öffentliche Korrektur-, Einspruchs-, Schieds- oder Aussetzungsstände enthalten.

Nach der Kündigung kämen der Verantwortliche für den nächsten Schritt und ein Wiedervorlagedatum hinzu. Ein formaler Verstoß kann geschlossen werden, als Forderung fortbestehen, in die Streitbeilegung übergehen oder für den Transfer ohne Bedeutung sein. Ein zusätzliches Bedenken kann beantwortet, später formalisiert oder als historische Notiz erhalten werden. Die Tabelle zeigt diese Übergänge, statt sie aus verstreuter Prosa erraten zu lassen.

Geschützte Postfächer, Personennamen, Rohprotokolle oder Rechtsberatung gehören nicht hinein. Erforderlich sind nachvollziehbare Klassifikationen und zurechenbare Ergebnisse.

Heng Lus Argument dient hier ausschließlich als analytische Disziplin: Institutionelle Macht mit erheblichen Folgen sollte an erkennbare Befugnis, Belege, Verantwortlichkeit und Überprüfung gebunden bleiben. ICANNs Befugnis folgt aus dem Vertrag, nicht aus diesem Essay. Der Essay erklärt, warum die öffentliche Nacherzählung weder Machtumfang noch Befund unbemerkt ausweiten sollte.

Die unmittelbare Aussage bleibt eng. ICANN hat IPIP die Kündigung mitgeteilt. Vier fortbestehende Verstöße sind benannt. Weitere Bedenken stehen getrennt. Das Wirksamkeitsdatum liegt noch in der Zukunft. Genauigkeit beginnt damit, aus diesen Klassen keine einzige vergrößerte Anschuldigung zu machen.

Quellen

  1. ICANN — Kündigungsschreiben an IPIP INC., 28. August 2026
  2. ICANN — Vertragsverletzungsanzeige an IPIP INC., 5. August 2026
  3. ICANN — Anzeigen zu Verstößen, Suspendierungen, Kündigungen und Nichtverlängerungen
  4. ICANN — Registrar Accreditation Agreement und zugehörige Unterlagen
  5. ICANN — Registration Data Policy
  6. ICANN — gTLD RDAP Profile
  7. ICANN — Registrar Data Escrow Program
  8. ICANN — Ansatz und Verfahren von Contractual Compliance
  9. ICANN — Beendigung einer Akkreditierung
  10. ICANN — De-Accredited Registrar Transition Procedure
  11. Heng Lu — Wenn Registry-Macht von Haftung getrennt wird