Zusammenfassung

  • Der Datatracker vermerkte am 11. September 2026 die Freigabe von draft-ietf-intarea-legacy-registries-00 als WG-Fassung. Das Dokument ist weiterhin ein Internet-Draft und kein RFC.
  • Der Entwurf verlangt vier Arten von Maßnahmen: ein Register schließen, für eines IESG Approval festlegen, zwei auf First Come First Served setzen und das TTL-Register entfernen oder seinen Hinweis ersetzen.
  • Die fünf IANA-Oberflächen zeigen noch den bisherigen Stand. Ein maßnahmenscharfer Beleg sollte Annahme, spätere Billigung, Ausführung und Archivwirkung auseinanderhalten.

INTAREA übernimmt das Dokument, nicht die IANA-Schaltstelle

Der aktuelle Datatracker-Eintrag führt „Updates to Legacy IANA Registries“ als aktives INTAREA-Dokument. In der Historie der WG-Fassung stehen für den 11. September sowohl die Freigabe von -00 als auch der Ersatz des vorherigen Individual Draft.

Die Umbenennung ist ein Zuständigkeitswechsel. Die Arbeitsgruppe verpflichtet sich, den Text gemeinsam weiterzuentwickeln und offene Einwände zu bearbeiten. Sie ist jedoch keine IETF-weite Billigung des angestrebten Standards. Zukunftsformulierungen in den IANA Considerations bleiben Anträge; aus ihnen wird nicht durch den Dateinamen eine Vollzugsmeldung.

Die Historie des Individual Draft dokumentiert den engeren Sinn der Entscheidung. Am 27. August stellten die Vorsitzenden Konsens zur Annahme fest. Sie erwähnten zugleich einen Einwand, den sie als gehört und erörtert ansahen, und ordneten das Vorhaben als Pflege von Registerverfahren ein, nicht als Festlegung zur Zukunft von IPv4. Eine WG kann ein lösbares Problem annehmen, ohne jeden Begründungssatz für unstrittig zu erklären.

Auch der Textsprung war klein. Die individuelle Fassung 03 und die WG-Fassung 00 fordern dieselben Maßnahmen. Geändert wurden eine grammatische Formulierung in den Security Considerations und die Danksagung. Neu ist die Verantwortung für den Entwurf, nicht sein Vollzug.

Hinter „Bereinigung“ stehen vier verschiedene Entscheidungen

Der Sammelbegriff verdeckt, dass der Entwurf die Register nicht gleich behandelt.

Das Register NetWare/IP Option Type 63 Sub-Option Codes soll geschlossen werden, weil NetWare nicht mehr erweitert wird. Danach wären keine neuen Einträge möglich, vorhandene Werte blieben jedoch gültig und aktualisierbar. Genau so definiert RFC 8126 ein geschlossenes Register: Die Information bleibt für Betrieb und Geschichte erhalten.

Für IP Option Numbers ist keine Schließung vorgesehen. Stattdessen soll IESG Approval als Registrierungsverfahren gelten. Damit kann das IESG Einzelfälle genehmigen, ohne zwingend eine RFC zu verlangen, zugleich Unterlagen anfordern oder die Community konsultieren. RFC 8126 beschreibt diesen Weg als seltene Ausnahme, nicht als Normalfall. Das ist eine benannte Entscheidungsschwelle, kein pauschales Verbot neuer IPv4-Optionen.

Machine Names und Terminal Type Names sollen First Come First Served erhalten. Dieses Verfahren verlangt nur minimale Dokumentation und keine fachliche Prüfung. Der Entwurf erkennt das Risiko unsinniger Einträge an und verweist auf die übliche Plausibilitätsfilterung durch IANA. Zwei seit Jahrzehnten ruhende Listen bekommen damit einen definierten, niedrigen Zugang — das Gegenteil einer Schließung.

Beim IP Time to Live Parameter soll nach Möglichkeit das Register entfernt werden. TTL könne vom Betriebssystem oder von der Anwendung frei gewählt werden; ein Register sei daher fehl am Platz. Falls eine vollständige Entfernung nicht möglich ist, liefert der Entwurf einen Ersatzhinweis. Löschen und Hinweisänderung sind unterschiedliche öffentliche Ergebnisse.

Der Live-Stand ist weiterhin der alte

Auf der IANA-Seite für DHCP- und BOOTP-Parameter sind die NetWare-Untercodes weiterhin sichtbar. Als Verfahren steht dort Not defined; eine Schließungsmarkierung fehlt.

Die Seite IPv4 Parameters zeigt für IP Option Numbers ebenfalls Not defined. Das TTL-Register samt Empfehlung des Standardwerts 64 ist noch vorhanden. Experimentelle Optionswerte bleiben dokumentiert, aber IESG Approval steht noch nicht als geltendes Verfahren auf der Seite.

Bei Machine Names lautet der Verfahrensstand weiter Not defined. Terminal Type Names trägt sogar noch Not defined?. First Come First Served ist auf keiner der beiden Seiten eingetragen.

Daraus folgt kein Versäumnis von IANA. RFC 8126 erklärt, dass IANA-Maßnahmen normalerweise erfolgen, wenn ein Dokument zur Veröffentlichung gebilligt wurde. Dieser Entwurf wird noch entwickelt. Die INTAREA-Dokumentenliste belegt den Prozessstand; die Registerseiten belegen den geltenden Registerstand. Wer nur eine Quelle liest, beantwortet zwei verschiedene Fragen mit demselben Beleg.

Die Annahme hat die Einwände nicht gelöscht

Im INTAREA-Protokoll von IETF 126 steht die Sorge, ein faktischer Stopp neuer IPv4-Optionsnummern könne sinnvolle Anwendungen in begrenzten Netzen behindern. Ein weiterer Beitrag verlangt, Informationen auch nach dem Außerdienststellen alter Technik zu bewahren. Der Autor verwies auf experimentelle Werte und den Fortbestand vorhandener Einträge.

Die Diskussion zur Annahme hinterfragt außerdem die Beschreibung der Zuverlässigkeit von IPv4-Optionen und warnt davor, die Begründung später zu breit zu zitieren. Andere Beiträge unterstützen die Annahme. Der Beschluss überträgt diese Auseinandersetzung an die WG; er verwandelt sie nicht nachträglich in Einstimmigkeit.

Die korrekte Nachricht bleibt daher begrenzt: INTAREA hat beschlossen, an dem Dokument zu arbeiten. Weder sind alle Maßnahmen als endgültiger Text gebilligt noch bei IANA umgesetzt.

Für jede Anweisung ein eigener Vollzugsbeleg

Zwischen dem Entwurf und dem späteren Registerzustand könnte ein Registermaßnahmen-Beleg die Nachvollziehbarkeit sichern. Das ist ein redaktioneller Vorschlag und keine bestehende Vorgabe von IETF oder IANA.

Ein solcher Beleg enthält den exakten Registernamen und die URL, einen datierten Vorher-Stand, Fassung und Hash des Entwurfs, das beantragte Verb, die Stationen in WG und IESG, die IANA-Bestätigung, die wirksame Referenz, den Nachher-Stand sowie die Archivbehandlung vorhandener Einträge.

Machine Names und Terminal Type Names brauchen getrennte Belege, auch wenn beide dasselbe Verfahren erhalten. NetWare muss als geschlossen mit erhaltenen Werten erscheinen, nicht als gelöscht. Beim TTL muss der Beleg zwischen Entfernung und Ersatzhinweis unterscheiden. Ändert eine spätere Fassung das Verfahren für IP Option Numbers, bleibt der überholte Antrag als Teil des Weges sichtbar.

Damit wird aus einer kleinen Registerpflege ein klar prüfbarer Vorgang. Der neue Dokumentname belegt die Übernahme durch INTAREA. Ein späterer RFC würde den gebilligten Auftrag belegen. Erst die geänderte IANA-Seite belegt die Ausführung. Keine dieser Aussagen darf die andere vorwegnehmen.

Quellen

  1. IETF Datatracker — aktuelles WG-Dokument
  2. Historie des WG-Dokuments
  3. Unveränderliche WG-Fassung 00
  4. Historie des ersetzten Individual Draft
  5. Unveränderliche Individualfassung 03
  6. INTAREA-Protokoll von IETF 126
  7. Diskussion zur Annahme
  8. IANA — DHCP- und BOOTP-Parameter
  9. IANA — IPv4-Parameter
  10. IANA — Machine Names
  11. IANA — Terminal Type Names
  12. RFC 8126 — IANA-Registrierungsverfahren
  13. INTAREA-Dokumente