Zusammenfassung

  • draft-ietf-netconf-yang-notifications-versioning-16 erlaubt es, ein benanntes Modul auf eine exakte Revision oder eine kompatible semantische Version festzulegen und die Koordinate in Statusmeldungen der Subscription auszugeben.
  • Die content-id der YANG Library reicht weiter: Sie erkennt auch Änderungen an importierten Abhängigkeiten, benennt aber weder deren Ursache noch deren semantische Auswirkung.
  • Sicheres Fortsetzen verlangt deshalb eine Kette aus Statusbeleg, neuer Bibliothek, Abhängigkeitsvergleich und freigegebenem Decoder; ein unverändertes direktes Modul ist kein Stabilitätsnachweis für das Gesamtschema.

Ein Telemetriestrom kann technisch einwandfrei weiterlaufen und trotzdem seinen Vertrag mit dem Empfänger verlieren. Der Transport liefert Bytes. Ob diese Bytes noch nach demselben Modell interpretiert werden, ist eine andere Frage.

Revision 16 von YANG-Push Notification Versioning setzt genau dort an. Das bisherige YANG-Push richtet Subscriptions ein und überträgt Änderungen, führt aber die Revision des abonnierten Moduls nicht im Subscription-Mechanismus mit. Nach einem Knoten-Upgrade kann sich das Schema ändern, während der Receiver mit dem alten Modell weiterarbeitet.

Das vorgeschlagene Modul ietf-yang-push-revision ergänzt eine explizite Bedingung. Eine Anfrage kann ein exaktes YANG-Revisionsdatum oder die neueste mit einer genannten semantischen Version kompatible Fassung verlangen. Kann der Publisher das nicht erfüllen, antwortet er mit invalid-value und einer der Identitäten revision-unsupported, version-unsupported oder incompatible-revision-and-version. Damit wird die abgelehnte Vertragsbedingung maschinenlesbar.

Auch der Lebenszyklus erhält Koordinaten. subscription-started und subscription-modified werden um Modul, Revision, optionale Version und yang-library-content-id erweitert. Ändert sich Revision oder Version eines beobachteten Moduls, gilt das als Änderung der Subscription-Policy und muss subscription-modified auslösen. Passt die YANG Library nach einem Neustart nicht mehr zur verlangten Revision oder Version einer konfigurierten Subscription, muss der Publisher subscription-terminated senden.

Der schmale Beleg endet jedoch am direkt sichtbaren Modul. Das entscheidende Beispiel abonniert /ietf-interfaces:interfaces und meldet die Koordinate von ietf-interfaces. Ändert sich dieses Modul, können Koordinate und Content-ID gemeinsam wechseln. Ändert sich ausschließlich das importierte ietf-yang-types, bleibt die direkte Revision gleich. Dass sich am Geräteschema dennoch etwas bewegt hat, erkennt der Receiver nur an der Content-ID.

Diese breitere Anzeige stammt aus der YANG Library. Sie ist ein implementierungsspezifischer Bezeichner für die aktuellen Bibliotheksinformationen eines bestimmten Servers. Sie ist kein herstellerübergreifend vergleichbarer Hash und kein semantischer Diff. Eine neue ID verrät weder das betroffene Modul noch, ob es unter dem Subscription-Pfad liegt oder einen vorhandenen Decoder tatsächlich bricht.

Ebenso kann eine für die Subscription irrelevante Schemaänderung den Wert bewegen. Wer jede Änderung als Inkompatibilität behandelt, macht fremde Bibliotheksarbeit zum Verfügbarkeitsrisiko. Wer das Signal wegen stabiler direkter Revision ignoriert, lässt möglicherweise einen alten Abhängigkeitsgraphen neue Daten erklären.

Die beiden Belege haben deshalb unterschiedliche Zuständigkeiten. Die Modulkoordinate dokumentiert die ausgewählte, pfadrelevante Linie, die der Publisher meldet. Die Content-ID sagt, ob der umfassendere Bibliotheksbeleg noch derselbe ist. Keiner belegt, dass gespeicherte Abfragen, Datenbankschemata oder Automatisierungen korrekt bleiben.

Eine belastbare Betriebskette beginnt mit Publisher-Identität und angekündigter Fähigkeit. Sie speichert lokale Subscription-ID, Filter oder Pfad, akzeptierte Einschränkungen, anfängliche Modulkoordinaten und Content-ID. Bei einer Statusmeldung vergleicht der Receiver beide Bereiche. Hat sich die ID bewegt, lädt er die aktuelle YANG Library, bildet die relevante Import- und Include-Hülle, prüft oder wählt den Decoder und gibt die Verarbeitung erst danach frei.

Bereits gepufferte Nachrichten bleiben an den Schema-Beleg ihrer Erzeugung gebunden. Eine spätere Bibliothek darf ältere Bytes nicht stillschweigend neu deuten. Decoder-Test, Speicherkompatibilität, Bestätigung des Verbrauchers und Freigabe der Automation sind eigenständige nachgelagerte Belege.

Schreibrechte auf die Einschränkungen sind eine Kontrollposition. Sie lassen sich anlegen, ändern und löschen; der Entwurf verlangt angemessene Autorisierung. RFC 8341 stellt mit NACM das Standardmodell bereit. Wer eine Versionsbedingung lockern kann, verändert den Interpretationsvertrag, den die Organisation akzeptiert.

Revision 16 ist vom 17. September 2026. Die Datatracker-Historie führt sie bis 29. September im IETF Last Call; im eingefrorenen Datensatz steht kein Telechat-Termin. Die YANG-Prüfung vom 27. September meldet keine Fehler und Warnungen. Das belegt das Ergebnis der Werkzeuge am eingereichten Modul, nicht korrektes Verhalten im Betrieb. Der Volltext bleibt ein veränderbarer Internet-Draft.

RFC 8639 definiert abonnierte Benachrichtigungen, RFC 8641 YANG-Push und RFC 7950 Revisionen und Imports in YANG. Die Entwürfe YANG Module Versioning und YANG Semantic Versioning sind selbst noch nicht abgeschlossen. RFC 9196 liefert einen weiteren Rahmen für Versionsauswahl. Ein Kompatibilitätslabel ersetzt keinen Test des konkreten Verbrauchers.

Quellen