Zusammenfassung

  • RFC 8126 legt zehn Registrierungspolitiken für die von der IANA verwalteten Protokollregister fest; bei zweien davon, Private Use und Experimental Use, zeichnet die IANA überhaupt keine Werte auf.
  • Die Einspruchsseite läuft auf einer festen Uhr: Der Einspruch muss innerhalb von zwei Monaten nach öffentlicher Kenntnis begonnen werden. Die Entscheidungsseite läuft auf einer offenen: „eine angemessene Frist“, ohne universelle Frist, wobei Vorhersehbarkeit als Abwesenheit unerwarteter Schritte definiert ist, nicht als zugesagte Zahl von Tagen.
  • Die IAB kann eine Entscheidung der IESG aufheben und den vorherigen Zustand wiederherstellen, aber keine Entscheidung treffen, die der IESG vorbehalten ist, und keine geprüfte Bestimmung überträgt ihr ausdrücklich die Befugnis, die Registrierung anzuordnen. Die IESG ist genau die Stelle, die den angefochtenen Experten ernennt und nach eigenem Ermessen abberufen darf.

Beginne mit einem Antrag, nicht mit einem Prinzip. Jemand will einen Wert in einem von der IANA verwalteten Protokollregister eingetragen sehen. Register, Feldnamen und anwendbare Politik sind drei verschiedene Dinge, und die eigene Anleitung der IANA, angezeigt als überarbeitet am 13. Juli 2026, sagt das ohne Umschweife: Verschiedene Bereiche innerhalb eines Registers können unterschiedliche Registrierungsverfahren verwenden, sodass die Nennung des Registers noch nicht die Regel benennt (IANA, Guidance for RFC Authors). Dieselbe Seite verlangt, das genaue Register zu benennen und die geforderten Feldangaben zu liefern, und warnt, dass der Referenz-RFC des Registers eine Vorlage mit Feldern verlangen kann, die die Registeranzeige nie zeigt.

Wer tatsächlich entscheidet, legt das Instrument fest, nicht die Gewohnheit. RFC 8722, ein informatives Dokument der IAB von Februar 2020, verortet die Aufgabe des Registerbetreibers darin, Parameter nach RFC-definierten Kriterien und Verfahren und nach der anwendbaren Registerpolitik einzutragen, wobei Unklarheiten zur Klärung weiterzuleiten sind (RFC 8722, §2.1). Dasselbe Dokument nimmt die technische Beurteilung vom Betreiber herunter: „the Registry Operator will seek and follow technical guidance exclusively from the IESG“, und die technische Bewertung ist grundsätzlich nicht seine Aufgabe (RFC 8722, §2.3). Bestellung oder Beendigung der Betreiberorganisation des Registers liegen bei der IAB gemeinsam mit der IETF LLC — ein anderer Akt als die Ernennung einzelner Experten (RFC 8722, §2.2).

Das Politikmenü ist eine geschlossene Menge von zehn. RFC 8126, veröffentlicht im Juni 2017, listet Private Use, Experimental Use, Hierarchical Allocation, First Come First Served, Expert Review, Specification Required, RFC Required, IETF Review, Standards Action und IESG Approval (RFC 8126, §§4.1–4.10). Zwei dieser Kategorien schweigen konstruktiv: Werte für Private Use und Experimental Use zeichnet die IANA gar nicht auf. Specification Required fügt der Expert Review eine Dokumentationsauflage hinzu — eine dauerhafte, öffentlich abrufbare, klare und technisch tragfähige Spezifikation, die unabhängige Interoperabilität ermöglicht, nicht zwingend ein RFC (RFC 8126, §4.6).

Wo das Register veröffentlichte Kriterien hat, wendet der Experte sie an. Wo es keine hat, verlangt RFC 8126 die Prüfung von Vollständigkeit der Dokumentation, Interoperabilität und Konflikten und die Vermutung der Zuteilung, solange kein zwingender Einwand besteht (RFC 8126, §§5.1–5.3). Die Ablehnung hat benannte Gründe — Knappheit der Ressource, unklare Dokumentation, schädliche architektonische oder betriebliche Auswirkungen, schädliche Konflikte mit der Arbeit der IETF — und keine weiteren sind genannt (RFC 8126, §5.3).

Nun die Uhr. RFC 2026, Oktober 1996 und bis heute das verfahrensrechtliche Sicherungsnetz, schreibt es hin und meint es: „All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged“ (RFC 2026, §6.5.4). Derselbe Abschnitt verpflichtet Entscheidende auf das Verfahren, verlangt Entscheidung und Mitteilung innerhalb einer angemessenen Frist und liefert keine universelle feste Frist. Die Grundsätze der IAB für den Betrieb der IANA-Register sagen dasselbe in anderer Tonlage: Vorhersehbare Bearbeitung heißt, unerwartete Schritte zu vermeiden, nicht, Expertementscheidungen innerhalb einer vorab festgelegten Zahl von Tagen zu garantieren (RFC 8720, §3.1). Liest man beide Bestimmungen nebeneinander, tritt eine scheinbare Asymmetrie hervor: Die Seite mit dem Beschwerdegrund wird getaktet, die Seite mit der Feder bekommt keine Zahl. Ob die Formulierung absichtlich so gewählt wurde, wird hier nicht festgestellt.

Die Leiter beginnt dort, wo die Ablehnung geschah. RFC 8126 leitet einen Einspruch gegen eine Registrierungsentscheidung zuerst an die IESG, dann an die IAB und wendet auf Streitigkeiten mit Expertengruppen das Streitverfahren aus RFC 2026 §6.5.1 an (RFC 8126, §10). Dieses einbezogene Verfahren läuft über Arbeitsgruppenvorsitzende, dann die zuständigen Area Directors, dann die volle IESG und dann die IAB, wobei jede Stelle prüfen und eine Lösung versuchen muss und die IAB in Verfahrenskonformität und technischer Bewertung letztinstanzlich ist (RFC 2026, §6.5.1). Wird ein Verfahrensfehler festgestellt, prüft die IESG ihre Handlung erneut und berichtet an die IETF; die IAB kann eine Entscheidung der IESG aufheben und den vorherigen Zustand wiederherstellen oder eine Handlung empfehlen, aber keine Entscheidung treffen, die der IESG vorbehalten ist (RFC 2026, §6.5.2).

Diese letzte Klausel wiegt mehr, als ihre Länge vermuten lässt, und die hier gezogene Schlussfolgerung ist die Lesart dieses Artikels, kein Satz, den eines der beiden Dokumente schreibt: Wenn das stärkste in der geprüften Leiter ausgewiesene Ergebnis eine Aufhebung ist, die den vorherigen Zustand wiederherstellt, und die Spitze keine der IESG vorbehaltene Entscheidung treffen kann, dann übertragen die geprüften Bestimmungen der IAB nicht ausdrücklich die Befugnis, die Registrierung anzuordnen. Das lässt eine Empfehlung, eine Aufhebung mit anschließender erneuter Prüfung oder einen fallspezifischen Weg zu einer späteren Registrierung offen.

Aufheben ist nicht Anordnen. Ein Antragsteller kann das Argument gewinnen, ohne dass der Einspruch selbst den Wert einträgt.

Ein weiterer struktureller Befund, und er gehört über den Schreibtisch geheftet. RFC 8126 §5.2.1 sagt wörtlich: „The IESG may remove any designated expert that it appointed, at its discretion“, und derselbe Abschnitt beschreibt die IESG dabei, Experten für IETF-Register zu ernennen und zu ersetzen, normalerweise auf Empfehlung eines Area Directors (RFC 8126, §5.2.1). Abschnitt 10 schickt den Einspruch zuerst an dieselbe Stelle. Keines der beiden Dokumente bringt die Ernennungsrolle mit der Einspruchsrolle in Einklang, und in den geprüften Bestimmungen ist eine Trennung zwischen ihnen nicht genannt. Die erste namentlich benannte institutionelle Stufe der Kette ist die Stelle, welche den Experten ernennt: Der Weg des §10 führt über Arbeitsgruppenvorsitzende und zuständige Area Directors, bevor die volle IESG befasst ist, und wer einen konkreten Einspruch hört und ob dieselben Personen handeln, wird hier nicht festgestellt.

Andere Bestimmungen glätten die Ränder, ohne die Form zu ändern. Die IESG darf ausnahmsweise fallweise die Registrierungsverfahren übergehen (RFC 8126, §3.3). Wiederholte unerklärte Verzögerungen in der Expertenprüfung verpflichten die IANA, die Sache an die IESG zu eskalieren, die den Zustand korrigieren oder den Experten ersetzen sollte (RFC 8126, §5.3) — ein Rechtsmittel gegen die Verzögerung, nicht für den beantragten Wert. Und der Transparenzgrundsatz ist ausdrücklich: „the recommendations by designated experts must be visible to the public to the maximum extent possible and subject to challenge or appeal“ (RFC 8720, §3.3). Sichtbarkeit ist zugesagt. Ein Entscheidungsdatum nicht.

Die Aktenlage um das Instrument ist lebendig und in Bewegung. RFC 9907 von März 2026 aktualisiert RFC 8126 und macht RFC 8407 obsolet; er verlangt Anweisungen, die Änderungen in einem maßgeblichen Register mit der Pflege des zugehörigen, von der IANA betreuten YANG-Moduls verbinden, wobei neue Werte in das Register gehören und nicht direkt in das Modul (RFC 9907). Die Errata-Akte zeigt, was die Gemeinschaft bereits versucht hat: Das technische Erratum 6522, am 8. April 2021 zurückgewiesen, hätte ausdrücklich erlaubt, dass datierte Fassungen von Internet-Drafts die Dokumentationsauflage des §4.6 erfüllen, und der Prüfer behandelte es als Politikvorschlag, der Diskussion und Konsens braucht, nicht als Fehlerkorrektur; das redaktionelle Erratum 5772, am 3. Juli 2019 zur Dokumentaktualisierung zurückgehalten, betrifft einen Danksagungsverweis und nichts weiter (Errata zu RFC 8126). Diese Zurückweisung hält fest, dass eine vorgeschlagene Formulierung abgelehnt wurde. Sie belegt nicht, dass nie ein Internet-Draft unter den Regeln irgendeines Registers in der Praxis angenommen wurde, und §4.6 in der geltenden Fassung nennt Internet-Drafts nicht unter den zulässigen Formen.

Es gibt einen Ersatztext, und er ist nicht in Kraft. draft-ietf-ianabis-rfc8126bis-05 wurde am 2. November 2026 veröffentlicht; seine Zusammenfassung sagt, er mache RFC 8126 obsolet, während der eigene Kopf dies unter den Vorbehalt der Genehmigung stellt und der Status ihn als Internet-Draft ausweist, also als laufende Arbeit (draft-ietf-ianabis-rfc8126bis-05). RFC 8126 wird hier daher als geltender Text gelesen; der Ersatz wird als bedingt festgehalten, nicht als vollzogene Ablösung.

Drei Grenzen gehören neben die Aussagen, nicht ans Textende. Kein tatsächlicher Registrierungsantrag, keine Ablehnung, keine Einspruchseinlegung und keine Entscheidung wurden geprüft, sodass alles oben den veröffentlichten Rahmen beschreibt, nicht die Behandlung eines bestimmten Antrags. Welche Politiken ein bestimmtes Register binden, wurde nicht festgestellt — ein Register kann mehrere Verfahren tragen. Die interne Behandlung eines Einspruchs durch die IESG und jede unveröffentlichte Geschichte früherer Einsprüche wurden nicht beschafft.

Eine Recherchegrenze, einmal gesagt: Drei Rechercheversuche zur Dokumentenklasse der Namensfunktion der IANA scheiterten beim Anbieter, bevor diese Linie geschlossen wurde, und der Vertrag zur Namensfunktion, die Satzung des Customer Standing Committee und der Bericht der Naming Function Review bleiben in dieser Prüfung ungelesen. Das ist eine Lücke der Recherche dieser Redaktion. Es ist keine Feststellung über diese Dokumente.

Was würde die Lesart ändern? Ein veröffentlichter Einspruchsbescheid, der mit einem unter Leitung der IAB statt der IESG eingetragenen Wert endet, oder ein Register, das seine eigenen Kriterien niederschreibt und damit die vermutete Zuteilung in eine prüfbare Bedingung verwandelt. Bis eines von beiden erscheint, ist die ehrliche Zusammenfassung für alle, die sich auf einen Eintrag im IANA-Register verlassen, enger als es aussieht: Der Rahmen veröffentlicht den Maßstab, veröffentlicht das Transparenzversprechen und übergibt Zeitplan und letztes Wort denselben wenigen Leuten.