Summary

  • RFC 9890 repairs a mismatch between RFC 6020's wording and IANA's established practice. Initial YANG module and submodule names must be unique; an initial module namespace must be unique; later revisions deliberately retain the same name and, for modules, the same namespace.
  • The stable identifiers establish lineage, not exact content or deployment. Reproducible operations require the revision and source, followed by server-specific YANG Library, feature, deviation, datastore and operational-state evidence.

The change-review screen shows the same module name before and after an upgrade. The namespace is unchanged too. A hurried reviewer concludes that the schema has not moved. Yet one revision added nodes, another altered constraints, the server enabled a different feature set, and a deviation changed what it would accept. The labels were stable because stability was their job. They were never a checksum of the thing behind them.

That is the practical importance of RFC 9890, An Update to YANG Module Names Registration. Published on the Standards Track in October 2025, it changes no YANG message, device operation or datastore. It updates the IANA guidance inherited from RFC 6020 so the written rule describes how module revisions are actually registered.

The old text said every module and submodule name in the registry had to be unique and every XML namespace had to be unique. Read literally across rows, a second revision with the same name and namespace looked forbidden. IANA's practice necessarily did something else: revisions of one module appeared under the durable module identity. RFC 9890 makes that structure explicit. Uniqueness applies to the initial version; later module and submodule revisions must keep the initial name, and module revisions must keep the initial XML namespace.

The correction is narrow. It is also a useful test of whether an organisation can distinguish identity from state.

One durable identity, several legitimate contents

RFC 6020 created the YANG Module Names registry and supplied the overbroad uniqueness sentence. It also explained why revision selection exists: published modules evolve independently, while an importing module may need the definitions it reviewed at a particular time. A revision date can bind that dependency; without one, the source revision is not defined by the import.

RFC 7950, YANG 1.1, sharpens the model. A module statement supplies a name. Revision statements record its editorial history, including the initial revision, with dates. An import may select a revision with revision-date; if it does not, which revision supplies the referenced definitions is undefined. YANG 1.1 even permits multiple revisions of the same module to be imported when distinct prefixes keep their references separate.

Those rules only work if a revision is allowed to remain the same module. Renaming every update would manufacture new identities, break the continuity of imports and waste the namespace as a version label. Conversely, keeping the name does not make revisions interchangeable. The correct key for exact content is not merely name, and not merely namespace. It is at least a revision coordinate, and where reproducibility matters it should include the retrieved source bytes and their hash.

The live IANA YANG Parameters registry makes the distinction visible. ietf-yang-types, for example, has dated files associated with revisions published in 2010, 2013 and 2025. The repetition is not a duplicate assignment. It is the audit trail of one module lineage. The registry answers which public lineage and documented revision a row belongs to; it does not say which copy a particular controller loaded at 09:17 on Tuesday.

RFC 9907 adds an important boundary for authors and reviewers. A published module name cannot be reused for an unrelated module, even if its RFC later becomes Historic. Changing the name creates a new module rather than renaming the old one. When published content changes, the module receives a later revision date and retains the earlier published revision statements. In other words, durability is intentional at both ends: the name protects lineage, while the revision history protects change.

The registry cannot testify for a server

A registry is a coordination mechanism. It can establish that a name and namespace were allocated through an authoritative process and that referenced revision files were published. It does not observe software packaging, controller caches, device boot state, feature activation or a vendor's local deviations.

The next evidence source is RFC 8525, the YANG Library. A server can report its module sets, the revision and namespace of implemented modules, import-only modules, enabled features, deviation modules, schemas and datastores. A module implemented in several datastores uses one revision across those datastores; several revisions of a name can coexist as import-only dependencies when imports are revision-specific.

This is already much more precise than a registry row, but it is still server-local testimony. YANG Library information may differ between servers, change at runtime or change across a reboot. Its content-id is an implementation-specific identifier for the current library information on that server. The value must change when that information changes, but equal information is not required to reproduce the same identifier. It is a cache-invalidation signal, not a portable content digest.

A useful audit record therefore binds the YANG Library response to an authenticated endpoint, server identity and capture time. It preserves the content-id, module-set and schema names, implemented or import-only status, module revision, namespace, source location, feature list and deviation list. If a compliance report records only ietf-example is present, it has thrown away the facts most likely to explain a later incompatibility.

The source file remains another layer. A revision date is an editorial identifier, not cryptographic proof that two repositories serve identical bytes. For a controlled build, retain the exact fetched artifact and hash it. Record where it came from and whether the installed package reproduces it. The IANA file, a vendor bundle, a controller cache and a generated binding may all carry the same module name while differing in provenance or transformation.

A schema is more than its module list

RFC 8342 defines a datastore schema as the combined schema nodes of the modules supported by that datastore after enabled features and deviations are taken into account. That qualification matters. Two devices can report the same module name and revision while exposing different effective schemas because one enables a feature the other omits, or because their deviation modules differ.

The evidence chain continues beyond schema. <running> can contain configuration that needs transformation before use. <intended> represents the result after those transformations and what the system attempts to apply. <operational> combines applied configuration with system state. Values can differ because of hardware interactions, protocols, other devices or propagation time.

Accordingly, a module's presence does not prove that a node exists in the effective schema; a node's presence in the schema does not prove a configuration value was authorized; a value in <running> does not prove it survived transformation; a value in <intended> does not prove the device applied it; and an operational value does not by itself prove the network delivered the intended business outcome.

This ladder is inconvenient only if the desired conclusion was larger than the evidence. In a disciplined system, it is liberating. Every layer has a specific question and custodian:

  • IANA coordinates the public module identity and revision record.
  • Authors define a revision and its change history.
  • Repositories and build systems preserve exact source bytes.
  • Implementers decide what software supports.
  • Server operators expose module sets, features, deviations and schemas.
  • Configuration authorities decide desired state.
  • Devices and surrounding networks produce operational state and observed outcomes.

No actor inherits the next actor's authority merely because the same name passes through all of them.

The cost moves downstream, where it can be managed

Stable naming reduces global coordination cost. Every revision does not need a new namespace, every consumer does not need to discover a new identity, and the registry does not grow a false forest of supposedly unrelated modules. This is the minimum shared rule: establish the lineage once, then let revisions evolve inside it.

The cost has not disappeared. It has moved to the parties making local decisions. An importer decides whether to pin a revision. A package manager decides how to cache source. A server decides which revision and features it implements. An operator decides when a fleet moves. An automation owner decides what counts as drift and what evidence permits rollout.

This is the division of power described in Heng Lu's Minimum Initial Specification and Localized Future Decision: central coordination should define what must be common, while future choices remain with the participants who can observe their local consequences. RFC 9890 does not cite that essay, but the operating logic is analogous. Global uniqueness protects the initial identity; revision selection remains a local, accountable act.

The same discipline underlies Running Code as Primary Evidence. A corrected standards sentence clarifies authority, but it cannot show what a running server loaded. The registry, module source, YANG Library and datastore observations must be joined rather than collapsed. Documentation is indispensable evidence of intent and coordination; execution is evidence of a different proposition.

Finally, Reality Layers and Symbolic Power explains why this separation can feel hostile to dashboards. A single green label is socially convenient. A layered record exposes unresolved joins, split responsibility and uncertainty. Yet the discomfort is precisely what prevents a durable symbol from acquiring powers it never possessed.

Sources