Zusammenfassung

  • Publisher- und Message-ID, Segmentnummer, Letztsegment-Bit und Annahmefenster belegen, was ein Empfänger zusammensetzte; sie zeigen nicht alles, was vor Beginn seiner sichtbaren Sequenz verschwand.
  • Belastbare Telemetrie benötigt getrennte Belege für Assoziation, Reassembly, Kontinuität, Identität, Abonnementkontext, Zeit, Lastsicherheit und maßgeblichen Betriebszustand.

Segment 2 kommt vor Segment 1 an. Sein L-Bit sagt, dass es das letzte ist. Der Empfänger wartet, sortiert 0, 1 und 2, fügt die Nutzdaten zusammen und liefert eine Benachrichtigung. Das ist ein echter, aber eng begrenzter Erfolg.

Die Revision 26 vom 29. Juli 2026 definiert eine unidirektionale UDP-Assoziation für konfigurierte Abonnements in kontrollierten Netzen. Jedes nicht auf IP-Ebene fragmentierte Datagramm enthält genau eine Nachricht oder ein Segment; eine Neuübertragung wird nicht erwartet. Der Datatracker-Eintrag nennt einen aktiven NETCONF-Internet-Draft mit angestrebtem Status Proposed Standard; die Historie zeigt seine Entwicklung. Er ist noch kein RFC.

Was Reassembly tatsächlich belegt

Segmente derselben Nachricht teilen Message Publisher ID und Message ID. Segment Number beginnt bei null, läuft nicht über; L markiert das Ende und damit die erwartete Anzahl. Der Empfänger verarbeitet Unordnung, verwirft Duplikate, wartet auf den Satz und verkettet aufsteigend. Andere Optionen sind nur im ersten Segment garantiert.

Damit steht fest, dass ein Empfänger unter bestimmten Headerwerten eine Bytefolge erzeugte. Nicht belegt ist, dass Duplikate derselben Nummer identische Bytes hatten, das erste Segment nicht ersetzt wurde oder die Gruppierungsschlüssel zu einer authentischen Prozessepoche gehörten. Ein Beleg sollte Hashes angenommener und verworfener Segmente, den Satz 0..L, Erstsegmentoptionen, Endhash, Timeout und Speichergrenzen enthalten.

Der Entwurf verlangt mindestens 96 KB und empfangsseitig 64 Segmente, empfiehlt weniger als 64, etwa zehn Sekunden Reassembly und höchstens zwanzig. Ein verlorenes Stück vernichtet die ganze Nachricht. RFC 8900 erklärt die Fragilität von IP-Fragmentierung; Anwendungssegmentierung vermeidet sie, nicht aber die Verlustverstärkung.

Kontinuität beginnt mit der Beobachtung

Message ID startet zufällig, steigt je Nachricht um eins und springt nach dem 32-Bit-Maximum auf null. Eine Lücke kann Verlust in einer stabilen Epoche zeigen. Eine vollständig verlorene Nachricht vor der ersten sichtbaren ID hinterlässt keine Lücke. Der Empfänger kann beim Start des Abonnements offline sein. Neustart, ID-Wiederverwendung, Relay, Ausfall, Überlauf und Fensterverschiebung verändern „kontinuierlich“.

Empfangszahlen lassen sich mit sent-event-records aus RFC 8639 vergleichen. Eine Differenz stützt nur bei gleichem Abonnement und gleicher Epoche eine Verlustannahme. Duplikate einer vollständigen Nachricht und außerhalb des Fensters verworfene Elemente gelten nicht als Zustellfehler; eigene Diagnosezähler bleiben nötig.

Korrelation ist keine Identität

Message Publisher ID bezeichnet lokal einen Prozess. Wenn diese Eindeutigkeit die Erfassungsdomäne nicht übersteht, kommt die Quell-IP hinzu; Relays müssen die Unterscheidung bewahren. Das korreliert, authentifiziert aber nicht. Ohne Schutz darunter verlangt der Entwurf sicheren Transport und beschreibt DTLS. RFC 9147 schützt eine DTLS-1.3-Assoziation gegen Manipulation und Replay und authentifiziert die Gegenstellen.

Eine authentische Gegenstelle kann dennoch für das Abonnement unbefugt sein oder nach einem Neustart einen anderen Prozess darstellen. RFC 8341 hält die Management-Autorisierung getrennt. Zu verbinden sind Gerät, Prozess, Credential-Epoche, Eindeutigkeitsdomäne, Netzwerktupel, Relay, Fensterentscheidung und Abonnementbefugnis.

Der Header enthält nicht die ganze Bedeutung

Der Medientyp unterscheidet JSON, XML, CBOR und private Kodierungen. Ziel, Filter, Trigger, Periode, Dämpfung, Empfänger und Konfigurationsversion liegen im Abonnement. RFC 8641 macht sie zur Semantik von YANG-Push. Message IDs können lückenlos bleiben, während eine Änderung die Bedeutung verschiebt.

Auch Ereigniszeit, Sendezeit, Empfang und Ende der Zusammensetzung sind getrennt. ID-Reihenfolge beweist weder Uhrgenauigkeit noch Kausalität. Der Zeitbeleg braucht Uhrquelle, Unsicherheit, alle Zeitpunkte und Abonnementversion.

UDP-Prüfsumme und DTLS schützen Bytes, nicht Einheit, Aktualität oder YANG-Bedeutung. RFC 8342 trennt running, intended und operational. Eine prozesstreue Benachrichtigung kann von dem für die Entscheidung maßgeblichen Zustand abweichen. Deshalb muss eine zweite Beobachtung Gerät, Route, Queue, Schnittstelle oder Dienst prüfen.

Auch Pfadbelastung gehört zur Integrität

RFC 8085 beschränkt datenintensive UDP-Nutzung. Revision 26 verlangt reservierte Kapazität und QoS, empfiehlt CS2, Pacing und begrenzte Standardraten. Ein vollständiger Strom, der Managementverkehr oder Empfängerspeicher beeinträchtigt, ist betrieblich kein Erfolg.

Die acht Belege lauten: Assoziation; Segmentsatz; Kontinuität; authentifizierte Quelle; Abonnement und Kodierung; Zeit; Prüfsumme, DTLS, Rate und QoS; maßgeblicher Zustand und unabhängiges Ergebnis.

Quellen und Prüfgrenze

Zum Kontext gehören RFC 8639, RFC 8641, RFC 8342, RFC 8341, RFC 8085, RFC 8900 und RFC 9147. Historisch urteilte TSVART zu -23 Ready with nits, OPSDIR zu -21 Has issues und YANG Doctors zu -20 On the right track. Keine Bewertung gilt neu für Revision 26.