Zusammenfassung

  • draft-cel-nfsv4-element-registries-00 schlägt acht IANA-Register vor und ersetzt die informelle Wahl der nächsten bekannten freien Zahl durch eine öffentliche endgültige oder frühe Zuteilung.
  • Das Register ist für die Koordinate und deren Geschichte maßgeblich; Standardqualität, Build-Inhalt, aktive Fähigkeit, Autorisierung, Ausführung, Speicherung und Anwendungsergebnis bleiben getrennte Aussagen.

Der freie Wert existierte zweimal

Zwei Entwürfe fügen NFSv4 unterschiedliche Operationen hinzu. Beide Autoren prüfen veröffentlichte RFCs. Beide wählen den kleinsten Wert hinter der höchsten bekannten Zuweisung. In ihren jeweiligen Testpaaren funktionieren die Erweiterungen.

Erst die gemeinsame Implementierung zeigt den Konflikt. Derselbe nfs_opnum4-Wert wählt zwei XDR-Union-Arme. Das Paket trägt keine Herkunftserklärung. Der Empfänger verwendet die Tabelle seines Binaries und kann die Absicht des Senders nicht aus der Zahl rekonstruieren.

Revision 00 von Registries of Network File System Version 4 Protocol Elements wurde am 25. September 2026 eingereicht und läuft am 29. März 2027 ab. Datatracker führt sie als aktiven individuellen Internet-Draft ohne WG-Übernahme, Stream, zuständigen AD oder IESG-Zustimmung. Der Kopf nennt Standards Track und ein Update von RFC 8178 für den Fall einer Genehmigung. Heute ist das Dokument kein RFC und kein Beleg für bereits eingerichtete IANA-Register.

Acht Kontexte für ausführbare Zahlen

Der Entwurf umfasst Operations, Callback Operations, Status Codes, fattr4 Attributes, ACCESS Flags, OPEN Share Access Flags, OPEN Result Flags und OPEN Delegation Types.

Operationsnummern wählen Strukturen in COMPOUND, Callback-Werte tun dies in CB_COMPOUND. Statusnummern tragen definierte Ergebnisse. Attributnummern sind zugleich XDR-Konstanten und Positionen in einer Bitmap. ACCESS- und OPEN-Werte beeinflussen Verhalten. Innerhalb eines Registers ist eine doppelte Bedeutung deshalb ein Wire-Konflikt.

Zwischen Registern kann dieselbe Ganzzahl gültig sein. Ein Nachweis muss also Register, Richtung, umgebenden XDR-Typ, Minor-Version und Referenz enthalten. Eine nackte Zahl ist keine globale Identität.

RFC 8178 erlaubt Erweiterungen durch neue Operationen, Attribute, Enum-Werte und Bits und untersagt Löschen oder Wiederverwenden. Die Auswahlmethode für einen neuen Wert bleibt offen. RFC 8276 dokumentierte eine manuelle Prüfung gegen bekannte aktuelle Spezifikationen. Das war sorgfältig, aber keine öffentliche Reservierung gegen unsichtbare parallele Arbeit.

Zuteilung wird zu einem eigenen Ereignis

Die Anfangstabellen der acht Register werden aus veröffentlichten RFCs aufgebaut. Nach einer möglichen Veröffentlichung des Entwurfs wäre jedes Register die maßgebliche Zuweisungsquelle für seinen Typ. Ein neues Dokument müsste den Wert in seinen IANA Considerations beantragen und die XDR-Konstante aus dem zugeteilten Wert ableiten.

Die Politik Standards Action with Expert Review verbindet zwei Aufgaben. Standards Action bewahrt die RFC-8178-Anforderung einer Proposed Standard. Der Experte kontrolliert Register und Richtung, niedrigsten verfügbaren oder passenden früh zugeteilten Wert, eindeutigen Namen, XDR-Definition, Versionsbereich und Referenz.

Der Experte urteilt ausdrücklich nicht über den fachlichen Wert der Funktion. Dafür ist IETF-Konsens zuständig. Eine korrekte Registrierung ist daher weder Empfehlung noch Produktfreigabe.

IANA kann verbindlich sagen, welcher Koordinate welches Dokument zugeordnet wurde. Der Standard beschreibt die Norm. Der Build zeigt die tatsächlich eingebaute Tabelle. Ein Server entscheidet über Unterstützung und Autorisierung. Speicherung und Anwendung liefern das Ergebnis. Diese Autoritäten sind verbunden, aber nicht austauschbar.

Frühzuweisung schließt die Prototypenlücke

Prototypen brauchen Werte vor der RFC-Veröffentlichung. RFC 7120 erlaubt eine frühe Zuteilung für ausreichend beschriebene und stabile Spezifikationen, wenn Implementierungsinteresse oder Kollisionsgefahr besteht. IANA veröffentlicht sie vorübergehend, gewöhnlich für ein Jahr.

Revision 00 verlangt, dass ein WG-Dokument nach Übernahme eine Frühzuweisung anstrebt und keinen weder registrierten noch früh zugeteilten Wert benutzt. „Temporary“ bedeutet Reservierung, nicht Standardsieg. Ablauf, Verlängerung, Abschreibung und mögliche spätere Freigabe sind eigene Zustände.

Endgültige Werte werden fortlaufend ab dem niedrigsten freien nicht reservierten Wert vergeben. Ein einmal zugeteilter Wert wird nicht wiederverwendet. Wird ein Element aus allen Versionen entfernt, bleibt die Zeile bestehen; Versions kann none werden.

Diese Geschichte schützt alte Artefakte. Firmware, generiertes XDR, Analyzer und Captures können die frühere Bedeutung länger tragen als der Standard. Wiederverwendung würde einen alten Sender und neuen Empfänger unter derselben Zahl auseinanderlaufen lassen.

Normative Reichweite ist keine Marktstatistik

4.1+ sagt, in welchen Versionen der Standard ein Element gelten lässt. Es sagt nicht, dass jedes 4.1-System es implementiert. RFC 8178 erlaubt unterschiedliche Erweiterungsvarianten innerhalb derselben Minor-Version. none sagt ebenso wenig, dass kein Gerät mehr sendet.

Ein fehlender Eintrag belegt für einen abgedeckten Wert fehlende öffentliche Zuteilungsautorität. Er beweist nicht die Abwesenheit privater Forks. Ein vorhandener Eintrag belegt Koordination, nicht die Aktualität eines Binaries.

Die Beweiskette benötigt Dokumentstatus, Registerzeile, Zuteilungsaktion und Daten, exakte XDR-Spezifikation, Quell-/Generator-/Build-Fingerprint, aktive Fähigkeit, Wire-Kontext, Erkennung und Autorisierung sowie Speicher- und Anwendungsergebnis.

Registrierung aktualisiert keinen Build. Dekodierung autorisiert nicht. Erfolg garantiert nicht automatisch Dauerhaftigkeit. Bei einer Umnummerierung müssen Quellen, Bindings, Dissectoren, Tests, Appliances und Pakete nach Register, Richtung und Wert inventarisiert und alte Fingerprints erhalten werden.

Grenzen der Quellen

Die dreizehn Quellen belegen Vorschlag, Kollisionsmechanismus, frühe Zuteilung, Nichtwiederverwendung und Expertenrolle. Sie belegen keine reale NFSv4-Kollision, kein fehlerhaftes Produkt, keine WG-Übernahme, keinen IETF-Konsens, keine erfolgte IANA-Umsetzung, kein Deployment, keinen Vorfall und keinen Angriff.

Mit Lu Hengs Trennung von Aufzeichnung und Autorität ist das Register stark, wenn es eine enge Aussage trägt: diese Koordinate gehört nach diesem Verfahren zu dieser Spezifikation. Laufzeitwahrheit braucht Laufzeitbelege.

Quellen