Summary

  • UDP-Notif's publisher and message identifiers, segment numbers, last-segment flag and acceptance window can support bounded claims about received transport units; they cannot reveal every event that vanished before the receiver established an observable sequence.
  • A trustworthy telemetry conclusion needs separate receipts for association, reassembly, continuity, identity, subscription context, time, path safety and authoritative operational state.

A receiver has segment zero. Then two. Then one. The L bit on segment two says that three segments make the message, so the receiver orders them, concatenates their payloads and reconstructs one notification. That is a real success. It is not yet evidence that the observation is complete.

The distinction matters because revision 26 deliberately trades transport machinery for speed and lower overhead. The current Internet-Draft, dated 29 July 2026, defines a unidirectional UDP association for configured subscriptions in controlled environments. Each unfragmented UDP datagram carries exactly one message or segment. There is no segment retransmission. The Datatracker record identifies an active NETCONF working-group draft intended for Proposed Standard, while its history shows a long revision process. It is not an RFC.

Reassembly proves a bounded object

Every segment of one message shares a Message Publisher ID and Message ID. Segment Number begins at zero; it cannot wrap. The L bit marks the last segment and therefore declares the expected count. A receiver must accept out-of-order arrival, drop duplicate segments, wait for the required set and concatenate payloads by ascending Segment Number. Options other than segmentation are guaranteed on the first segment, not every segment.

This grammar can prove that one receiver assembled one byte sequence under one set of header fields. It cannot, by itself, prove that two same-number segments carried identical bytes before one was discarded; that the first segment and its options survived an unobserved substitution; or that the grouping keys still belonged to one authentic publishing epoch. A production receipt should preserve the digest of every accepted segment, the discarded duplicates, the complete zero-through-L set, first-segment options, the reassembled digest, timeout and resource limits. “Reassembled” is a verb, not a verdict.

The limits are material. Both sides must support messages of at least 96 KB and receivers at least 64 segments. The draft recommends fewer than 64 segments, a ten-second reassembly target and a hard maximum of twenty seconds. One lost fragment defeats the whole message, while too many fragments can consume receiver resources. RFC 8900 explains why IP fragmentation is fragile; application segmentation avoids that mechanism but does not remove loss amplification.

A continuous sequence begins where observation begins

Message ID starts from a randomized 32-bit value, increments by one for successive messages from the same Message Publisher ID and wraps after its maximum. A gap can therefore expose loss inside a stable observed epoch. But no gap is visible for a whole message lost before the first received ID. A receiver may not be running when the configured subscription takes effect. Publisher restart, Message Publisher ID reuse, relay behavior, receiver downtime, wrap and acceptance-window movement all change what “continuous” means.

The draft lets the receiver compare its successfully delivered count with RFC 8639's publisher sent-event-records counter. A higher publisher count supports the inference that something was not delivered. Yet the scopes and epochs must match. Duplicate segments in an otherwise completed message and out-of-window messages are not delivery failures under the draft's accounting, though they may have separate diagnostic counters. A quiet failure counter can therefore coexist with duplication, misconfiguration, attack traffic or evidence discarded before reassembly.

RFC 8639 separates subscription control from transport and defines lifecycle, replay and counters. That separation is healthy. It means a transport sequence cannot silently inherit authority over what the subscription selected.

Identity needs more than a grouping key

Message Publisher ID identifies a software process and is locally unique to a publisher node. When that uniqueness does not survive the collection domain, the draft also requires source IP; relays must preserve the distinction. These fields are correlation material, not cryptographic identity. In an unsecured lower-layer environment the draft requires secure transport and profiles DTLS. RFC 9147 supplies DTLS 1.3 authentication, integrity and replay protection within its association.

Even authenticated delivery does not prove that the process was entitled to publish this subscription, that its identity survived a restart, or that its data came from the claimed datastore. RFC 8341 keeps authorization as a separate management control. Record the DTLS peer, certificate or credential epoch, device identity, process identity, publisher-ID uniqueness domain, source tuple, any relay, acceptance-window decision and the subscription authority that bound them.

Context and time are not in the fixed header

The header identifies media type—JSON, XML, CBOR or a private encoding—but the encoding is configured per subscription. The fixed header does not carry the complete subscription target, filter, update trigger, period, dampening, receiver binding or configuration version. RFC 8641 makes those distinctions central to YANG-Push. If the subscription changes while Message IDs remain continuous, the transport sequence can be flawless while the meaning of the stream shifts.

Time has the same boundary. Event time, publisher send time, receiver arrival time and reassembly completion time are different clocks. Out-of-order segment support means arrival order is not content order. Message ID order is publisher emission order within an interpreted epoch, not proof of clock accuracy or causality in the managed system. A useful receipt binds clock source, uncertainty, event timestamp, send/receive/reassembly times and the subscription version that governed generation.

Valid bytes can still be wrong evidence

UDP checksums detect a bounded class of accidental corruption. DTLS can authenticate and protect bytes. Neither validates YANG semantics, units, freshness or the authority of the source state. RFC 8342 distinguishes running, intended and operational state: transformations, missing resources and system-created values prevent those views from collapsing into one. A successfully decoded notification can be faithful to a publisher and still fail to represent the authoritative state needed for a decision.

This is why the last receipt must be independent. Correlate the notification with a declared datastore and schema epoch, then verify the relevant device, route, queue, interface or service outcome through another observation path. The transport tells you what arrived. The network tells you whether it was true enough to act on.

The path is part of integrity

RFC 8085 constrains bulk UDP use, and revision 26 restricts UDP-Notif to controlled environments. It requires provisioned capacity and QoS, recommends CS2, pacing and bounded default rates, and asks operators to monitor delivery failures and queues. An intact stream that starves control traffic, overwhelms a receiver or masks queue loss is not an integrity success.

The evidence chain is therefore eight receipts: association; complete reassembly; sequence continuity; authenticated source; subscription and encoding context; time semantics; checksum, DTLS, rate and QoS safety; and authoritative datastore plus independent outcome. None can borrow certainty from the previous one.

Sources and review boundary

The specification context is RFC 8639, RFC 8641, RFC 8342, RFC 8341, RFC 8085, RFC 8900 and RFC 9147. Historical reviews were Ready with nits for TSVART on revision 23, Has issues for OPSDIR on revision 21 and On the right track for YANG Doctors on revision 20. None is a fresh verdict on revision 26.