Zusammenfassung

  • 2015 ordnete Alain Durand fünf Jahre IANA-Nutzungsdaten drei Betriebsbereichen zu: Domainnamen, Nummernressourcen und Protokollparameter.
  • Mit den neuen gTLDs nahmen Delegierungsanfragen zu; Anfragen zu Nummernressourcen blieben im betrachteten Zeitraum weitgehend stabil. Die besonders häufigen PEN-Anfragen stellte Durand separat dar.
  • Anfragen zu zählen zeigt Aktivität, aber nicht automatisch Arbeitsaufwand, Bearbeitungsqualität, Fehlerfolgen oder die Stelle, die eine Regel festlegt und ihre Umsetzung beaufsichtigt.

Eine vertraute Schnittstelle, ein unbekannter Betrieb

Alain Durands Beitrag vom 27. Mai 2015 beginnt mit einer klar begrenzten Wissenslücke. Er hatte mehr als zwei Jahrzehnte im IETF gearbeitet, Arbeitsgruppen geleitet und an RFCs mitgeschrieben. Als technischer Teilnehmer kannte er IANA-Register aus ihrer Nutzung. Einige Monate nach seinem Wechsel zu ICANN stellte er fest, dass dieses Wissen noch nicht erklärte, wie der Betrieb Anfragen entgegennahm, prüfte und über verschiedene Communities hinweg bearbeitete.

Zu seiner neuen Aufgabe gehörte die Unterstützung des Übergangs der Aufsicht über die IANA-Funktionen. Um den Umfang der Arbeit besser zu verstehen, stellte er die verfügbaren Nutzungsdaten aus fünf Jahren zusammen. Er bezeichnete das nicht als unabhängiges Audit oder Prognose und leitete daraus auch kein Governance-Modell ab. Seine Frage war operativ: Welche Dienste nutzten die drei Communities, und wie änderte sich die Nachfrage? Die Aufteilung machte einen Betrieb sichtbar, den die Sammelbezeichnung „IANA“ leicht als eine einzige Aufgabe erscheinen lässt.

Durand zufolge betreute die Abteilung mehr als 2.800 Register für drei Betriebsbereiche: Domainnamen, Nummernressourcen und Protokollparameter, darunter die vom IETF genutzten Register. Die Zahl beschreibt den Umfang des Katalogs, nicht 2.800 gleich aktive oder gleich aufwendige Warteschlangen. Ein selten geänderter Eintrag kann für die Kontinuität wichtig sein. Eine große Zahl routinemäßiger Änderungen kann dagegen viele Vorgänge erzeugen, ohne dass jeder einzelne komplex ist. Die Zahl der Register ist daher weder eine Personalbemessung noch ein Risikomaß.

Auch die drei Bereiche sind nicht austauschbar. Im Namensdienst gibt es Kontaktänderungen ebenso wie Delegierungen und Wiederdelegierungen. Bei Nummernressourcen setzt der Betreiber Vereinbarungen der zuständigen Community um. Protokollparameter folgen jeweils einschlägigen technischen Verfahren. Dass ein Betreiber alle drei Dienste erbringt, macht aus ihren Vorgängen keine gemeinsame Arbeitseinheit und überträgt dem Betreiber nicht die Urheberschaft der Regeln.

Drei Reihen, verschiedene Ursachen

Für die Namensarbeit trennte Durand Delegierungen und Wiederdelegierungen von Änderungen an Kontakten, Nameservern oder DS-Einträgen. Bei den gTLDs nahm die Zahl der Delegierungen und Wiederdelegierungen mit dem Start der neuen gTLDs deutlich zu. Die Reihe zeigt, dass ein neues Programm die Nachfrage nach einem Betriebsdienst verändern kann. Sie beweist weder, dass IANA das Programm geschaffen hat, noch dass mehr Anfragen proportional mehr Schwierigkeit oder öffentlichen Nutzen bedeuten.

Die Nummernressourcen hatten eine andere Entwicklung. Vor 2010 gab es große Anfragen der RIRs nach IPv6-Unicast-Blöcken. Der Bestand nicht zugeteilter IPv4-Unicast-Adressen bei IANA war 2011 erschöpft; einige zurückgegebene Blöcke wurden später nach der globalen Policy erneut an RIRs verteilt. Trotzdem blieb die Zahl der beim Betreiber eingehenden Anfragen in der dargestellten Fünfjahresreihe weitgehend stabil. Das ist eine Aussage über den Zuteilungsstrom der IANA, nicht über den gesamten Adressgebrauch, den Internetverkehr oder das Ausmaß der IPv4-Knappheit.

Die meisten von ICANN als IANA-Betreiber geführten Register gehörten zu den Protokollparametern, die das IETF definiert und verwendet. Am stärksten genutzt wurden die Private Enterprise Numbers (PEN), die typischerweise bei der Konfiguration von SNMP-MIBs zum Einsatz kommen. Ihre hohe Fallzahl hätte die kleineren Reihen in einer gemeinsamen Darstellung schwer lesbar gemacht. Durand zeigte PEN deshalb separat. Das verbessert die Lesbarkeit und macht zugleich sichtbar, dass Gruppierung und Achsenwahl beeinflussen, welche Unterschiede auffallen.

In der Gesamtgrafik führte Durand die drei Communities zusammen und setzte die ccTLD- und gTLD-Delegierungen auf eine zweite Achse. Seine Lesart: Das Gesamtvolumen sei abgesehen vom Effekt der neuen gTLDs recht vorhersehbar gewesen; die Nummernressourcen blieben relativ flach, während die Protokollparameter nach einer ruhigeren Phase um Mitte 2012 wieder zunahmen. Als Beschreibung von Verläufen ist das aufschlussreich. Es belegt nicht, dass jede Anfrage denselben Aufwand hat oder dass die Summe die Betriebskapazität zuverlässig misst.

Was eine Zahl offenlässt

Die monatliche Zahl beantwortet, wie viele Vorgänge registriert wurden. Sie sagt nicht, wie viele Prüfschritte, Rückfragen oder Arbeitsstunden ein einzelner Fall erforderte. Sie trennt auch nicht die Zeit unter Kontrolle des Betreibers von Wartezeiten auf Antragsteller, RIRs, technische Fachleute oder zuständige Policy-Gremien. Fehlerfolgen, Korrekturen, betroffene Systeme und Zuständigkeit für eine Überprüfung bleiben ebenfalls außerhalb dieser Zählung.

Der vertragliche Leistungsbericht C.4.4 für Mai 2015 nutzte bereits andere Maßstäbe. Für routinemäßige Änderungen an delegierten TLDs lautete das Ziel, 80 Prozent innerhalb von 21 Tagen abzuschließen. Gemeldet wurden 86,1 Prozent fristgerecht und 100 Prozent Genauigkeit. Die Kennzahlen für Nummernressourcen betrafen unter anderem die korrekte Umsetzung der Policy, Aktualisierungszeiten, Rückfragerunden, Abschlussdauer und öffentliche Transparenz. In diesem Monat wurde keine Nummernressourcenanfrage abgeschlossen.

Das widerspricht Durands Nutzungsreihe nicht: Der eine Bericht zählt Vorgänge, der andere prüft Zeit, Genauigkeit und Prozessmerkmale.

RFC 2860 markiert die Grenze zwischen Betrieb und Regelsetzung für Parameter im Zuständigkeitsbereich des IETF. Zuweisungen folgen den in RFCs festgelegten Kriterien und Verfahren; bei technischen Zweifeln holt IANA Anleitung beim IESG ein. Der Betreiber setzt eine Regel um, aber die Anfragezahl ist nicht deren Quelle. RFC 3901, RFC 3363 und RFC 4472 dokumentieren zudem technische Arbeit Durands an DNS- und IPv6-Fragen gemeinsam mit anderen Autoren und Editoren. Das belegt fachliche Erfahrung, keine alleinige Urheberschaft.

Der endgültige Vorschlag der IANA-Stewardship-Übergangskoordination vom 10. März 2016 beließ Policy und Aufsicht für Namen, Nummerierung und Protokollparameter bei den jeweiligen operativen Communities. Der ICANN-Vorstand nahm den Vorschlag am selben Tag an. Die geprüften Dokumente schreiben Durands Analyse nicht die Ursache oder Entscheidung dieser Architektur zu. Sein Beitrag lässt sich würdigen, ohne aus einer Beobachtung die Erklärung eines gemeinschaftlichen Übergangs zu machen.

Eine Karte, kein Urteil

Sichtbar ist eine konkrete Arbeitsentscheidung: Durand erkannte, dass seine Erfahrung als Nutzer die interne Arbeit nicht abdeckte, und ordnete die verfügbaren Fünfjahresdaten nach Community und Anfragetyp. Dadurch wurde die Zusammensetzung des Betriebs leichter besprechbar. Nicht belegt sind der interne Erhebungsaufwand, die Arbeitsstunden pro Fall oder ein Einfluss der Veröffentlichung auf Budget und Übergangsdesign.

Eine vollständige Dienstbewertung beginnt mit weiteren Fragen: Was zählt als Anfrage? Wer legt Kategorien fest und dokumentiert ihre Änderung? Welche Regel erlaubt den jeweiligen Schritt? Welcher Teil der Bearbeitungszeit liegt beim Betreiber, welcher bei externen Beteiligten? War der Eintrag korrekt, veröffentlicht und korrigierbar? Welche Stelle kann einen Streit prüfen und Abhilfe verlangen? Diese Fragen hängen zusammen, sollten aber nicht in einer einzigen Kennzahl verschwinden.

Der heutige IANA-Leistungsindex führt Namens-SLAs, Nummernressourcen, IETF-Zuweisungsstatistiken und Root-Zone-Maintenance weiterhin getrennt. Daraus folgt keine direkte Abstammung von Durands Grafik. Es zeigt aber, warum Dienste mit verschiedenen Zusagen und Nutzergruppen nicht unbedingt einen gemeinsamen Gesamtwert brauchen.

Ein anhaltender Anstieg kann eine Kapazitäts- oder Prozessprüfung auslösen; er entscheidet nicht automatisch über Policy. Eine flache Reihe beweist kein geringes Risiko. Ein seltener Vorgang kann weitreichende Folgen haben. Welche Kennzahl sinnvoll ist, hängt davon ab, welche Entscheidung ansteht.

Durands Studie ist am stärksten als Betriebskarte: Sie zeigt, wo Anfragen aufliefen und wie sich ihr Mix bewegte. Sie verleiht der aktivsten Community keine zusätzliche Zuständigkeit und ersetzt keine Qualitätsprüfung. Nach der Sichtbarkeit müssen Regeln, Ergebnisse und die Institution benannt werden, die prüfen oder korrigieren kann.

Quellen