Summary

  • draft-ietf-netmod-yang-xml-00 extracts XML representation rules from the YANG language specification: node names and namespaces, list and leaf-list order, value encodings, metadata hooks, identityref and instance-identifier.
  • XML well-formedness, schema validation or identical canonical bytes closes only a representation question. Effective defaults, user order, mounted schema, protocol acceptance, datastore change, operational state and external effect remain separate claims.

Imagine a controller comparing two backups before a change window. One uses a default namespace; the other assigns an arbitrary prefix to the same namespace. Attribute order and whitespace differ. Canonical XML produces the same bytes, so the dashboard announces “no change”. Hours later, one device applies a different access-list order because the comparison ignored the YANG model and the server’s default-handling mode.

The fictional incident is useful because every individual green light can be genuine. Both documents may be XML. A canonicalizer may work perfectly. A generic schema may accept both. The operational conclusion can still be wrong because the evidence was promoted across layers it did not test.

Revision 00 of XML Encoding of Data Modeled with YANG, dated 8 June 2026, tries to make one layer more explicit. The Standards Track Internet-Draft moves the normative XML encoding rules out of RFC 7950. It covers configuration and state data, RPC and action parameters, and notifications. It remains work in progress, expires on 10 December 2026, and still carries FIXME sections for IANA and security considerations. That status matters: this is a useful draft boundary, not a deployed-conformance certificate.

Names are pairs, not spellings

The draft maps each YANG data node instance to an XML element. The local element name is the YANG identifier; the namespace comes from the module. A top-level element must establish a namespace, and a child defined by another module must change it. Prefix spelling is local. <foo xmlns="urn:example:foo"/> and <p:foo xmlns:p="urn:example:foo"/> can denote the same expanded name even though their bytes differ.

That is the first legitimate equivalence. It does not identify the module revision, enabled features or deviations that give foo its constraints. A validator must bind the instance to the intended schema set. RFC 8525 gives a server a way to advertise YANG Library content, but an advertisement and the bytes actually loaded by a process are still different observations.

The distinction sharpens for values that contain names. An identityref is a namespace-qualified identity; the same identity may appear with different locally declared prefixes. An instance-identifier requires every node name to carry an explicit prefix, but those prefixes are also local to the instance. Text comparison will produce false differences. Blind prefix rewriting can produce false equality if the namespace bindings are not preserved.

Order has more than one owner

Ordinary container children can appear in any XML order, except RPC or action input/output parameters, which follow schema order. List keys come first. List and leaf-list entries marked ordered-by user must follow the user’s order; when system ordered, the implementation chooses. Entries may also be interleaved with siblings.

A generic XML comparison sees one sequence. YANG sees several distinct rules. Sorting every sibling may make diffs quieter while destroying a user-controlled policy order. Preserving every observed order may create noise where order carries no meaning. The correct comparison must know which node is being compared, its ordered-by statement and whether the instance represents ordinary data or operation parameters.

This is not pedantry for access lists, preference chains or any model where first-match or explicit priority has consequences. The receipt should preserve the original sequence, the schema rule that gives it meaning and the server readback. A sorted rendering is never a substitute.

Missing XML can still mean present behavior

The draft says an empty non-presence container may be encoded or omitted. It does not define NETCONF’s default-handling modes. Those rules live elsewhere. RFC 7950 says that when a leaf or leaf-list default is in use, the server must behave as if the node existed; conditions such as when and if-feature can prevent that default from being in use. RFC 6243 then allows servers to report defaults through report-all, trim, explicit and report-all-tagged behavior.

Consequently, absence from an XML reply is not absence from the effective data tree. Presence with the schema-default value does not reveal whether a client explicitly wrote it, the server inserted it for the reply, it is stored, or it merely governs behavior. Two servers may expose different XML while behaving from the same default; two identical replies may be interpreted differently if their schema revisions or advertised modes differ.

Default comparison needs a declared target. Are auditors comparing wire representations, stored configuration, the accessible tree with defaults in use, or a fully expanded reply requested with a particular with-defaults mode? Without that declaration, “equal configuration” is not a reproducible statement.

Canonical XML is deliberately application-bounded

Canonical XML 1.1 normalizes physical XML representation, including character encoding, attribute and namespace-declaration ordering, and several syntactic freedoms. The W3C specification explicitly warns that application-specific equivalence cannot be captured by a general XML algorithm. Documents with different canonical forms may still be equivalent for an application; canonical equality does not import an external application’s rules.

YANG adds those external rules: type lexical spaces and canonical forms, namespace-aware identity resolution, defaults, ordering and constraints. XML canonicalization does not select a YANG revision, evaluate features, compile deviations, expand defaults or dereference a leafref. It also does not prove that an instance-identifier points to a node that exists in the relevant data tree.

The same boundary applies to apparently richer validation. XSD can inspect XML structure, while a YANG-aware validator can test an instance against a chosen model. Neither result proves that the chosen model is the one a server used, nor that the surrounding datastore and operation context was correct.

Metadata and mounted models travel beside the tree

Revision 00 permits XML attributes for special purposes such as YANG metadata, while leaving their exact syntax and semantics to RFC 7952. A tool that strips unknown attributes may retain ordinary data and lose a timestamp, origin annotation or other modeled qualification. The remaining XML can still look valid while the claim it supports has changed.

Schema mount makes context even more local. RFC 8528 allows different instances of the same mount point to use different mounted schemas. Bytes copied out from under a mount point therefore need the mount instance and its schema reference. A standalone fragment cannot recover that authority from its element names alone.

anydata creates a related limit. The draft says its content model may be unknown at runtime; when it is unknown, conversion to another encoding may be impossible. anyxml is less constrained still. A conversion system that promises lossless XML-to-JSON-to-XML round trips must identify which subtree had a known model and which was opaque.

Protocol success begins after representation success

An XML document on disk is not a NETCONF request. A sent <rpc> is not a received one. A received request is not an authorized operation. RFC 6241’s <rpc-reply> and <rpc-error> close protocol questions; <ok> says the operation was processed without an error or warning and had no data to return. It does not certify every later physical consequence.

For a change, retain the exact request and message identifier, authenticated session, server capabilities and YANG Library state, response, and datastore before-and-after readback. Then keep going. RFC 8342 distinguishes running, intended and operational because valid configuration, transformed intent and applied state may diverge. The last step is an observation of the external effect that motivated the change—reachability, policy enforcement, capacity or service behavior.

This is the practical meaning of running-code primacy. A specification defines the interpretation parties are entitled to expect. A canonicalizer, validator and protocol receipt can each close a bounded claim. Only linked observations can show that the selected bytes became the intended tree, entered the intended datastore, survived transformation, appeared operationally and produced the claimed result.

Sources