Summary

  • draft-ietf-netconf-yang-notifications-versioning-14 lets a subscriber constrain YANG-Push subscriptions by module revision or compatible semantic version and adds module context to subscription-started and subscription-modified notices.
  • The revision, optional version and yang-library-content-id expose the publisher's schema context. They do not prove that queued records, receiver decoders, storage mappings or downstream models crossed the same boundary without loss or semantic drift.
  • Daniel Kade proposes a telemetry schema-handoff record joining the exact notice to old and new module-set fingerprints, last/first decoded records, queue and replay treatment, decoder tests, downstream holds and an accountable release decision. This is not an IETF requirement.

The record that was already in flight

Imagine a configured YANG-Push subscription delivering interface state. At 01:57:42, the publisher emits an update under one revision of ietf-interfaces. At 01:57:43, an upgrade changes its available module set. A subscription-modified notice follows with the subscription ID, filter, module name, revision, semantic version where one exists, and a different YANG-library content ID. At 01:57:44, another update arrives.

The sequence looks orderly on a diagram. A real collector may have several queues. The first update may still be compressed in a transport buffer when the state-change notice reaches a control process. A worker using the old decoder may finish after a second worker has loaded the new one. A storage mapper may deploy several seconds later. An alerting rule may read the same field name while its unit, range or presence condition has changed.

Which event is the handoff?

The publisher's schema change, the notice's eventTime, the receiver's arrival time, decoder activation, durable storage, and release of downstream automation are different events. Revision 14 gives the receiver a much better semantic reference. It does not collapse those clocks into one authoritative instant.

What the draft fixes

The draft addresses a concrete weakness in today's subscription workflow. Under RFC 8641, a receiver may need to query the publisher's ietf-yang-library after a subscription state-change notification to learn whether the semantics of referenced modules changed. That extra query creates delay and another opportunity for context to drift.

The proposed ietf-yang-push-revision module adds two useful controls. First, a subscriber can name a module and require either a particular revision or a semantic version. If the server does not support the request, it must return an RPC error. If a configured subscription's requested revision or version no longer matches the YANG library, the publisher must not send notifications.

Second, subscription-started and subscription-modified can carry a list of relevant modules, their revisions, optional semantic versions and an optional yang-library-content-id. The receiver can detect a changed module context without blindly re-querying the entire library after every state change. Capability discovery can also reveal support for the extension.

These are meaningful improvements. A subscriber can reject an unacceptable version before accepting data. A receiver can identify the schema advertised for a stream. An operator can distinguish an unchanged subscription identifier from an altered semantic environment.

The draft does not claim to prove a collector's operational transition. That is the boundary governance must preserve.

A content identifier is a signal, not a portable fingerprint

The YANG-library content ID represents the server's current library information and is implementation-specific. A change means one or more modules on that server changed. It may therefore be broader than the subscription's selected path. It is not defined as a globally comparable digest of the exact module bytes a collector used.

The module list in the notice is more focused, but the receiver still has work to do. It must possess the corresponding schemas, resolve imports, features and deviations, load the intended decoder, and know how its internal storage mapping treats altered data. An honest module identity at the publisher does not attest to those receiver-side facts.

Nor is “compatible” a universal outcome. Traditional YANG revisions are expected to preserve compatibility; YANG semantic versioning can explicitly mark non-backward-compatible change. Even a nominally compatible change can expose a bug in one parser, collide with an old mapping, alter an alert's assumptions or introduce a node that a downstream model silently ignores.

Compatibility is a property asserted about a change. Safe use is a result observed for a particular consumer and purpose.

The notice does not fence the data plane

A state-change notification is evidence that an event was reported. It is not, by itself, a transactional barrier across every queue that carries the related telemetry.

Suppose records A and B were produced under the old schema, the notice C reports the new revision, and record D uses the new schema. A receiver might observe A, C, B, D because transport, processing and control queues differ. It might observe A, C, D and later replay B. It might lose C and recover the new module context from a later start notice. It might receive C correctly but fail to activate the decoder.

The draft's normative work need not solve all of those operational cases. Keeping the protocol extension narrow is a virtue. The mistake would be made elsewhere: a dashboard sees a changed revision and records “migration complete”; an analytics team assumes all records after the notice's timestamp use the new meaning; or an automation owner resumes control because the schema inventory is green.

Those conclusions require evidence about receipt, ordering, processing and reliance, not just publication.

Silence after a mismatch has several meanings

The rule that a publisher must not send notifications when a configured revision or version constraint no longer matches is protective. It prevents a publisher from continuing to stream data outside the subscriber's stated policy.

But the resulting silence is not self-explanatory. A quiet on-change subscription may simply have no changes. A transport may have failed. The collector may be unavailable. Access control may have changed. Or the publisher may be correctly withholding notifications because the module constraint is no longer satisfied.

An operator who treats every silence as “stable network” defeats the protection. An operator who treats every silence as a schema failure invents incidents. The schema-handoff record must preserve why delivery stopped, which party observed the condition, and what evidence justified resumption.

The minimum handoff record

The extra record should not duplicate the telemetry or ask the IETF draft to become a deployment system. It should join the propositions that different systems already control.

  • Publisher identity, subscription ID, exact XPath or subtree selection and configured revision/version constraint
  • Old and new module-set fingerprints assembled from the exact acquired schemas, imports, features and deviations, while preserving the publisher's content IDs as separate evidence
  • Hash of the authenticated state-change notice, publisher event time, receiver receipt time and collector processing time
  • Last record successfully decoded under the old set and first record successfully decoded under the new set
  • Sequence, replay and resynchronisation evidence, including queued, dropped, quarantined or reprocessed intervals
  • Decoder and storage-mapper builds, test vectors, failures and the mapping applied to changed nodes
  • Alerts, automations, reports and learned models paused, recalculated or explicitly accepted without revalidation
  • Decision owner, exception, uncertainty, rollback target and evidence that closure occurred

The old/new fingerprints are an operator artefact. They must not be mislabeled as the draft's yang-library-content-id. Keeping both values prevents a locally computed digest from impersonating a server-defined identifier.

The last/first records also need careful language. They are the last and first records the collector can prove it decoded under each set, not necessarily the last and first records the publisher generated. If transport evidence cannot close that gap, the receipt should say so.

Security protects the channel, not the interpretation

Revision 14 correctly treats the new writable subscription controls as sensitive. NETCONF and RESTCONF need secure transport and mutual authentication, while NACM limits who can establish or alter the version policy. An attacker or unauthorised operator who changes a constraint could stop a feed or force an unexpected context.

Strong authentication proves who participated in the exchange and helps protect the notice from alteration. It does not prove that the collector selected the right decoder, that an old queue was drained, or that a business rule still means what its owner thinks it means. Those are separate controls with separate owners.

That division is not an argument for a larger protocol. It is an argument against laundering downstream responsibility through protocol metadata.

A useful notice should trigger a disciplined pause

The most mature reaction to a changed revision is neither panic nor automatic acceptance. It is a bounded pause whose exit criteria are known before the maintenance window begins.

The collector can quarantine ambiguous records, fetch and fingerprint the exact module set, run decoder fixtures, compare old and new projections, and reconcile sequence or replay evidence. The automation owner can decide whether the change affects observation only or changes the semantics of a control input. The service owner can declare which degraded uses remain acceptable while consequential actions stay suspended.

If everything is compatible, the record can be small and closure fast. If the content ID changed because of an unrelated module, the evidence can show that too. Governance should make a harmless transition cheap without making an unproven transition invisible.

Revision 14 supplies the missing notice. Accountable operators must still prove the handoff.

Sources