Zusammenfassung

  • Der IESG gab am 18. August 2026 die Genehmigung von draft-ietf-netmod-yang-module-versioning-17 zur Veröffentlichung als Proposed Standard bekannt. Der Text erlaubt dokumentierte, nicht rückwärtskompatible Modulentwicklung, ergänzt recommended-min-date bei Imports und macht den Umgang mit deprecated und obsolete Nodes sichtbar.
  • Im eigenen Verzweigungsbeispiel erfüllt die Revision 2019-05-01 ein Mindestdatum 2019-04-01, obwohl ihr der Inhalt des Zweigs von 2019-04-01 fehlen kann. Ein Datum ordnet Artefakte; es belegt weder Abstammung noch das wirksame Zielschema oder die Befugnis zur Einführung.

Das Datumstor ließ den Schwesterzweig passieren

Der Einstieg ist eine analytische Konstruktion aus dem Beispiel des Dokuments, kein gemeldeter Vorfall bei einem Gerät, Hersteller oder Netz. Der Resolver tut genau, was recommended-min-date verlangt: Er nimmt eine Revision mit gleichem oder späterem Datum.

Nach der gemeinsamen Revision 2019-02-01 teilt sich die Geschichte. Ein Zweig führt über 2019-03-01 zu 2019-05-01, der andere über 2019-04-01 zu 2019-06-01. Benötigt ein Verbraucher eine am 2019-04-01 eingeführte Fähigkeit, kann er diesen Tag als Untergrenze nennen. Rechnerisch besteht 2019-05-01. Genealogisch liegt es auf dem anderen Ast.

Der Entwurf warnt ausdrücklich, dass 2019-05-01 den gewünschten Inhalt von 2019-04-01 möglicherweise nicht enthält. Das Feld sei für verzweigte Verläufe ungeeignet und vor allem bei linearer Entwicklung hilfreich. „Später“ bezeichnet eine Kalenderposition; „davon abgeleitet“ bezeichnet einen Pfad im Graphen.

Die Genehmigung macht inkompatible Kanten sichtbar

„Updated YANG Module Revision Handling“ ist ein NETMOD-Arbeitsprodukt. Es bleibt ein Internet-Draft in der Warteschlange des RFC Editor und kann vor der Veröffentlichung redaktionell geändert werden. Laut Mitteilung ist der Implementierungsstand unbekannt; eine allgemeine Produktunterstützung lässt sich daraus nicht ableiten.

RFC 7950 verlangte streng rückwärtskompatible Aktualisierungen. Der neue Text erkennt an, dass eine Fehlerbehebung reales Serververhalten abbilden, ein obsolete Node nach dem Übergang verschwinden oder instabiles Material neu geordnet werden muss. Solche Brüche bleiben unerwünscht und sollen minimiert werden.

Enthält eine Revision gegenüber ihrem Elternstand eine nicht rückwärtskompatible Änderung, muss rev:non-backwards-compatible unter der revision-Anweisung stehen. Damit wird eine zuvor stumme Kante prüfbar. Das Zeichen beschreibt aber nur diese Eltern-Kind-Beziehung; es weist keinen Weg vom benötigten Zweig zum Kandidaten nach.

Eine unveränderliche Identität ist noch keine Abstammung

Innerhalb ihrer Geschichte bezeichnen Modulname und Revisionsdatum eine bestimmte unveränderliche Definition. Diese Identitätsfunktion ist stark, aber keine Linienfunktion. Der Entwurf erklärt, dass sich Abstammung zwischen Modul- oder Submodulrevisionen nicht allein aus Datum oder Versionskennung ermitteln lässt; dafür muss die Historie gelesen werden.

Bei Submodulen entsteht eine weitere Lücke. Beschränkt include die Revision nicht exakt, beweist das einschließende Modul nicht, welcher Submodulinhalt verwendet wurde. Ein genaues revision-date, YANG Library oder ein Paketbestand muss den Kontext liefern.

Eine Zulassungsakte braucht daher Artefakthash, Elternbeziehung oder Zweigpfad, Submodulrevisionen und den am Ziel aufgelösten Modulsatz. Auch ein unveränderlicher Bezeichner kann in den falschen Stammbaum eingeordnet werden.

Das empfohlene Mindestdatum vermeidet absichtlich eine harte Bindung

recommended-min-date ist eine optionale Unteranweisung von import und darf dort höchstens einmal vorkommen. Eine importierte Revision folgt der Empfehlung, wenn ihr Datum gleich oder später ist. Hinzufügen, Ändern oder Entfernen gilt selbst als rückwärtskompatibel. Parser ohne Kenntnis der Erweiterung fahren nach RFC 7950 fort.

Wo eine Abhängigkeitsuntergrenze sinnvoll ist, empfiehlt der Entwurf diesen Hinweis statt eines exakten import revision-date, weil das genaue Datum eine zu starre Abhängigkeit erzeugt. Spätere kompatible Arbeit kann so aufgenommen werden, ohne ein Artefakt festzuschreiben.

Die lose Kopplung braucht jedoch eine getrennte Eignungsprüfung. Das Feld fragt nicht, ob der Kandidat vom benötigten Stand abstammt, einen Node behält, dieselben Vorgaben nutzt oder für den Client taugt. Das Datum öffnet die Kandidatensuche; Historie und wirksames Schema schließen sie.

Der Inkompatibilitätshinweis gehört auf eine Kante

rev:non-backwards-compatible kann anzeigen, dass ein Node obsolete wurde, eine Einschränkung wechselte oder ein anderer zulässiger Bruch entstand. Es bescheinigt nicht die Beziehung zu jedem anderen Punkt einer verzweigten Geschichte.

Ein Dashboard, das Beweise auf jüngstes Datum und Warnsymbol reduziert, verliert diese Trennung. Die abhängige Fähigkeit kann auf einem Nachbarzweig entstanden sein. Kein Warnsymbol in der gewählten Zeile erschafft keine fehlende Ahnenkante.

Pflegende dürfen das Zeichen auch bei formal kompatiblen Änderungen setzen, deren Clientwirkung erheblich sein kann, etwa bei einem größeren Wertebereich eines operativen Leafs. Es ist ein konservatives Prüfsignal, kein automatischer Entscheid. Schemavergleich beschreibt die Änderung; Tests am Ziel zeigen ihre praktische Wirkung.

Mit gekürzter Historie schrumpft der Beweisraum

Einige veröffentlichte revision-Anweisungen dürfen entfernt werden, um sehr lange Verläufe zu kürzen oder alte Imports zu entmutigen. Der jüngste Eintrag muss bleiben, und verbleibende Inkompatibilitätsmarker müssen die Beziehungen zwischen den behaltenen Einträgen weiterhin richtig beschreiben.

Der Text rät von Kürzungen ab, weil sie den Zeitpunkt eines Bruchs verdecken können. Ein Zwischeneintrag darf nicht entfallen, wenn eine spätere Revision dadurch über einen verborgenen inkompatiblen Schritt hinweg kompatibel mit einer älteren erscheinen würde.

Historie ist damit Betriebsbeweis. Fehlt die notwendige Kante im Standardverlauf, müssen Artefaktspeicher, signierte Hashes, Paketlisten und Änderungsakten die rekonstruierbare Kette bewahren. Eine kosmetische Bereinigung kann die Grundlage späterer Zulassung löschen.

Node-Status ist eine Tatsache des Zielsystems

Das neue ietf-yang-library-status erweitert YANG Library um zwei Boolesche Werte. deprecated-nodes-implemented gleich true bedeutet, dass deprecated Nodes wie current implementiert sind, sofern keine deviation sie entfernt. obsolete-nodes-absent gleich true bedeutet, dass der Server keine obsolete Nodes implementiert.

Beide Werte sind standardmäßig false; false heißt hier unbekanntes Verhalten, nicht das gesicherte Gegenteil. Der Entwurf empfiehlt true für beide, damit Clients das genaue Schema bestimmen können. Ohne die erste Zusage dürfen sie Kompatibilität nicht nur aus den Markern ableiten.

Auch der richtige Zweig kann daher am Ziel anders aussehen: Ein deprecated Node kann fehlen, ein obsolete Node noch vorhanden sein, eine deviation kann weitere Unterschiede schaffen. Die Lebenszyklusführung geht von current über deprecated zu obsolete. Clients sollen den Ausstieg aus deprecated Nodes planen und obsolete Nodes nicht mehr verwenden. Das ist Migration, kein Kalendermerkmal.

Zulassung braucht Graph und laufendes Ziel

Eine belastbare Steuerung zeichnet die benötigte Fähigkeit und ihre Ursprungsrevision auf, löst das genaue Artefakt, beweist den Elternpfad, erhält inkompatible Kanten und Lücken, fixiert Submodule, erfasst YANG Library und beide Statuswerte, wendet deviations an, baut das wirksame Schema und prüft Beispieldaten.

Danach testet sie den Client gegen tatsächliche Serversoftware und Konfigurationsklasse. Eine inkompatible Revision kann Werte außerhalb der Annahmen alter Clients liefern, Vorgaben ändern oder angepasste NACM-Regeln erfordern. Ein Datum sieht diese Folgen nicht.

Fehlerarten müssen getrennt bleiben: ein Schwesterzweig ist ein Linienfehler, fehlender Status eine Erkennungslücke, ein anderer Baum ein Schemafehler, unerwarteter Wert oder Vorgabe eine Implementierungsfolge und fehlende Freigabe ein Governancefehler. Chronologie wählt Kandidaten. Bewiesene Abstammung, genauer Zielzustand, Laufzeittest und benannter Verantwortlicher entscheiden über den Einsatz.

Quellen