Zusammenfassung

  • Der ICANN-Vorstand weist in seiner Antwort vom 21. August eine feste Höchstfrist zurück, die die nach den Bylaws erforderliche Prüfung unterschiedlich komplexer Empfehlungen beeinträchtigen könnte. Er will stattdessen vor jedem ICANN Public Meeting berichten und den Politikstatus in vorbereitenden Workshops ständig prüfen.
  • Ein Statusbericht ist kein Verfahrensprotokoll. Eine Uhr von der Empfehlung bis zur Entscheidung muss Eingang, notwendige Unterlagen, Fragen, Zuständigkeiten, revidierte Erwartungen und die Behandlung jeder Empfehlung festhalten, ohne Liaison, Caucus, Mitarbeiteranalyse oder Dialog zur Entscheidungsgewalt zu erheben.

Der Vorstand hat eine Bitte um zeitliche Begrenzung mit einem Rhythmus der Rechenschaft beantwortet.

Am 25. Mai wandten sich Spitzen von sechs GNSO Stakeholder Groups und Constituencies an die Vorstandsvorsitzende Tripti Sinha. Ausgangspunkt war nicht das Fehlen jeder Zeitregel. Annex A verlangt, dass der Vorstand eine Empfehlung des GNSO Council so bald wie möglich, vorzugsweise spätestens in der zweiten Sitzung nach Eingang des Recommendations Report, erörtert.

Die Lücke liegt zwischen Erörterung und Abschluss. Die Unterzeichner schlugen einen Standardrahmen aus einer Zielzahl von Vorstandssitzungen und einer maximalen Monatszahl vor; sechs Monate nannten sie als Beispiel. Außerdem forderten sie regelmäßige Fortschrittsangaben, einen dauerhaften Ort für den Consolidated Policy Scorecard und einen Weg für Rückfragen an GNSO Council und Working-Group-Leitungen.

Die Antwort vom 21. August teilte das Ziel zügiger Arbeit, lehnte aber den festen Endpunkt ab. Empfehlungen unterschieden sich in Art und Komplexität; eine starre Frist könne die nach den Bylaws nötige Prüfung stören. Der Vorstand will Vorhersehbarkeit deshalb durch erwartete Zeitpunkte und Statusberichte schaffen: vor jedem ICANN Public Meeting eine Aktualisierung und in jedem vorgeschalteten Workshop einen festen Tagesordnungspunkt.

Das ist eine institutionelle Entscheidung. Eine Frist diszipliniert die verstrichene Zeit. Ein Berichtstakt diszipliniert, wann eine Institution ihren Zustand erklären muss. Er wird nur dann zum Ersatz, wenn jede Erklärung Geschichte hinzufügt, statt die vorige Momentaufnahme zu überschreiben.

Die beiden Beispiele wurden vor der Antwort entschieden

Der Brief vom Mai verwies auf IDN EPDP Phase 2, dessen Empfehlungen seit Dezember 2024 vorlagen, und auf den Transfer Policy Review vom April 2025. Beide waren damals noch nicht abschließend behandelt.

Am 7. Juni nahm der Vorstand alle 47 Empfehlungen des Transfer Policy Review und alle 14 Politikempfehlungen von IDN EPDP Phase 2 an. Für beide beauftragte er den President and CEO oder Beauftragte mit der Umsetzung, vorbehaltlich Priorisierung und weiterer operativer, technischer, rechtlicher, sicherheitsbezogener oder ressourcenbezogener Fragen.

Die Begründungen erkannten die Sorge über Dauer und Ablauf der Prüfung an. Sie nannten Final Reports, Public Comment, Machbarkeitsanalysen, GAC-Benachrichtigung und fachspezifische Unterlagen. Damit liegt eine Entscheidung mit wesentlichen Grundlagen vor. Was fehlt, ist ein einheitlicher öffentlicher Verlauf der Erwartungen bis zum Beschluss.

Auf der aktuellen Umsetzungsseite stehen beide Vorhaben in der implementation queue. Das folgt auf die Vorstandsentscheidung, ist aber noch kein nachgewiesener Arbeitsbeginn. Eine Warteschlange belegt weder Personalzuweisung noch IRT, Entwurf oder Wirksamkeitsdatum.

Wer nur den Mai-Brief liest, hält die Pakete womöglich weiter für unerledigt. Wer nur die Warteschlange sieht, verlegt die frühere Frage fälschlich in die Umsetzung. Der Beschluss vom 7. Juni ist das Ereignis, das die Zustände verbindet.

Die zweite Sitzung verlangt Diskussion, nicht zwingend Entscheidung

Aus der Kalenderdauer allein folgt kein Verstoß gegen die Bylaws. Annex A spricht von einer Sitzung zur Erörterung und nennt eine Präferenz. Die Bestimmung verlangt nicht, dort bereits anzunehmen oder abzulehnen. Die geprüften öffentlichen Quellen zeigen auch nicht jede Beratung oder die Zählweise des Begriffs Sitzung.

Die belastbare Aussage ist enger: Am Eingang der Vorstandsprüfung besteht eine zeitliche Erwartung; am Ausgang gibt es keine feste Obergrenze.

Flexibilität schützt eine echte Pflicht. Eine durch GNSO supermajority gestützte Empfehlung muss grundsätzlich angenommen werden, sofern nicht mehr als zwei Drittel der stimmberechtigten Vorstandsmitglieder feststellen, dass sie nicht im besten Interesse der ICANN community oder ICANNs liegt. Das gibt dem Bottom-up-Prozess Gewicht, entbindet den Vorstand aber nicht von Rechts-, Sicherheits-, Machbarkeits-, Kosten- und Gemeinwohlprüfung.

Automatische Annahme nach sechs Monaten wäre ebenso falsch wie unbegrenztes „in Prüfung“. Rechenschaft verlangt, dass der Grund für zusätzliche Zeit und der nächste Verantwortliche sichtbar bleiben.

Früher Dialog darf keine stille Änderungsbefugnis schaffen

Die Antwort verweist auf Board liaisons, proaktiven Austausch und Board Caucus Groups. Der Board-Readiness-Bericht von 2025 beschrieb das Problem: Häufig begann die Vorstandsarbeit Monate nach dem Final Report, als das PDP-Team bereits aufgelöst war und die Freiwilligen mit Kenntnis der Kompromisse zu ihren Berufen zurückgekehrt waren.

Frühe Fragen können den Informationsverlust verringern. Ein Liaison meldet Bylaws-, Kosten- oder Umsetzungsfragen, solange das Working Group antworten kann. Ein Caucus organisiert die Vorstandsprüfung. Mitarbeiter bündeln Kommentare und Machbarkeit. Die Working-Group-Leitung erklärt, ob eine Unschärfe Absicht oder Lücke ist.

Keiner dieser Akteure darf den Text informell ändern. Der Liaison stellt keinen GNSO-Konsens fest. Ein Mitarbeiterbericht ersetzt keine Empfehlung. Ändert der Dialog die Substanz, muss der Datensatz zeigen, wer zuständig war und ob die Sache zurück an das Politikorgan ging. Die August-Antwort hält genau diese Grenze fest: Klärung ohne Veränderung der Rollen von Board und GNSO Council.

Der Scorecard zeigt den Ort, nicht den Weg

ICANN org veröffentlicht den Consolidated Policy Scorecard regelmäßig, um community-entwickelte Politik an einer Stelle zu verfolgen. Das ist sinnvoll. Niemand sollte Korrespondenz, Board-Unterlagen, GNSO-Seiten und Umsetzungslisten jedes Mal neu verbinden müssen.

Doch der jüngste Status kann den Übergang nicht erklären. Der Wechsel in die implementation queue sagt nicht, wann alle Unterlagen vorlagen, welche Frage den Termin verschob oder ob einzelne Empfehlungen pended blieben. Auch „pending“ kann Public Comment, GAC-Frist, Machbarkeit, Rechtsfrage, Agenda oder fehlende Zuständigkeit bedeuten.

Privilegierte Rechtsberatung muss nicht veröffentlicht werden. Begrenzte Grundkategorien wie Rechtsprüfung, technische Machbarkeit, Ressourcen, Public-Policy-Input, Klärungsbedarf oder Agendakapazität reichen aus, um die Abhängigkeit zu benennen.

Eine Uhr von der Empfehlung zur Entscheidung

Daniel Kades Vorschlag beginnt mit dem autoritativen Eingang des Recommendations Report. Er speichert Paketkennung und Hash, GNSO-Abstimmung, Bylaws-Pfad und Schwelle. Für Public Comment, GAC-Benachrichtigung, Machbarkeit und weitere benannte Unterlagen hält er Öffnung, Abschluss und Eingang in die Vorstandsakte fest.

Koordination bleibt von Autorität getrennt. Liaison, Caucus oder Mitarbeiter können als Informationsverantwortliche erscheinen; Entscheider ist der Board. Erste Diskussion, wesentliche Beratung und Abstimmung sind getrennte Ereignisse.

Der Statuswortschatz bleibt klein: eingegangen, Unterlagen ausstehend, beratungsreif, Klärung angefordert, Entscheidung terminiert, angenommen, abgelehnt, pended, zurückgezogen oder ersetzt. Jeder Zustand trägt Belegdatum, nächste Handlung, Verantwortlichen und Erwartung. Eine neue Prognose löscht die alte nicht, sondern erklärt ihre Änderung.

Am Ende wird jede Empfehlung mit Abstimmung, Begründung und Bedingung erfasst. Ein gesonderter Handoff unterscheidet Implementierungswarteschlange und Arbeitsbeginn. Die Uhr erzwingt keine Zustimmung durch Zeitablauf; sie macht die Nutzung von Zeit prüfbar.

Quellen

  1. ICANN-Korrespondenzindex
  2. Tripti Sinha an Mason Cole, Rafik Dammak und andere, 21. August 2026
  3. Owen Smigelski, Mason Cole und andere an Tripti Sinha, 25. Mai 2026
  4. Genehmigte ICANN-Vorstandsbeschlüsse, 7. Juni 2026
  5. Aktuelle ICANN Bylaws
  6. ICANN-Seite zur Politikumsetzung
  7. Abschlussbericht des GNSO Board Readiness Small Team
  8. GNSO-Projektseite IDN EPDP
  9. GNSO-Projektseite Transfer Policy Review