Summary

  • draft-jgc-netmod-yang-path-00 defines a rooted, module-aware syntax for schema paths, instance paths and filter paths, including list-key predicates, wildcard and regular-expression matching, key-value sets and path enumeration.
  • Parsing and conformance establish how a producer writes a path and how a consumer reads it. They do not establish node existence, schema/context agreement, complete expansion, authorization, safe cost or IETF endorsement.

A path is often asked to carry more confidence than its grammar can support. A controller emits a compact expression; a receiver parses it; a list of concrete results comes back. It is tempting to treat that sequence as proof that both sides meant the same thing and that every relevant object was found. The ypath draft is more disciplined than that interpretation.

The proposal starts every path at /. The first node is qualified by its YANG module unless a default module is supplied by the enclosing specification. Descendants may inherit that module, while a node introduced by an augment uses the augmenting module. List entries are selected with bracketed key predicates. A schema path names the keys without values; an instance path supplies one value for every key; a filter path can additionally use a wildcard, a POSIX extended regular expression, or a set of key values.

That combination is useful because it puts three related tasks in one lexical family. A schema path can identify a definition. An instance path can identify one concrete item. A filter path can select several items. Enumeration can then turn matched data into instance paths, with list keys retained inside predicates rather than being emitted as child segments. A producer has rules for constructing these forms; a consumer has rules for rejecting invalid grammar, resolving module inheritance and augment boundaries, and refusing unsupported filter features.

Those are interoperability rules, not an existence oracle. The draft deliberately leaves the existence test to the API or protocol that embeds the path. A string can conform while naming a node absent from the server’s active schema, a list entry that no longer exists, or a namespace interpreted against a different module set. YANG Library, the Network Management Datastore Architecture and the enclosing operation remain relevant because grammar alone does not carry the live schema, datastore or operational context.

Filter expansion creates another boundary. A wildcard across a list, a regular expression over key values, or an explicit set may be syntactically sound but costly. The draft warns implementers to limit match count, set size and processing time, and notes the denial-of-service risk of regular expressions. A partial response, server limit or policy restriction cannot be upgraded into evidence that the returned enumeration is complete unless the enclosing operation says how truncation and failure are represented.

Authorization is separate again. The draft does not define authentication, authorization or transport. It observes that enumerating paths can disclose sensitive information and calls for the same access controls that protect the underlying data. NACM supplies an established access-control model for NETCONF and RESTCONF, but a path’s successful parse does not mean the caller has read permission. Nor does a rejected result reveal whether the node was nonexistent, inaccessible or withheld by policy unless the enclosing protocol specifies that distinction.

Canonical comparison requires care. Two surface forms can resolve to the same data target after module inheritance or normalization. An authorization check tied only to raw string equality may therefore disagree with the parser’s semantic resolution. Conversely, normalizing before the active schema and module context are fixed can collapse expressions that are not actually equivalent. The control point is the resolved target under an identified context, followed by the applicable policy—not a visually familiar string.

The proposal should also be described with its actual standing. The Datatracker lists draft-jgc-netmod-yang-path as an active individual Internet-Draft, revision 00, last updated 12 August 2026. It lists no IETF stream, intended status or formal document status. The draft header itself says “Intended status: Standards Track” and is dated 13 August 2026. These are different metadata surfaces: an author-declared intended status in the draft header is not an IETF endorsement, adopted working-group position or published standard. This article reports the difference and does not reconcile it by assumption.

Nothing in the reviewed sources establishes deployment or adoption. The proposal belongs beside, but not inside, several neighbouring questions. YANG’s XML encoding rules concern how data is serialized. Module and submodule filenames concern revision-labelled artifacts. Schema comparison concerns whether definitions changed. XPath and RESTCONF already provide expression and resource-path contexts. ypath’s narrower question is whether one constrained, module-aware notation can reduce ambiguity across schema, instance and filtering uses.

A positive answer would still leave operational reality to implementations, contexts, policies and observable results.

Sources

Primary sources: https://datatracker.ietf.org/doc/draft-jgc-netmod-yang-path/ ; https://datatracker.ietf.org/doc/draft-jgc-netmod-yang-path/history/ ; https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/ ; https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/ ; https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/ ; https://www.ietf.org/archive/id/draft-jgc-netmod-yang-path-00.html ; https://www.ietf.org/archive/id/draft-jgc-netmod-yang-path-00.txt ; https://www.rfc-editor.org/rfc/rfc6241.html ; https://www.rfc-editor.org/rfc/rfc7950.html ; https://www.rfc-editor.org/rfc/rfc8040.html ; https://www.rfc-editor.org/rfc/rfc8341.html ; https://www.rfc-editor.org/rfc/rfc8342.html ; https://www.rfc-editor.org/rfc/rfc8525.html