Summary

  • Revision 21 says the Publisher Parent, not the Subscriber, splits one Network Node Subscription into non-overlapping Component Subscriptions. It also requires the modeled subscription-state list to contain at least one Message Publisher ID.
  • Parent lifecycle notices describe the current Agent set, but they cannot by themselves prove that every necessary component was selected or that each Agent delivered continuously.
  • A trustworthy receiver record combines the node context, declared publisher set, per-process Publisher ID, sequence epoch, message identity where applicable, observation time and subscription-state history.

Revision 21 repairs authority before Last Call closes

The current event is a standards review change, not a product launch. draft-ietf-netconf-distributed-notif-21 was uploaded on 6 September 2026 while the NETCONF Working Group document was in IETF Last Call through 8 September. It is intended for the standards track and has been submitted to the IESG, but it remains an Internet-Draft. There is no RFC or completed registration to announce.

Revision 20 had just received an IANA - Not OK review. The review identified an invalid XML example and set out the expected future registrations. Revision 21 repairs the quotation marks in that example, revises the registration language and changes the review state to Version Changed - Review Needed. It also corrects security-sensitive YANG paths and updates the module revision date. Those repairs matter, but the more consequential sentence changes the actor that performs decomposition.

The Subscriber maintains the Network Node Subscription at the Publisher Parent. The Publisher Parent then disassembles it into Component Subscriptions. Revision 20 had attributed the split to the Subscriber. That was not a harmless noun swap. The Subscriber expresses the requested data and delivery terms; the Parent knows the node's participating Agents and their capabilities. The authority to choose which component covers which part of the request therefore sits inside the node.

Revision 21 also adds min-elements 1 to the message-publisher-id leaf-list in subscription state. A started or modified subscription can no longer present an empty modeled publisher set. This creates a useful structural receipt. It does not make the receipt complete.

One subscription is a contract, not one emitting process

The architecture separates the Collector into a Subscriber and one or more Receivers. Requests go only to the Parent. The Parent advertises network-node notification capabilities, constructs non-overlapping component subscriptions, relays their properties to Agents and maintains overall status. Agents inherit the Network Node Subscription ID and lifecycle, collect their assigned component data and publish updates directly to Receivers.

That means a familiar identifier has changed meaning. The Subscription ID ties several emissions to one logical contract; it does not identify one software process. A dashboard that groups all messages by Subscription ID can show a continuous aggregate while one Agent is silent. The aggregate may even become quieter without revealing whether demand fell, decomposition changed, an Agent restarted or a transport path failed.

The draft deliberately leaves Parent-Agent coordination out of scope. It also leaves assignment of YANG schema subtrees implementation-specific. Those choices permit different internal designs, but they prevent the protocol text from proving that the Parent selected every component needed to satisfy the original request. Non-overlap prevents duplication among declared components. It does not prove exhaustive coverage of the running node.

The Parent declaration is a receipt, not proof of coverage

All subscription lifecycle notifications come from the Parent. subscription-started and subscription-modified expose the current list of Message Publisher IDs; when decomposition changes, the Parent sends the modified state with a new list. An operator should preserve those messages as signed-in-time declarations of what the Parent believed the subscription comprised.

Three realities still have to be kept separate. The Parent has a declared set. The Receiver has an observed set of processes from which it has accepted data. The device has a running set of components that ought to contribute for the requested schema and current configuration. Equality between the first two only shows that every declared Agent was heard. It says nothing about an omitted line card or an incorrect subtree assignment that never entered the declaration.

This is the same discipline Heng Lu applies to symbolic and operational layers: a control-plane statement is evidence about authority, not a replacement for running reality. The declaration becomes trustworthy when it can be reconciled with independent inventory, capability and configuration evidence, and when discrepancies retain owners rather than disappearing into an aggregate health score.

Continuity belongs to each publishing process

Each push-update or push-change-update can carry the locally unique Message Publisher ID of its originating process. The notification-envelope draft adds an optional hostname and per-publisher sequence number. That 32-bit counter starts at 1, wraps after 4,294,967,295, and uses zero to make wrap visible. The observation timestamp describes when a value was observed; it is not necessarily the event time, encoding time or delivery time.

These fields answer different questions. Publisher ID says which process asserts the update. Sequence number exposes a gap within that process's current epoch. Observation time locates the measurement rather than network delay. Message ID, where the transport defines one, helps distinguish retransmission or duplication. Subscription-state history says whether a process was expected at that moment.

None is sufficient alone. A process restart can reset sequence state. A changed publisher set can make an apparent gap legitimate. A delayed old message can arrive after a new epoch. A locally unique Publisher ID can collide when records from several nodes are combined. A defensible continuity key therefore includes node context, publisher identity, sequence epoch, message identity as applicable and the Parent's effective state interval.

One address can conceal several authorities

The Agents appear to Receivers under the same source IP address. With UDP they may also share a Layer 4 source port. The UDP notification transport accordingly combines Message Publisher ID and Message ID, and may still need source IP when local identifiers are reused across a collection domain. With HTTPS, the architecture requires a dedicated source port for each software process.

Network teams often treat the five-tuple, TLS endpoint or Subscription ID as the source of truth because those fields are easy to index. In this design they are routing context, not complete provenance. Several component authorities can occupy the same apparent endpoint. The useful unit for loss alarms and replay analysis is the publishing process inside the subscription-state interval, not merely the socket that carried its bytes.

Large notifications introduce another boundary. The UDP transport warns implementations not to rely on IP fragmentation. A completeness strategy that can identify a missing publisher but cannot handle its largest message safely will still turn attribution into silent loss.

Direct publication fragments the security perimeter

The purpose of the architecture is to let network processors or line cards publish directly rather than moving every update through a central route processor. That can remove a data-path bottleneck. It also distributes trust.

Authentication, authorization, key lifecycle, source validation, rate limits and resource controls must now hold across multiple processes. NETCONF or RESTCONF secure transports and NACM remain relevant, but their effective identities and enforcement locations are deployment facts. A policy installed at the Parent does not automatically prove equivalent enforcement at every Agent that sends directly to a Receiver.

Message Publisher IDs also disclose internal process placement. A sequence of publisher-set changes can reveal component restarts, expansion or reassignment. The identifiers are operationally valuable precisely because they expose the split; that same visibility can help an attacker map the node or make a forged message look structurally plausible. Access to raw publisher topology should therefore be narrower than access to an aggregate service graph, without stripping the identifiers from the audit record that needs them.

The remaining Last Call question

The prose says update notifications must include publisher identity. Yet the current YANG tree renders the per-message message-publisher-id leaf as optional. Revision 21's new min-elements 1 applies to the publisher list in subscription state, not automatically to each data update. This article does not declare a standards defect from that tension. It identifies a review and implementation question: under which negotiated feature and schema condition can a Receiver reject or quarantine an unattributed update?

The safe operational posture is to test the invariant explicitly. A non-empty Parent list proves that at least one publisher was declared. It does not make an individual update attributable if the update omits its origin. Systems should record whether publisher identity was present, whether it matched the effective Parent set and what happened when it did not.

Scope limits

The evidence here is documentary. It establishes draft text, revision history, review state and the contracts of referenced RFCs and drafts. It establishes no vendor adoption, conformance, topology, loss rate, latency improvement, incident or exploit. The envelope, UDP and HTTPS documents are also drafts and may change.

The durable finding is narrower: decomposition, declaration, emission, observation and reconciliation are separate acts. One identifier cannot collapse them without losing accountability.

Sources