Summary

  • draft-ietf-netconf-yang-notifications-versioning-14 erlaubt Revision- oder Versionsvorgaben für YANG-Push-Abonnements und ergänzt Start- und Änderungsmeldungen um Modulkontext.
  • Revision, optionale semantische Version und yang-library-content-id beschreiben den Kontext beim Publisher. Sie belegen weder die Zuordnung fliegender Datensätze noch Decoder-Aktivierung, Speichermigration oder gleichbleibende Bedeutung nachgelagerter Entscheidungen.
  • Daniel Kade schlägt ein Telemetrie-Schema-Übergabeprotokoll vor: exakte Modulsätze vorher/nachher, Meldung, letzter und erster dekodierter Datensatz, Queue- und Replay-Behandlung, Tests, Sperren nachgelagerter Nutzung, Entscheider und Abschluss. Das ist keine IETF-Vorgabe.

Sechs Zeitpunkte für dieselbe Wartung

Der Change-Kalender nennt 02:00 Uhr. Der Publisher aktiviert seine neue YANG Library zu einer anderen Sekunde. Die Meldung trägt ein eventTime, der Collector verzeichnet den Empfang, ein Worker lädt den neuen Decoder, das Warehouse wechselt sein Mapping, und der Eigentümer einer Automatisierung gibt die Daten später wieder frei.

Alle Zeitpunkte können stimmen. Sie belegen nur nicht dasselbe.

Die Uhr des Publishers leert keine Queue beim Empfänger. Der Eingang einer authentischen Meldung belegt nicht, welcher Decoder einen bereits wartenden Datensatz verarbeitet. Eine erfolgreiche Speicherung beweist nicht, dass eine Alarmformel Einheit und Gültigkeitsbedingung weiterhin richtig versteht. Wer daraus einen einzigen Status „Migration abgeschlossen“ macht, überträgt einem lokalen Ereignis unbemerkt die Autorität über die ganze Kette.

Gute Governance sucht deshalb nicht nach einer magischen Uhrzeit. Sie verbindet die verschiedenen Übergänge und benennt, wer jeden davon freigegeben hat.

Die konkrete Verbesserung des Entwurfs

Heute muss ein YANG-Push-Empfänger nach einer Subscription-State-Change-Meldung unter Umständen die ietf-yang-library des Publishers abfragen, um eine semantische Änderung der referenzierten Module zu erkennen. Die getrennte Abfrage kostet Zeit und kann bereits einen späteren Library-Zustand sehen.

Das vorgeschlagene Modul ietf-yang-push-revision fügt eine Abonnementpolitik hinzu. Ein Client kann für ein benanntes Modul eine bestimmte Revision oder semantische Version verlangen. Unterstützt der Server die Vorgabe nicht, muss er einen RPC-Fehler liefern. Passt eine konfigurierte Vorgabe nicht mehr zur YANG Library, darf der Publisher keine Benachrichtigungen senden.

Zudem können subscription-started und subscription-modified Modulnamen, Revisionen, vorhandene semantische Versionen und eine optionale yang-library-content-id enthalten. Eine unveränderte Subscription-ID kaschiert damit nicht länger automatisch eine veränderte semantische Umgebung. Über das Capability-Modell lässt sich die Unterstützung entdecken.

Das ist ein erheblicher Gewinn. Eine unerwünschte Revision kann abgelehnt und ein laufender Kontextwechsel erkannt werden. Der Entwurf behauptet nicht, dass die Meldung zugleich Software, Queues, Speicherung und Anwendungen atomar umstellt.

Die Content-ID hat einen begrenzten Anspruch

Die yang-library-content-id repräsentiert die aktuelle Library-Information eines bestimmten Servers und ist implementierungsspezifisch. Ein neuer Wert zeigt, dass sich mindestens ein Modul auf dem Server geändert hat. Das betroffene Modul kann außerhalb des ausgewählten Subscription-Pfads liegen.

Die ID ist auch kein definierter, portabler Hash der Schema-Bytes, die der Collector tatsächlich benutzt. Ein Betreiber kann einen eigenen Fingerabdruck über die beschafften Module, Imports, Features und Deviations bilden. Dieser lokale Fingerabdruck und die Content-ID des Publishers sind getrennte Belege mit unterschiedlicher Herkunft.

Die Modulliste in der Meldung verengt den Kontext, attestiert aber nicht die vollständige Empfängerumgebung. Ein anderes Feature-Set verändert den wirksamen Baum. Eine Deviation kann einen erwarteten Knoten entfernen. Der Parser kann syntaktisch erfolgreich sein, während ein altes Speichermapping Einheit, Nullwert oder Kardinalität falsch behandelt.

Eine korrekte Referenz ist noch kein korrekt ausgeführter Interpretationsprozess.

Eine Meldung ist keine Queue-Barriere

A und B seien unter dem alten Schema erzeugt, C sei die Änderungsmeldung und D der erste neue Datensatz. Das logische Bild zeigt A-B-C-D. Getrennte Kontroll- und Datenwege können am Empfänger A-C-B-D ergeben. Ein Replay kann B nach D liefern. Ein alter Worker kann B beginnen und erst enden, nachdem ein neuer Worker D gespeichert hat.

Selbst eine authentische und pünktliche Meldung C klassifiziert B nicht automatisch. Dafür braucht es Transportreihenfolge, Queue-Zustand, Worker-Zuordnung und das konkrete Decodergebnis.

Der IETF-Entwurf muss daraus keine verteilte Transaktion über fremde Systeme machen. Ein enger Standard ist implementierbar und hält Zuständigkeiten klar. Betreiber dürfen die Grenze des Standards nur nicht in eine Behauptung verwandeln, jenseits dieser Grenze sei ebenfalls alles erledigt.

Kompatibel für wen und wofür?

Das traditionelle YANG-Revisionsmodell erwartet kompatible Änderungen; die semantische Versionierung kann nicht rückwärtskompatible Änderungen markieren. Das hilft bei Auswahl und Politik.

Ein konkreter Verbraucher hat weitere Abhängigkeiten. Eine kompatible Ergänzung kann einen Parserfehler auslösen. Features oder Deviations können vom Testaufbau abweichen. Ein neues Feld kann still ignoriert werden, obwohl es eine Berechnung ändern müsste. Syntax kann grün bleiben, während die Aussage eines KPI kippt.

Drei Urteile gehören getrennt ins Protokoll: Klassifizierung durch den Modulautor, Annahme durch die Abonnementpolitik und Ergebnis im verbraucherspezifischen Test. Das Wort „kompatibel“ darf diese Verantwortlichen nicht verschmelzen.

Schutzbedingtes Schweigen bleibt mehrdeutig

Wenn eine konfigurierte Revision oder Version nicht mehr passt, schützt das Sendeverbot den Subscriber. Der Publisher darf nicht einfach Daten in einem unvereinbarten Kontext weiterliefern.

Von außen gleicht dieses Schweigen jedoch einem stillen On-change-Abonnement, einem Transportausfall, einem gestoppten Collector, geänderten Rechten oder einem leeren Filter. Wer den letzten Wert weiter als „stabil“ anzeigt, hebelt den Schutz aus. Wer jedes Schweigen als Versionsfehler meldet, erzeugt Fehlalarme.

Das Übergabeprotokoll muss die gültige Liefererwartung, die beobachtete Stop-Bedingung, die Abgrenzung zu Alternativen und die Freigabe der Wiederaufnahme enthalten. Reicht die Evidenz nicht, werden folgenreiche Nutzungen gesperrt, statt der Lücke eine bequeme Ursache zu geben.

Ein kleines Protokoll für die semantische Grenze

Das vorgeschlagene Artefakt dupliziert nicht die Telemetrie. Es verbindet:

  • Publisher, Subscription-ID, genauen XPath/Subtree-Filter und verlangte Revision/Version;
  • Content-IDs vorher/nachher sowie getrennt lokale Fingerabdrücke der exakten Module, Imports, Features und Deviations;
  • Hash der authentischen Meldung und Ereignis-, Empfangs- und Verarbeitungszeit;
  • letzten nachweislich mit dem alten Satz und ersten nachweislich mit dem neuen Satz dekodierten Datensatz;
  • Sequenz-, Replay- und Resynchronisationsbelege sowie wartende, verworfene, quarantänisierte und neu verarbeitete Intervalle;
  • Builds von Decoder und Storage-Mapper, Testvektoren, Ergebnisse und Regeln für geänderte Knoten;
  • pausierte, neu berechnete oder per Ausnahme akzeptierte Alarme, Steuerungen, Berichte und Modelle;
  • Entscheidungseigentümer, Restunsicherheit, Rollback-Ziel und Abschlussbeleg.

„Letzter“ und „erster“ bezeichnen die Grenze, die der Collector beweisen kann. Sie muss nicht mit der Erzeugungsgrenze beim Publisher identisch sein. Fehlen Transportbelege, bleibt dieser Abstand ausdrücklich offen.

Sichere Übertragung ist keine sichere Semantik

Revision 14 behandelt die beschreibbaren Versionsvorgaben zu Recht als sensibel. NETCONF und RESTCONF brauchen sicheren Transport und gegenseitige Authentisierung; NACM begrenzt die Änderungsrechte. Ein unbefugter Eingriff kann den Feed stoppen oder einen unerwarteten Kontext erzwingen.

Diese Kontrollen belegen Teilnehmer und Nachrichtenintegrität. Sie beweisen nicht das Leeren einer Queue, den richtigen Decoder oder die Gültigkeit einer Geschäftsregel. Kryptografische Stärke vergrößert nicht den Inhalt der geschützten Aussage.

Ein reifer Betrieb nutzt die Meldung als Startsignal für eine begrenzte Pause: exakte Module beschaffen und fingerprinten, Decoder-Fixtures ausführen, Queue und Replay abgleichen, Projektionen vergleichen und Nutzungen risikogerecht freigeben. Betrifft die Library-Änderung nur ein filterfremdes Modul, kann das schnell gehen. Steuert die Telemetrie automatische Eingriffe, liegt die Schwelle höher.

Die Meldung macht die Grenze sichtbar. Das Übergabeprotokoll macht die Freigabe vertretbar.

Quellen