Summary

  • draft-ietf-netconf-yang-notifications-versioning-16 lets a YANG-Push subscription constrain a named module by exact revision or compatible semantic version, then reports path-relevant module coordinates in subscription state changes.
  • A whole-server YANG Library content-id covers a wider scope: it can reveal that an imported dependency changed even when the directly named module did not, but it neither names the cause nor proves that the subscription is incompatible.
  • Safe continuation therefore needs a decision chain from state-change receipt to library refresh, dependency comparison and decoder approval; neither coordinate alone is sufficient evidence.

The dangerous packet is not necessarily malformed. It can be perfectly valid under a schema that the receiver no longer has.

That is the operational problem addressed by revision 16 of YANG-Push Notification Versioning. Existing YANG-Push can establish a subscription and stream updates, yet the subscription mechanism does not carry the revision of the subscribed module. A node upgrade can alter the schema while a receiver continues parsing the stream under an older model.

Revision 16 introduces ietf-yang-push-revision. A request can constrain a directly named module either to an exact YANG revision date or to the latest compatible semantic version referenced by the request. A server that cannot satisfy the requested coordinate returns an invalid-value application error with a more specific identity: revision-unsupported, version-unsupported or incompatible-revision-and-version.

This is the narrow receipt. The draft augments subscription-started and subscription-modified with the module, revision, optional version and the YANG Library content-id associated with the state change. If a tracked module's revision or version changes during the subscription lifecycle, the draft treats that as a policy change and requires subscription-modified. After a reboot, if the Publisher's YANG Library no longer matches a configured subscription's required revision or version, the Publisher must send subscription-terminated.

The narrow receipt becomes most useful precisely where it stops. The draft's decisive example subscribes to /ietf-interfaces:interfaces. The state-change notification reports the ietf-interfaces coordinate. If that module changes, its coordinate and the content ID can both move. But if only the imported ietf-yang-types module changes, the directly reported ietf-interfaces revision can stay put. The receiver recognizes that the server's schema state changed only because the wider content-id changed.

That content ID comes from YANG Library. It is an implementation-specific identifier for the current YANG Library information of a particular server. It is not a portable digest whose value can be compared meaningfully across arbitrary publishers. Nor is it a semantic diff. A changed value says that the represented library state moved; it does not name the changed module, show whether the dependency is below the subscribed path, or establish that a decoder will fail.

The reverse warning matters too. The same content ID may change because of a schema addition unrelated to this subscription. A receiver that treats every movement as proof of incompatibility will create avoidable interruption. One that ignores the signal because the directly named revision stayed constant risks interpreting new bytes with an old dependency graph.

The two signals therefore have different jurisdictions. The module coordinate answers which selected path-relevant lineage the Publisher reports. The content ID answers whether the wider library receipt still matches. Neither answers whether a particular consumer, stored query or automation remains correct.

A defensible continuation chain begins with the Publisher identity and advertised support for the revision module. It records the local subscription ID, filter or path, accepted module constraints, starting module coordinates and starting content ID. When a state-change receipt arrives, the receiver compares both scopes. A moved content ID causes it to fetch the fresh YANG Library, calculate the relevant import and include closure, select or validate a decoder, and only then release the stream to downstream consumers.

Messages already buffered require their own discipline. A later library snapshot must not silently reinterpret bytes produced under an earlier one. The minimum useful provenance binds each batch to the schema receipt active when the Publisher produced it. Decoder validation, storage compatibility, consumer acknowledgement and automation policy are later receipts, not properties of the transport signal.

The draft's security boundary is correspondingly concrete. Subscription constraints can be created, modified and deleted. The document calls for access control so only properly authorized actors can reach them; NACM supplies the standard access-control model. A writer who can relax a module constraint changes which schema state the receiver agrees to consume. That is a control-plane privilege, not routine telemetry plumbing.

Revision 16 is dated 17 September 2026. Its Datatracker history places it in IETF Last Call ending 29 September 2026, with no telechat date shown in the frozen record. Datatracker reports YANG validation with no errors or warnings on 27 September. That result validates the submitted module against the reported tools; it does not prove deployed behavior, interoperability or operational safety. The plain draft text remains work in progress.

The surrounding specifications explain why the receipt has layers. RFC 8639 defines subscribed notifications; RFC 8641 carries YANG-Push subscriptions; RFC 7950 defines YANG's revision and import mechanics. The active YANG module versioning draft and YANG semantic versioning draft remain drafts themselves. RFC 9196 offers a broader view of YANG version selection. None turns a compatibility label into proof that a specific receiver survived a dependency change.

Sources