Summary

  • RFC 5237 strich die Expert-Review-Route für nicht offengelegte Informationen. IESG Approval und Standards Action blieben bestehen, jedoch auf Grundlage öffentlicher, überprüfbarer Spezifikationen.
  • Die Zuteilung koordiniert eine eindeutige Bedeutung. Sie beweist weder Implementierung noch Interoperabilität, Sicherheit, Einsatz oder Verkehr. Öffentlichkeit legitimiert den Verbrauch des Werts, nicht den späteren Betrieb.

Die Ausnahme wirkte außerhalb des Geheimvertrags

RFC 2780 kannte für IPv4-Protocol-Werte Expert Review, IESG Approval und Standards Action. Expert Review war besonderen Fällen mit Geheimhaltungsinformationen vorbehalten; das IESG sollte die Fachleute bestimmen.

Für einen Antragsteller schützte das Forschung oder ein künftiges Produkt. Die Folgen der Zuteilung blieben aber nicht vertraulich. Betriebssysteme, Router, Filter, Analysatoren und spätere Protokollentwürfe mussten den Wert als belegt behandeln.

Diese Dritten konnten den Zweck nicht prüfen. Trotzdem mussten sie Kollisionen vermeiden und eine Ausnahme pflegen, deren Begründung ihnen verschlossen blieb. Privater Informationsschutz wurde so zu öffentlicher Dauerarbeit.

RFC 5237 löste nicht das Geschäftsgeheimnis auf. Es entzog ihm nur die Möglichkeit, über diesen Weg einen bleibenden Anspruch auf das knappe gemeinsame Feld zu erzeugen.

Knappheit verlangt eine Schichtentscheidung

Das Feld umfasst 256 Werte. RFC 5237 hielt fest, dass zur Zeit seiner Abfassung im Jahr 2008 55 Prozent verwendet wurden. Das ist keine heutige Auslastungszahl, sondern der historische Anlass für eine strengere Prüfung.

Eine solche Prüfung fragt nach einer stabilen Spezifikation und einer tatsächlichen Nutzerschaft. Sie sucht Doppelbelegungen und prüft die technische Grenze: Benötigt der Entwurf wirklich einen IP-Protocol-Wert, oder wäre ein TCP- beziehungsweise UDP-Port die passendere Zuordnung?

Standards Action blieb für Standards erhalten. IESG Approval blieb für begründete Nicht-IETF- oder Nicht-Standards-Track-Nutzungen erhalten. Gestrichen wurde allein die nicht öffentlich überprüfbare Abkürzung.

Öffentlich bedeutet nicht standardisiert

Eine veröffentlichte Spezifikation erlaubt Widerspruch, Vergleich und Schichtanalyse. Sie wird dadurch nicht automatisch zum IETF-Standard. Die fortbestehende IESG-Approval-Route zeigt gerade, dass zulässige Zuteilungen außerhalb von Standards Action möglich sind.

Öffentlichkeit klärt ebenso wenig automatisch Patente, Lizenzen oder Eigentum. Sie verlangt nur, dass der Teil, der dem gemeinsamen Wert Bedeutung gibt, prüfbar ist.

Dokument, Entscheidung und Betrieb bleiben verschiedene Belege. Die Spezifikation beschreibt das Vorhaben. Die Genehmigung erlaubt die Belegung. IANA hält die Zuordnung fest. Laufender Code und Interoperabilität folgen, wenn überhaupt, später.

IANA verwaltet die Zeile, nicht die Technik

Das IANA-Register Protocol Numbers ist das maßgebliche Verzeichnis von Werten und Referenzen. Eine Zeile bedeutet nicht, dass IANA das Protokoll entworfen, seinen Marktwert anerkannt oder seine Sicherheit getestet hat.

Diese Trennung hält auch die Rolle des Verwalters klein. Wer Eindeutigkeit bewahrt, wird nicht Eigentümer der Technologien. Umgekehrt darf der Zuteilungsempfänger den Registereintrag nicht als Gütesiegel verwenden.

Bewiesen ist die koordinierte Bedeutung unter einer veröffentlichten Referenz. Nicht bewiesen sind Produkt, Installation, Verbreitung, Paketaufkommen oder betrieblicher Nutzen.

Experimente haben einen anderen Ausgang

RFC 4727 reserviert 253 und 254 für Experimente und Tests. Ein Entwurf kann erprobt werden, bevor er eine dauerhafte globale Bedeutung beansprucht.

Die Werte sind keine Garantie. Mehrere Experimente können kollidieren, Zwischenstellen können sie sperren, und ein Laborlauf belegt keine Internetweite Unterstützung. Doch die Unsicherheit bleibt dort sichtbar, wo sie hingehört.

Erst wird in einem begrenzten Raum getestet. Eine permanente Zuteilung folgt, wenn Spezifikation und Bedarf öffentlich genug sind, um die gemeinsamen Kosten zu rechtfertigen.

Die Regel hat einen ausdrücklich begrenzten Umfang

RFC 5237 nimmt keine Stellung zu Geheimhaltungsvereinbarungen in anderen Parameterbereichen. Register unterscheiden sich in Größe, Delegierbarkeit und Kollisionskosten. Die konkrete Änderung gilt für IPv4 Protocol und über den Verweis in RFC 2780 für IPv6 Next Header.

Die Anreizfrage reicht weiter. Geheimhaltung nutzt einer Partei; der Verlust eines gemeinsamen Werts trifft alle. Eine legitime Politik darf diesen Kostentransfer nicht verbergen.

RFC 8126 modernisierte später die Begriffe der IANA-Zuteilungspolitik. Das hilft beim Verständnis, ersetzt aber nicht die historische Handlung von BCP 37 im Februar 2008.

Zuteilung unterhalb der Betriebswirklichkeit halten

Die Nachweiskette beginnt mit Antrag und öffentlicher Spezifikation. Danach folgen autorisierte Entscheidung und Registereintrag. Erst dann können Implementierung, Interoperabilitätstest, Einsatz und beobachteter Verkehr entstehen.

Jeder Übergang kann scheitern. Ein öffentliches Dokument kann einen schlechten Entwurf offenlegen. Ein zugeteilter Wert kann ohne Code bleiben. Zwei Programme können sich widersprechen. Eine funktionierende Implementierung kann ohne Einsatz bleiben.

Lu Hengs Vorrang der laufenden Wirklichkeit verhindert die Aufwertung eines Belegs zum nächsten. Transparenz ist stärker als eine geheime Zusicherung, aber eine Spezifikation ist kein laufender Code. Der Registereintrag ist eine Eindeutigkeitsquittung, kein Leistungsbericht.

Sources

Additional standards record

  1. RFC 5237 als Klartext
  2. Informationsseite zu RFC 5237
  3. RFC 5237 im Datatracker
  4. Historie von RFC 5237
  5. Errata zu RFC 5237
  6. Referenzen auf RFC 5237