Grammar for Enterprise YANG Module Namespace

The use of a standard data modeling language YANG together with Network Configuration Protocol (NETCONF) allows for the creation of a standard network configuration interface. YANG further allows vendors to customize standard YANG modules and to create enterprise YANG modules that adapt standard YANG modules to different devices and features. To identify YANG modules, requires YANG module namespaces of all YANG modules, both standard YANG modules and enterprise YANG modules, be globally unique. also recommends that enterprise YANG modules have module names that are globally unique. Based the module naming convention recommended in , this document defines the grammar to create YANG module namespaces for enterprise YANG modules that result in globally unique namespaces.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, .

consists of several YANG module name and namespace requirements and recommendations. Section 5.3 paragraph 1 states that Each module is bound to a distinct XML namespace , which is a globally unique URI . Section 5.3 paragraph 3 states that XML namespaces for private modules are assigned by the organization owning the module without a central registry. Namespace URIs MUST be chosen so they cannot collide with standard or other enterprise namespaces -- for example, by using the enterprise or organization name in the namespace. Section 6.2.1 paragraph 1 states that Each identifier is valid in a namespace that depends on the type of the YANG item being defined. All identifiers defined in a namespace MUST be unique. o All module and submodule names share the same global module identifier namespace. The requirement in Section 6.2.1 means that even enterprise YANG module names must be globally unique. The recommendation in Section 5.3 means that it is desirable to define enterprise YANG modules names to use an organization's name as a prefix.

This section defines the grammar to create globally unique enterprise YANG module namespaces. The grammar defines a namespace to be a Uniform Resource Name (URN) under the top-level "rdns" name identifier , followed by an organization's reverse registered domain name and optional sub-domain hierarchies, and ending with the module name with the organization's name as the prefix. <namespace> = urn:rdns:<reverse-dns>:<sub-domain><module-name> <reverse-dns> = An organization's registered domain name in reverse <sub-domain> = Empty string or additional levels of hierarchy defined within a domain in which each level is delimited by colons <module-name> = <organization-prefix>-<function> <function> = A string that describes the function provided by the YANG module In discussions on the NETMOD working group mailing list, there are suggestions that the top-level name identifier should be "yang" instead of "rdns". While the final decision on the exact name identifier might not be "rdns", the grammar described in this document is expected to remain as described above.

Suppose a vendor has a registered domain name "example.com". This vendor has also chosen to place all of its YANG modules under the "yang" sub-domain. Following the enterprise YANG module namespace grammar described in this document, the vendor ends up with the patterns below. <reverse-dns> = com:example <sub-domain> = yang <namespace> = urn:rdns:com:example:yang:<module-name> <module-name> = example-<function> As a result, this vendor's OSPF YANG module has the namespace "urn:rdns:com:example:yang:example-ospf".

TBD.

This document does not register any new names with IANA. The registration of the new "rdns" name is done in .