Zusammenfassung

  • draft-ietf-netmod-iana-yang-guidance-03 beschreibt, wie ein normatives YANG-Modul von einer durch das IESG genehmigten Vorabfassung über kontrollierte Änderungen des RFC Editor, die endgültige Revision und YANG-Semver-Wahl sowie erneute Validierung bis zur annähernd gleichzeitigen Veröffentlichung bei RFC und IANA gelangen soll.
  • Identische Bytes bei RFC und IANA wären ein belastbarer Publikationsnachweis. Sie beweisen jedoch weder, dass eine redaktionelle Änderung die Bedeutung erhalten hat, noch dass der Versionssprung richtig war, ein Client genau diese Bytes abgerufen oder ein Gerät sie geladen hat oder das Laufzeitverhalten kompatibel geblieben ist.
  • Vom IETF veröffentlichte Module und von IANA gepflegte, aus Begleitregistern abgeleitete Module folgen verwandten, aber unterschiedlichen Aktualisierungspfaden. Weder eine Registerveröffentlichung noch ein erfolgreicher Toollauf ist eine Betriebsbescheinigung.

Stellen wir uns zwei gläserne Vitrinen vor, die fast im selben Augenblick geöffnet werden. Die eine gehört zur RFC-Veröffentlichung, die andere zur Kopie im IANA-Register YANG Module Names. In beiden liegt dasselbe Byte-Muster. Diese Symmetrie ist beabsichtigt und nützlich: Ein Betreiber muss nicht mehr erraten, welcher Herausgeber die endgültige Ausgabe besitzt.

Doch die übereinstimmenden Vitrinen stehen am Ende eines Publikationsprozesses, nicht am Ende eines Rollouts. Sie zeigen, dass zwei Veröffentlichungsflächen denselben Stand tragen. Sie zeigen nicht, was bei einer semantischen Redaktionsentscheidung, im Cache eines Clients, im Lader eines Servers, im wirksamen Schema, in einem Datenspeicher oder auf einem Paketpfad geschah.

Genau diese Grenze macht Revision 03 von Guidance for Managing YANG Modules in RFCs and IANA Registries bemerkenswert. Der am 11. September geprüfte Datatracker-Eintrag führt ein aktives NETMOD-WG-Internet-Draft in Revision 03 mit den Zuständen WG Document, I-D Exists und dem vorgesehenen Status Informational. Der Text trägt das Datum 6. Juli 2026 und läuft am 7. Januar 2027 ab. Die Datatracker-Angabe „Last updated“ vom 27. August betrifft Änderungen am Shepherding-AD und am beabsichtigten Status; die jüngste Dokumentrevision bleibt vom 6. Juli. Der Entwurf ist kein RFC, und keine seiner vorgeschlagenen Übergaben darf als abgeschlossenes Produktionsereignis ausgegeben werden.

Die Vorabkennung erhält redaktionellen Spielraum

Die vorgeschlagene Kette setzt an einem sinnvollen Punkt ein: Bei der IESG-Genehmigung würden normative Module gewöhnlich noch Vorabkennungen tragen, etwa eine Null-Hauptversion oder einen Release Candidate mit Entwurfsnummer. Das ist kein Schönheitsfehler. Es signalisiert, dass der Inhalt noch nicht die für eine veröffentlichte Revision erwartete Unveränderlichkeit besitzt.

Während der Bearbeitung durch den RFC Editor können Beschreibungen ohne Bedeutungsänderung präzisiert, Entwurfsverweise durch endgültige RFC-Nummern ersetzt, Tippfehler korrigiert und Formate vereinheitlicht werden. Revision 03 zieht um diese Arbeit eine Zuständigkeitsgrenze: Redaktionelle Änderungen dürfen regulär erfolgen, substantielle Änderungen verlangen Abstimmung mit den Autoren. Könnte eine Beschreibung ihre Semantik ändern oder ist eine BC/NBC-Einstufung unklar, verlangt das Dokument eine zusätzliche menschliche Prüfung.

Vor der Veröffentlichung werden das endgültige Revisionsdatum gesetzt, die Vorabkennung entfernt und die Release-Version nach YANG Semver gewählt. Bei einem bereits veröffentlichten Modul ist außerdem der Vergleich mit dem Vorgänger nötig und gegebenenfalls die Markierung rev:non-backwards-compatible. Ändern spätere Eingriffe das Modul erneut, muss auch die Versionsentscheidung neu aufgerollt werden. Die endgültige Kennung dokumentiert somit ein Urteil über den finalen Kandidaten; sie beweist nicht dessen Unfehlbarkeit.

Validierung gilt für Bytes, Abhängigkeiten und Werkzeuge

Revision 03 empfiehlt, nach Redaktion und Formatierung erneut zu validieren, normalerweise mit pyang und yanglint. Ebenso wichtig ist der richtige Abhängigkeitssatz. Gemeinsam veröffentlichte Module müssen möglicherweise zusammen extrahiert und geprüft werden. Ein sauberer Lauf gegen ein bequemes, aber anderes Abhängigkeitsverzeichnis beantwortet eine andere Frage.

Der Entwurf benennt die Grenze ungewöhnlich offen. Werkzeuge können nicht immer entscheiden, ob eine Beschreibung nur klarer wurde oder ihre Bedeutung wechselte. Ein Updatevergleich kann bekannte NBC-Fälle erkennen, ohne für jede denkbare Änderung die einzig richtige Semver-Stufe zu beweisen. Fehler und unbehandelte Randfälle können falsche positive wie negative Ergebnisse liefern. Ein Vorabvorgänger kann verhindern, dass die nächste Release-Version automatisch vorgeschlagen wird. Unerwartete Ausgabe ist deshalb ein Grund für Prüfung, nicht die Erlaubnis, Absicht zu automatisieren.

„Keine Warnungen oder Fehler“ ist also ein präziser Beleg: Diese Werkzeugversion akzeptierte diese Bytes mit diesen Abhängigkeiten und Optionen. Es ist kein Beleg für erhaltene Semantik, vollständige Kompatibilität oder korrekte Ausbringung.

IANA wartet auf finale Bytes und veröffentlicht dann neben dem RFC

Der Entwurf fordert IANA auf, das normative Modul erst zu veröffentlichen, wenn die Arbeit des RFC Editor abgeschlossen ist. Nach der Finalisierung würde der RFC das Modul enthalten; IANA würde die entsprechende Version ungefähr gleichzeitig im Register YANG Module Names bereitstellen. Ziel sind Bytegleichheit und korrekte endgültige Verweise.

Das ist Publikationsgleichzeitigkeit, keine verteilte Ausführung. Ein Prüfer würde dafür die aus dem RFC extrahierten Bytes, das IANA-Objekt, ihre Digests, Abrufzeiten und endgültigen Revisions- und Versionsdaten sichern. Selbst perfekte Gleichheit sagt nichts über einen früher beobachteten Spiegel, einen zwischengespeicherten unsuffigierten URL, Paketauflösung, das vom Server angekündigte YANG-Library-Set, den Prozessstart, aktivierte Features und Deviations, eine Instanzdatenmigration oder das Laufzeitverhalten.

Die benachbarte BTW-Analyse zu YANG-Dateinamen behandelt Alias- und Laderauswahl; der Schemavergleich behandelt die Klassifizierung ED/BC/NBC; Modulversionierung behandelt Zweige und Abstammung; Pakete behandeln rekursive Zusammensetzung. Der eigenständige Beitrag dieses Entwurfs ist die kontrollierte Übergabe, die einen Publikationskandidaten einfriert und zwei Veröffentlichungsflächen zur Übereinstimmung bringt.

Aus Registern abgeleitete Module folgen einer anderen Uhr

Revision 03 wechselt anschließend den Pfad. Ein von IANA gepflegtes Modul ist nicht bloß eine zweite Kopie eines IETF-Moduls. Es ist eine maschinenlesbare Projektion eines Begleitregisters, häufig in Form von Enumerationen oder Identities. Neue Werte gelangen zuerst in das maßgebliche Begleitregister. Danach identifiziert IANA dessen Delta, überträgt die Änderung in das Modul, setzt Revision und Version neu, prüft die Einstufung, validiert und veröffentlicht datums- und versionsadressierbare Artefakte.

Auch dieser Ablauf erzeugt einen begrenzten Nachweis. Eine Revision kann zeigen, dass eine dokumentierte Registeränderung in einer bestimmten Modulausgabe abgebildet wurde. Sie beweist weder kontinuierliche Aktualität vor oder nach der Prüfung noch Vollständigkeit jeder Zuordnung oder den Abruf und das Laden durch einen Verbraucher. Das in RFC 9907 behandelte Problem eindeutiger Registerautorität und Aktualität bleibt von den Übergabemechanismen dieses Entwurfs getrennt.

Nach der Veröffentlichung geht die Beweiskette weiter

Ein belastbarer Abschluss hält mindestens neun Nachweise auseinander: den genehmigten Entwurfskandidaten; jede Änderung und Konsultation beim RFC Editor; die endgültige Revisions- und Semver-Entscheidung; genaue Validierungseingaben und Werkzeugversionen; die extrahierten RFC-Bytes; die bei IANA veröffentlichten Bytes samt Abrufzeit; Abruf- und Cache-Provenienz des Clients; Geräteladung und angekündigtes wirksames Schema; sowie beobachtetes Verhalten von Datenspeicher, Protokoll und Dienst.

Heng Lus Running-Code Primacy liefert hier die Auslegungsdisziplin, nicht eine Behauptung über die Absicht des IETF: Ein Koordinationsartefakt kann ein Kompatibilitätsziel beschreiben, ohne die Einführung real zu machen. Minimum Initial Specification erklärt die Stärke des engen, möglichst deterministischen und lokal prüfbaren Publikationsvertrags. Reality, Not Advocacy und Reality Layers verlangen, dass die Darstellung an der letzten beobachteten Schicht endet.

Zwei identische Veröffentlichungen sind deshalb keineswegs banal. Sie beseitigen eine Unklarheit, die Betreiber nie erreichen sollte. Ihre Aussagekraft entsteht gerade daraus, dass sie den Rest nicht zertifizieren.

Quellen

  1. Text der Revision 03
  2. Aktueller Datatracker-Eintrag
  3. Datatracker-Verlauf
  4. RFC 9907
  5. RFC 9890
  6. RFC 7950
  7. YANG Module Versioning, Revision 17
  8. YANG Semantic Versioning, Revision 26
  9. YANG Schema Comparison, Revision 09
  10. YANG Module Filename, Revision 14
  11. IANA YANG Parameters
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Reality, Not Advocacy
  15. Heng Lu — Reality Layers