Zusammenfassung

  • Nach RFC 9907 ist ein IANA-gepflegtes YANG-Modul eine Darstellungsform des zugehörigen Registers, kein zweites Register. Das Register bleibt die einzige maßgebliche Quelle.
  • Ein Validator kann alte Bytes korrekt akzeptieren. Belastbare Evidenz verbindet Registerzeitpunkt, Modulrevision und Hash, Prüfbedingungen, YANG Library des Servers, konkrete Operation und beobachtetes Ergebnis.

Alle Kontrollen waren grün, doch die Freigabe beruhte auf einer falschen Gleichung. Der Parser hatte ein Modul geprüft; das dazugehörige IANA-Register führte bereits einen neueren Wert. „Gültig“ beschrieb die Form des Inputs. Im Freigabeprotokoll war daraus unbemerkt „maßgeblich und aktuell“ geworden.

RFC 9907 erschien im März 2026 als BCP 216, löste RFC 8407 ab und aktualisierte RFC 8126. Der RFC-Editor-Eintrag hält diesen Status fest. Das Dokument leitet Autoren und Prüfer von Spezifikationen mit YANG-Modellen an; es definiert keinen neuen Gerätekonfigurationsdienst.

Für IANA-gepflegte Module setzt es eine klare Ordnung. Eine YANG- oder MIB-Darstellung eines Registers ist ein weiteres Format, kein eigenständiges Register. Neue Werte werden in das Begleitregister aufgenommen, anschließend spiegelt IANA die autorisierte Änderung im Modul. IANA YANG Parameters stellt versionierte Dateien und Pflegehinweise bereit.

Sogar die erste Fassung wird bewusst entmachtet. Im Internet-Draft dürfen Erzeugungsskript und vollständiges Anfangsmodul die Begutachtung erleichtern. Vor der RFC-Veröffentlichung müssen die Autoren den RFC Editor bitten, den Modulanhang zu entfernen. Der fertige Text bezeichnet ihn nur als Anfangsversion und verweist auf IANA. Eine in einem dauerhaften Dokument eingefrorene Kopie soll nicht durch ihren offiziellen Rahmen zur ewigen Gegenwart werden.

Auch bei IANA sind „latest“ und eine revisionsgebundene URL unterschiedliche Belege. Die erste liefert die gegenwärtige Projektion, die zweite ein bestimmtes historisches Artefakt. Für Wiederholbarkeit braucht es Abrufzeit, Registerstand, Revision, URL und Hash. Sonst kann dieselbe veränderliche Adresse morgen andere Bytes unter dieselbe Prüfgeschichte legen.

Validierung bleibt notwendig. RFC 9907 nennt etwa pyang --ietf; YANG 1.1 liefert die Sprachregeln. Der Befund gilt jedoch für diese Bytes, diese Imports, Optionen und Werkzeugversion. Er beweist weder Aktualität noch Übereinstimmung mit dem Zielserver.

RFC 8525 macht den Server separat beobachtbar: YANG Library meldet Modulsätze, Features, Deviations und Datastore-Schemata; bei jeder Änderung muss sich content-id ändern. Lokale Prüfung und Vergleich mit dem angekündigten Inventar sind verschiedene Kontrollen.

Danach folgen Zustand und Wirkung. RFC 8342 unterscheidet unter anderem intended und operational. NETCONF sowie RESTCONF definieren Operationen und Fehler. Annahme, operativer Zustand und Serviceerfolg bilden drei Nachweise, nicht einen.

Ein belastbares Dossier verknüpft daher Register-Snapshot, IANA-Revision/URL/Hash, Erzeugungsherkunft, Validator/Optionen/Abhängigkeiten, Servermodule und content-id, Operation und Quittung, Vorher-/Nachher-Sichten, Rückfallzustand und Servicetest. Das ist eine redaktionelle Evidenzsynthese, kein Formular einer einzelnen RFC.

Heng Lus Minimum Initial Specification hält die gemeinsame Ebene schmal. Running-Code Primacy begrenzt Beobachtungen auf ihre direkte Aussage. Reality Layers verhindert, Register, Datei, Prüfung, Datastore und Service in eine Ampel zu pressen. Das ist offengelegte redaktionelle Methodik, keine zusätzliche IETF-Norm.

Die Prüfung war nicht zu schwach. Die Behauptung war zu groß. RFC 9907 liefert die Architektur, um beides wieder passend zu machen.

Sources