Summary

  • An active NETCONF working-group draft adds exact module-revision and compatible semantic-version constraints to YANG-Push subscriptions, plus module version and YANG-library content identifiers in lifecycle notifications. These mechanisms can reject an unsupported contract or reveal that a publisher’s schema moved while a configured subscription remained alive.
  • They do not prove that imported modules stayed compatible, the receiver loaded the right schema, downstream transformations preserved meaning, access policy remained appropriate, or an automated network action succeeded. Stream activity, schema identity, interpretation, authority and observed effect require separate receipts.

The incident began with a reassuring dashboard. The number of notifications had not fallen. Sequence handling looked normal. The long-lived configured subscription had survived the publisher’s software upgrade exactly as operations expected. Only later did an engineer compare the device’s current YANG library with the schema bundle pinned in the collector. A module beneath the subscribed path had changed. The pipeline had kept processing values under yesterday’s assumptions.

Nothing in that story requires a broken transport. In fact, transport continuity is what makes the failure easy to miss. A subscription is a durable instruction to send selected data. The meaning of that data depends on a separate, evolving set of YANG modules, revisions, imports and deviations. When the publisher changes that set without giving the receiver an actionable version receipt, a healthy stream can carry an unhealthy agreement.

draft-ietf-netconf-yang-notifications-versioning-16, dated 17 September 2026, addresses this particular gap. The Datatracker records it as an active NETCONF working-group document submitted to the IESG for Proposed Standard publication, with IETF Last Call ending 29 September 2026. It remains an Internet-Draft. It is not a final RFC, a procurement certificate or proof that any named implementation behaves correctly in production.

Its useful contribution is narrower and stronger: it makes the schema contract of a YANG-Push subscription more explicit. A receiver can ask for a module revision or a compatible semantic version, and lifecycle notifications can carry enough version state to show that the contract changed. That turns an invisible assumption into evidence that can be logged, tested and acted upon.

The durable subscription and the moving library

RFC 8641 defines YANG-Push subscriptions for datastore updates. Existing subscription metadata identifies the selected data and operating policy, but does not carry the revision of the YANG module behind the selection. A configured subscription can persist through reboot or upgrade. The data source can therefore resume delivery under a new module set while the receiver sees the same subscription as before.

The draft adds two ways to narrow that uncertainty. A request can name an exact revision date for the module. It can instead name a version, defined as the latest compatible YANG semantic version satisfying the request. The first asks for one dated artifact. The second accepts evolution inside a declared compatibility boundary.

These are not two spellings of the same promise. Exact revision matching favors reproducibility and can deliberately stop a stream when the requested artifact is unavailable. Compatible-version matching favors controlled evolution, but relies on module authors and toolchains correctly declaring which changes are backward compatible. The choice belongs in the operating contract, not in a library default.

The rejection paths matter because silence is ambiguous. If the publisher does not support the requested revision, the draft defines revision-unsupported. If it cannot satisfy the requested semantic version, it defines version-unsupported. If a request supplies revision and version constraints that conflict, it defines incompatible-revision-and-version. Each is carried as an application invalid-value RPC error. A collector can record a reasoned refusal instead of treating a missing subscription as an unexplained outage.

Configured subscriptions create a second decision point. After reboot, the publisher compares the stored constraint with its current YANG library. If the revision or version no longer matches, it must issue subscription-terminated. The subscription does not earn a right to keep running merely because it existed yesterday. This is an important reversal of operational intuition: durable configuration does not mean durable compatibility.

The positive lifecycle messages also become richer. subscription-started and subscription-modified carry the module name, revision, optional semantic version and YANG-library content-id. If a module revision or version changes during the subscription lifecycle, the draft treats that as a subscription-policy change and requires subscription-modified. A receiver no longer has to infer schema movement only from malformed values or a later human audit.

Revision is a named artifact, not a running interpretation

Suppose the publisher reports the requested revision and the receiver logs it. That proves something real at the protocol boundary: the publisher says the subscription uses that revision for the constrained module. It does not prove the collector loaded the corresponding schema file. It does not prove its decoder generated the right type, units or default. It does not prove a transformation job preserved a leaf’s semantics, or that an alert rule written for the old model still means what its author thought.

The gap is easy to hide in automation. A schema registry may contain the correct revision while a worker has an older generated binding in memory. The parser may accept a new enumeration but a database column may collapse it into unknown. A transformation may rename a path yet leave a downstream query pointed at the previous field. Every component can be “up” while the evidence chain is split.

Revision metadata should therefore join, not replace, running-code evidence. A useful receipt identifies the publisher build, receiver build, subscription identifier, requested constraint, effective module revision, YANG-library snapshot, schema artifact digest, decoder version, transformation version and the result of a frozen replay corpus. The claim “revision matched” occupies one field in that receipt. It cannot stand in for the rest.

The distinction reflects Running-Code Primacy. A standard names the coordination rule; the deployed system must show which code and artifacts actually executed it. The embedded ietf-yang-push-revision module passed the Datatracker’s reported YANG validation on 28 September with zero errors and zero warnings. That is valuable model-artifact evidence. It is not evidence about a router, collector, message bus or operational decision.

Compatible is a declaration that still needs a consumer test

Semantic version constraints solve a different problem. They let a request accept the latest module version declared compatible with a base. In a healthy module ecosystem, backward-compatible additions can arrive without pinning every subscriber to one date. Non-backward-compatible changes should cross a boundary that the request refuses.

But “compatible” is not an observation of every consumer. It is a statement made under the YANG module-versioning and YANG semantic-version contracts. Those contracts provide vocabulary for development history and compatibility. They cannot know that one collector depends on an undocumented enumeration order, that one generated binding mishandles an added node, or that one policy engine interprets absence differently after a default changes.

Compatibility must be tested at the receiver’s actual use surface. Which subscribed paths are consumed? Which imported types reach them? Which deviations apply on this publisher? Which values are material to an alert or action? A compatible label can justify attempting an upgrade. It cannot close the change record by itself.

The safest posture is asymmetric. Use semantic constraints to permit evolution where the module contract supports it, then replay representative and adversarial fixtures through the deployed decoder and policy chain before accepting the new state as operationally equivalent. If the receiver cannot complete that test, it should quarantine, degrade or stop the affected automation rather than borrow confidence from the version string.

The imported-module blind spot

The directly listed module is not the whole schema. YANG modules import definitions from other modules and can depend on shared typedefs, identities and groupings. A directly subscribed module may keep its own revision and semantic version while an imported module changes beneath it.

The draft recognizes this boundary through the YANG library content-id. RFC 8525 defines the content identifier as an implementation-specific identifier for the current YANG-library information. If it changes, the receiver knows that the device’s schema inventory changed. This can expose movement that the directly listed module revision does not.

It is deliberately a broad signal. A content identifier can change because a module unrelated to the selected path was added or removed. It does not identify which dependency changed. Equality is not a universal proof of semantic sameness across different publishers because the identifier is implementation specific. A changed value says “investigate the library state,” not “this subscription is broken.” An unchanged value supports continuity only within the publisher’s stated behavior.

That makes content-id a detection receipt, not a diagnosis. The receiver should fetch or compare the relevant YANG-library snapshot, calculate a dependency-aware diff, identify which selected nodes are affected and then run compatibility tests. Treating every content change as fatal would create noisy outages. Treating it as irrelevant would restore the original blind spot.

This is where Minimum Initial Specification is useful. The shared protocol need not encode every consumer’s dependency policy. It needs a small, reliable way to state the directly constrained version and signal broader library movement. Each receiver can then apply a visible local rule appropriate to its risk: continue, quarantine, request review, replay tests or terminate downstream action.

A lifecycle notification is not a migration

subscription-modified is evidence that the publisher declared a policy or version change. It is not evidence that the consumer migrated successfully. The message may arrive while queued notifications encoded under the earlier schema are still in transit. Multiple workers may observe it at different times. A state store may commit new schema metadata after it has already written values decoded with old bindings.

The transition therefore needs an ordering contract. Record the transport position at which the lifecycle change was observed, the last item processed under the old schema, the first item accepted under the new schema and the schema digest used for each. Pause or partition downstream actions if the boundary cannot be established. Replay buffered data after the correct artifacts are loaded. Do not merely update a dashboard label while workers continue with mixed state.

Likewise, subscription-terminated is a clean incompatibility signal after reboot, but it does not prove that every old value was drained or every dependent action stopped. A control system should connect termination to cancellation, queue quarantine and operator acknowledgement. Otherwise the stream can end correctly while stale automation continues from cached data.

The capability yang-push-module-revision-supported has the same evidence boundary. It advertises that a publisher supports exporting revision or version state in subscription lifecycle notifications. Capability discovery helps a client choose a procedure. It does not prove that a live publisher reports every transition correctly. That requires fault injection, upgrade tests and captured notifications.

Delivery activity is the earliest receipt, not the final one

Operations often monitor a telemetry system by liveness: messages per minute, lag, reconnect count and subscription state. Those indicators are necessary. They answer whether the delivery machinery is active. They do not answer whether the received values have the intended schema or whether a later decision was justified.

A defensible chain keeps the reality layers separate:

  1. the publisher exposes a particular YANG-library state;
  2. the subscription constraint is accepted against that state;
  3. lifecycle metadata identifies the effective module revision or version;
  4. notifications arrive in an attributable order;
  5. the receiver loads the intended schema artifacts;
  6. decoding and transformation preserve the selected meaning;
  7. local policy accepts the resulting fact for a stated purpose;
  8. an authenticated principal is authorized to act;
  9. the operation is attempted; and
  10. the network effect is independently observed.

No earlier layer inherits the authority of a later one. A continuous stream cannot prove correct interpretation. Correct interpretation cannot grant permission. Authorization cannot prove that a configuration commit took effect. Observed effect cannot retroactively validate a wrongly interpreted trigger.

This separation is not bureaucratic duplication. It tells an incident team where to look. If lifecycle metadata changed but decoder replays pass, the issue may be harmless library movement. If revisions match but application outcomes diverge, the fault lies after the schema receipt. If actions were correct but unauthorized, schema versioning is irrelevant to the governance failure.

Version controls are themselves privileged controls

A client allowed to create or modify a subscription’s revision constraint can influence which schema state the receiver will accept. That is not an ordinary display preference. A malicious or mistaken change could pin an obsolete model, force termination during an upgrade, or broaden a semantic-version range beyond the consumer’s tested boundary.

The draft therefore sits inside, rather than replaces, the security mechanisms of NETCONF and RESTCONF. Secure transport and mutual authentication protect the management channel. NACM can restrict who may read or change configuration and operational state. The exact access-control design remains local, but the version fields should be treated as consequential policy.

Audit the principal, method, before-and-after constraint, subscription identifier, publisher state and approval context for every change. Separate the authority to observe a content-id from the authority to relax a version requirement. Ensure an automated remediation process cannot silently rewrite the constraint merely to make a failed subscription green.

Even a correctly authorized constraint says nothing about downstream action authority. Telemetry may inform a route change, capacity allocation or incident response. The identity permitted to subscribe is not automatically the identity permitted to execute those actions. Bind the data receipt to a distinct policy and authorization receipt at the point of decision.

Implementation claims belong in a test queue

The draft’s implementation-status section records author-reported work across Huawei VRP, 6WIND VSR and Cisco IOS XR, covering different subsets. Those statements help the working group understand feasibility and deployment interest. They are not independent interoperability results and should not be promoted into a blanket claim that the feature is production-ready.

Procurement and deployment should ask for observed behavior. Can the publisher reject an unsupported exact revision? Does a conflicting revision/version pair return the specified error? Does a reboot mismatch produce subscription-terminated? Does a live module change produce one attributable subscription-modified? Are module name, revision, version and content-id preserved? What happens when only an imported module changes? What happens when an unrelated module changes the content-id?

Run those cases against the actual build and receiver. Include dropped lifecycle messages, reordered data, duplicate notifications and rollback to an earlier software image. Capture the wire record and the receiver’s durable state. Interoperability begins when independently built components agree on the transition, not when both names appear in an implementation appendix.

Build a subscription contract that can survive an upgrade

The minimum durable record should include protocol and draft or RFC revision; publisher identity and build; receiver identity and build; subscription identifier; configured and effective filters; exact revision or semantic-version constraint; advertised capability; effective module set; YANG-library snapshot and content-id; lifecycle notifications with transport positions; loaded schema digests; decoder and transformation versions; queue boundary; compatibility-test result; policy decision; authorization; attempted operation; rollback decision; and observed effect.

Before an upgrade, capture the old library and run the candidate module set through a dependency-aware diff. Test exact-revision acceptance and rejection, compatible-version selection, the first non-backward-compatible version, direct-module change, imported-module-only change and unrelated-library change. Test reboot as well as in-service transition. Preserve the old schema artifacts for replay.

During cutover, watch the version-bearing lifecycle event and establish the data boundary. If the content-id changes, retrieve the new library state rather than guessing from the identifier. If a required constraint cannot be met, fail visibly. If compatible evolution is accepted, require the local replay result before restoring high-impact automation.

After cutover, prove more than liveness. Compare decoded fixtures, transformed records, alert decisions and intended network effects. Confirm that stale queues are drained or quarantined and that rollback restores both the publisher and the receiver’s schema state. A successful upgrade is not “the subscription still exists.” It is a set of linked receipts whose remaining uncertainty is explicit.

The draft closes an important observability gap. It lets a long-lived subscription say more about the schema contract under its feet. That is exactly the right scope for a protocol mechanism. The remaining work belongs to implementations and operators: turn version statements into tested artifacts, treat content-id as an alarm rather than an oracle, and never let continuous delivery impersonate continuous meaning.

Sources