Zusammenfassung

  • YANG 2.0 verdrängt YANG 1 und 1.1 nicht. Ein vollständiges Modell darf Sprachversionen mischen, während include und import bewusst asymmetrisch bleiben.
  • Eine Ausnahme für Imports ohne Revision hält das alte Modul A neben dem auf 2.0 aktualisierten B und verhindert Kaskaden. Sie belegt weder die Auswahl des Clients noch ein gemeinsames effektives Schema oder Produktionsverhalten.

Das Wartungsfenster sieht harmlos aus. B wurde auf YANG 2.0 umgestellt. A bleibt in YANG 1.1 und importiert B ohne Revisionsangabe. Der Server startet, A und B stehen im Inventar, die Änderung erhält grünes Licht. All das kann regelgerecht sein. Unbewiesen bleibt, ob zwei Clients dieselben Bytes geladen, dieselbe B-Revision gewählt und denselben Schemabaum erzeugt haben.

Der Draft in Revision 00 vom 6. Juli 2026 erklärt, dass YANG 2.0 weder RFC 6020 noch RFC 7950 obsolet macht und ein Gesamtmodell mehrere Sprachversionen enthalten kann. Der IETF Datatracker führt ihn als aktiven NETMOD Working Group Internet-Draft. Der Kopf nennt Standards Track als Ziel; ein RFC oder Implementierungsnachweis ist er nicht.

Die Asymmetrie ist der Migrationspfad

Abschnitt 12 erlaubt einem 2.0-Modul nur 2.0-Submodule. Ein 1/1.1-Modul darf kein 2.0-Submodul einbinden und kein 2.0-Modul mit festgelegter Revision importieren. Umgekehrt darf ein 2.0-Modul ein Modul in YANG 1 oder 1.1 per Revision importieren.

Das ist kein symmetrisches Kompatibilitätsversprechen. Die neue Seite darf gezielt zurückgreifen; die alte Seite darf keine nach vorn gerichtete, revisionsgebundene Abhängigkeit zur neuen Sprache bilden.

Für A und B gilt eine Sonderregel. Importiert A B ohne Revision und wechselt B später zu 2.0, darf der Server A und B gleichzeitig implementieren. Er muss sie nach den Implementierungsregeln ankündigen und sollte A zusammen mit der jüngsten noch in YANG 1 oder 1.1 spezifizierten B-Revision anzeigen. So soll eine Aktualisierung von B nicht A und danach jeden weiteren Importeur zur Konvertierung zwingen.

Diese Begrenzung erhält lokale Entscheidungsfreiheit. Sie passt zu Lu Hengs Konzept von minimaler Anfangsspezifikation, lokaler Zukunftsentscheidung und freiwilliger Übernahme. Gerade weil die Übernahme nicht zentral erzwungen wird, muss jeder Teilnehmer seine tatsächlich geprüfte Kombination belegen.

Inventar ist noch kein Kompilat

Abschnitt 5.6.4 verbietet die Implementierung mehrerer Revisionen desselben Moduls, unterscheidet aber implemented von import-only. RFC 8525 beschreibt module sets, Konformitätsrollen, Features, Deviations und Änderungskennungen.

Damit lässt sich die Serveraussage zu einem Zeitpunkt sichern: A, aufgeführte B-Revisionen und ihre Rollen. Nicht belegt sind die vom Client gelesene Datei, die Auflösung des Imports ohne Revision, die Parser-Version oder die Identität des resultierenden effektiven Schemas.

Auch Nachbarinstrumente schließen diese Lücke nicht. Module Versioning verbessert Revisionsidentität, Semver setzt Bereiche, Packages beschreiben Mengen, Schema Comparison klassifiziert Änderungen und Dateinamen erleichtern die Suche. Keines ersetzt Resolver-Trace, Kompilat, Validierung und Laufzeitbeobachtung.

Acht Stufen belastbarer Evidenz

Eine Kompatibilitätsaussage braucht:

  1. exakte Bytes, Herkunft, Namespace, Sprachversion, Revision und Hash aller Module und Submodule;
  2. den vollständigen import/include-Abschluss und jede Entscheidung bei Imports ohne Revision;
  3. einen kompletten YANG-Library-Snapshot mit Rollen, Features, Deviations, module-set-ID und Zeitpunkt;
  4. Parser/Compiler, Diagnosen und normalisierten Fingerprint des effektiven Schemas;
  5. gültige wie absichtlich ungültige Instanzen gegen das eingefrorene Schema;
  6. Resolver-Traces unabhängiger Clients;
  7. Tests für Lesen, Ändern, RPC, Actions, Notifications, Fehler und Rollback;
  8. Beobachtung von intended und operational Datastores, wie sie RFC 8342 trennt, plus tatsächliche Wiederherstellung.

Diese Stufen sind kumulativ. Ankündigung, aufgelöstes Artefakt, Validierung und Betrieb liegen auf verbundenen, aber nicht austauschbaren Realitätsebenen.

Der Draft löst somit ein präzises Problem: unnötige Kaskadenkonvertierung. Den Nachweis des effektiven Clientvertrags nimmt er niemandem ab.

Quellen