Zusammenfassung

  • Im Januar 2024 verzeichnete der Monatsbericht des Betreibers die Kennzahl Technical Check (Retest) — Routine (Technical) bei 12,88 Minuten gegen eine Grenze von zehn Minuten auf dem 95-Prozent-Perzentilziel. Der am 14. Februar 2024 veröffentlichte CSC-Befund nannte 98,4 Prozent der definierten Kennzahlen als erfüllt, akzeptierte die Erklärung von PTI und eröffnete keine Eskalation.
  • Im Juni 2026 stellte der auf den 22. Juli 2026 datierte CSC-Befund fest, PTI habe alle 64 der damals definierten Grenzwerte erfüllt. Zwischen diesen beiden Dokumenten und irgendeiner vertraglichen Folge steht eine Leiter aus Fristen, Schreiben und Genehmigungen, die sich nur bei einem Verfahrens-, Umsetzungs- oder Berichtsfehler bewegt — nicht bei der Zahl.

Das nützlichste Dokument zum Verständnis der Aufsicht über die IANA-Namensfunktionen ist nicht das Kennzahlen-Dashboard. Es ist der monatliche Befund, den das Customer Standing Committee nach der Lektüre des Betreiberberichts veröffentlicht. Im Januar 2024 tat dieser Befund die drei Dinge, die ein Befund tun kann — er verzeichnete, er qualifizierte, er entschied über das Weitere — und er tat sie so, dass es sich lohnt, sie auseinanderzuhalten.

Zuerst die Zahl. Der monatliche Leistungsbericht der IANA-Namensfunktionen für Januar 2024 verzeichnet Technical Check (Retest) — Routine (Technical) bei 12,88 Minuten gegen eine Grenze von zehn Minuten auf dem 95-Prozent-Perzentilziel (Bericht Januar 2024). Die Detailtabelle desselben Berichts führt 123 Retests mit einem Mittelwert von 3,15 Minuten. Die beiden Zahlen beantworten verschiedene Fragen: 12,88 ist die Kennzahl, die mit der Grenze verglichen wird, und 3,15 ist der Mittelwert einer Menge, die die schnellen Retests einschließt. Der Mittelwert verwandelt die verfehlte Vorgabe nicht in eine erfüllte, und der Bericht versucht das auch nicht — er stellt in einem eigenen Satz fest, „one request exceeded the technical check threshold of 10 minutes“.

Der Befund steht in einem anderen Dokument, veröffentlicht am 14. Februar 2024, und dort wird die Sprache interessant. Das CSC schreibt, PTI habe „die Vereinbarung über das Servicelevel für 98,4 % der definierten Kennzahlen erfüllt“ (Befund Januar 2024). Es benennt die verfehlte Kennzahl. Es akzeptiert die Erklärung von PTI, die den Ausnahmefall auf das Warten auf unerreichbare Nameserver einschließlich Zeitüberschreitungen und Wiederholungen zurückführt. Es stellt kein dauerhaftes Problem fest. Es kommt zu dem Schluss, dass keine weitere Maßnahme erforderlich sei, und meldet für den Zeitraum keine neuen Eskalationen.

Drei Aussagen, und es ist wichtig, sie getrennt zu halten, weil die bequeme Lesart sie verschmilzt. Die erste ist das Messergebnis: eine definierte Kennzahl lag in jenem Monat unter der Grenze. Die zweite ist die Qualifizierung: das Komitee hielt die Ursache für erklärt und nicht dauerhaft. Die dritte ist der Eskalationsbefund: keine neue Eskalation. Ein Befund, der alle drei verzeichnet, ist kein Befund, der die erste ignoriert hat. Er ist ein Befund, der entschieden hat, dass die erste allein die anderen beiden nicht in Bewegung setzt.

Was das CSC ist und was es nicht ist, steht in zwei Instrumenten. Die geänderte Charta des Customer Standing Committee wurde am 3. Mai 2026 vom Board genehmigt und trat am 3. Juli 2026 in Kraft: Das Komitee überwacht monatlich die vereinbarten Servicelevel, analysiert die Berichte des Betreibers der IANA-Funktionen, veröffentlicht monatliche Befunde und arbeitet mit dem Betreiber an Plänen zur Leistungsauflösung (CSC-Charta). Dieselbe Charta weist das Komitee an, Beschwerden auf systemische oder dauerhafte Muster zu prüfen, und erklärt im selben Satz, dass es nicht in einzelne Streitigkeiten zwischen Betreiber und Kunde eingreift. Und sie legt fest, dass das CSC nach erfolgloser Bemühung um Abhilfe in gutem Glauben und nach Eskalation über das Abhilfeverfahren Leistungsfragen an die Räte von ccNSO und GNSO verweisen darf — und dass es selbst den Betreiber nicht über eine Special IFR austauschen kann.

Die Zusammensetzung folgt §17.2 der am 3. Juli 2026 geänderten Satzung: zwei Personen, die gTLD-Registrybetreiber vertreten und von der Registries Stakeholder Group benannt werden, neben zwei vom ccNSO benannten ccTLD-Vertretern und einer PTI-Verbindungsperson, dazu ein optionales Mitglied für andere TLD-Registries und optionale Verbindungspersonen; die Jahreslisten werden von ccNSO und GNSO genehmigt (ICANN-Satzung). Verbindungspersonen haben kein Stimmrecht. Die Amtszeiten laufen zwei Jahre und sind zweimal verlängerbar.

Nun die Leiter, denn dort verliert die Zahl ihre automatische Folge. Der Vertrag, der alles trägt, ist der IANA Naming Function Contract vom 30. September 2016 zwischen ICANN und Public Technical Identifiers (Vertrag). §7.2(c) enthält die meistzitierte Pflicht: „Contractor shall act in good faith to resolve issues identified by the CSC.“ §7.3(c) erlaubt ICANN, den Vertrag zu ändern oder zu beenden, um eine genehmigte Empfehlung einer IFR, Special IFR oder SCWG umzusetzen, vorbehaltlich der Satzung. §§8.2–8.3 verlangen Abhilfeverfahren mit Ursachenanalyse und Minderung. §§9.1–9.2 regeln die fünfjährigen Erst- und Verlängerungslaufzeiten, die auf Trennung gestützte Beendigung und die qualifizierte Nichtverlängerung, die eine schriftliche Ankündigung von mindestens zwölf Monaten und die Zustimmung des Boards verlangt. Anhang A §3(d) verlangt die Monatskennzahlen binnen fünfzehn Kalendertagen; §3(g) verlangt die Korrektur oder erneute Vorlage beanstandeter Liefergegenstände binnen zehn Geschäftstagen.

Dieser Anhang ist nicht mehr die Quelle der Grenzwerte. Änderung Nr. 1, datiert und wirksam vom 7. Mai 2019, ersetzt Anhang A §2(c)–(g), sodass die Verwaltung der Root-Zone extern veröffentlichten Servicelevel-Vereinbarungen folgt, die über ein definiertes Änderungsverfahren angepasst werden (Änderung Nr. 1). Der Ersatztext unterscheidet Verfahren, Kennzahl, Einzelantragsgrenze, Mindest- oder Höchsttyp, aggregierten Erfüllungsgrad und Messzeitraum — und definiert: „Threshold. The specified target for each individual change request.“

Was die Leiter bewegt, steht in den Remedial Action Procedures von CSC und PTI, Version 2.0, im Januar 2019 vom CSC und im Februar 2019 von PTI angenommen (Verfahren). Vor der abschließenden Feststellung eines Leistungsproblems lädt das CSC den Präsidenten von PTI zur Stellungnahme ein, üblicherweise binnen zehn Geschäftstagen. Danach sendet es einen Abhilfebericht an den Präsidenten von PTI, in Kopie an den Präsidenten der Global Domains Division von ICANN. Sitzung, Lieferung des Korrekturplans und Prüfung durch das CSC tragen aufeinanderfolgende Fristen von zehn Geschäftstagen. Ausgelöst wird die Eskalation jedoch durch die Verletzung verfahrens-, umsetzungs- oder berichtsbezogener Pflichten — nicht durch eine verfehlte Messgrenze. Der Fehler kann zum PTI-Board, dann zum CEO von ICANN, dann zum ICANN-Board aufsteigen; bleibt er danach ungelöst, kann das CSC die Frage an ccNSO und GNSO herantragen, möglicherweise einschließlich einer Special IFR. Antwortfristen können im Einvernehmen geändert werden.

Die Satzung ergänzt das Design um drei Uhrwerke und ein Tor. §17.3(b) sieht Überprüfungen der Wirksamkeit des CSC alle fünf Jahre vor, gerechnet ab dem vorangegangenen Abschlussbericht; §18.2(b) verlangt periodische IFRs mindestens alle fünf Jahre, gerechnet ab der Vorlage des vorangegangenen Abschlussberichts an das Board und nicht ab der Einsetzung der vorigen Überprüfung. §18.12 verlangt erfolglose Abhilfe, Prüfung durch die Räte, breitere Konsultation und die qualifizierte Mehrheit beider Räte vor einer Special IFR. Das ist das Tor, das der Monatsbefund allein nicht öffnet.

Es gibt außerdem einen kürzeren Weg, die Zahl zu ändern, und er verdient eigene Aufmerksamkeit. Das Verfahren zur Änderung der Servicelevel-Vereinbarungen der IANA-Namensfunktionen wurde nach eigenem Text zuletzt am 16. Juli 2025 geändert (Änderungsverfahren). PTI, ICANN oder das CSC können Änderungen beantragen; bestehende Vereinbarungen bleiben ohne beiderseitiges Einvernehmen unverändert; gewöhnliche Änderungen verlangen öffentliche Kommentierung und die Zustimmung der Räte von ccNSO und GNSO. Änderungen, die ausschließlich bestehende Grenzwerte betreffen, sind von diesen beiden Schritten ausgenommen. Dasselbe Verfahren verlangt, dass das CSC mindestens alle fünf Jahre eine vollständige Überprüfung der Vereinbarungen anstößt, und stellt fest, dass die Vereinbarungen in den Vertrag einbezogen und über ihn durchsetzbar sind.

Die organisatorische Folge ist präzise und kein Skandal. Der Weg, der das Ziel ändert, ist leichter als der Weg, der die Abweichung vom Ziel sanktioniert. Wer das Dashboard als Zusage liest, muss wissen, dass Maßstab und Rechtsmittel nicht dasselbe verfahrensrechtliche Gewicht haben.

Im Juni 2026 kam das Dashboard sauber. Der auf den 22. Juli 2026 datierte CSC-Befund stellt fest, PTI habe „alle 64 der derzeit definierten Grenzwerte erfüllt“, bewertete die Leistung als ausgezeichnet, nannte keine Kennzahl, die eine engmaschige Beobachtung erfordert hätte, und verzeichnete für den Zeitraum keine neuen Eskalationen (Befund Juni 2026). Der Betreiberbericht jenes Monats zeigt Technical Check (First) — Routine (Technical) bei 3,50 Minuten gegen ≤50 Minuten bei 95 Prozent und Retest bei 1,18 Minuten gegen ≤10 Minuten bei 95 Prozent; Validation and Reviews — Routine (Technical) bei 1,54 Tagen gegen ≤5 Tage bei 90 Prozent; Root Zone Publication — Routine (Technical) bei 58,00 Stunden gegen ≤72 Stunden bei 99 Prozent; die Verfügbarkeit des Root Zone Management System bei 100,00 Prozent gegen ≥99 Prozent; die Genauigkeit der Root-Zone-Datei bei 100,00 Prozent gegen 100 Prozent (Bericht Juni 2026). Die Übersichtstabelle trägt die Überschrift „Percentage of SLA thresholds met of those defined“ und summiert 64 von 64.

Juni 2026 sollte das Gewicht bekommen, das ihm zukommt — formale Übereinstimmung in jenem Monat, mit allen definierten Grenzwerten erfüllt — und Januar 2024 das seine: Beleg dafür, wie eine einzelne verfehlte Vorgabe kontextualisiert wird. Eine Verbesserung zwischen den beiden Zeiträumen zu berechnen, wäre falsch. Kennzahlen, Nenner und Grenzwerte wären nur vergleichbar, wenn die geprüfte Menge zeigen würde, dass sie gleich geblieben sind, und das zeigt sie nicht.

Die finanzielle Grundlage bestätigt, dass der Vertrag lebt, und fügt eine Datumsabweichung hinzu. Der Konzernabschluss von ICANN für das am 30. Juni 2026 endende Geschäftsjahr, mit dem auf den 6. Oktober 2026 datierten Bestätigungsvermerk, führt in Anmerkung 10 aus, der Vertrag sei am 24. Juni 2024 geändert worden, gelte seit dem 30. September 2021, laufe über fünf Jahre mit automatischer Verlängerung unter bestimmten Voraussetzungen und sei am 30. September 2026 verlängert worden (Abschluss). Der Abschluss des Vorjahres nannte stattdessen die Änderung vom 7. Mai 2019. Kein in dieser Prüfung beschafftes Dokument zeigt, was die Änderung vom 24. Juni 2024 geändert hat.

Zwei Seiten von PTI schließen den Umfang des Nichterlangten ab: Die Vereinbarungsseite gab lediglich einen Hinweis zurück, dass JavaScript erforderlich ist (PTI-Vereinbarungen), und die Seite zu den Servicelevel-Vereinbarungen gab denselben Hinweis zurück (SLA-Seite von PTI). Der konsolidierte Vertragstext und die geltende Grenzwerttabelle wurden in dieser Prüfung daher nicht erlangt. Die hier genannten Grenzwerte sind an Januar 2024 und Juni 2026 gebunden und werden nicht als aktuelle Tabelle präsentiert. Eine mehrjährige Reihe von Monatsbefunden liegt in dieser Menge nicht vor, deshalb wird kein Trend behauptet.

Was nach alldem bleibt, ist ein Satz, der mehr wert ist als jeder Vorsichtsabsatz: Der Monatsbefund ist eine veröffentlichte Bewertung mit echten verfahrensrechtlichen und reputationsbezogenen Folgen, kein Rechtsmittel, das sich selbst vollstreckt. Ein sauberes Dashboard als Gewähr zu lesen, verwechselt das Journal mit der Leiter.

Für den Leser aus der Nummerngemeinschaft, der auf diese Funktion angewiesen ist, lautet die nützliche Frage nicht, ob der Monat gut war, sondern wer was unterschreiben müsste, damit ein schlechter Monat Folgen hat — und der Befund zeigt, dass es viele Unterschriften sind, in verschiedenen Dokumenten, mit Fristen, die erst laufen, wenn der Fehler im Verfahren, in der Lieferung oder im Bericht liegt.

Zum Verzeichniseintrag dieser Publikation: IANA im BTW-Verzeichnis.