Summary

  • RFC 9890 updates RFC 6020's registration wording for YANG module and submodule names.
  • Initial-version names and XML namespaces remain unique, while later revisions reuse the initial name and namespace.
  • IANA's YANG Module Names registry procedure is authoritative for assigning those names; registry identity is not a revision-aware deployment inventory.

RFC 6020 said that all module and submodule names, and all XML namespaces, in the registry must be unique. RFC 9890 explains that this wording did not match IANA's practice for revisions. Under the updated rule, uniqueness applies to the initial version: an initial module or submodule name remains unique, and an initial module XML namespace remains unique. Every later revision retains the initial name and the same XML namespace.

That continuity is deliberate. A consumer can recognize the module family without treating each revision as a new registered identity. The boundary matters operationally, however. A registry lookup by name or namespace answers which identity is registered; it does not, without revision metadata and the relevant module artifact, answer which revision is installed, validated, or safe to restore. Nor does it establish that successive revisions are semantically compatible.

IANA lists RFC 9890 as an additional reference because its procedure is authoritative for assigning names in the YANG Module Names registry. The frozen IANA snapshot is evidence of registry state observed on 2026-09-05, not evidence of implementation quality, operator adoption, tooling compatibility, or correctness of any particular revision.

Theo March analysis—not an RFC 9890 requirement: treating a stable name as a complete deployment key creates an identity ambiguity. In automation, that ambiguity can become inventory drift: a record may point to the right module family while validation and deployment used different revisions. The practical control is to retain the revision identifier, source artifact or digest, validation result, and rollback target alongside the stable name and namespace.

Verification fixtures

A minimal fixture should contain: module name example-module; XML namespace urn:example:module; initial revision 2024-01-01; later revision 2025-06-01; the registry lookup result; the exact artifact validated; and the artifact retained for rollback. Verify that both revisions retain the same name and namespace, then verify that inventory records distinguish their revision dates or equivalent revision metadata. A second fixture should intentionally omit revision metadata. Its expected result is a failed control check, not an inference that the artifacts are equivalent. These are operational tests proposed in this briefing, not requirements created by RFC 9890.

Operator decision path

  1. Resolve the registered name and namespace through the authoritative registry procedure.
  2. Retrieve and record the exact revision metadata and module artifact used for validation.
  3. Compare the deployed revision with the validated revision before activation.
  4. Store a revision-specific rollback target and evidence that it was retained.
  5. If revision identity is missing, pause promotion or rollback; do not infer compatibility from the stable registry identity.

The evidence set does not measure how many tools assumed globally unique names across all revisions. It establishes no operator incident, interoperability failure, or migration cost. RFC 9890 does not validate semantic compatibility between successive revisions. The frozen IANA snapshot may change after observation. Vendor support and deployment prevalence are outside the source set.

Sources

RFC 9890 says the change aligns policy with existing registry practice and introduces no new operations or manageability requirements. It also states that it introduces no new or increased security risks requiring discussion.