An Update to YANG Module Names Registration

RFC 6020 required all YANG module and submodule names in the registry to be unique, but IANA's actual practice allowed re-registration of revised modules under the same name. This document amends RFC 6020 to align the normative guidance with established IANA practice.

yang, registry

Modules and their revisions are now explicitly maintained together in the registry. The updated policy distinguishes between initial version entries (subject to uniqueness) and revision entries (which reuse the initial name and namespace), aligning registry semantics with how YANG module versioning works in practice.

yang, registry, netconf

All initial version module and submodule names in the 'YANG Module Names' registry MUST be unique. This replaces the prior blanket uniqueness requirement that applied to all entries including revisions.

yang, registry, netconf

All module and submodule revisions MUST have the same name as the one in the initial version of the module or submodule. This preserves name stability across revision history.

yang, registry, netconf

All module revisions MUST have the same XML namespace as the initial version of the module. Namespace stability is required across all revisions of a given YANG module.

yang, registry, netconf

All XML namespaces of initial version modules in the 'YANG Module Names' registry MUST be unique. Revised module registrations inherit the namespace of the initial version and are exempt from this uniqueness constraint.

yang, registry, netconf

IANA updated the 'YANG Module Names' registry under the 'YANG Parameters' registry group to list RFC 9890 as an additional reference, making this document authoritative for assigning names in that registry.

yang, registry, netconf

RFC 9890 defines a new IANA action and an update to an existing IANA registration procedure from RFC 6020. It does not introduce any new or increased security risks.

yang, registry, security