Zusammenfassung

  • Der Entwurf macht Erzeugungszeit, Hostname, einen 32-Bit-Zähler je Publisher-Prozess und Beobachtungszeit transportierbar; jedes Feld bleibt eine begrenzte Aussage in einem bestimmten Schema und Betriebskontext.
  • Automatisierung braucht getrennte Belege für Schema, authentisierte Identität, Prozessepoche, Uhren, Subscription, Inhaltsidentität, nachgelagerte Kette und maßgebliches Ergebnis.

Ein Collector erhält ein sauberes Objekt. Die Wurzel heißt envelope, die Zeit ist gültig, der Hostname sieht vertraut aus, die Nummer folgt der vorigen und das YANG-Push-Update in contents lässt sich dekodieren. Sicher ist zunächst nur: Diese Instanz war lesbar.

Revision 05 des Entwurfs über ein erweiterbares Benachrichtigungsmodell, datiert auf den 18. Mai 2026, löst ein praktisches Problem. Der Header aus RFC 5277 besitzt lediglich das Pflichtfeld eventTime und ist nicht erweiterbar. Wird eine Nachricht an Broker oder Zeitreihendatenbank weitergeleitet, kann der ursprüngliche Transportkontext verschwinden. Der Entwurf bündelt deshalb Metadaten und Nutzlast in einer YANG-Struktur für XML, JSON oder CBOR.

Der Datatracker führt ihn als aktiven NETCONF-Arbeitsgruppenentwurf mit angestrebtem Status Proposed Standard, der auf das Weiterleiten durch die WG-Leitung wartet. Es ist kein RFC. Die Konstruktion macht Aussagen tragbarer; sie vergrößert nicht automatisch deren Beweiskraft.

Ein gültiges Schema bestätigt die Form

Ist die Funktion aktiviert, enthält envelope das verpflichtende event-time, optionale hostname und sequence-number sowie contents vom Typ anydata. RFC 8791 definiert die Struktur; RFC 7951 und RFC 9254 beschreiben JSON und CBOR.

Validierung kann Knoten, Typen, Namespaces und Kodierung gegen die geladenen Modelle bestätigen. Sie beweist weder, dass das Modellinventar das beabsichtigte war, noch dass das Innere von contents geprüft wurde, noch dass Werte stimmen. Am 10. September 2026 zeigte der Datatracker vier YANG-Fehler und zwei Warnungen. Die Historie enthält zugleich einen früheren Bericht über fehlerfreie yanglint- und pyang-Prüfungen und erläutert, dass anydata in den Beispielen nicht geprüft wurde. Zeitpunkt und Umfang unterscheiden sich; beides ist kein Laufzeitnachweis.

Der Schema-Beleg hält Modulrevision, Features, Serialisierung, Namespaces oder SIDs, Validatorversion, geladene Modelle und Prüftiefe fest.

Ein Hostname authentisiert sich nicht selbst

Der Entwurf bezeichnet hostname als Namen des veröffentlichenden Netzknotens und als im Netz eindeutig. Die YANG-Beschreibung sagt zugleich, dass ein Administrator den Wert üblicherweise konfiguriert. In einer geregelten Namensdomäne ist er ein guter Korrelationsschlüssel, aber kein Ausweis.

Der Sicherheitsteil verlangt für NETCONF oder RESTCONF sicheren Transport und gegenseitige Authentisierung. Er warnt, dass ein offengelegter Hostname Netzaufklärung oder gefälschte Benachrichtigungen erleichtern kann. edge-17.example auf einem ungesicherten Weg beweist nur, dass jemand diese Zeichen gesendet hat.

Der Identitätsbeleg bindet den Namen an authentisierten Peer oder Signaturschlüssel, Zertifikat und Schlüsselepoche, Gerät, Publisher-Prozess, Namensautorität und Subscription-Berechtigung. RFC 8341 trennt zusätzlich Authentisierung von Leserechten und kann Inhalte filtern oder verwerfen.

Eine lückenlose Sequenz gilt nur für eine Epoche

sequence-number ist ein counter32: Start bei 1, je veröffentlichter Nachricht plus eins, nach 4294967295 zurück auf 0. Innerhalb einer bekannten, beobachteten Prozessepoche zeigen Lücken oder Umkehrungen eine Diskontinuität.

Der Entwurf definiert jedoch weder eine dauerhafte Epochen-ID noch Persistenz über Neustarts. Beginnt ein Empfänger bei 914, kennt er das Davor nicht. Ein neuer Prozess kann denselben Hostnamen tragen. Ein Relay kann verlieren, duplizieren oder umordnen. Der Zähler läuft regulär über. „Keine Lücke“ heißt deshalb nur: Im gespeicherten Bereich dieser erklärten Identität und Epoche wurde keine Lücke gesehen.

Zum Beleg gehören authentisierter Prozess, Startzeit, erster Wert, Wrap-Entscheidung, Beobachtungsbeginn, Relay-Pfad und Speicherquittung.

Zeitangaben beantworten verschiedene Fragen

event-time steht für die Erzeugung des Ereignisses, im Entwurf als Bau und Versand der Nachricht erläutert. Die Beobachtungserweiterung fügt timestamp für die Messung oder erkannte Zustandsänderung hinzu; point-in-time unterscheidet current-accounting, initial-state und state-changed.

Damit kann eine vor der Zeitfenstergrenze erhobene, aber danach versandte Messung richtig eingeordnet werden. Das Format zertifiziert dennoch keine Uhr. RFC 6991 definiert date-and-time und erlaubt -00:00 bei unbekannter Zeitzone. Dezimalstellen beweisen weder NTP/PTP-Synchronität noch UTC-Rückführbarkeit, begrenzten Fehler oder Monotonie.

Beobachtung, Erzeugung, anchor-time, Empfang und Speicherung müssen samt Zeitquelle und Unsicherheit getrennt bleiben.

Capability ist eine Erklärung, kein Instanzbeleg

RFC 9196 beschreibt Fähigkeiten zur Implementierungs- oder Laufzeit. Revision 05 ergänzt Anzeigen für Envelope, Hostname/Sequenz und Beobachtungszeit. Das macht Aushandlung möglich.

Ein wahrer Wert sagt „unterstützt“. Er beweist nicht, dass der globale Schalter aktiv ist, das optionale Feld in dieser Nachricht vorkam, der Wert richtig war oder jeder Zwischenknoten ihn erhielt. Unterstützung, Konfiguration, Ausgabe und Aufbewahrung sind vier Zustände.

Der Schalter wirkt serverweit. Jede Änderung beendet bestehende konfigurierte und dynamische Subscriptions; die Terminierung wird noch im alten Format versandt. Alte und neue Formate können im Netz nebeneinander bestehen. Ein Migrationsbeleg erfasst Transaktion, beendete Subscriptions, Empfängerkompatibilität und neue Epochen.

contents bleibt vom Subscription-Vertrag abhängig

RFC 8639 bindet Zustellung an Filter, Empfänger, Rechte und Lebenszyklus. RFC 8641 unterscheidet periodisch und on-change, Datastore, Filter, Anker, Dampening und Synchronisierung. Eine push-update ist vollständig gemäß ihrer Subscription; eine push-change-update kann Zwischenänderungen während des Dampening verdichten.

Das Envelope wiederholt diesen Vertrag nicht. Eine Subscription-ID ist ein Nachschlageschlüssel, kein Beweis für die bei Erzeugung gültige Version. Filter, Datastore, Rechte, Trigger oder Empfänger können sich ändern, während Hostname und Sequenz glatt bleiben. Ein Fingerprint der wirksamen Konfiguration und ihre Lebenszyklusereignisse gehören in den Beleg.

RFC 8342 trennt intended, running und operational state. Eine korrekt serialisierte Datastore-Sicht beweist weder Weiterleitungsverhalten noch Servicewirkung.

Nachgelagerte Verwahrung braucht Inhaltsidentität

Der Basisentwurf sagt, contents trage die Werte unverändert, enthält aber keine Inhaltssignatur. Ein sicherer NETCONF- oder RESTCONF-Kanal schützt eine Verbindung. Nach Dekodierung, Neukodierung, Weiterleitung, Aggregation oder Speicherung wandert diese Sicherheit nicht automatisch mit.

Der YANG-Provenance-Entwurf schlägt eine COSE-Signatur exakt über contents vor. Seine Grenzen sind ebenso wichtig: geschützt werden Ursprung und Integrität zum Signaturzeitpunkt, nicht Frische, Richtigkeit der Daten eines legitimen Signierenden, unkompromittierte Schlüssel, lückenlose Signaturen aller Zwischenstellen oder die vertrauenswürdige Zuordnung der Key ID.

Der Inhaltsbeleg bewahrt Digest, Kanonisierung, Serialisierung, Signierenden, Schlüsselregel, Prüfergebnis, Frischekontext und jede Transformation. Ob die signierte Beobachtung wahr war, bleibt eine zweite Prüfung.

Acht Belege ohne geliehene Gewissheit

Erforderlich sind: Schema und Prüfumfang; authentisierte Identität; Prozesskontinuität; Uhr und Unsicherheit; Subscription und Berechtigung; Inhaltsidentität und Signatur; Transport und nachgelagerte Kette; maßgeblicher Datastore und unabhängiges Ergebnis.

Das Envelope kann diese Belege tragen. Der Hostname darf sich keine Authentisierung leihen, der Zähler keine dauerhafte Geschichte, der Timestamp keine Synchronität, Capability keine tatsächliche Präsenz und gültige Bytes keine Betriebswahrheit.