[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07

Internet Draft                                                   I. Chen
<draft-chen-rdns-urn-05.txt>                                    Ericsson
Category: Informational
Expires in 6 months                                        March 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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 9, 2016


   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 9, 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

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

Chen                       Expires in 6 months                  [Page 3]

Internet Draft                  rdns URN                   March 9, 2016

   "OPTIONAL" in this document are to be interpreted as described in

3.  URN Specification for Enterprise YANG Module Namespace Identifier

   Namespace ID:

     Request "rdns"

   Registration Information:

     Version Number: 1

     Date: <when submitted to IANA>

   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:<reverse-dns>:<dss>

       <reverse-dns>    ::= registered domain name in reverse, each label
                            separated by a colon (":") and all letters
                            MUST be written in lowercase letters

       <dss>            ::= 1*<rdns-URN-char>

       <rdns-URN-char>  ::= <rdns-trans> | "%" <rdns-hex> <rdns-hex>

       <rdns-trans>     ::= <lower> | <number> | <others> | <reserved>

       <rdns-hex>       ::= <number> | "a" | "b" | "c" | "d" | "e" |

     <lower>, <number>, <others>, and <reserved> are the same as those
     defined in [RFC2141].

Chen                       Expires in 6 months                  [Page 4]

Internet Draft                  rdns URN                   March 9, 2016

     With the grammar above, a valid "rdns" URN MUST consist of
     "urn:rdns" in lowercase letters.

     The reverse registered domain name <reverse-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 <reverse-dns> 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
     <reverse-dns> MUST be in lowercase letters.

     The domain specific string <dss> is a mandatory string with at
     least one <rdns-URN-char>.  The structure of the string <dss> is
     opaque, because it is defined by the organization encoded in
     <reverse-dns>.  <dss> 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 <dss> MUST
     guarantee the uniqueness of <dss> within its organization.  Using a
     <dss> 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

   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 9, 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 <reverse-dns> portion of the URN is "com:ericsson".  As
     mentioned above, the <dss> 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

   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 <reverse-dns> 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.


     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 9, 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, <http://www.rfc-

   [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, <http://www.w3.org/TR/2009/REC-xml-

Chen                       Expires in 6 months                  [Page 7]

Internet Draft                  rdns URN                   March 9, 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, <http://www.rfc-

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI
              10.17487/RFC2119, March 1997, <http://www.rfc-

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
              May 1997, <http://www.rfc-editor.org/info/rfc2141>.

   [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, <http://www.rfc-editor.org/info/rfc1035>.

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, <http://www.rfc-

   [RFC2276]  Sollins, K., "Architectural Principles of Uniform Resource
              Name Resolution", RFC 2276, DOI 10.17487/RFC2276, January
              1998, <http://www.rfc-editor.org/info/rfc2276>.

   [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, <http://www.rfc-

Author's Address

Chen                       Expires in 6 months                  [Page 8]

Internet Draft                  rdns URN                   March 9, 2016

   I. Chen

Chen                       Expires in 6 months                  [Page 9]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/