Zusammenfassung

  • Am 6. September genehmigte der ICANN-Vorstand einen Vertrag für Systementwicklung und Support der New-gTLD-Runde 2026. Der am 9. September veröffentlichte Beschluss nennt Funktionalität, zeitnahe Störungsreaktion, Stabilität und kritische Geschäftsprozesse, schwärzt aber Anbieter, Betrag und wesentliche Teile der Begründung.
  • Ein Beschluss vom 3. Mai hatte sechs Monate verstärkter Rufbereitschaft vorgesehen: von der Öffnung des Antragsfensters bis zur damals für den 30. Oktober erwarteten String Confirmation, danach sollte das Supportteam auf reguläre Geschäftszeiten zurückgehen.
  • Aus den öffentlichen Unterlagen folgt nicht, dass beide Beschlüsse denselben Vertrag, Anbieter oder Leistungsumfang betreffen. Fest steht jedoch, dass die frühere Begründung eine zeitliche Grenze mit einem erwarteten Ergebnis setzte.
  • Ein nicht sensibles Ausstiegsprotokoll könnte Normalabdeckung, interne Verantwortung, Übergabenachweis, offene Ausnahmen, Entscheidungsdatum und nächste Prüfung je Funktion festhalten.

Der neue Vertrag lässt die alte Grenze nicht verschwinden

Die Beschlüsse vom 6. September ermächtigen ICANNs President and CEO oder Beauftragte, einen Vertrag über Systementwicklung und Unterstützung der Runde 2026 zu schließen und Zahlungen zu leisten. Öffentlich genannt werden ausreichende Funktionalität, schnelle Reaktion auf Vorfälle, Systemstabilität und kritische Geschäftsprozesse. Die finanziellen Folgen seien im FY27-Budget und in der weiteren Planung berücksichtigt.

Nicht veröffentlicht sind Leistungskatalog, Supportzeiten, Schweregrade, Laufzeit, Anbieter und Preis. Ein ganzer Absatz und weitere Vertragsteile gelten als vertrauliche Verhandlungsinformation. Der Vorstand ordnet die Entscheidung als administrative Organisationsfunktion ein, die keine öffentliche Kommentierung erfordert.

Das ist kein Beleg für ein Problem. Verhandlungsdetails und sicherheitskritische Einsatzanweisungen dürfen geschützt werden. Außerdem endet der technische Bedarf eines Programms nicht mit dessen Start. Die Governance-Frage entsteht durch den Vergleich mit den Beschlüssen vom 3. Mai.

Damals genehmigte der Vorstand Vertragsverlängerungen für ein erweitertes Rufbereitschaftsmodell. Die Begründung beschrieb eine sechsmonatige Phase erhöhter Nachfrage und Komplexität: vom Beginn der Antragstellung am 30. April bis zur seinerzeit für den 30. Oktober erwarteten String Confirmation. Zusätzliche Stunden sollten Störungen außerhalb der üblichen Arbeitszeit abdecken. Danach sollte das Supportteam verkleinert werden und während regulärer Geschäftszeiten arbeiten.

Diese Erwartung war keine Garantie, dass alle Systeme an einem Stichtag gleichzeitig umgestellt werden. Sie definierte aber öffentlich Ausnahme, Zeitraum und Zielzustand. Mit der September-Entscheidung wird deshalb der Übergang selbst prüfenswert: Welche Funktion kann in den Normalbetrieb wechseln? Welche braucht eine befristete Ausnahme? Wer trifft diese Entscheidung anhand welcher Belege?

Die Unterlagen erlauben keine Behauptung, beide Verträge seien identisch. Im Mai hieß es, der damalige Anbieter sei in einem RFP vom Oktober 2023 ausgewählt worden und habe RSP- und ASP-Systeme geliefert sowie TAMS vorangebracht. September bestätigt weder denselben Anbieter noch dieselbe Vereinbarung oder denselben Umfang. Ein Ausstiegstest folgt der Funktion und ihrem internen Eigentümer, nicht einer vermuteten Lieferantenidentität.

Nach dem Antragsfenster beginnt eine andere Belastung

Am 12. August endete die Einreichung. ICANN meldete mehr als 1.600 Hauptanträge; über 1.100 enthielten zusätzlich Ersatz-Strings. Diese Zahl misst weder Transaktionen noch gleichzeitige Zugriffe, Supportfälle oder Störungen. Sie eignet sich nicht zur Personalbemessung.

Sie zeigt aber, dass die Runde nicht abgeschlossen ist. Die Applicant Journey führt weiter über administrative Prüfung, Reveal Day, Community-Eingaben, Einwände und Rechtsbehelfe, String- und Bewerterprüfungen, Konfliktlösung, Vertragsabschluss, Onboarding und Delegierung. Nach Ende der Annahme ändert sich die Aufgabe des Systems.

Der Statusbericht vor ICANN85 macht die Staffelung sichtbar. Im Februar waren TAMS Build 5 und User Acceptance Testing abgeschlossen, Ende-zu-Ende-Integrationstests liefen an; Builds 6, 7 und 8 sollten später Funktionen für Bewertung und Verträge vervollständigen. Daneben beschreibt der Bericht Program Governance, Infrastrukturentwicklung, Operationalisierung, Vorbereitung von Beschäftigten und Dienstleistern sowie unterstützende Funktionen.

Nicht jede Schicht erreicht deshalb am selben Tag den Dauerbetrieb. Antragserfassung kann stabil sein, während eine Auswertungsfunktion noch gebaut wird. Eine Tätigkeit kann intern übernommen sein, eine andere weiterhin vorübergehenden Nachtdienst benötigen. Weder pauschales Abschalten noch pauschales Fortführen liefert eine belastbare Entscheidung.

Der Ausstiegstest in sechs Zeilen

Ein datiertes Blatt mit Bezug auf die Beschlussnummern genügt. Für jede sachgerechte, grobe Serviceklasse hält es fest:

  1. welche Abdeckung außergewöhnlich war und welcher Normalzustand angestrebt wird;
  2. welche interne ICANN-Rolle den Dienst abnimmt und über Reduktion, Verlängerung oder Umbau entscheidet;
  3. welche Belegarten geprüft wurden, etwa Wiederherstellungstest, offene Fehler, Arbeitsprognose, Übergabe der Runbooks oder klar definierte Rufbereitschaftsdaten;
  4. welche Funktionen wann in den Dauerbetrieb wechselten;
  5. welche Ausnahmen aus welchem Grund bis zu welchem Prüftermin fortbestehen;
  6. wann der nächste öffentliche Entscheidungspunkt erreicht wird.

Der Test schreibt kein Vertragsende vor. Er kann den Normalbetrieb bestätigen, eine begrenzte Verlängerung für eine Funktion begründen, eine interne Übergabe mit abrufbarer Spezialhilfe akzeptieren oder den neuen Normalzustand ausdrücklich festlegen. Ein Sunset ist hier ein Entscheidungsfenster, kein automatischer Abbruch.

Auch Kennzahlen brauchen Grenzen. Eine Jahresverfügbarkeit kann die wenigen kritischen Stunden glätten. Ticketzahlen vermischen ohne Definition Störung, Anfrage, Fehler und geplante Änderung. Erst wenn Einheit und Zeitraum feststehen, trägt eine Zahl zur Übergabeentscheidung bei.

Betriebszustand offenlegen, Sicherheitsdetails schützen

ICANNs Documentary Information Disclosure Policy geht von öffentlicher Verfügbarkeit aus, erkennt aber zwingende Vertraulichkeitsgründe an, darunter mögliche Schäden für Geschäftsinteressen. Die Publication Practices erläutern, wie Beschlüsse, vorläufige Berichte und Protokolle nach den Bylaws veröffentlicht und bestimmte Angaben ausgelassen werden.

Ein Ausstiegsprotokoll passt in diese Trennung. Anbieter, Preis, Zugangsdaten, Schwachstellen, persönliche Schichten und laufende Eskalationswege bleiben nichtöffentlich. Dagegen kann veröffentlicht werden, dass eine bestimmte Funktionsklasse bis zu einer datierten Prüfung erweitert betreut wird und welche interne Rolle dafür verantwortlich ist.

Die Contracting and Disbursement Policy verlangt Vorstandsgenehmigung für Verpflichtungen über 750.000 US-Dollar und regelmäßige Berichte des CFO zu bedeutenden Auszahlungen. Da der September-Betrag geschwärzt ist, darf daraus kein Wert abgeleitet werden. Finanzielle Genehmigung beantwortet zudem nicht die Frage der Betriebsabnahme. Beide Kontrollen sind nötig, aber nicht austauschbar.

Was nicht belegt ist

Keine Quelle meldet Ausfall, verfehlte Reaktionszeit, Sicherheitsverletzung, schlechte Leistung, Kostenüberschreitung, Lock-in oder misslungene Übergabe. Die Antragszahl ist keine Lastmessung. Aus den im Mai genannten Systemen TAMS, RSP und ASP folgt nicht, dass September nur diese betrifft.

Der neue Vertrag kann geplante Entwicklung, eine andere Phase, einen anderen Umfang oder einen gut gesteuerten Übergang abbilden. Er beweist nicht, dass ICANN die frühere Reduktion aufgegeben hat. Gefordert ist daher kein Urteil aus den Schwärzungen, sondern ein öffentliches Ergebnis, sobald die damalige Grenze erreicht wird.

Quellen

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. ICANN — Genehmigte Beschlüsse vom 6. September 2026
  5. ICANN — Genehmigte Beschlüsse vom 3. Mai 2026
  6. ICANN — Statusbericht zur Runde 2026 vor ICANN85
  7. ICANN — Runde 2026 endet mit mehr als 1.600 Anträgen
  8. New gTLD Program — Applicant Journey
  9. ICANN — Documentary Information Disclosure Policy
  10. ICANN — Publication Practices
  11. ICANN — Contracting and Disbursement Policy