Zusammenfassung

  • Die GNSO Operating Procedures v3.8 vom 1. September 2026 enthalten das am 21. Mai vom GNSO Council beschlossene Rücknahmeverfahren. Es gilt nur in begrenzten, außergewöhnlichen Fällen vor Abschluss der Umsetzung; nichts belegt eine laufende Anwendung.
  • Das Board soll dem GNSO Council ausreichend Zeit für den Dialog geben; etwa 60 Tage sind nur ein Beispiel. Die erste zwingend öffentliche Board Statement folgt aber erst auf die Board-Handlung. Eine vorherige öffentliche Konsultation oder Beteiligung des Implementation Review Team ist nicht vorgeschrieben.

Eine Empfehlung kann angenommen sein, ohne bereits vollständig zu wirken. Vertragsformulierungen werden geprüft, Systeme gebaut, ein IRT bearbeitet offene Fragen und Unternehmen planen schon auf Grundlage des Beschlusses. Dann tauchen neue Informationen auf. Das ICANN Board kommt zu dem Schluss, dass die Empfehlung nicht länger im besten Interesse von ICANN oder seiner Community liegt, und erwägt die Rücknahme der früheren Annahme.

Die institutionelle Frage lautet nicht, ob ein Organ seine Meinung ändern darf. Entscheidend ist, wann Betroffene die Belege prüfen und bestreiten können, die eine Sorge in eine Handlung verwandeln. Die neue Regel erwartet zunächst einen Dialog mit dem GNSO Council. Bei der Rücknahme muss das Board seine Gründe veröffentlichen. Dazwischen liegt jedoch die erste Board-Handlung, ohne vorgeschriebene öffentliche Beweisakte davor.

Diese Kontrollgrenze zeigt Version 3.8 der GNSO Operating Procedures. Eine ungeregelte Lücke zu schließen, ist ein Fortschritt. Eine Erklärung nach der Handlung erfüllt aber nicht dieselbe Funktion wie überprüfbare Belege vor der Abstimmung.

Drei Daten, drei verschiedene Funktionen

Die am 2. September aktualisierte GNSO-Verfahrensseite führt v3.8 mit Datum 1. September. Der Versionsvermerk sagt, die konsolidierte Fassung nehme Annex 2, das PDP Manual, und Annex 5, das GGP Manual, auf; beide wurden am 21. Mai 2026 genehmigt. Die eigenständigen Dateien tragen das Datum 11. Mai. Abgesehen von den aktualisierten Anhängen werden die übrigen Änderungen in v3.8 als administrativ und redaktionell bezeichnet.

Der Council-Beschluss vom 21. Mai ist somit die Genehmigung. September ist die Konsolidierung und Veröffentlichung. Keines dieser Daten ist eine Einleitung des Rücknahmeverfahrens. Die geprüften Quellen nennen keine Empfehlung, die derzeit diesen Weg durchläuft.

Der Bericht der Strategieklausur 2025 erklärt den Ausgangspunkt. Bei bereits angenommenen Empfehlungen, darunter Empfehlung 20.6 zu den neuen gTLD-Runden, waren später Probleme aufgetreten, ohne dass ein spezieller Rücknahmeweg bestand. Diese Geschichte begründet die neue Regel; sie macht den alten Fall nicht zu einer laufenden Anwendung von v3.8, und dieser Beitrag bewertet seinen Inhalt nicht neu.

Die jetzt festgelegte Abfolge

Abschnitt 16 des PDP Manual und Abschnitt 10 des GGP Manual folgen fast demselben Muster. Eine Rücknahme soll selten bleiben und ist begrenzten, außergewöhnlichen Umständen vorbehalten. Sie kommt in Betracht, wenn das Board eine Empfehlung angenommen hat, deren Umsetzung noch nicht abgeschlossen ist. Ist die Empfehlung umgesetzt und in Kraft, steht dieser Weg nicht mehr zur Verfügung.

Vor der Handlung soll das Board mit dem GNSO Council sprechen. Mindestens soll es seine Absicht mitteilen, das Problem benennen, Begründung und Auswirkungen darlegen und erklären, warum eine Rücknahme die einzige oder beste Option ist. Der Council soll ausreichend Zeit zur Prüfung und für Rückfragen haben. „Zum Beispiel 60 Tage“ ist eine Orientierung, keine starre Frist.

Der materielle Test hat zwei Teile. Es braucht neue Informationen oder veränderte Umstände. Hinzukommen muss die Feststellung, dass die Empfehlung nicht länger im besten Interesse von ICANN oder der ICANN Community liegt. Eine bloße Veränderung genügt nicht; ebenso wenig eine abstrakte Berufung auf das institutionelle Interesse ohne erneuerte Tatsachengrundlage.

Die Abstimmungsschwelle hängt vom ursprünglichen GNSO-Rückhalt ab. Hatte die Empfehlung eine GNSO-Supermehrheit, benötigt die Rücknahme zwei Drittel des Boards. Unterhalb einer Supermehrheit reicht eine Board-Mehrheit.

Bei der Handlung muss das Board seine Entscheidung in einer Board Statement an den GNSO Council begründen. Erklärung und Begleitdokumente müssen öffentlich zugänglich sein. Danach prüft der Council die Erklärung, erörtert sie mit dem Board und bestätigt oder verändert seine Empfehlung. Die Supplemental Recommendation geht anschließend zurück an das Board; auch dort richtet sich die Schwelle nach dem GNSO-Unterstützungsniveau.

Der Council behält also eine formelle Antwort. Das engere Problem ist der Zeitpunkt der Offenlegung: Das erste zwingend öffentliche Dokument erscheint nach der ersten Board-Handlung.

Was die Konsultation verlangte

Das Public-Comment-Verfahren lief vom 20. November 2025 bis zum 22. Januar 2026 und erhielt zehn Eingaben. Der Zusammenfassungsbericht dokumentiert breite Zustimmung zu einem seltenen, abgesicherten Verfahren.

Einige Vorschläge veränderten den Text. Aus der Möglichkeit, das Board „könne“ dem Verfahren folgen, wurde die Erwartung, es „solle“ ihm folgen. Außerdem wurden veränderte Umstände als möglicher Grund neben neue Informationen gestellt.

Andere Wünsche wurden nicht verpflichtend. Mehrere Stellungnahmen verlangten eine begrenzte öffentliche oder gemeinschaftliche Konsultation vor Abschluss. Registrar Stakeholder Group, Registries Stakeholder Group und Tucows befürworteten eine verpflichtende Anhörung des zuständigen IRT; die Registries schlugen nach Möglichkeit auch die Einbeziehung der ursprünglichen Arbeitsgruppe vor. Die angenommenen Handbücher schreiben diese Schritte nicht vor.

Daraus folgt nicht, dass ein künftiges Verfahren geheim wäre. Council-Mitglieder können ihre Gruppen konsultieren, das Board kann früh veröffentlichen und beide Seiten können das IRT anhören. Feststellbar ist nur: Diese Öffnung ist möglich, aber keine Bedingung der ersten Handlung.

Eine Umsetzungsgrenze ohne benannten Nachweis

Die Zugangslinie klingt binär: „noch nicht abgeschlossene“ Umsetzung auf der einen, „umgesetzt und in Kraft“ auf der anderen Seite. Reale Programme wechseln ihren Zustand selten als Ganzes. Vertragstext kann fertig sein, während Software fehlt. Ein Wirksamkeitsdatum kann vor dem Ende der Migration liegen, IRT-Fragen können offen und Durchsetzung kann aufgeschoben sein. Eine Empfehlung kann zudem Teil eines abhängigen Pakets sein, das nicht vollständig zurückgenommen wird.

Die Handbücher benennen weder die Stelle, die diesen Zustand bescheinigt, noch ein vorgeschriebenes Zertifikat oder einen Mindestbelegsatz. Das ist eine textliche Lücke, keine Behauptung, ICANN verfüge intern über keine Informationen. Sie ist dennoch folgenreich, weil die Einstufung über die Verfügbarkeit einer außergewöhnlichen Befugnis entscheidet.

Eine zu frühe Einstufung als „in Kraft“ kann den Weg schließen, obwohl neue Belege gewichtig sind. Eine zu lange Einstufung als „nicht abgeschlossen“ kann die Rücknahme ermöglichen, nachdem Registries, Registrare, Bewerber oder Nutzer bereits berechtigt auf die angenommene Regel vertraut haben. Die spätere Board Statement erklärt die Einstufung, eröffnet aber keine garantierte Korrektur vor der ersten Abstimmung.

Eine öffentliche Rücknahmeakte vor der ersten Abstimmung

Es fehlt eine begrenzte, versionierte öffentliche Rücknahmeakte vor der ersten Board-Handlung. Sie muss weder endlos konsultieren noch privilegierte Beratung offenlegen. Sie soll die ausgeübte Befugnis mit den Belegen verbinden, solange das Ergebnis noch veränderbar ist.

Die Akte sollte Auslöser und Zeitpunkt, alle betroffenen Empfehlungen, Abhängigkeiten außerhalb des Umfangs, ursprünglichen Annahmebeschluss und Schwelle, Umsetzungsphase und den benannten Hüter dieser Einstufung enthalten. Die Bescheinigung sollte auf einen datierten Beleg-Snapshot verweisen, nicht nur auf ein Statuswort.

Weiter gehören die neue Information oder Veränderung, ihre Herkunft, behauptete Auswirkungen und geprüfte Alternativen hinein. Board-Fragen und GNSO-Antworten brauchen stabile Versionen. Ein zeitlich begrenzter Kanal sollte Belege des IRT, der ursprünglichen Arbeitsgruppe und der Community aufnehmen. Geschützte Unterlagen können vertraulich bleiben, wenn Existenz, Verwahrer, Schutzgrund und Entscheidungswirkung öffentlich bezeichnet werden.

Nach der Handlung nimmt dieselbe Akte Abstimmung, Board Statement, Dialog, Supplemental Recommendation und die endgültige Behandlung auf. Korrekturen werden mit Verweisen ergänzt, statt den Belegstand der ersten Entscheidung still zu überschreiben.

Diese Akte ist mein redaktioneller Vorschlag, keine ICANN-Zusage. Sie folgt der Autoritätsanalyse in The Policy Mirror, der beobachtbaren Ausführung aus Running-Code Primacy und der Trennung von Tatsache und institutioneller Selbstdarstellung in Reality, Not Advocacy.

V3.8 erkennt zu Recht an, dass spätere Tatsachen eine frühere Annahme erschüttern können. Der nächste Schritt ist ebenso klar: Transparenz nach der Handlung darf nicht als Anfechtbarkeit vor der Handlung gelten.

Quellen