Summary

  • draft-ietf-netconf-yp-transport-capabilities-07 lets an orchestrator discover supported YANG notification transports, encodings and security protocols from implementation-time data or a running server.
  • The record is a capability menu. It does not itself select one exact tuple, approve it under local policy, provision a receiver, establish an RFC 8639 subscription or prove delivery.
  • Implementation-time and runtime claims have different provenance and freshness. Automation should preserve which one it read instead of collapsing both into a generic “supported” flag.
  • A capability-to-subscription decision receipt should join the observed record, selected tuple, policy version, receiver, request, outcome and fallback. This is an editorial proposal, not an IETF requirement.

The seductive certainty of one row

Imagine a controller preparing telemetry from a new router. Its discovery response contains an HTTPS transport entry. Beneath it sit XML and JSON encodings, then TLS 1.2 and TLS 1.3 security identities. The controller has learned much more than it would from a product brochure. It can avoid proposing UDP-notif to a device that does not list it, or CBOR beneath a transport that lists only XML and JSON.

The temptation is to store one green badge: notification capable.

That badge discards the control surface. Which encoding did the controller choose? Which TLS version did policy allow? Was the information obtained from a product instance-data file or from this running device? Was the notification receiver provisioned and reachable? Did the authenticated principal have authority to create the subscription? Did the publisher accept the request? Did a first notification arrive?

Revision 07 of YANG Notification Transport Capabilities was posted on 17 August 2026. Datatracker was last updated on 8 September, the date comments were due under the IETF Last Call announced on 25 August. At the 9 September research cutoff, the document remained an active Internet-Draft intended for Proposed Standard, submitted to the IESG and waiting for the responsible area director to proceed. That is a live process state, not an RFC or final approval.

The draft deserves credit for making discovery structured. The governance problem begins after discovery succeeds.

“Supported” has two clocks

The design extends the system-capabilities framework in RFC 9196. That RFC deliberately supports two ways to publish capability information. An implementer can provide YANG instance data before a device is live. A running server can expose capability data over NETCONF or RESTCONF.

Those sources are not interchangeable copies. Implementation-time information helps an NMS designer integrate a product family and helps an operator assess a system before purchase or deployment. Runtime information describes the live server and can reflect licensing or hardware constraints. RFC 9196 explicitly identifies runtime reads as a way to check whether earlier information is what the publisher actually implemented. It also says systems whose capabilities change at runtime should support on-change notifications for the capability container.

A procurement catalogue may therefore be true without being current for one chassis. A runtime read may be current at observation and stale by execution. A licence can change; a line card can disappear; a software image can be replaced. Flattening both sources into the same Boolean erases the very distinction the framework was designed to preserve.

An automation record should name the source, module revision, device and software build, retrieval method, observation time and freshness rule. “Supported” without those coordinates is not false. It is incomplete in a way that becomes expensive when machines act on it.

The model stops before the act

The draft augments subscription capabilities with a transport-capabilities container. Each transport-capability entry is keyed by transport protocol and contains lists of security protocols and encoding formats. Its example groups HTTPS with XML and JSON and with TLS 1.2 and 1.3. A second entry groups UDP-notif with JSON and CBOR and with DTLS 1.2 and 1.3.

This is exactly the right scale for discovery. It tells a client where a feasible choice may exist. It is not a transcript of a choice.

One must also resist inventing a flaw. Separate leaf-lists do not, by themselves, prove that the server falsely advertises every Cartesian combination. The safe operational claim is narrower: set membership is insufficient evidence for the exact tuple a controller intends to use. The controller should select, attempt and record that tuple rather than infer successful composition from several independent badges.

The distinction is reinforced by RFC 8639. A dynamic subscription does not exist merely because a subscriber sent a request. It comes into being only when the publisher accepts establish-subscription. The publisher may reject the request for many reasons and can return structured hints about parameters more likely to succeed. Capability discovery reduces blind negotiation; it does not replace that state transition.

Even acceptance is not the last proof. It confirms creation under the publisher's state machine. It does not show that the receiver endpoint remained reachable or that notifications continued to arrive. An operational view needs at least five states: discovered, selected, policy-approved, accepted and delivering.

A provisioned management path is an assumption, not the result

The draft states its deployment assumption plainly. A management network between orchestrator and device is available, and management connectivity plus the device's management endpoint have been provisioned. That lets the orchestrator retrieve the menu.

It does not provision the destination to which notifications will be sent. Nor does it decide whether one authenticated management principal may create a subscription for one receiver. Authentication answers who is at the management interface. Authorization and local policy answer what that principal may cause, using which security profile and destination.

This matters most when automation spans organizational borders. A central controller may read the device, a security team may own the allowed protocol profile, a telemetry platform may own the receiver, and a network team may own reachability. A single green discovery response belongs to none of these institutions exclusively. Unless the handoffs are visible, each team can assume another one approved the consequential step.

The draft says its new data nodes are read-only and not security sensitive. It expects secure, mutually authenticated NETCONF or RESTCONF access and points to NACM for access control. There is no need to exaggerate the confidentiality of the menu. The governance risk is different: a non-secret fact can still be used as an unauthorized instruction. Reading “TLS 1.2 supported” is not the same act as approving it for a regulated receiver.

Validation and implementation are necessary but bounded evidence

Datatracker reported zero errors and zero warnings for YANG validation on 8 September. It also recorded a current security review as ready, a transport review as almost ready, IANA actions needed and expert reviews complete. These are useful, specific process facts. None is a production result.

Revision 07 contains an implementation-status section saying Huawei implemented the document for a YANG-Push publisher in VRP and Cisco did so in IOS XR. The same section tells the RFC Editor to remove it before publication. The statements show that the model has reached running code somewhere. They do not supply a public revision-specific interoperation matrix, deployment share, tested tuple inventory or delivery success rate.

Running-code primacy asks for more than names. For this mechanism, convincing evidence would show two implementations exporting their capability source, a controller selecting the same exact tuple, policy accepting it, establish-subscription succeeding or failing with a recorded reason, and notifications reaching the named receiver. Failure evidence is valuable too, provided the fallback is explicit rather than silently weaker.

The draft's dtls12 identity offers a useful warning about such silent weakening: its description calls DTLS 1.2 obsolete and says it is not recommended to enable. That statement is local and precise. It does not prohibit TLS 1.2, which the example also lists, and it does not prove that every existing DTLS 1.2 use violates some unstated rule. Policy must consume the actual identity and the applicable standard, not a keyword search for “1.2.”

Join the menu to the decision

The missing institutional object is a capability-to-subscription decision receipt. It need not alter the YANG module or travel on the constrained path. It can be an operator-side record created when automation crosses from observation into action.

The receipt identifies the device, product family, module revision and software build. It says whether the source was an implementation-time file or a live NETCONF/RESTCONF read, where it came from, when it was observed and when policy considers it stale. It retains the exact advertised transport entry and the chosen transport, encoding and security tuple.

Then it records the acting principal, receiver identity and endpoint, local policy version, subscription parameters and attempt time. The result is not merely pass or fail: accepted, rejected, timed out, later terminated, or accepted without first delivery are distinct outcomes. Structured error hints, any fallback, and the authority that approved a downgrade stay attached.

Such a receipt changes no protocol semantics. It prevents a series of individually true claims from becoming one false conclusion. “The product documentation listed it.” “The live server returned it.” “Policy allowed it.” “The publisher accepted it.” “The receiver obtained data.” Each can be proved on its own clock.

The Policy Mirror asks where the consequential value is actually written. Here, support is written into a capability tree; permission may live in NACM and organizational policy; existence is written by the subscription state machine; usefulness appears only at the receiver. Running-Code Primacy requires their execution evidence to meet. Reality, Not Advocacy keeps the conclusion proportionate: the draft is not accused of promising deployment. It gives automation a better menu. Operators must keep the receipt for what they order.

Sources