Summary

  • draft-ietf-netmod-node-tags-11 proposed collecting module-defined, implementation-assigned and user-configured labels around YANG nodes, then presenting a visible operational set after exact tags in masked-tag have been removed.
  • A surviving tag proves only that a server exposed that label for that selector, datastore and authorization context. It does not prove the selector resolves in the consumer's schema, the node exists now, its value is fresh, the implementation behaves as labelled, or the draft was deployed.

Suppose an automation service asks a router for every node tagged as sensitive. It receives three paths and launches tighter monitoring. A fourth path is absent. Was it never tagged, hidden by access control, removed by a user mask, suppressed by a schema mismatch, or unavailable in that datastore? The returned list cannot decide.

That uncertainty is the most valuable feature of YANG Data Model for Node Tags. Revision 11 does not merely attach words to nodes. It exposes a small contest over classification: module authors can provide design-time labels, implementations can add labels, users can add their own, and users can mask a tag whatever its origin. The server then offers a composed view for discovery.

The proposal defines an ietf-node-tags module. Its association list has an integer identifier, a node-selector typed as a NACM node-instance identifier, a set of tag values and a set of masked-tag values. The selector can point to a schema node or a data-node instance. The draft describes querying the operational datastore with <get-data>; for schema nodes it also mentions <get-schema>. Its appendix first discovers a tagged path and then uses that path in an establish-subscription request.

That example is a useful workflow sketch. It is not a field report. The source set identifies no production deployment, independent implementation, interoperability event or vendor support claim.

Three sources, one visible set—and an ambiguity

The source taxonomy is clearer than the construction algorithm. Sections 5.1 to 5.3 separately discuss tags supplied at module design, tags added by an implementation and tags configured by a user. Section 5.4 lets a user mask any tag, irrespective of origin.

But revision 11's numbered account of the operational view says to add system-origin tags assigned at module definition, add user-configured intended-origin tags, and remove any tag equal to a masked-tag. It does not name a separate implementation step there.

The defensible reading is that automatic implementation additions belong to the server-side or system material later exposed in operational state. It is still a reading, not an explicit fourth algorithm step. An audit should preserve that ambiguity instead of drawing four neat arrows the draft itself never specified.

The order matters. A mask is not a denial that a tag ever existed. It is an instruction to remove an exact value from the visible set. Nor is the visible set a complete provenance record. If vendor:critical survives, the result alone does not reveal whether it came from a module statement, a software build or a local operator, when it was added, or what evidence justified it.

The proposal reserves ietf:, vendor: and user: prefixes. It also says an unregistered prefix remains a valid tag and should still be processed. Registration therefore governs namespace coordination. It does not certify the assertion after the colon. A well-governed name can describe a badly implemented node; an unregistered name can happen to describe one accurately.

The selector carries hidden dependencies

A tag association looks portable because node-selector is structured. Yet its resolution depends on the effective schema. RFC 7950 supplies YANG's data-model rules. RFC 8525 describes the YANG Library inventory of modules, revisions, features and deviations. A selector that resolves under one library snapshot may fail or point elsewhere after a revision, feature change or mount-context change.

Datastore choice adds another boundary. RFC 8342 distinguishes intended configuration from operational state. The draft follows that distinction by describing user configuration as intended-origin material and the composed result as operational. “Operational” here means the server's operational datastore view. It does not mean unmediated device reality.

Authorization also shapes observation. RFC 8341 can restrict access to the association list or target node. NETCONF and RESTCONF, defined by RFC 6241 and RFC 8040, provide retrieval transactions; they do not make every authorized response complete for every observer. A missing tag or node must therefore be investigated as a multi-cause result, not immediately converted into “does not exist”.

RFC 7952 provides a useful contrast. Its metadata annotations accompany data instances. The node-tags proposal centralizes associations around selectors. Neither form automatically supplies authorship, custody, freshness or causal truth. Those properties require separate records.

An evidence ladder for tag-driven automation

The safe way to use the model is to keep each inference on its own rung.

First, the archived draft proves that this mechanism was proposed. Datatracker proves the document's lifecycle. A registered prefix proves that a namespace was allocated. A query result proves that the queried server exposed a post-composition tag in a particular access and datastore context. Resolving the selector against a frozen YANG Library proves that the path maps to a node under that schema.

Only then can an authorized node read show what the server returned for that transaction. Even that does not establish freshness, completeness, correct implementation or custody. Device telemetry, forwarding-table inspection, packet observation and service reconciliation are needed before an operator can claim that the network behaved as the tag implied.

This separation matters most when a label triggers action. RFC 8639 and RFC 8641 can turn a discovered path into a subscription. RFC 9195 and RFC 9196 can represent instance data and capabilities. None of them converts a classification token into evidence that every notification arrived, that the device implemented the model faithfully, or that downstream policy was correct. RFC 9371's treatment of vendor identifiers similarly helps namespace hygiene without endorsing vendor behaviour.

The draft itself recognizes the security edge. Tags may disclose how a node is used and reveal an attack vector. Privilege is needed for additions and removal, and actions based on tags are out of scope. A control system that maps ietf:critical directly to a disruptive response would therefore be importing a local policy the draft never authorized.

The status is part of the evidence

Revision 11 is dated 21 October 2023 and says it would expire on 23 April 2024. Datatracker now records it as an Expired Internet-Draft, Expired & archived, a Dead WG Document, with IESG state Expired. Its intended status was Proposed Standard. It did not become an RFC.

Datatracker also reports that its YANG modules passed validation with zero errors and zero warnings. That is evidence that the submitted model cleared the named tooling checks. It is not evidence of adoption, interoperability, deployment or correct runtime composition.

RFC 8819 must not be used to upgrade this status by association. RFC 8819 is a published Standards Track specification for tags on YANG modules. It supplies important precedent for module-definition, implementation, user and masked inputs. Revision 11 tried to extend that pattern to nodes. The standard status of the former does not flow into the latter.

The editorial lesson from Heng Lu's writing is similarly bounded. Specifications, registries and labels can coordinate action, while implementation and observable operation occupy another reality layer. That is an analytical lens, not an IETF rule. Applied here, it yields a modest discipline: keep the tag as a locator and classification clue; do not let it borrow authority from the document, prefix or system that carried it.

Sources

Primary record: revision 11, current Datatracker status, and Datatracker history.

Model and access context: RFC 6241, RFC 7950, RFC 7952, RFC 8040, RFC 8341, RFC 8342, RFC 8407, RFC 8525, and RFC 8526.

Tags, subscriptions and adjacent evidence models: RFC 8639, RFC 8641, RFC 8819, RFC 9195, RFC 9196, and RFC 9371.

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