Summary

  • RFC 6020 said every YANG module and submodule name in the registry, and every XML namespace, had to be unique. IANA’s established practice instead kept successive revisions under the same module name and namespace.
  • RFC 9890, co-authored by Qin Wu, repaired the text: uniqueness applies to the initial version; revisions must retain the initial name, and module revisions must retain the initial XML namespace.
  • A stable registered identity does not make revisions interchangeable. Revision dates, selected source, implementation tests and observed deployment outcomes remain separate receipts controlled by different actors.

On 1 September 2026, the IANA YANG Module Names registry contained three rows named ietf-yang-types. One pointed to the dated YANG file for 2010-09-24, another to the 2013-07-15 revision and another to the 2025-12-22 revision. All three carried the XML namespace urn:ietf:params:xml:ns:yang:ietf-yang-types.

Read literally against the original wording of RFC 6020, this looked impossible. Section 14 said all module and submodule names in the registry “MUST be unique”. It also said all XML namespaces in the registry must be unique. Yet the repeated rows were not accidental rival claims. They were the editorial history of one module identity.

RFC 9890 resolved the contradiction in October 2025. The six-page Standards Track document, written by Andy Bierman, Mohamed Boucadair and Qin Wu, did not invent a new registry operation. It changed the rule so the specification described the practice already used to maintain modules and their revisions.

The correction is small enough to overlook. It is also a clean test of what a technical registry is for.

The old sentence described the wrong unit

Uniqueness is meaningful only after the system says what must be unique. A first module name is an identity assignment. A later revision is a new editorial state inside that identity. Treating both as the same kind of event creates a false collision.

RFC 9890 rewrites the boundary precisely. Names of initial module and submodule versions must be unique. XML namespaces of initial module versions must be unique. Every later module or submodule revision must use the initial name, and every module revision must use the initial XML namespace.

The distinction protects two properties at once. Initial uniqueness prevents unrelated specifications from taking the same public identifier. Revision continuity prevents one specification from changing identity every time its definition changes. A registry can enforce both only if it stops asking revisions to behave like first registrations.

This is why “duplicate” is a dangerous dashboard label. Three rows with the same name can be evidence of corruption, three competing initial claims or three dated revisions in one authorised lineage. The string match does not decide. The record needs event type, revision date, source document and namespace.

The same discipline applies outside YANG. A control that rejects repeated identifiers without knowing whether the event is creation, renewal, revision, transfer or recovery can make a database look tidy while breaking the continuity it was meant to protect.

A revision keeps identity, not meaning

The new rule could be misread in the opposite direction. If revisions must have the same name and namespace, a hurried reader may assume they are interchangeable. RFC 7950 shows why that inference fails.

YANG 1.1 describes the revision statements as a module’s editorial revision history. The argument is a date. Every published editorial change should add a new dated statement at the front of a reverse-chronological sequence. The recommended filename combines the stable module name with an optional @revision-date.

That structure says two things simultaneously: this is still the same named module, and this is not necessarily the same definition. Identity continuity answers “which lineage?” The date answers “which editorial state?” Neither answer can impersonate the other.

Imports make the difference operational. When an import includes revision-date, the referenced definitions come from that specified revision; it is an error if the revision does not exist. Without a date, RFC 7950 says it is undefined which revision is taken. Multiple revisions of the same module may even be imported when different prefixes are used.

An unchanged namespace therefore cannot be an upgrade policy. It cannot tell a toolchain which revision was bundled, a vendor which behaviours were implemented, or an operator whether a schema change is safe. It keeps the public identity stable while the rest of the evidence chain stays visible.

The date is a selector, not decoration

The IANA rows for ietf-yang-types make the mechanism concrete. The 2010 row refers to RFC 6021. The 2013 row refers to RFC 6991. The 2025 row refers to RFC 9911. The name and namespace remain constant, while the dated files and documentary authorities change.

An inventory that stores only ietf-yang-types collapses three editorial states into one. An inventory that renames them ietf-yang-types-v1, -v2 and -v3 invents identities the registry did not assign. The faithful record holds both dimensions: stable identity and dated revision.

Operators need more than the date. A useful receipt joins module name, namespace, revision date, file digest, source RFC, package or firmware version, validation result and deployment observation. A date can select the intended text; a digest can identify the exact bytes; a package manifest can say what shipped; a test can say what the implementation accepted; observation can say what the live system did.

None of those fields is redundant. If a vendor silently replaces a same-named module file, the date and digest reveal the substitution. If two products claim the same revision but parse it differently, conformance evidence separates them. If a tested build never reached production, deployment state prevents a laboratory receipt from becoming a live claim.

The registry has a narrow job

RFC 9890 adds itself as an authoritative reference for assigning names in the YANG Module Names registry. It then says the change creates no new operations or manageability requirements and no new or increased security risk.

That restraint matters. The registry’s common function is collision prevention and lineage recording. It can say that an initial module identity is already assigned. It can record that a dated revision belongs to the same name and namespace. It cannot certify the quality of the YANG model, the correctness of a parser, the compatibility of two revisions or the wisdom of deploying one.

Heng Lu’s Minimum Initial Specification offers a useful design test here. Centralise only what participants must share. The ecosystem needs a common answer to the identity question because conflicting initial names and namespaces would damage coordination. It does not need IANA to choose a vendor’s upgrade window, approve a local import graph or accept an operator’s service risk.

Localised future decision follows naturally. A revision can be published and registered without forcing every implementation to adopt it at once. A vendor can package it, a tool can select it and an operator can stage it on different schedules. The public identity remains portable across those decisions; the decisions remain attributable to the parties that make them.

Qin Wu’s credit supplies context, not operating authority

RFC 9890 lists Qin Wu of Huawei as one of three authors, alongside Andy Bierman and Mohamed Boucadair. The official IETF Datatracker links a substantial RFC record to the same public identity. That is enough to place Qin Wu within a long standards practice concerned with network management and YANG.

It is not enough to turn a co-author into the owner of the rule. The RFC represents IETF process and consensus. IANA maintains the registry. Specification authors write revisions. Tool and product teams implement them. Network operators decide what enters production and carry the result.

This separation is not ceremonial modesty. It prevents the wrong person from becoming responsible for a system they do not control. A registry mistake belongs to the registry process. A parser defect belongs to the implementation chain. A poorly tested rollout belongs to the party that approved it. An RFC author’s name is source provenance, not a transferable operating mandate.

Qin Wu’s contribution is more useful when read narrowly. The document helps the written rule stop contradicting the identity practice on which the registry already relied. It defines the public boundary clearly enough that other actors can retain their own choices and responsibilities.

When written policy catches working practice

Running-Code Primacy does not mean that any behaviour becomes legitimate merely because software performs it. Bad practice can be widespread. An implementation can be convenient and still violate an interoperability or security property. Practice must be tested against the reason the coordination rule exists.

RFC 9890 passes that narrower test. Revisions retaining the initial name and namespace do not weaken initial uniqueness. They make the registry able to express revision history without fabricating a new identity for each editorial change. The practice preserves both the uniqueness boundary and continuity of references.

The correction also demonstrates an accountable way for standards to change. The document states the old rule, names the inconsistency, publishes the replacement text and points to the registry it governs. It does not hide the mismatch behind editorial cleanup. Future reviewers can see exactly which normative sentences moved.

That record is better than pretending the old sentence had always meant something else. A specification gains credibility when it can admit that a durable, bounded practice exposed the wrong abstraction in its text.

Build a revision receipt that survives the next update

Begin with the initial assignment: module or submodule name, module namespace, assigning document and registry timestamp. Mark it explicitly as the initial version. A uniqueness check should run against this layer, not against every later row indiscriminately.

For each revision, record the unchanged identity fields together with revision date, exact file URL, digest, source RFC and predecessor. Preserve whether a tool selected the revision explicitly or accepted an undefined/default choice. An omitted revision-date is not the same evidence as a deliberate selection.

Then extend the chain into software. Record the parser and version, validation output, package or firmware containing the module, import graph, deviations and enabled features. Join that record to staging tests, production approval, rollout scope, observed errors and rollback result.

Dashboards should use different verbs for each stage. IANA registered. An RFC specified. A package included. A parser accepted. A vendor supported. An operator deployed. A service continued or failed. One green status must not speak for the next.

The result is not bureaucratic excess. It is the minimum evidence needed to obtain both things RFC 9890 protects: one stable public identity, and honest visibility into every change made under it.

Sources