Zusammenfassung

  • recommended-min-version vergleicht nur die Zahlen für Haupt-, Neben- und Patchversion. Revision 28 des YANG-Semver-Entwurfs blendet _compatible, _non_compatible sowie Vorab- und Build-Metadaten dabei aus.
  • Auch eine höhere Hauptversion kann genügen. Findet der Compiler keinen geeigneten Kandidaten, darf er warnen und nach RFC 7950 fortfahren. Eine abgeschlossene Auflösung beweist daher weder die Erfüllung der Empfehlung noch Clientkompatibilität.
  • Vor dem Einsatz sollte ein Auflösungsbeleg Anfrage, Kandidaten, ignorierte Angaben, ausgewählte Bytes, vollständigen Modulsatz, Features, Abweichungen, Warnungen, Clienttests, Entscheidungsverantwortung und Rücksprungziel verbinden. Der Beleg ist Daniel Kades Vorschlag, keine IETF-Anforderung.

Das Wort „mindestens“ übernimmt unbemerkt die Freigabe

In einer Sicherheitsrichtlinie zieht eine Mindestversion eine harte Linie. In einer Beschaffung gilt ein höherer Wert meist als besser. Bei Softwareabhängigkeiten klingt „mindestens 3.1.0“ deshalb wie das Versprechen, jede spätere passende Ausgabe enthalte die benötigte Fähigkeit und bleibe innerhalb einer bekannten Verträglichkeitsordnung.

draft-ietf-netmod-yang-semver-28 verspricht das nicht. Die am 21. Juli 2026 veröffentlichte Revision ist ein aktiver Internet-Draft für den Standards Track und liegt in der RFC-Editor-Warteschlange; ein RFC ist sie noch nicht. Ihre Erweiterung recommended-min-version steht unter einer YANG-import-Anweisung und nimmt genau drei Zahlen entgegen.

Ein Kandidat genügt, wenn sein Zahlentripel identisch ist, sein Patch bei gleicher Haupt- und Nebenversion höher liegt, seine Nebenversion innerhalb derselben Hauptversion höher liegt oder seine Hauptversion größer ist. Kompatibilitätsmodifikatoren und Metadaten spielen für diesen Vergleich keine Rolle. Der Entwurf nennt den entscheidenden Fall ausdrücklich: Bei 3.1.0 bestehen auch 3.1.2 _non_compatible und 4.1.2 den Test.

Beide Versionsangaben tragen Warnsignale. Das Suffix benennt einen nicht rückwärtskompatiblen Bruch im Zweig. Die höhere Hauptversion steht nach den YANG-Semver-Regeln ebenfalls für nicht rückwärtskompatible Änderung. Der Mindestvergleich lässt sie dennoch zu.

Das ist eine gewollte Arbeitsteilung. Der Text hält die Importauflösung bewusst einfach und erwartet die Verantwortung für einen kohärenten Satz von Modulversionen außerhalb dieser Erweiterung, etwa in YANG Packages. Der Resolver entscheidet numerische Zulässigkeit. Ob ein bestimmter Controller mit dem Ergebnis umgehen kann, ist eine andere Entscheidung.

Wenn ein Buildsystem beide Aussagen unter „minimum satisfied“ zusammenführt, erzeugt es eine Garantie, die weder der Autor noch der Standard ausgesprochen hat.

Versionssemantik ist wertvolle Evidenz, aber kein Testurteil

YANG Semver macht die Entwicklung eines Modells besser lesbar. Eine höhere Hauptversion kennzeichnet einen nicht rückwärtskompatiblen Schritt auf der Hauptlinie. Eine höhere Nebenversion beschreibt im Regelfall eine kompatible Erweiterung innerhalb derselben Hauptversion. Ein Patch ohne Modifikator ist redaktionell. Die YANG-spezifischen Suffixe erlauben begrenzte Wartungszweige; _non_compatible bleibt im Zweig erhalten, damit eine spätere redaktionelle Änderung den früheren Bruch nicht unsichtbar macht.

Auch die Identitätsregel ist stark: Name und semantische Version eines Artefakts müssen gemeinsam genau eine Revision bestimmen. Unterschiedlicher Inhalt darf dieses Paar nicht wiederverwenden. Das schafft nachvollziehbare Veröffentlichungsidentität.

Die Kennzeichnung beschreibt jedoch die Absicht des Modellautors gemäß einer Regel. Sie führt keinen unbekannten Verbraucher aus. Eine formal rückwärtskompatible neue Identität kann einen Client treffen, der eine offene Menge wie eine geschlossene behandelt. Ein zusätzlicher Knoten kann einen Fehler im Codegenerator offenlegen. Eine Anwendung kann auf Reihenfolge oder Beschreibung vertrauen, obwohl beides nie ihr Vertrag war. Eine korrekte Modulklassifikation heilt keine stillen Clientannahmen.

Selbst der Hash einer einzelnen Datei ist nicht der ganze Gegenstand. Der Entwurf weist darauf hin, dass sich die Bedeutung eines Submoduls drastisch ändern kann, obwohl sich dessen Inhalt und Revision nicht ändern: Ein anderes Submodul kann ein verwendetes Grouping oder einen Typ verändert haben. Der Hash fixiert die Datei, nicht das wirksame Gesamtschema.

Eine semantische Version ist deshalb strukturierte Herkunftsevidenz. Sie ist kein kryptografischer Inhaltsnachweis, keine Sperrdatei, kein Konformitätstest und keine Betriebsfreigabe.

Drei Erfolgszustände dürfen nicht dieselbe Farbe haben

Der erste Zustand ist die Erfüllung der Empfehlung. Ein sichtbarer Kandidat bestand die numerischen Regeln. Um diese Wahl später zu reproduzieren, muss der gesamte damalige Kandidatenbestand erhalten bleiben. Eine neu im Repository auftauchende Revision kann den Gewinner ändern, obwohl das importierende Modul unverändert ist.

Der zweite Zustand ist der Abschluss nach Rückfall. Findet ein Compiler keinen nach der Erweiterung geeigneten Kandidaten, soll er warnen und anschließend nach den etablierten Regeln von RFC 7950 weiterarbeiten. Dort bindet revision-date an eine bestimmte Revision; fehlt die Angabe, ist die verwendete Revision sprachlich nicht auf dieselbe Weise festgelegt. Ein Schema kann also nach einer Warnung entstehen, ohne dass die Semver-Empfehlung erfüllt wurde.

Der dritte Zustand ist die Einsatzfreigabe. Der exakte aufgelöste Satz wird gegen die Controller, Agenten, Sammler, Generatoren, Konfigurationen und Betriebsabläufe geprüft, die ihn tatsächlich verwenden. Ein Änderungsverantwortlicher bewertet Testabdeckung, Restunsicherheit und Rückweg.

Ein numerisch zulässiges Modul kann für eine alte Bibliothek unlesbar sein. Ein Rückfall kann einen Typ liefern, der älter ist als die vom Autor vorausgesetzte Abhängigkeit. Das Schema kann kompilieren, während ein aktiviertes Feature dem Client neue Äste zeigt. Ein gemeinsames grünes Buildzeichen verschleiert, ob die Suche gelang, die Kompilierung nur fortgesetzt wurde oder der Betrieb nachweislich tragfähig ist.

Kompatibel sein muss der aufgelöste Schemakontext

RFC 8525 liefert den größeren Rahmen. Ein Datastore besitzt ein Schema, das sich aus Modulsätzen zusammensetzt. Darin stehen implementierte Module, reine Importmodule und Submodule; bei implementierten Modulen kommen unterstützte Features und Deviation-Module hinzu. Ändert sich der Inhalt der YANG Library, ändert sich deren content-id.

Zwei Systeme mit derselben Basismodulrevision können deshalb verschiedene Verwaltungsoberflächen besitzen. Eine Deviation kann einen erwarteten Knoten einschränken oder entfernen. Ein Feature kann einen bislang fehlenden Ast öffnen. Ein reines Importmodul kann Typen verändern, die mehrere übergeordnete Modelle verwenden. Die Entscheidungseinheit ist größer als die Gewinnernummer eines Imports.

Der YANG-Packages-Entwurf organisiert solche Einheiten als versionierte Hierarchie. Ein Package kann andere Packages, implementierte Module, Importmodule und Features einschließen und geerbte Module oder Features ausschließen. Bei Konflikten können die Auflösungsregeln automatisch die spätere Revision wählen, was einen Hotfix erleichtert. Für eine ältere Version ist dagegen eine explizit verfeinernde Package-Komposition nötig.

Packages stärken die Kohärenz, sind aber nicht allein schon ein universelles Zertifikat. Der Entwurf erlaubt unvollständige Packages für Hotfixes oder logische Gruppierungen; Abhängigkeiten können erst in der Zielumgebung festgelegt werden. Wird eine Package-Komposition an ein Datastore-Schema gebunden, muss das Ergebnis einschließlich zusätzlicher Features genau dem YANG-Library-Modulsatz entsprechen und referenziell vollständig sein. Das beweist eine Zusammensetzung, nicht das Verhalten eines konkreten Clients.

Ein Schemavergleich misst Änderung, nicht Wirkung

Der Entwurf zu YANG Schema Comparison kann Unterschiede zwischen zwei Schemata maschinenlesbar beschreiben. Das ist belastbarer als eine Beurteilung allein anhand der Versionsnummer: Geänderte Statements und ihre Klassifikation werden sichtbar.

Der Vergleich führt aber keine generierten Bindings eines Controllers aus. Er kennt weder die Zusatzvalidierung einer Anwendung noch die Annahme eines Skripts, ein Leaf sei immer vorhanden. Er beobachtet nicht, wie ein Sammler eine neue Identity behandelt oder wie eine Zustandsmaschine auf eine neue Notification reagiert. Ebenso wenig beweist er, dass ein Rollback Schema, generierten Code, persistierte Konfiguration und Gerätezustand gemeinsam zurückbringt.

Kompatibilität ist eine Beziehung. Der aufgelöste Satz, der Client und dessen Version, die Last und die geprüften Annahmen müssen genannt werden. „Der Vergleich ist kompatibel“ bleibt ohne Ausgangsschema, Klassifikationspolitik und beobachtete Verbraucher unvollständig.

Der Auflösungsbeleg bewahrt, was der Algorithmus verwirft

Ein Auflösungsbeleg beginnt beim importierenden Modul: Name, exakte Revision, vollständige semantische Version, Inhalts-Hash und Quelle. Das angeforderte Zahlentripel wird wörtlich gespeichert. Danach folgt jeder für das Werkzeug sichtbare Kandidat mit vollständigem Versionsstring, Ort und Hash. Der Algorithmus darf _non_compatible beim Sortieren ignorieren; die Governance darf es nicht vergessen.

Für den Gewinner werden exakte Bytes oder ein stabiler Digest, Revisionsdatum, Version und Abrufherkunft festgehalten. Anschließend wird der gesamte Satz entfaltet: eingeschlossene und ausgeschlossene Packages, implementierte und reine Importmodule, Submodule, Features, Deviations, Mount-Kontext und content-id. Der Beleg nennt die Vollständigkeit der Packages, lokal aufgelöste Abhängigkeiten und die Regel, die jeden Konflikt entschied.

Auch das Werkzeug gehört zur Beweiskette. Compiler oder Resolver und deren Version werden genannt, Warnungen bleiben erhalten, Semver-Erfüllung und RFC-7950-Rückfall werden getrennt. Ein Schemavergleich enthält Ausgangspunkt, Politik und Ergebnis, ohne zum Clientzertifikat umgedeutet zu werden.

Zum Schluss folgt die Verbraucherseite: Versionen getesteter Controller, Agenten, Generatoren und Sammler; repräsentative Konfigurationen, RPCs, Notifications und Zustandspfade; Fehlschläge; verantwortliche Risikoannahme; Umfang und Ablauf der Freigabe; der genaue alte Satz für den Rücksprung. Ein Labortest erteilt nicht automatisch jedem Nutzer desselben Repositories eine Freigabe.

Der Beleg überlädt die Importerweiterung nicht. Er verhindert vielmehr, dass eine Organisation deren begrenzte Aufgabe zur umfassenden Garantie umdeutet.

Quellen