Summary

  • draft-ietf-netmod-yang-anydata-validation-00 proposed finding the schema for children of an anydata node through their encoded identity and an RFC 8525 YANG Library context.
  • Its anydata-complete option would apply all constraints in the corresponding schema; anydata-candidate deliberately would not apply constraint checks. Neither result proves origin, authorization, operational state, forwarding or business outcome.

A validator returns green. The analytics job accepts a counter. Capacity forecasts and invoices move on. Weeks later, an engineer discovers that the check ran against a different module revision from the one advertised by the device. The green result was real, but the proposition attached to it was never recorded.

That is the useful problem exposed by revision 00 of Validating anydata in YANG Library context. YANG 1.1 uses anydata when content can be modelled with YANG but its data model is not known when the containing module is designed. This flexibility appears in datastore filters and results, edit operations, instance-data files, notification filters and YANG-Push. It also leaves consumers with an awkward question: which schema, if any, should judge the nodes that arrive inside the open container?

The draft's answer was a join. An instantiated node carries enough identity in its encoding to locate a data node: XML combines the local name with the module namespace; JSON uses an identifier that may be module-qualified; CBOR can use a SID, SID delta, qualified name or instance identifier. The validator then consults YANG Library to find the corresponding schema.

The phrase “consults YANG Library” hides the hard part. RFC 8525 describes a datastore associated with a schema, a schema assembled from module sets, and module entries qualified by revisions, submodules, enabled features and deviations. Its content-id changes when the library information changes, but it is an implementation-specific identifier, not a universal checksum. A mounted subtree can add another context. A reusable result therefore needs the library snapshot, not just the name of a module remembered later.

Two green checks with different meanings

Revision 00 introduced two optional modes. anydata-complete would validate the contents and require them to obey all rules in the corresponding schema. anydata-candidate would omit constraint checks. The terminology echoes RFC 7950's distinction between a completed datastore operation and the candidate datastore, where enforcement may wait for commit or validate.

The asymmetry is operationally decisive. A complete pass says that a particular decoder and validator, with a particular schema context, found no violation among the rules it applied. A candidate pass says that the candidate path accepted the structure without completing those checks. Calling both “YANG-valid” destroys the very distinction the proposal was trying to create.

A failure is bounded too. It can identify a range violation, a failed must or when, a type mismatch, a cardinality error, an unknown node or a context mismatch. It does not decide whether the sender was compromised, whether a mediator rewrote the message or whether the consumer selected the wrong library. The diagnostic should lead to quarantine and investigation, not leap directly to attribution.

The draft uses a deliberately concrete risk: a defective node sends a negative interface-octet counter in a YANG-Push notification, and an analytics system produces a false aggregate that may affect billing or capacity planning. Schema validation could catch one class of bad input. It could not prove that a non-negative counter was fresh, complete, authentic or measured at the interface the business process assumed.

The receipt is the product

A credible validation record begins with the payload hash, capture time and encoding. It preserves the decoded node identity, the YANG Library content-id and frozen library response, the datastore and schema name, all module-set members, module and submodule revisions, features, deviations and any schema-mount path. It also names the validator build, flags and validation option, then records diagnostics and disposition.

This detail is not audit ornament. Change a feature and a node may cease to exist. Change a deviation and a constraint may change. Move beneath a schema mount and the same apparent local name may resolve in a different context. Upgrade the validator and parser behaviour may shift. When an old payload flips from pass to fail, a complete receipt lets an operator distinguish a changed schema from changed bytes.

The proposal itself was modest about policy. Validation would be optional, and a consumer could ignore, log or alert on a nonconforming message. That leaves an important decision outside the validator: which failures block automation, which trigger a retry, and which require human review? An organization needs to assign that authority before the check is connected to billing, planning or control.

An expired proposal, not a deployed standard

The status requires precision. Datatracker lists 2 December 2025 as the latest revision date and records revision 00 as the WG version on that day. The text expired on 3 June 2026. Datatracker now labels it an Expired Internet-Draft, Expired & archived, Dead WG Document and IESG Expired; the structured Intended RFC status is None.

The draft masthead separately said Intended status: Standards Track. That historical authoring label is not an IETF approval and does not override the current record. The document also left its security analysis unfinished, requested no IANA action and identified no shepherd on Datatracker.

Its implementation section pointed to an anydata-candidate branch of libyang and asked the RFC Editor to remove that section before publication. A branch can demonstrate that someone exercised a code path. It does not establish that the work was merged, independently implemented, interoperable or deployed. No operational claim in this report rests on it.

What the validator cannot sign

Schema conformance is one layer of evidence. RFC 8342 keeps running, intended and operational information distinct; a valid value is not proof that a device applied it. RFC 8341 handles access control; a conforming node is not proof of NACM permission. Notification and YANG-Push specifications govern subscriptions and delivery; a valid subtree cannot prove that every event arrived once, in order and without an upstream rewrite.

Identity, transport integrity and custody need their own evidence. So do device counters, FIB inspection, packet capture, remote observation and financial reconciliation. A validator should not be asked to speak for those layers simply because its output is machine-readable.

The durable contribution of revision 00 is therefore not a new badge called “valid”. It is the possibility of making a previously opaque subtree testable under a named context, while retaining two different levels of assurance. Used carefully, that can narrow an incident. Used carelessly, a context-free green check becomes another untraceable promise.

Sources

Draft record: revision 00, current Datatracker status, and Datatracker history.

Technical context: RFC 7950, RFC 8525, RFC 8342, RFC 8341, RFC 8528, RFC 8639, and RFC 8641.

Analytical frame: Minimum Initial Specification, On Reality Layers, and Running Code Primary.