Grammar for Enterprise YANG Module Namespace
draft-chen-netmod-enterprise-yang-namespace-02

Abstract

This document defines the grammar to create enterprise YANG module namespaces that are globally unique, as required by the YANG modeling language.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 16, 2017.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Terminology
• 2. YANG Module Name and Namespace Requirements and Recommendations
• 3. Enterprise YANG Module Namespace Grammar
• 4. Usage Example
• 5. Security Considerations
• 6. IANA Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

1. Introduction

The use of a standard data modeling language YANG [RFC7950] together with Network Configuration Protocol (NETCONF) [RFC6241] 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, [RFC7950] requires YANG module namespaces of all YANG modules, both standard YANG modules and enterprise YANG modules, be globally unique. [RFC7950] also recommends that enterprise YANG modules have module names that are globally unique.

Based the module naming convention recommended in [RFC7950], this document defines the grammar to create YANG module namespaces for enterprise YANG modules that result in globally unique namespaces.

1.1. Terminology

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, [RFC2119].

2. YANG Module Name and Namespace Requirements and Recommendations

[RFC7950] consists of several YANG module name and namespace requirements and recommendations.

[RFC7950] Section 5.3 paragraph 1 states that

Each module is bound to a distinct XML namespace [XML-NAMES], which is a globally unique URI [RFC3986].

[RFC7950] 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.

[RFC7950] 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 [RFC7950] Section 6.2.1 means that even enterprise YANG module names must be globally unique. The recommendation in [RFC7950] Section 5.3 means that it is desirable to define enterprise YANG modules names to use an organization's name as a prefix.

3. Enterprise YANG Module Namespace Grammar

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 [rdns], 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.

4. Usage Example

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".

5. Security Considerations

TBD.

6. IANA Considerations

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

7. References

7.1. Normative References

7.2. Informative References

Author's Address