Zusammenfassung

  • Indien fordert in seinem Schreiben vom 14. Juli die Prüfung von E-Mail und Telefonnummer vor Freischaltung einer Domain, verpflichtende zentrale DNS-Missbrauchsberichte und eine einsatzfähige Strafverfolgungs-Authentifizierung für dringende Registrierungsdatenanfragen.
  • ICANNs President and CEO bezeichnet die ersten beiden Themen als weiter prüfungswürdig und Teil der GNSO-Priorisierungsdebatte, kann aber weder die Prioritäten des Councils noch das Ergebnis eines PDP vorgeben.
  • Die Authentication Input Group veröffentlicht Treffen und Meilensteine von Juni 2026 bis März 2027. Sie ist kein politiksetzendes Gremium; ihr Proof of Concept aktiviert die 24-Stunden-Vorgabe nicht von selbst.
  • Ein öffentlicher Wegestatus je Forderung sollte zuständiges Organ, aktuellen Stand, Verfahren, nächste autorisierte Entscheidung und die ausdrückliche Nichtentscheidung festhalten.

Ein Sicherheitsrahmen, drei Regelungsobjekte

Am 14. Juli 2026 schrieb S. Krishnan, Secretary im indischen Ministerium für Elektronik und Informationstechnologie, an ICANN President and CEO Kurt Erik Lindqvist. Er ordnete drei seit längerem diskutierte Fragen dem öffentlichen Interesse, der Nutzersicherheit und dem Vertrauen zu und verlangte für sie unmittelbare Priorität.

Die erste Forderung verlegt die Kontaktprüfung zeitlich nach vorn. E-Mail-Adresse und Telefonnummer sollen vor Aktivierung der Domain validiert werden. Indien stellt dies dem bestehenden Reaktionszeitraum nach einer Genauigkeitsanfrage gegenüber und hält begrenzte Vertragsänderungen für ausreichend. ICANNs Erläuterung zum Whois Accuracy Program beschreibt, dass nach mehr als 15 Kalendertagen ohne Antwort Sperre, Beendigung oder Lock möglich sind. Daraus folgt nicht, dass eine Vorabprüfung bereits beschlossen wäre.

Die zweite Forderung betrifft eine neue Berichtspflicht und eine gemeinsame Infrastruktur. Registrare und Registries sollen regelmäßig Zahl, Art, Gegenmaßnahmen und Reaktionszeiten bei DNS-Missbrauchsfällen veröffentlichen; ICANN soll einen zentralen Mechanismus bereitstellen. Ob es eine Pflicht gibt und ob ein zentrales System entsteht, sind zwei Entscheidungen. Vergleichbare Daten erfordern außerdem Definitionen, Abdeckung, Nenner, die Trennung von Meldung und bestätigtem Vorfall sowie Korrekturhistorien.

Die dritte Forderung soll eine bereits formulierte, aber aufgeschobene Vorgabe nutzbar machen. Die Registration Data Policy nennt eine Empfangsbestätigung binnen zwei Stunden und eine Antwort auf dringende Anfragen binnen 24 Stunden, mit begrenzter Ausnahme. Ihre Implementierungsnotiz hält Section 10.7 jedoch zurück, bis ICANN eine Consensus Policy zur Authentifizierung des Antragstellers vollständig umgesetzt hat. Indien verlangt eine rasche Operationalisierung für Strafverfolgungsstellen.

Alle drei Punkte sind dokumentierte staatliche Politikpräferenzen. Sie sind weder GNSO-Beschluss noch Vertragsänderung noch Wirkungsnachweis. Verantwortliche Governance muss zeigen, durch welchen befugten Weg jede Präferenz zu einer gültigen nächsten Entscheidung gelangen kann.

Die Antwort wahrt die Kompetenzordnung

Lindqvists Antwort vom 11. August, am Folgetag veröffentlicht, teilt das Sicherheitsziel, leitet daraus aber kein zusätzliches Mandat für die Exekutive ab.

Zunächst verweist sie auf den Konsensratschlag des GAC aus ICANN83 und auf DNS Abuse Mitigation PDP 1 der GNSO zu Associated Domain Checks. Dieses Verfahren untersucht Pflichten hinsichtlich weiterer Domains, die mit einem Konto verbunden sind, gegen das eine verwertbare Missbrauchsmeldung vorliegt. Es ist ein echtes laufendes Politikverfahren. Es ist weder Vorabvalidierung der Kontaktdaten noch ein zentrales Meldesystem.

Bei Registrierungsdatenprüfung und Berichtstransparenz bleibt die Antwort vorsichtiger. ICANN org sieht weiteren Prüfungsbedarf und versteht beide Fragen als Gegenstand der Priorisierungsarbeit im GNSO Council. Das belegt Aufmerksamkeit, nicht eine formelle Platzierung. Charter, Arbeitsgruppe, Vertragsverhandlung, Empfehlung und Liefertermin werden nicht genannt.

Diese Begrenzung folgt der Institution. Die GNSO entwickelt und empfiehlt materielle gTLD-Politik und führt den Policy Development Process. Der GAC berät zu Anliegen von Regierungen und öffentlicher Politik. Der CEO kann Daten, Unterstützung und Betriebswissen der ICANN org sicherstellen und verabschiedete Politik umsetzen. Er kann weder die GNSO-Prioritäten festlegen noch den Ausgang eines PDP bestimmen.

Die Grenze schützt nicht nur das Council. Ein dringendes Regierungsanliegen wird nicht automatisch zur Entscheidungskompetenz. Eine Erörterung erlaubt der GNSO nicht, das Anliegen als erledigt zu verbuchen. Implementierungsvorbereitung macht ICANN org nicht zur Politikautorin. Neue Pflichten für Vertragspartner benötigen das jeweils gültige Politik- oder Vertragsverfahren.

Drei öffentlich belegte Zustände

Zum Stichtag 31. August ergibt sich aus den geprüften Quellen folgende Lage:

Geforderte Maßnahme Öffentlicher Stand Sichtbarer nächster befugter Schritt
E-Mail und Telefon vor Aktivierung prüfen Empfangen, beantwortet, als weiter prüfungswürdig und in GNSO-Priorisierungsdebatten beschrieben Kein datierter Prioritätsbeschluss, keine Charter, kein PDP und kein Vertragsschritt ausgewiesen
DNS-Missbrauchsberichte verpflichtend und zentral machen Empfangen, beantwortet, als weiter prüfungswürdig und in GNSO-Priorisierungsdebatten beschrieben Keine datierte Entscheidung zu Pflicht, Datenmodell, zentralem System oder Verfahren ausgewiesen
Strafverfolgungsstellen für dringende Anfragen authentifizieren Input Group gebildet, Treffen begonnen, Proof-of-Concept-Meilensteine veröffentlicht RDRS-Wireframe im Oktober 2026, Testbeginn im Dezember, Erkenntnisse im März 2027, danach weiterhin das erforderliche gültige Politikinstrument

Das ist keine Rangfolge der politischen Bedeutung. Es ist ein Vergleich der öffentlich überprüfbaren Prozessbelege.

Das Protokoll des GNSO Councils vom 13. August zeigt, warum Lücken nicht durch Vermutung geschlossen werden dürfen. Der Council beriet die Draft Charter für DNS Abuse Mitigation PDP 2. Umstritten waren Ausgangstext, Umfang automatisierter Mechanismen und Fragen, die bindende Ergebnisse vorwegnehmen könnten. Ein Charter Drafting Team sollte in der Woche vom 24. August mit wöchentlichen Sitzungen beginnen.

Das Protokoll ordnet Indiens erste beiden Forderungen nicht PDP 2 zu. Es hält jedoch fest, dass der GNSO-GAC Liaison Fragen zur Registranten-Verifizierungsfrist bei ICANN86 für zu spät hielt, um die Council-Gruppen ausreichend zu konsultieren. Das ist ein Kommunikationsbefund, keine Politikentscheidung und kein Beleg, dass Indiens späterer Brief den Vorgang ausgelöst hat.

Auch die Liaison-Grenze wird festgehalten. GAC-Input kann über den Liaison früh ankommen; die Charter bleibt Sache des Councils. Ohne geänderte Rollenbeschreibung vertritt der Liaison nicht die GAC-Position im Council. Information wird übermittelt, Entscheidungsbefugnis nicht.

Ein datierter Test schafft noch keine Regel

Der Authentifizierungsweg ist genauer zu beobachten. ICANN nennt Gruppenbildung im Juni, Sitzungsbeginn im Juli, RDRS-Wireframe-Änderungen im Oktober, Proof-of-Concept-Tests im Dezember und einen Erkenntnisbericht im März 2027. Aufzeichnungen vom 22. Juli und 12. August sind verlinkt.

Dieselbe Seite erklärt, dass die Gruppe keine Politik entwickelt oder empfiehlt. Ihre Charter steht weiterhin als „coming soon“ aus. Sie kann Interoperabilität, Abläufe, Datenminimierung, Protokollierung und Bedienbarkeit erproben. Sie kann nicht entscheiden, ob eine einzelne Anfrage dringend, rechtmäßig oder erforderlich ist, und kein automatisches Recht auf Offenlegung schaffen.

Öffentliche Meilensteine erhöhen daher die Kontrollierbarkeit, nicht die Zuständigkeit. Sie zeigen Beginn, Änderung oder Verzögerung eines Tests. Sie ersetzen nicht die Consensus Policy, von der das Wirksamwerden der 24-Stunden-Regel abhängt.

Der fehlende Nachweis nach der Eingangsbestätigung

ICANN hat beide Briefe veröffentlicht. Der Stand der drei Maßnahmen verteilt sich dennoch auf CEO-Antwort, GNSO-Seiten, Council-Protokoll, Input-Group-Seite und Implementierungsnotiz.

Ein Wegestatus-Nachweis je Forderung könnte die Kette schließen, ohne ein neues Entscheidungsorgan zu schaffen. Er würde das verlangte Ergebnis, die Autoritätsklasse des Absenders, das zuständige Organ, den Zustand — empfangen, konsultiert, priorisiert, Charter-Erstellung, PDP, Vertragsgespräch, Umsetzung, abgeschlossen, abgelehnt oder ersetzt —, Verfahren und Akte, Support-Verantwortung in ICANN org, Abhängigkeiten, nächste Entscheidung samt Datum oder „nicht terminiert“, jüngsten Beleg und Korrekturen enthalten.

Entscheidend ist das Feld für Nichtentscheidungen. „Beantwortet“ bedeutet nicht priorisiert. „In Priorisierung“ bedeutet nicht, dass eine Charter existiert. „Charter wird erstellt“ legt die Antwort nicht fest. „Proof of Concept“ schafft weder Pflicht noch Zugangsrecht. „Umgesetzt“ muss auf das vollziehbare Instrument verweisen.

Die Einheit ist die einzelne Maßnahme, nicht der Brief. Drei Forderungen können drei Wege, drei zuständige Stellen und drei Zeitachsen haben. „ICANN steht mit Indien im Dialog“ kann wahr sein und dennoch verbergen, dass nur ein Weg Daten hat und zwei noch keine nächste Entscheidung zeigen.

Transparenz über den Weg gibt dem Antragsteller keine Ergebnisgewalt. Sie benennt nur, wer den nächsten Schritt verantwortet. Verzögerung wird prüfbar, ohne als Zustimmung zu gelten; Verfahrensautonomie bleibt bestehen, ohne sich hinter Schweigen zu verbergen.

Dringlichkeit braucht einen sichtbaren Zuständigkeitsweg

Die Antwort vom 11. August macht den CEO nicht zum Vorgesetzten der GNSO. Das ist ihre Stärke. Ihre dokumentarische Schwäche besteht darin, dass zwei Maßnahmen unter weiten Verben verbleiben, während die dritte bereits eine Ausführungsfolge besitzt.

Der nächste Schritt muss kein versprochenes Ergebnis sein. Er muss die nächste befugte Entscheidung ausweisen. So wird staatliche Dringlichkeit nicht zum Mandat gewaschen, und das Multistakeholder-Verfahren kann nicht als Beleg dienen, dass die öffentliche Sorge bereits beantwortet sei.

Eine schlankere Ordnung lässt Beteiligte Fakten, Forderungen und Einwände liefern. Der GAC berät. Die GNSO steuert die gTLD-Politik. ICANN org unterstützt und setzt um. Verträge und Consensus Policies tragen Pflichten. Der öffentliche Nachweis verbindet die Übergaben, ohne Anwesenheit, Korrespondenz oder Dringlichkeit in Souveränität umzudeuten.

Quellen

  1. ICANN — Korrespondenzindex
  2. S. Krishnan an Kurt Erik Lindqvist, 14. Juli 2026
  3. Kurt Erik Lindqvist an S. Krishnan, 11. August 2026
  4. ICANN — Politikentwicklung
  5. GNSO Council — Protokoll vom 13. August 2026
  6. ICANN — Input Group zu Authentifizierungsmechanismen für Strafverfolgungsstellen
  7. GNSO — DNS Abuse Mitigation PDP 1
  8. ICANN — Registration Data Policy
  9. ICANN — RAA 2013 und Whois Accuracy Program Specification
  10. Lu Heng — The Multi-Stakeholder Mirage