idnits 2.17.1 draft-chen-netmod-enterprise-yang-namespace-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 13, 2016) is 2752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD I. Chen 3 Internet-Draft Kuatro Technologies 4 Intended status: Informational October 13, 2016 5 Expires: April 16, 2017 7 Grammar for Enterprise YANG Module Namespace 8 draft-chen-netmod-enterprise-yang-namespace-03 10 Abstract 12 This document defines the grammar to create enterprise YANG module 13 namespaces that are globally unique, as required by the YANG modeling 14 language. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 16, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. YANG Module Name and Namespace Requirements and 53 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Enterprise YANG Module Namespace Grammar . . . . . . . . . . 3 55 4. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 60 7.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 The use of a standard data modeling language YANG [RFC7950] together 66 with Network Configuration Protocol (NETCONF) [RFC6241] allows for 67 the creation of a standard network configuration interface. YANG 68 further allows vendors to customize standard YANG modules and to 69 create enterprise YANG modules that adapt standard YANG modules to 70 different devices and features. To identify YANG modules, [RFC7950] 71 requires YANG module namespaces of all YANG modules, both standard 72 YANG modules and enterprise YANG modules, be globally unique. 73 [RFC7950] also recommends that enterprise YANG modules have module 74 names that are globally unique. 76 Based the module naming convention recommended in [RFC7950], this 77 document defines the grammar to create YANG module namespaces for 78 enterprise YANG modules that result in globally unique namespaces. 80 1.1. Terminology 82 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described in BCP 85 14, [RFC2119]. 87 2. YANG Module Name and Namespace Requirements and Recommendations 89 [RFC7950] consists of several YANG module name and namespace 90 requirements and recommendations. 92 [RFC7950] Section 5.3 paragraph 1 states that 94 Each module is bound to a distinct XML namespace [XML-NAMES], which 95 is a globally unique URI [RFC3986]. 97 [RFC7950] Section 5.3 paragraph 3 states that 99 XML namespaces for private modules are assigned by the organization 100 owning the module without a central registry. Namespace URIs MUST be 101 chosen so they cannot collide with standard or other enterprise 102 namespaces -- for example, by using the enterprise or organization 103 name in the namespace. 105 [RFC7950] Section 6.2.1 paragraph 1 states that 107 Each identifier is valid in a namespace that depends on the type of 108 the YANG item being defined. All identifiers defined in a namespace 109 MUST be unique. 111 o All module and submodule names share the same global module 112 identifier namespace. 114 The requirement in [RFC7950] Section 6.2.1 means that even enterprise 115 YANG module names must be globally unique. The recommendation in 116 [RFC7950] Section 5.3 means that it is desirable to define enterprise 117 YANG modules names to use an organization's name as a prefix. 119 3. Enterprise YANG Module Namespace Grammar 121 This section defines the grammar to create globally unique enterprise 122 YANG module namespaces. The grammar defines a namespace to be a 123 Uniform Resource Name (URN) under the top-level "rdns" name 124 identifier [rdns], followed by an organization's reverse registered 125 domain name and optional sub-domain hierarchies, and ending with the 126 module name with the organization's name as the prefix. 128 = urn:rdns:: 130 = An organization's registered domain name in reverse 132 = Empty string or additional levels of hierarchy defined 133 within a domain in which each level is delimited by colons 135 = - 137 = A string that describes the function provided by the 138 YANG module 140 In discussions on the NETMOD working group mailing list, there are 141 suggestions that the top-level name identifier should be "yang" 142 instead of "rdns". While the final decision on the exact name 143 identifier might not be "rdns", the grammar described in this 144 document is expected to remain as described above. 146 4. Usage Example 148 Suppose a vendor has a registered domain name "example.com". This 149 vendor has also chosen to place all of its YANG modules under the 150 "yang" sub-domain. Following the enterprise YANG module namespace 151 grammar described in this document, the vendor ends up with the 152 patterns below. 154 = com:example 156 = yang 158 = urn:rdns:com:example:yang: 160 = example- 162 As a result, this vendor's OSPF YANG module has the namespace 163 "urn:rdns:com:example:yang:example-ospf". 165 5. Security Considerations 167 TBD. 169 6. IANA Considerations 171 This document does not register any new names with IANA. The 172 registration of the new "rdns" name is done in [rdns]. 174 7. References 176 7.1. Normative References 178 [rdns] Chen, I., "Work in progress, 'draft-chen-rdns-urn- 179 07.txt'", September 2016. 181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 182 Requirement Levels", BCP 14, RFC 2119, 183 DOI 10.17487/RFC2119, March 1997, 184 . 186 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 187 Resource Identifier (URI): Generic Syntax", STD 66, 188 RFC 3986, DOI 10.17487/RFC3986, January 2005, 189 . 191 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 192 RFC 7950, DOI 10.17487/RFC7950, August 2016, 193 . 195 [XML-NAMES] 196 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 197 Thompson, "Namespaces in XML 1.0 (Third Edition)", 198 Recommendation REC-xml-names-20091208, December 2009. 200 7.2. Informative References 202 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 203 and A. Bierman, Ed., "Network Configuration Protocol 204 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 205 . 207 Author's Address 209 I. Chen 210 Kuatro Technologies 212 Email: ichen@kuatrotech.com