Internet Draft I. Chen Ericsson Category: Informational Expires in 6 months March 18, 2016 A Uniform Resource Name (URN) Namespace for Enterprise YANG Modules Status of this Memo Distribution of this memo is unlimited. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in 6 months. 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. Chen Expires in 6 months [Page 1] Internet Draft rdns URN March 18, 2016 Abstract This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources to uniquely identify enterprise YANG modules. This document defines a single top level "rdns" Namespace identifier (NID), with which organizations and enterprises can define Uniform Resource Name (URN) Namespaces to uniquely identify enterprise YANG modules. Chen Expires in 6 months [Page 2] Internet Draft rdns URN March 18, 2016 Table of Contents 1. Introduction ....................................................3 2. Keywords ........................................................3 3. URN Specification for the Enterprise YANG Module Namespace Identifier ......................................................4 4. Namespace Considerations ........................................7 5. Community Considerations ........................................7 6. Security Considerations .........................................7 7. IANA Considerations .............................................7 8. References ......................................................7 8.1. Normative References .......................................7 8.2. Informative References .....................................8 1. Introduction The use of a standard data modeling language YANG [RFC6020] together with Network Configuration Protocol (NETCONF) [RFC6241] allows for the creation of a standard network management interface. A networking device that supports such a standard network configuration interface supports NETCONF as well as a set of YANG modules, allowing administrators to manage data defined by the supported YANG modules in a single uniform manner, regardless of the make and model of the device. To identify YANG modules, RFC 6020 Section 5.3 [RFC6020] requires that each YANG module, whether it is a standard YANG module or not, specify an XML namespace [XML-NAMES], and that the XML namespace be a globally unique Uniform Resource Identifier (URI) [RFC3986]. To date, IETF standard YANG modules register their XML namespaces with the IETF XML namespaces [RFC3688] that fall under the "ietf" Namespace Identifier (NID). Various standards governing bodies such as IEEE are also in the process of registering NIDs for their respective standard YANG module XML namespaces. As a shortcut, this document registers the "rdns" NID for organizations such as commercial companies or open source communities to create globally unique XML namespaces when they create and publish enterprise YANG modules. An organization can use the "rdns" NID and append its registered domain name in reverse, followed by a string that is unique within its organization, to create a globally unique XML namespace for its enterprise YANG module without incurring extra effort to register a new NID. 2. Keywords The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and Chen Expires in 6 months [Page 3] Internet Draft rdns URN March 18, 2016 "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. URN Specification for Enterprise YANG Module Namespace Identifier Namespace ID: Request "rdns" Registration Information: Version Number: 1 Date: Declared Registrant of the Namespace: Registering organization: IETF Netmod Working Group Designated contact: ichen@kuatrotech.com Declaration of Syntactic Structure: An "rdns" URN is meant to be XML namespaces, and thus should follow the rules from both [RFC2141] and [XML-NAMES] for its character set and also when evaluating for lexical equivalence. For ease of determining lexical equivalence, all letters MUST be in lowercase letters. Based on these constraints, URNs that use the "rdns" NID shall have the following structures: "rdns" URN ::= urn:rdns:: ::= registered domain name in reverse, each label separated by a colon (":") and all letters MUST be written in lowercase letters ::= 1* ::= | "%" ::= | | ::= | "a" | "b" | "c" | "d" | "e" | "f" , , and are the same as those defined in [RFC2141]. Chen Expires in 6 months [Page 4] Internet Draft rdns URN March 18, 2016 With the grammar above, a valid "rdns" URN MUST consist of "urn:rdns" in lowercase letters. The reverse registered domain name is a mandatory string that is an organization's complete registered domain name in reverse. The structure of the string is an organization's domain name from the least specific label to the most specific label, using colons (":") to separate labels. The string is based on the A-label form [RFC5890] for internationalized labels, i.e., the labels as turned into ASCII by Punycode. All letters in MUST be in lowercase letters. The domain specific string is a mandatory string with at least one . The structure of the string is opaque, because it is defined by the organization encoded in . is a string for the organization to identify the name or hierarchies of names the organization uses to identify its enterprise YANG module. Relevant Ancillary Documentation: See [RFC1034] and [RFC1035] for definitions and conventions of registered domain names, and [RFC5890] for the A-label form for internationalized labels within domain names. Identifier Uniqueness Considerations: An organization that provides the domain specific string MUST guarantee the uniqueness of within its organization. Using a that is unique within an organization in conjunction with a globally unique registered domain name (albeit in reverse) and the new "rdns" top-level NID, a URN is guaranteed to be globally unique. Identifier Persistence Considerations: Persistence of an "rdns" URN is dependent upon the organization that owns the registered domain name encoded in the URN to continue to own the domain name and also to not reassign the URN to a different YANG module. Organizations that change their domain names MUST republish their enterprise YANG modules to use "rdns" URNs with the new domain name. In practice, an administrator consciously installs YANG modules in a device. Thus, in the unlikely event that there is a collision due to changing domain names, the administrator can detect the collision and rectify the situation by requesting that the offending organization republish its YANG modules with the correct Chen Expires in 6 months [Page 5] Internet Draft rdns URN March 18, 2016 "rdns" URNs. Process of Identifier Assignment: The assignment of an "rdns" URN is delegated to the organization that has registered the domain name encoded in the URN. For example, Ericsson registers for the domain name ericsson.com and can assign URNs with the prefix "urn:rdns:com:ericsson", where the portion of the URN is "com:ericsson". As mentioned above, the portion of the URN is assigned by the registrant of the domain name ericsson.com. Process for Identifier Resolution: "rdns" URNs are not intended to be accessible for global resolution. Rather, they are only intended to uniquely identify enterprise YANG modules (within a networking device). Resolution of an "rdns" URN is delegated to the organization owning the registered domain name encoded in the URN. If an organization that owns the registered domain name wishes for its "rdns" URNs to be resolvable, then the organization must register with the Resolution Discovery System [RFC2276]. Rules for Lexical Equivalence: Two valid "rdns" URNs are identical if and only if the strings are identical. Conformance with URN Syntax: No special considerations. Validation Mechanism: Validation mechanism is controlled by the organization that owns the registered domain name. If an "rdns" URN contains an invalid domain name in the portion, then the URN is invalid. In reality, an "rdns" URN is only meaningful in the context of YANG modules installed and supported in a device. Consequently, the "rdns" URNs in use should all be valid. Scope: The scope of an "rdns" URN is limited to enterprise YANG modules. 4. Namespace Considerations Chen Expires in 6 months [Page 6] Internet Draft rdns URN March 18, 2016 [RFC6020] suggests that for enterprise YANG modules to have globally unique XML namespaces, one possibility is to use Uniform Resource Locators (URLs) based on an organization's registered domain name. However, in addition to being a globally unique identifier, a URL is also a resource locator, providing information about the resource's primary access mechanism. Consequently, an enterprise YANG module using a URL as its XML namespace also identifies the location of the resource, which is not necessarily the desired outcome. For example, an enterprise forced to use the URL http://www.example.com/yang/ospf as its YANG module XML namespace might not wish to make the YANG module available via HTTP [RFC2616], even though that is what using a URL implies. Using "rdns" URNs defined in this document yields globally unique XML namespaces which do not have the side effect of URLs that imply how to obtain resources. 5. Community Considerations The "rdns" NID is intended for organizations such as enterprises and open source communities to easily create globally unique XML namespaces for enterprise YANG modules, without the need for all organizations to register their own NIDs. 6. Security Considerations This document does not introduce new security considerations beyond those associated with the use and resolution of URNs in general. 7. IANA Considerations This document defines a new URN NID registration for "rdns" in IANA's "Formal URN Namespace" registry. The completed registration template is in Section 3. 8. References 8.1. Normative References [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [XML-NAMES] Hollander, D., Tobin, R., Thompson, H., Bray, T., and A. Layman, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, . Chen Expires in 6 months [Page 7] Internet Draft rdns URN March 18, 2016 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, May 1997, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . 8.2. Informative References [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, DOI 10.17487/RFC2276, January 1998, . [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, . Author's Address Chen Expires in 6 months [Page 8] Internet Draft rdns URN March 18, 2016 I. Chen ichen@kuatrotech.com Chen Expires in 6 months [Page 9]