Zusammenfassung

  • Der IESG hat am 27. August einen Last Call zu einem Verfahren eröffnet, das die vorzeitige Einrichtung eines vollständigen IANA-Registers erlauben würde. Es wäre zunächst zwei Jahre gültig, öffentlich als temporär markiert und könnte verlängert, geschlossen oder verstetigt werden.
  • Register und Einträge durchlaufen unterschiedliche Zustände. Ein öffentliches Übergangsprotokoll sollte Entwurfsversion, WG-Konsens, Genehmigungen, vorläufige Zulassungsregel, Richtlinienwechsel und die Folgen von Verlängerung, Schließung oder Verstetigung verbinden.

Ein Ablaufdatum ist eine präzise Angabe mit erstaunlich vielen möglichen Bedeutungen. Es kann das Ende einer Tabelle bezeichnen, das Ende einer einzelnen Zuweisung oder nur den Zeitpunkt, an dem eine neue Entscheidung fällig wird. Wer die Zahl aus dem Register in Software übernimmt, sieht diese Unterschiede später oft nicht mehr.

Der aktuelle Entwurf Early IANA Registry Creation macht diese Mehrdeutigkeit zu einer Governance-Frage. Der IESG eröffnete am 27. August den Last Call; Stellungnahmen sind bis 10. September vorgesehen. Version 02 strebt den Standards Track an, ist aber weiterhin ein Internet-Draft. Eine Genehmigung oder ein RFC liegen nicht vor.

Das Koordinationsproblem ist real. Ein Arbeitskreis kann in einem Dokument einen neuen Parameterraum definieren, während andere Entwürfe bereits Werte daraus benötigen. Auch eine externe Standardisierungsorganisation kann auf fortlaufende Zuweisungen angewiesen sein. Eine interne Liste schafft kurzfristig Ordnung, kann aber nach der offiziellen IANA-Tabelle als zweite Wahrheit weiterleben. Vollständiges Warten auf den Gründungs-RFC verlagert Interoperabilitätstests nach hinten.

Der Vorschlag würde deshalb nach einer festgelegten IETF-Genehmigung die frühe öffentliche Einrichtung durch IANA erlauben. Das ist nicht bloß eine temporäre Zeile in einer bestehenden Tabelle. Es nimmt die Tabelle selbst, ihre provisorische Eingangskontrolle und ihre Verwaltung in Betrieb.

Die Einrichtung verteilt Verantwortung

Die Autoren beantragen die frühe Einrichtung bei den WG-Vorsitzenden. Diese prüfen die Voraussetzungen und ermitteln, ob die Arbeitsgruppe einen Konsens für die vorzeitige Einrichtung trägt. Anschließend holen sie die Zustimmung der Area Directors ein. Die ADs dürfen insbesondere das Risiko berücksichtigen, dass das Register nie dauerhaft wird. Erst danach ersuchen die Vorsitzenden IANA um die Umsetzung.

IANA würde das Register am vorgesehenen Ort erstellen, als temporär kennzeichnen und Erstellungs- sowie Ablaufdatum veröffentlichen. Die erste Laufzeit beträgt zwei Jahre. Vor ihrem Ende fragt IANA Vorsitzende und AD, ob weitere zwei Jahre gewünscht sind. Nach der ersten Verlängerung erfordern weitere Verlängerungen zusätzlich die Zustimmung des IESG, eine Begründung und den Plan der WG für die Spezifikation.

Ohne genehmigte Verlängerung schließt IANA das Register und kennzeichnet es entsprechend. Die Vorsitzenden können eine Schließung auch früher verlangen. Befindet sich das Gründungsdokument bei noch gültigem Register bereits in der IESG-Prüfung, läuft die Frist während dieser Prüfung nicht ab. Bei Sicherheits- oder anderen Problemen kann IANA den IESG um Aussetzung des Verfahrens bitten.

Der Entwurf enthält damit mehr als ein unverbindliches Versprechen. Dennoch beschreibt die sichtbare Mindestoberfläche vor allem Status und Daten. Für eine spätere Prüfung fehlt ohne zusätzliche Historie die Verbindung zur konkreten Entscheidung, die den jeweiligen Zustand erzeugte.

Der Zustand der Tabelle ist nicht der Zustand jeder Zeile

Das Gründungsdokument nennt die geplante Registrierungsrichtlinie für das endgültige Register. Vor der Verstetigung gilt sie jedoch nicht unmittelbar. IANA nutzt in der Übergangszeit ein Verfahren, das von der später erwarteten Richtlinie abhängt.

Soll das endgültige Register First Come First Served oder Expert Review verwenden, genehmigt in einem WG-Dokument ein zuständiger Vorsitzender die vorläufigen Einträge. Diese Einträge benötigen laut Entwurf nach ihrer Genehmigung keine Verlängerung. Bei einem AD-gesponserten Dokument übernimmt der Sponsor diese Rolle.

Erfordert die spätere Richtlinie einen RFC, etwa IETF Review oder Standards Action, muss der Eintrag das Verfahren des begleitenden Entwurfs zur frühen Zuweisung durchlaufen. Selbst wenn das Register dauerhaft wird, bleibt eine solche Zeile temporär, bis ihr eigenes Dokument genehmigt ist. Für Specification Required verzweigt die Regel danach, ob Internet-Drafts als dauerhafte Spezifikation zugelassen werden sollen.

Ein temporäres Register kann folglich eine nicht zu verlängernde Vorsitzenden-Zulassung, eine befristete frühe Zuweisung und Initialwerte des Gründungsdokuments enthalten. Später kann das Register dauerhaft und eine einzelne Zeile weiterhin temporär sein. Ein Feld für das Ablaufdatum des Registers kann diese Zustandskombinationen nicht abbilden.

Genau darin liegt der Unterschied zum geltenden RFC 7120. Der BCP regelt eine frühe Zuweisung aus einem bereits bestehenden Register. Der neue Entwurf würde die frühe Einrichtung des Registers selbst erlauben. Nicht nur ein Wert, sondern die Institution, die ihn sichtbar macht, beginnt früher zu wirken.

Eine Änderung am Entwurf kann das Übergangsverfahren ändern

Ein eröffnetes Register friert seinen Gründungsentwurf nicht ein. Wechselt die geplante Richtlinie beispielsweise von Expert Review zu IETF Review, muss auch das vorläufige Verfahren wechseln. IANA ist darüber zu informieren. Zugleich stellt der Text klar, dass IANA Änderungen an den registerschaffenden Dokumenten nicht selbst verfolgt.

Diese Grenze ist sachgerecht. IANA setzt Anweisungen um und führt das Register; sie soll nicht aus jeder neuen Entwurfsfassung politische Folgerungen ziehen. Autoren und Vorsitzende müssen Struktur- und Inhaltsänderungen prüfen.

Gerade deshalb braucht jede Mitteilung einen öffentlich prüfbaren Anker: genaue Fassung und Hash, frühere und neue Regel, entscheidende Rolle, Wirksamkeitszeitpunkt und betroffene Einträge. Sonst kann die Tabelle zwar aktuell aussehen, ohne zu zeigen, ob eine Zeile durch Vorsitzenden-Genehmigung, frühe Zuweisung, Expertenprüfung oder eine erst für den Endzustand gedachte Regel aufgenommen wurde.

Ein Zustandsprotokoll darf frühere Tatsachen nicht überschreiben

Auf Registerebene sollte das Protokoll eine feste Kennung, Registergruppe, Gründungsentwurf mit Version und Hash, Konsensnachweis, Entscheidungen von Vorsitzenden und AD, Antrags- und Erstellungsdatum, aktuelle Frist, geplante Endrichtlinie und geltendes Übergangsverfahren enthalten. Änderungen an Struktur oder Richtlinie werden als neue Ereignisse angefügt. Verlängerung, Stillstand der Uhr während der IESG-Prüfung, Aussetzungsersuchen, Schließung und Verstetigung bleiben als Kette erhalten.

Auf Eintragsebene gehören Wert, Bedeutung, Referenz, Change Controller, tatsächlicher Genehmigungsweg, Richtlinienfassung und Zeitstatus in die Zeile. Hängt ein Eintrag von einem eigenen Entwurf ab, muss die Abhängigkeit sichtbar sein. Bei Schließung oder Verstetigung des Registers ist festzuhalten, welche Eigenschaft der Zeile sich änderte.

Dafür müssen keine privaten Nachrichten veröffentlicht werden. Rollen, Entscheidungsreferenzen, Dokument-Hashes, Zeitpunkte und Ergebnisse reichen aus. Transparente Provenienz erweitert IANAs politische Kompetenz nicht; sie belegt, welche Anweisung der Betreiber ausgeführt hat.

Koordination bleibt eine begrenzte Aussage

Ein früher Eintrag verhindert Kollisionen. Er zertifiziert kein Produkt, verpflichtet keinen Netzbetreiber zur Einführung und ersetzt nicht die endgültige IETF-Prüfung. Eine Genehmigung durch einen Vorsitzenden erfüllt eine eng beschriebene Übergangsfunktion. Ein Last Call ist noch keine IESG-Entscheidung.

Auch die Schließung darf nicht überinterpretiert werden. Version 02 verlangt, dass IANA ein nicht verlängertes Register schließt und kennzeichnet. Sie legt nicht fest, dass sämtliche Einträge sofort gelöscht, ungültig oder wieder frei werden. Ohne eintragsbezogene Entscheidung lässt sich dieser Effekt nicht behaupten.

Die geprüften Quellen zeigen weder ein bereits nach diesem Verfahren eingerichtetes Register noch eine darauf beruhende Implementierung oder einen Missbrauch. Das Zustandsprotokoll ist vorbeugend gedacht: Bevor Werte in Geräte und Bibliotheken wandern, sollte ihre vorläufige institutionelle Herkunft ebenso kopierbar sein wie die Werte selbst.

Quellen