Zusammenfassung

  • draft-ietf-netmod-yang-versioning-reqs-14 beschreibt Probleme und fünf Anforderungsgruppen, ohne eine konkrete Lösung zu untersuchen oder zu empfehlen.
  • WG-Status, I-D Exists, eine ausgefüllte Klauselmatrix und BC/NBC-Kennzeichen belegen Dokumentation. Sie belegen weder die Richtigkeit der Einstufung noch Client-Schutz, Migration oder Betriebssicherheit.

Die Architekturprüfung beginnt mit fünf grünen Zeilen. Nicht rückwärtskompatible Änderungen: abgedeckt. Kennzeichnung der Kompatibilität: abgedeckt. Bestehende Clients: abgedeckt. Veraltete Knoten: abgedeckt. Migration: abgedeckt. In der Belegspalte stehen ausschließlich Verweise auf Abschnitt 5 eines zwölfseitigen Internet-Drafts.

Damit wurde der Prüfplan mit dem Prüfergebnis verwechselt.

Revision 14 der YANG Module Versioning Requirements trägt das Datum 20. Juli 2026. Im Kopf ist „Informational“ als beabsichtigte Einordnung genannt. Der Datatracker führt das Dokument als aktiven Internet-Draft der NETMOD-Arbeitsgruppe, als WG Document mit dem IESG-Status I-D Exists. Bereits der Abstract zieht die Grenze: Das Dokument beschreibt Probleme und Anforderungen an mögliche Lösungen, betrachtet oder unterstützt aber keine bestimmte Lösung.

Die erste Gruppe verlangt, dass eine nicht rückwärtskompatible Änderung möglich wird, ohne alle importierenden Module gleichzeitig umzubenennen. Clients, die nur unveränderte oder kompatibel geänderte Knoten verwenden, sollen geschützt werden. Hinzu kommen eine Importbeschränkung zwischen „beliebige Revision“ und einer einzigen exakten Revision sowie eine Möglichkeit, inkompatible Schritte auszudrücken.

Das sind mehrere Abnahmetatbestände. Ein Verfahren kann eine Umbenennung vermeiden und trotzdem die falsche Abhängigkeit auflösen. Es kann einen NBC-Schritt markieren und ihn dennoch falsch klassifizieren. Es kann alle Module kompilieren, während ein alter Client an einem neuen Wert, Default oder Verhalten scheitert. Ein belastbarer Nachweis braucht daher die Vorher-/Nachher-Artefakte, den vollständigen Import- und Include-Abschluss, das effektive Schema samt Features und Deviations sowie die tatsächlich ausgeführten Client-Versionen.

Die zweite Gruppe verlangt, dass Menschen und Werkzeuge BC- und NBC-Änderungen erkennen. Der Hintergrund erklärt zugleich, warum reine Syntaxvergleiche nicht genügen: Semantisches Verhalten kann sich ändern, obwohl die YANG-Statements gleich bleiben. Zu prüfen ist deshalb nicht nur, ob ein Kennzeichen lesbar ist, sondern ob die Einstufung für genau dieses Revisionspaar und diesen Kontext stimmt. Dafür müssen verglichene Bytes, Vergleichsregel, Feature-/Deviation-Kontext, manuelle Entscheidungen und Warnungen erhalten bleiben.

Die dritte Gruppe schützt vorhandene Clients, ausdrücklich auch solche, die nach einer NBC-Änderung eine ältere Modulversion erwarten. Die vierte Gruppe verlangt, dass Clients erkennen können, ob als deprecated markierte Knoten implementiert sind, welche Alternative vorgesehen ist und warum die Ablösung erfolgt. Außerdem soll eine frühe Warnung möglich sein, solange eine bald obsolete Definition noch funktioniert.

Beides sind Aussagen über ein Zielsystem. Erforderlich sind Tests in beiden Richtungen: alter Client gegen neuen Server und neuer Client gegen alten Server. Lese- und Schreiboperationen, RPCs, Notifications, Fehler und Rollen müssen mit exakten Binärständen und Schemakonfigurationen geprüft werden. Bei zurückgezogenen Knoten ist die veröffentlichte Erklärung mit effektivem Schema, Deviations und beobachtetem Verhalten abzugleichen, auch nach einem Neustart.

Die fünfte Gruppe fordert Anleitung, einen Übergang von YANG 1.0/1.1 und eine Erklärung der Folgen für Instanzdaten und Referenzen. RFC 9195 kann den Content-Schema-Kontext von Instanzdaten identifizieren. Ob dieselben Daten unter einem anderen Schema nutzbar bleiben, hängt dennoch von Revisionen, Features, Deviations, Geltungsbereich und Kompatibilität ab. Ein Migrationsnachweis muss umbenannte, entfernte, erzeugte, mit Defaults versehene und abgewiesene Werte bilanzieren, semantische Invarianten prüfen und die Lesbarkeit nach einem Rollback zeigen.

Revision histories, Semver, Packages, Schemavergleich, Dateinamenregeln und YANG 2.0 können Zellen der Matrix schließen. Ihre Existenz neben dem Anforderungsdokument tut das nicht automatisch. Revision 14 enthält weder ein neues Protokoll noch ein Datenmodell. Ihre Stärke liegt darin, Versprechen so zu benennen, dass spätere Implementierungen sie nicht mit Dokumentstatus oder einem grünen Validator verwechseln können.

Primärquellen

Der eingefrorene offizielle Quellensatz umfasst Revision 14, den Datatracker-Eintrag, dessen Historie, die NETMOD-Dokumentliste sowie RFC 2119, RFC 6020, RFC 7950, RFC 8049, RFC 8299, RFC 8525 und RFC 9195.