Zusammenfassung

  • RFC 9911 überarbeitet die gemeinsamen Module ietf-yang-types und ietf-inet-types, behält deren Namen und Namensräume bei und veröffentlicht eine neue Revision. Der RFC ist IETF Proposed Standard vom Dezember 2025 und obsolet RFC 6991.
  • Damit ist Namensraumkontinuität kein Beweis für unveränderte Semantik. Wertemengen, kanonische Formen, Muster und Beschreibungen können sich ändern und abhängige Modelle sowie Werkzeuge erreichen.
  • Hinzu kommen Typen für Datum und Uhrzeit, Dauer, Sprach-Tags, Protokollnummern, Link-Local-Adressen, Adresse-mit-Präfix, Hostnamen und E-Mail-Adressen. yang-identifier wird an YANG 1.1 angeglichen; mehrere Pattern- und Description-Statements wurden korrigiert oder verbessert.

Die operative These lautet: Ein gemeinsames Typmodul ist eine Schnittstelle, nicht bloß eine Bibliothek im Hintergrund. Welche Auswirkung entsteht, hängt von der importierten Revision, dem konkreten Modell und der Implementierung ab. Die Quellen belegen weder eine universelle Einführung der Revision von 2025 noch, dass alle Werte aus RFC 6991 ungültig wären.

Besonders sichtbar ist die Zeitsemantik. Bei date-and-time bedeuten Z und +00:00 beide UTC. Nach der von RFC 9557 geprägten Semantik behauptet jedoch nur +00:00, dass UTC der lokale Bezugspunkt ist; Z enthält diese Behauptung nicht in gleicher Weise. Ein Parser kann daher beide Formen akzeptieren, während ein anderer nur eine Form kanonisch ausgibt oder eine Randform ablehnt. Tests müssen deshalb gespeicherte Werte und Serializer-Ausgaben einbeziehen, nicht nur das Anwendungsschema.

Die überarbeiteten Module ergänzen außerdem Datums-/Zeit- und Dauertypen, Sprachkennzeichnungen, Protokollnummern, Link-Local-Adressen, Adresse-und-Präfix, Hostnamen und E-Mail-Adressen. Mehrere reguläre Muster und Beschreibungen wurden präzisiert. Für einzelne Typen wird ausdrücklich eine Gleichwertigkeit mit SMIv2-Textkonventionen angegeben, für andere eine Nichtgleichwertigkeit. Ähnlichkeit der Bezeichnung reicht daher nicht als Beweis für Austauschbarkeit.

Die Migration beginnt mit einer Inventur: Welche Modelle importieren welches Modul und welche Revision? Danach werden reale Datenspeicherwerte, Grenzwerte und historische Eingaben gegen beide relevanten Verhaltensweisen geprüft. Zu vergleichen sind Servervalidierung, Clientbibliotheken, Schemawerkzeuge sowie XML- und JSON-Serialisierung. Ein unveränderter Modulname darf nicht als alleinige Freigabe dienen. Ebenso wenig lässt sich aus dem RFC das Verhalten eines bestimmten Herstellers ableiten.

Revisionsbewusstes Evidenzprotokoll

Aussage Beleg Bedeutung und Grenze
Überarbeitung der beiden Module und Ablösung von RFC 6991 RFC 9911, Abstract und Abschnitt 1 Definiert die neue Referenz, nicht den Verbreitungsgrad.
Neue Typen, Muster und Beschreibungen RFC 9911, Abschnitte 2 und 3 Belegt die Änderungsfläche, nicht die Ungültigkeit aller Altwerte.
yang-identifier und YANG 1.1 RFC 9911; RFC 7950 Verknüpft die Kennungsregeln mit YANG 1.1.
Unterschied zwischen Z und +00:00 RFC 9911; RFC 9557 Beide stehen für UTC; nur die zweite Form setzt UTC als lokalen Bezugspunkt.
Gleicher Modulname bei neuer Semantik RFC 9911, Abschnitte 3 und 4 Namenskontinuität garantiert keine semantische Kompatibilität.

Quellen