Internet Draft I. Chen Ericsson Category: Informational Expires in 6 months February 9, 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 February 9, 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 February 9, 2016 Table of Contents 1. Introduction ....................................................3 2. URN Specification for the Enterprise YANG Module Namespace Identifier ......................................................3 3. Namespace Considerations ........................................6 4. Community Considerations ........................................6 5. Security Considerations .........................................6 6. IANA Considerations .............................................6 7. References ......................................................6 7.1. Normative References .......................................6 7.2. Informative References .....................................7 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, specifies an XML namespace [XML-NAMES], and that the XML namespace must be a globally unique Uniform Resource Identifier (URI) [RFC3986]. To date, IETF standard YANG modules registers 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. URN Specification for Enterprise YANG Module Namespace Identifier Namespace ID: Request "rdns" Chen Expires in 6 months [Page 3] Internet Draft rdns URN February 9, 2016 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: URNs that use the "rdns" NID shall have the following structures: urn:rdns:: The reverse registered domain name (revers-dns) 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 domain specific string (dss) is a mandatory string defined by the organization. The structure of this string is opaque. It is a string that identifies 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. 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 Chen Expires in 6 months [Page 4] Internet Draft rdns URN February 9, 2016 different YANG module. 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 a 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: Because domain names are case-insensitive, the portion of the URN is case-insensitive for matches. For the portion of the URN, the rules for lexical equivalence are specified in [RFC2141]. 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. Chen Expires in 6 months [Page 5] Internet Draft rdns URN February 9, 2016 3. Namespace Considerations [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 a 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. 4. 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. 5. Security Considerations This document does not introduce new security considerations beyond those associated with the use and resolution of URNs in general. 6. 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 2. 7. References 7.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, . [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, . [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, . [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, May 1997, . 7.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 I. Chen ichen@kuatrotech.com Chen Expires in 6 months [Page 7] Internet Draft rdns URN February 9, 2016 Chen Expires in 6 months [Page 8]