Summary

  • In draft-tt-netmod-yang-config-templates-03, explicit non-template configuration has the highest precedence, the nearest ancestor beats a more distant ancestor, and the first applicable template named at one node wins a conflict.
  • A reproducible intended tree needs the complete, same-snapshot running and system data, template definitions, application locations and order, I-Regexp key matching and explicit overrides. It does not prove client authorship, race-free propagation, NACM correctness, implementation identity, operational convergence or traffic delivery.

Imagine receiving a support bundle containing a single line: ct:apply-templates="ethernet-interface base-interface". The names are present and their order is visible. Yet the line alone cannot tell an investigator what the device intended. The answer also depends on where the metadata sits in the tree, which templates existed at that instant, which list keys matched, what an inner ancestor supplied, and which ordinary configuration overrode the inherited values.

That is the useful precision of revision 03. The draft is not merely a convenience for copying boilerplate. It defines a transformation from compact configuration into intended configuration, and it gives conflicts an order. Once order determines the winner, order is part of the executable input.

Three axes decide the winner

The first axis is explicitness. Ordinary non-template configuration in running or system has the highest precedence. A template can provide a default-like value, but an explicitly configured value wins. A template-provided node can be overridden; it cannot be made to disappear simply by trying to delete the expanded node.

The second axis is location. Templates may be applied at a node or inherited from ancestors. If two applicable templates conflict, an application on the innermost ancestor outranks one farther away. A capture that preserves names but drops their attachment paths has therefore lost evidence.

The third axis is list order at one location. Revision 03 says the order is supplied by the client. Its Ethernet example applies ethernet-interface before base-interface; for matching Ethernet entries, the first template's MTU of 1500 wins over the second template's 65536. “Both templates were applied” is not an adequate receipt. The ordered vector is the configuration.

Updating that vector has exact semantics. A non-empty metadata value replaces the entire list. Empty or whitespace-only metadata removes the application. Omitting the metadata leaves the current list untouched. A patch log that records only added and removed names, without the complete replacement value, may be insufficient to replay the change.

Pattern matching enlarges the input envelope

A template can address list instances through regular expressions on keys whose built-in type is string, or derives from it. The draft points to RFC 9485 I-Regexp, a deliberately constrained interoperable subset of XML Schema regular expressions. This improves portability, but it does not make the pattern self-proving. Reproduction still needs the exact rule revision, the implementation's interpretation and the concrete keys present in the captured tree.

The pattern eth.*, for example, is useful only alongside the list keys against which it was evaluated. A later interface rename, a missing system-generated entry or a capture made after another edit can change the match set without changing the pattern text. The evidence object is pattern plus candidate keys plus evaluation context—not the pattern alone.

Template definitions may also be partial. The draft says a server should validate template data where possible, while the merged result must satisfy the relevant YANG constraints when applied. Validation of the extracted YANG module is a different thing. The Datatracker currently reports zero errors and zero warnings for its tool check of ietf-config-template (revision 2026-07-03). That is a valuable document-tool receipt, not evidence that NETMOD adopted the draft or that a server produced a valid merged tree.

Intended is a transformed view

In the NMDA model, running remains compact: it contains definitions, applications and explicit configuration rather than substituting an expanded copy. intended is where inheritance, precedence and overrides become visible. Changing an applied template in running or system should change intended state. An active template cannot simply be deleted; revision 03 calls for a data-missing rejection until all references have first been updated.

Those rules describe a desired state transition, not its concurrency proof. “Update every reference, then delete” can span more than one request. Another client can edit an application between inventory and deletion. A server may offer a transaction boundary, locking discipline or vendor operation that closes the race, but the draft passages alone do not prove that one was used.

The same distinction applies to an intended readback. It is strong evidence of what one server exposed at one observation point. It is not a unique inverse of the transformation. Several histories can lead to the same tree: different template definitions plus explicit overrides, a reordered list whose conflicts happen not to be exercised, or a system change followed by a running override. The output cannot recover the complete client request or every intermediate state.

Freeze the experiment before reproducing it

An off-box expander can provide a meaningful independent check, but only when its input envelope is complete. Preserve the exact draft and rule revision; server and expander implementation identities; complete running and system snapshots; all template definitions; every application path and ancestor depth; ordered name lists; I-Regexp semantics and candidate keys; explicit overrides; and a datastore version or timestamp relation showing that the parts belong together.

Hash the bundle, not just the rendered intended tree. Then run the expansion and compare both structure and values with the server's intended readback. A mismatch is diagnostic evidence. A match establishes that two transformations agreed on those inputs; it does not prove that all servers implement the mechanism identically.

The protocol receipts remain separate. NETCONF and RESTCONF can show that a request was accepted and can carry resource-version signals. They do not show that a later template update propagated without a race, that every principal saw the correct NACM-filtered view, or that the intended nodes were applied. RFC 8341 makes authorization its own control plane; test the role matrix rather than inferring it from a correct merge.

Finally, RFC 8342 separates intended from operational state for a reason. Resource limits or execution failures can prevent intended configuration from appearing operationally. Even operational agreement is not a FIB, packet-delivery or service-level receipt. Each claim needs its own observer.

Status is part of the uncertainty

Revision 03 is dated 3 July 2026. Its document header says “Intended status: Standards Track.” The Datatracker, separately, labels it an active individual Internet-Draft, shows no stream, no intended RFC status, and the state I-D Exists. These are not contradictory if kept in their proper fields; they are contradictory only when compressed into “standards-track IETF work” without qualification.

The disciplined reading is narrower. The draft offers a concrete ordered merge proposal. The Datatracker tool result says its extracted module passed a named validation surface. Neither statement establishes working-group adoption, IETF endorsement, RFC status or deployed interoperability.

Sources

Primary sources: YANG Configuration Templates revision 03; IETF Datatracker record; YANG 1.1, RFC 7950; YANG Metadata, RFC 7952; NMDA, RFC 8342; NACM, RFC 8341; NETCONF, RFC 6241; RESTCONF, RFC 8040; I-Regexp, RFC 9485. Revision chronology: Datatracker history. Related boundary sources: System Configuration revision 20; Lu Heng on running-code primacy, minimum initial specification, and reality layers.