Zusammenfassung

  • Ein aktiver NETCONF-Entwurf ergänzt YANG-Push um eine exakte Modulrevision oder eine kompatible semantische Version und nimmt Modulversion sowie YANG-Library-content-id in die Lebenszyklusmeldungen auf.
  • Damit lässt sich ein Teil der Schema-Drift ablehnen oder erkennen. Unbewiesen bleiben importierte Abhängigkeiten, das tatsächlich geladene Empfängerschema, die Bedeutung nach Transformation, die Handlungsbefugnis und die beobachtete Wirkung im Netz.

Ausfallüberwachung bevorzugt sichtbare Brüche. Keine Nachrichten, wachsender Rückstand und eine neue Verbindung liefern klare Signale. Semantische Drift kann dagegen in einem äußerlich gesunden Dienst leben. Die Zahl kommt pünktlich an; nur der Vertrag, der Einheit, Typ und Bedeutung festlegt, ist ein anderer geworden.

Bei YANG-Push haben Abonnement und Schema-Bibliothek getrennte Lebenszyklen. Das Abonnement legt Auswahl und Übertragungspolitik fest. Die aktiven YANG-Module, Revisionen, Imports, Identities und Deviations prägen die gelieferten Werte. Eine gespeicherte Subscription kann Neustart und Software-Upgrade überstehen, während sich die Bibliothek ändert.

Genau diese Lücke behandelt draft-ietf-netconf-yang-notifications-versioning-16 vom 17. September 2026. Der Datatracker führt ihn als aktiven Internet-Draft der NETCONF Working Group, dem IESG für Proposed Standard vorgelegt und bis 29. September in IETF Last Call. Er ist kein endgültiger RFC und kein Produktnachweis.

Der Entwurf macht eine bisher stillschweigende Annahme beobachtbar. Ein Client kann eine Revision oder einen kompatiblen Versionsbereich verlangen. Der Publisher kann eine unerfüllbare Bedingung begründet zurückweisen. Start und Änderung des Abonnements tragen den wirksamen Versionszustand. So entsteht ein prüfbarer Übergang statt einer Vermutung.

Zwei Bedingungen mit unterschiedlichen Betriebskosten

revision bezeichnet ein bestimmtes Datum des Moduls. Die Bedingung eignet sich für streng reproduzierbare Abläufe. Fehlt die Revision beim Publisher, lautet die Antwort revision-unsupported; eine ähnliche Ausgabe darf sie nicht still ersetzen.

version verlangt die jüngste kompatible YANG Semantic Version. Damit kann das Modul innerhalb einer erklärten Grenze fortentwickelt werden. Fehlt ein passender Stand, gilt version-unsupported. Widersprechen sich revision und version in derselben Anfrage, dokumentiert incompatible-revision-and-version den Konflikt. Alle drei erscheinen als application-invalid-value-RPC-Fehler.

Eine feste Revision vereinfacht die Rekonstruktion, kann bei einem Upgrade aber absichtlich zum Stopp führen. Ein kompatibler Bereich verringert Koordination, setzt jedoch Vertrauen in die Klassifizierung der Änderung und in Tests des Verbrauchers voraus. Eine Anzeige für menschliche Analyse und ein autonomer Routing-Eingriff benötigen nicht dieselbe Toleranz.

Für konfigurierte Abonnements liegt eine weitere Grenze nach dem Neustart. Der Publisher vergleicht die gespeicherte Bedingung mit seiner aktuellen YANG Library. Passt sie nicht mehr, fordert der Entwurf subscription-terminated. Dauerhafte Konfiguration erzeugt keine dauerhafte Kompatibilität.

Wenn die Subscription starten oder weiterlaufen kann, enthalten subscription-started und subscription-modified Modulname, revision, optionale version und yang-library-content-id. Eine Änderung von Revision oder Version während der Laufzeit zählt als Policy-Änderung und muss subscription-modified auslösen.

Eine korrekte Meldung lädt kein korrektes Artefakt

Meldet der Publisher die verlangte Revision, ist das ein belastbarer, aber begrenzter Beleg. Er sagt, welchen Stand der Publisher dem eingeschränkten Modul zuordnet. Er lädt beim Collector keine Schema-Datei, erzeugt keine Bindings neu, startet keinen Worker und leert keinen Cache.

In einer realen Pipeline kann das Registry bereits die neue Datei besitzen, während ein Prozess noch alten generierten Code nutzt. Der Parser kann eine neue Identity akzeptieren, die Datenbank sie aber zu unknown reduzieren. Eine Transformation kann einen neuen Pfad schreiben, den die Alarmregel nie liest. Sämtliche Healthchecks bleiben grün, obwohl die Bedeutung auseinanderläuft.

Ein brauchbarer Laufzeitbeleg verbindet deshalb Publisher- und Receiver-Build, Subscription-ID, geforderte Bedingung, effektiven Modulsatz, Snapshot und Digest der YANG Library, Digest des geladenen Schemas, Decoder- und Transformationsversion sowie das Ergebnis eines eingefrorenen Replay-Korpus. Die Protokollrevision ist ein Feld darin, nicht die Gesamtaussage.

Running-Code Primacy stellt die entscheidende Frage: Was lief für diesen konkreten Datensatz? Die vom Datatracker am 28. September ausgewiesene YANG-Validierung des eingebetteten Moduls ietf-yang-push-revision ergab null Fehler und null Warnungen. Das ist gute Evidenz für das Modellartefakt unter diesen Werkzeugen. Es beobachtet keinen Router, Collector oder Entscheidungsprozess.

„Kompatibel“ ist eine Erklärung, kein universeller Testbericht

YANG Module Versioning und YANG Semantic Versioning liefern ein Vokabular für rückwärtskompatible und nicht rückwärtskompatible Änderung. Dadurch kann ein Abonnement einen sinnvollen Bereich angeben. Modulautoren kennen jedoch nicht jede zufällige Abhängigkeit jedes Verbrauchers.

Ein optionaler neuer Knoten kann einen Fehler im Codegenerator auslösen. Ein zusätzlicher Enum-Wert kann in einen gefährlichen Default-Zweig fallen. Ein erweiterter Wertebereich kann den Speicher überfordern. Eine formal kompatible Änderung kann Volumen oder Kardinalität so verändern, dass eine nachgelagerte Stufe versagt.

Die jüngste kompatible Version eröffnet deshalb eine Prüfung; sie schließt sie nicht. Der Receiver verfolgt die tatsächlich genutzten Imports und Identities, lädt die Kandidatenartefakte und spielt normale, grenzwertige und unbekannte Werte durch den produktiven Build. Solange ein hochwirksamer Pfad nicht belegt ist, werden Daten quarantänisiert oder Aktionen angehalten.

Nicht jede Differenz verlangt einen Komplettstopp. Zeigt ein abhängigkeitsbewusster Diff keinen Bezug zur Auswahl und bleibt das Replay stabil, kann die Verarbeitung fortgesetzt werden. Das gemeinsame Protokoll stellt ein kleines, verlässliches Signal bereit. Die lokale Entscheidung über Fortsetzen, Einschränken, Prüfen oder Beenden bleibt sichtbar.

Das importierte Modul ist die leise Abhängigkeit

YANG-Module übernehmen typedefs, groupings und identities aus anderen Modulen. Das direkt genannte Modul kann Revision und Version behalten, während sich eine importierte Grundlage ändert. Eine Prüfung nur des direkten Moduls sieht nicht die ganze Bedeutungskette.

Der content-id der YANG Library erweitert die Detektion. RFC 8525 beschreibt ihn als implementationsspezifischen Bezeichner für den aktuellen Bibliotheksinhalt. Ändert er sich, weiß der Empfänger, dass sich der Schema-Bestand des Geräts bewegt hat.

Der Hinweis ist absichtlich grob. Ein für die Auswahl belangloses Modul kann ihn verändern. Er nennt nicht die betroffene Abhängigkeit und ist kein universeller Hash zwischen Herstellern. Eine Änderung bedeutet „Bibliothek holen und vergleichen“, nicht „Subscription unbrauchbar“. Gleichheit unterstützt Kontinuität im Verhalten des Publishers, beweist aber keine vollständige semantische Identität.

Der sichere Ablauf lautet: Änderung entdecken, Vorher- und Nachher-Snapshot sichern, Imports in den Diff einbeziehen und den betroffenen Verbraucher testen. Nach jedem Wechsel alle Subscriptions zu beenden erzeugt unnötige Ausfälle. Den Wechsel zu ignorieren lässt die ursprüngliche Blindstelle bestehen.

Hier zeigt sich Minimum Initial Specification: Das Protokoll muss nicht jede lokale Risikoregel abbilden. Es benennt die direkte Bedingung und signalisiert eine breitere Bibliotheksbewegung. Der Receiver entscheidet mit dokumentierter lokaler Policy.

Eine modified-Meldung macht die Migration nicht atomar

Wenn subscription-modified eintrifft, können unter dem alten Schema erzeugte Daten noch unterwegs oder in einer Queue sein. Parallele Worker sehen das Ereignis möglicherweise in anderer Reihenfolge. Ein Metadatenkatalog kann den neuen Digest speichern, bevor jeder Prozess das neue Binding geladen hat.

Darum braucht der Übergang eine rekonstruierbare Grenze: letztes Element unter dem alten Artefakt, Position der Lebenszyklusmeldung und erstes akzeptiertes Element unter dem neuen. Zweifelhafte Daten kommen in Quarantäne und werden nach dem Laden erneut verarbeitet. Jede folgenreiche Ausgabe verweist auf Schema, Decoder und Transformation.

Auch subscription-terminated hat eine Grenze. Es belegt die Entscheidung des Publishers, eine nicht mehr passende Subscription nach Neustart nicht fortzuführen. Es belegt nicht, dass alte Queues geleert, Caches entwertet oder abgeleitete Aufgaben abgebrochen wurden. Diese Folgen müssen lokale Kontrollen nachweisen.

Die Capability yang-push-module-revision-supported ist ebenfalls eine Ankündigung. Sie hilft dem Client, ein Verfahren auszuwählen. Erst Tests mit Upgrade, Neustart, Verlust, Duplikat und Umordnung beweisen das Verhalten des laufenden Streams.

Ein lebender Stream steht am Anfang der Beweiskette

Eine saubere Kette trennt: aktiven Modulsatz des Publishers, Annahme der Bedingung, gemeldete Version, Reihenfolge der Zustellung, geladenes Schema, Decoding, Transformation, lokale Policy, Autorisierung, Ausführungsversuch und beobachtete Netzwirkung.

Keine Stufe leiht sich die Autorität der nächsten. Kontinuierliche Zustellung beweist keine richtige Auslegung. Richtige Auslegung verleiht keine Handlungsbefugnis. Autorisierung beweist keinen Commit. Eine beobachtete Änderung beweist nicht automatisch ihre Ursache.

Die Trennung der Reality Layers beschleunigt Diagnose. Ein geänderter content-id kann nach Diff und identischem Replay als folgenlos geschlossen werden. Bei gleicher Revision und anderer Entscheidung liegt die Suche beim Verbraucher. Eine technisch richtige, aber unbefugte Aktion ist ein Zugriffsproblem, kein Versionierungsfehler.

Gemeinsame IDs und Zeiten verbinden die Belege. Sie dürfen die Aussagen nicht verschmelzen. Jede Stufe dokumentiert Beobachtung und verbleibende Unsicherheit.

Wer die Versionsbedingung ändert, ändert eine sensible Policy

Die Befugnis, revision oder version zu ändern, beeinflusst den akzeptierten Bedeutungsraum. Damit lässt sich ein altes Modell festschreiben, beim nächsten Boot eine Beendigung auslösen oder der Bereich über getestete Grenzen hinaus erweitern. Das ist keine Darstellungspräferenz.

NETCONF und RESTCONF benötigen weiterhin geschützten Transport und geeignete gegenseitige Authentisierung. NACM begrenzt Zugriff auf Konfiguration und Zustand. Das Audit sollte Principal, Methode, alten und neuen Wert, Subscription, Bibliothekszustand und Freigabegrund enthalten. Ein Recovery-Prozess darf seine eigene Bedingung nicht lockern, nur um wieder grün zu werden.

Die Erlaubnis, Daten zu abonnieren, ist zudem nicht die Erlaubnis, auf ihrer Grundlage zu handeln. Am Entscheidungspunkt braucht es eine eigene Policy- und Autorisierungsprüfung.

Implementierungsangaben werden erst durch Tests belastbar

Der Entwurf nennt nach Angaben seiner Autoren unterschiedliche Teilimplementierungen in Huawei VRP, 6WIND VSR und Cisco IOS XR. Das zeigt Interesse und technische Machbarkeit. Es ist keine unabhängige Interoperabilitätsprüfung.

Eine Qualifikation testet unterstützte und fehlende Revision, fehlende Version, widersprüchliche Bedingungen, kompatible Auswahl, Beendigung nach Neustart, Änderung im Betrieb, direkte Änderung, reinen Import-Wechsel und unbeteiligte Library-Änderung. Danach folgen verlorene, doppelte und umgeordnete Lifecycle-Meldungen sowie Rollback.

Die Ergebnisse werden an Build, Wire-Aufzeichnung und dauerhaften Receiver-Zustand gebunden. Zwei Produktnamen in einem Abschnitt belegen nicht, dass zwei unabhängige Implementierungen dieselbe Übergangsgrenze bilden.

Ein Upgrade muss rekonstruierbar und umkehrbar sein

Vorher werden YANG Library, Module, generierte Bindings, Decoder-Image und Replay-Korpus archiviert. Der Kandidat wird transitiv verglichen. Annahme und Ablehnung, erste inkompatible Version, direkte und indirekte Änderung werden geprobt.

Während der Umstellung wird die Lifecycle-Position festgehalten. Bei neuem content-id wird die Bibliothek abgerufen, nicht die Ursache erraten. Irreversible Aktionen bleiben bis zum lokalen Replay pausiert. Eine unerfüllte Bedingung scheitert sichtbar mit ihrem Grund.

Danach werden decodierte Objekte, Transformationen, Entscheidungen und Wirkungen verglichen. Alte Queues und Caches werden geprüft, der koordinierte Rollback beider Seiten geprobt. Erfolg heißt nicht, dass das Abonnement lebt. Erfolg heißt, dass die notwendige Bedeutungskontinuität belegt und jede verbleibende Unsicherheit benannt ist.

Der Entwurf macht eine reale Lücke sichtbar. Er kann dem Betreiber nicht die Auswertung, Befugnis und Wirkung abnehmen. Ein ununterbrochener Stream ist wertvolle Zustellevidenz — und nichts darüber hinaus.

Quellen