Zusammenfassung

  • Die IESG gab am 18. August 2026 die Annahme von draft-ietf-netmod-yang-semver-28 als Proposed Standard bekannt. Der Entwurf versieht YANG-Module mit semantischen Versionskennungen, die optional auch über YANG Library sichtbar werden.
  • Die Kennung beschreibt, wie der Autor die Beziehung zweier Modulartefakte einordnet. Sie beweist weder einen kohärenten Modulsatz noch aktivierte Features, fehlende Abweichungen oder korrektes Verhalten auf einem Ziel. Dafür braucht eine Freigabe das vollständige wirksame Schema und Laufzeitbelege.

Eine Empfehlung ist keine Änderungsbefugnis

Der Einstieg ist ein hypothetischer Kontrollfehler, kein gemeldeter Herstellerdefekt. recommended-min-version nennt die älteste kompatible Version, die ein Verbraucher bevorzugt. Verglichen werden nur drei Zahlen; Kompatibilitätszusatz sowie Vorab- und Buildangaben bleiben außen vor.

Damit kann eine höhere Hauptversion die Untergrenze erfüllen, ebenso eine Fassung mit _non_compatible. Findet der Compiler keine passende Wahl, soll er warnen und mit der normalen YANG-Importauflösung fortfahren. Das Feld ist bewusst ein Hinweis statt einer Sperre.

Wer aus „Untergrenze erfüllt“ unmittelbar „Produktion freigegeben“ macht, fügt dem Hinweis eine Entscheidung hinzu, die weder der Modulauthor noch das Zielsystem getroffen hat.

Der Standard macht Abstammung maschinenlesbar

Die angenommene Fassung 28 befindet sich noch in der Warteschlange des RFC Editor. Sie stammt aus NETMOD; die IESG-Mitteilung vermerkt allgemeinen Konsens mit etwas Widerspruch und noch entstehende Werkzeuge.

ysv:version folgt X.Y.Z_COMPAT und kann Vorab- sowie Buildinformationen tragen. Eine höhere Hauptversion steht gewöhnlich für eine nicht rückwärtskompatible Änderung, eine höhere Nebenversion für eine kompatible Ergänzung und ein Patch für kompatible redaktionelle Änderungen.

Modulname und semantische Version identifizieren zusammen eine bestimmte Revision und ihren Inhalt. Abhängigkeiten und Herkunft werden damit genauer als durch ein Datum allein. Ein Server kann die von ihm beanspruchte Version in YANG Library ausweisen.

Das verbessert Herkunftsnachweise. Es bescheinigt nicht, welches Gesamtschema das Ziel tatsächlich anbietet oder wie dessen Software eine Änderung ausführt.

Kompatibilität bleibt eine Einordnung des Maintainers

Autoren oder Maintainer vergeben die Nummer. Die Regeln erlauben einen größeren Sprung als unbedingt nötig und das Überspringen von Fassungen. Es handelt sich nicht um einen unabhängig auf dem Ziel gemessenen Wert.

Der Entwurf sagt ausdrücklich, dass die Nummer weder das Stattfinden der beschriebenen Änderung noch ihre Wirkung auf einen bestimmten Verbraucher garantiert. Konkrete Unterschiede gehören in einen Schemavergleich; konkrete Folgen in Instanzprüfung und Implementierungstest.

Ein isoliert kompatibles Modul kann Teil eines unpassenden Gesamtschemas sein. Ein fremdes Modul kann es erweitern, ein Feature kann ausgeschaltet sein, eine Abweichung kann einen Knoten entfernen oder einschränken. Die Versionsaussage bleibt wahr, obwohl der Controller einen anderen wirksamen Baum vorfindet.

Der inkompatible Zweig behält seine Narbe

_compatible und _non_compatible kennzeichnen begrenzte Entwicklungszweige. Sobald _non_compatible innerhalb desselben Haupt- und Nebenzweigs erscheint, darf es später dort nicht verschwinden oder wieder als kompatibel ausgegeben werden.

Die Regel bewahrt Geschichte. Deshalb müssen Belegsysteme die vollständige Kennung speichern und dürfen sie nicht auf drei Zahlen reduzieren.

Die empfohlene Untergrenze betrachtet hingegen nur die Zahlen. Soll ein markierter Zweig ausgeschlossen werden, braucht die Organisation eine eigene, ausdrücklich dokumentierte Regel nach der Artefaktauflösung.

Das Ziel besteht aus einem Modulsatz

YANG Library beschreibt Module und Revisionen, reine Importmodule, Submodule, aktivierte Features, Abweichungen und Fundorte. Die semantische Version ergänzt dieses Inventar, ersetzt es aber nicht.

Der Entwurf erklärt die Bildung eines kohärenten Modulsatzes zur Aufgabe außerhalb der Erweiterung und verweist auf benachbarte Arbeit wie YANG Packages. Zwei Server mit derselben Kernmodulversion können daher verschiedene wirksame Schemata haben.

RFC 7950 definiert das Zusammenspiel von Imports, Erweiterungen, Features und Abweichungen. RFC 8525 erschließt den Zielbestand, RFC 9907 Revisionskennungen. Keines davon testet Binärprogramm, vorhandene Daten oder Produktionswirkung.

Freigabe braucht eine nachvollziehbare Kette

Zu protokollieren sind Anforderung, aufgelöstes Artefakt und Hash, vollständige Version, YANG-Library-Schnappschuss, Hash des wirksamen Schemas, Vorher-nachher-Vergleich, Datenvalidierung, Implementierungstest, Software- und Konfigurationsklasse sowie der Verantwortliche für das Restrisiko.

Eine verfehlte Untergrenze ist Auswahlproblem, ein inkompatibler Zusatz Abstammungspolitik, ein fehlendes Feature oder eine Abweichung Zielschemaproblem, eine Laufzeitregression Implementierungsproblem und fehlende Zustimmung Governanceproblem. Diese Unterschiede bestimmen die richtige Reaktion.

Die Nummer darf früh Kandidaten aussortieren. Die letzte Schranke gehört dem kompilierten Ziel, dem laufenden Code und demjenigen, der die Folgen trägt.

Quellen