Zusammenfassung

  • draft-ietf-netmod-yang-schema-comparison-09 vergleicht geparste Anweisungen ebenso wie den effektiv kompilierten Datenbaum und ordnet Änderungen als redaktionell, rückwärtskompatibel oder nicht rückwärtskompatibel ein.
  • Das Ergebnis unterstützt Review, semantische Versionierung und Konvertierungsplanung. Es beweist weder identische Eingaben noch verlustfreie Migration, Implementierungsinteroperabilität, stabile NACM-Regeln, eine sichere Rollout-Reihenfolge oder operative Konvergenz.

Ein kurzer Diff verführt zu einer langen Schlussfolgerung. Aus „keine inkompatible Änderung gefunden“ wird im Change-Antrag „freigegeben“ und im Dashboard „erfolgreich aktualisiert“. Dabei hat das Werkzeug weder einen Konverter noch einen Client, Server, Zugriffspfad oder eine laufende Anlage gesehen. Es hat eine klar begrenzte Schemafrage beantwortet.

Revision 09 erschien am 3. Juli 2026. Der IETF Datatracker führt sie als aktiven Internet-Draft der NETMOD-Arbeitsgruppe, nicht als RFC. Die aktuelle Validierungsübersicht zeigt null Fehler und null Warnungen. Das beschreibt Dokument- und Werkzeugzustand, nicht Verbreitung, Interoperabilität oder Produktionswirkung.

Das Experiment umfasst Parsing und Kompilierung

Der Entwurf trennt parsed schema und compiled schema. Die geparste Form entspricht weitgehend dem geladenen Anweisungsbaum, bevor alle Verweise und Transformationen aufgelöst sind. Die kompilierte Form bildet das effektive Modell: Imports und Submodule werden einbezogen, uses und typedef aufgelöst, augment, deviation und refine angewandt und aktivierte if-feature-Ausdrücke ausgewertet.

Beide Sichtweisen schließen unterschiedliche Lücken. Eine kleine typedef-Änderung kann viele Leaves erreichen. Ein Augment aus einem fremden Modul kann Knoten einfügen. Eine herstellerspezifische Deviation kann eine Einschränkung ändern, obwohl die Zieldatei unverändert bleibt. Reiner Quelltext verfehlt den effektiven Baum; nur der Baum verfehlt Anweisungsänderungen, die für Autoren und Importer relevant sind.

Revision 09 meldet deshalb zuerst Änderungen an kompilierten Datenknoten und vergleicht danach die übrigen geparsten Anweisungen, ohne Knoten doppelt zu zählen. Die Kompilierungsidentität enthält Namen und Revisionen der alten und neuen Module, eingebundene Submodule, aktive Features und rekursive Imports.

Ein leerer Diff gilt nur für genau diese Eingaben. Ein anderes Feature, eine andere Importrevision, eine Deviation oder ein anderes Submodul definieren einen neuen Versuch. Quell-Hashes und vollständige Kompilierungsidentität gehören in den ersten Beleg.

Drei Klassen mit nachvollziehbarer Herkunft

Jede Änderung wird ED, BC oder NBC. Redaktionell darf weder den gültigen Datenraum ändern noch importierende Module ungültig machen. Rückwärtskompatibel darf den gültigen Raum erweitern, ohne Importer zu brechen. Alles, was ihn einschränkt oder einen Importer gefährdet, ist nicht rückwärtskompatibel.

Die Regeln erfassen auch wenig intuitive Brüche. uint32 durch uint64 zu ersetzen erweitert den Zahlenbereich, ändert nach RFC 7951 aber die JSON-Darstellung von einer Zahl zu einer Zeichenkette. Für einen Client ist das ein Typbruch; die Änderung kann NBC sein.

Änderungen an pattern, when und must sind standardmäßig NBC. description, reference und presence sind standardmäßig ED, eine Erweiterungsinstanz BC. Autoren dürfen die Vorgabe mit dauerhaften Semver-Markierungen ed-change-at, bc-change-at oder nbc-change-at überschreiben.

Eine solche Überschreibung macht Urteil sichtbar, nicht wahr. Ein Review sollte feste Regel, Standardannahme und manuelle Einstufung auseinanderhalten und Begründung sowie Genehmigung festhalten. Das Versionslabel bleibt eine verantwortete Aussage, keine Messung des Einsatzes.

BC heißt nicht unverändertes Verhalten

Ein optionales Leaf kann rückwärtskompatibel ergänzt werden und dennoch Systeme verändern: Server befüllen es, Clients serialisieren es, Richtlinien lesen es, Oberflächen zeigen es an. Ein neuer Default kann effektives Verhalten ohne Änderung der gespeicherten Konfiguration verschieben. when, must, Features und Deviations ändern Prüfpfade und das gerätespezifische Modell.

Der Vergleich führt keine RPCs aus, spielt nicht alle Konfigurationen ein und beobachtet keine Clients. RFC 8525 identifiziert die vom Server gemeldete YANG Library mit Modulen, Features und Deviations. Deren content-id beweist nicht, dass der Server jede Regel korrekt ausführt.

NACM nach RFC 8341 ist eine weitere unabhängige Fläche. Gruppen, Regeln und Default-Deny können Sicht- und Schreibrechte ohne Schemaänderung verschieben. Deshalb braucht die Produktionsaussage Tests der wirksamen Rollenmatrix.

Konvertierung braucht eine Verlustrechnung

Der Entwurf sagt, dass der Diff Werkzeuge bei der Überführung alter Instanzdaten unterstützen kann. Das Werkzeug entscheidet dennoch, welche Knoten entfernt, abgebildet, normalisiert, durch Defaults ergänzt, synthetisiert oder abgelehnt werden.

RFC 9195 liefert ein brauchbares Muster für Inhaltsidentität und Herkunft. Ein Konvertierungsbeleg sollte Hash und Schema der Quelle mit Version und Regelsatz des Konverters verbinden. Er zählt entfernte, ergänzte, normalisierte und abgelehnte Knoten, hasht das Ergebnis, validiert gegen das neue kompilierte Schema und dokumentiert Roundtrip- oder semantische Invarianten.

Gültigkeit im Zielschema ist nicht Gleichheit der Bedeutung. Wenn zwei alte Zustände in einen neuen fallen, ist Information verloren. Die Entscheidung darüber gehört dem Dateneigentümer.

Die weiteren Tore müssen ausgeführt werden

Danach folgen Implementierungstests: unabhängige Parser oder Server, wenn Interoperabilität zählt; repräsentative Konfigurationen und RPCs; Fehlerkennungen, Defaults, kanonische Kodierungen, Feature-Aushandlung und betroffene NACM-Rollen. Binärdateien, Module, Optionen und Testvektoren müssen reproduzierbar gebunden sein.

Auch die Rollout-Reihenfolge braucht einen Test. Während einer schrittweisen Umstellung treffen alte Clients auf neue Server und umgekehrt; Nachbarn können unterschiedliche Feature- oder Deviation-Sätze haben. Der Diff bestimmt nicht, wer zuerst umgestellt wird, garantiert keine lückenlose Telemetrie und beweist nicht, dass eine alte Version neue Daten für ein Rollback lesen kann.

Schließlich trennt RFC 8342 running, intended und operational, weil Konfiguration, angewandte Absicht und beobachteter Zustand auseinanderfallen können. Nur der laufende Einsatz zeigt Konvergenz, Alarme, Leistung und externe Wirkung.

Revision 09 macht Schemareviews reproduzierbar und zurechenbar. Ihre Stärke bleibt erhalten, wenn der klassifizierte Diff als erster Beleg behandelt wird — nicht als Ersatz für alle folgenden.

Quellen

Primärquellen: YANG Schema Comparison, Revision 09; IETF Datatracker; YANG 1.1, RFC 7950; YANG Library, RFC 8525; NMDA, RFC 8342; NACM, RFC 8341; YANG Instance Data, RFC 9195; YANG Semantic Versioning, Revision 28; YANG Module Versioning, Revision 16. Zeitfolge: Datatracker-Revisionsverlauf.