Internet DRAFT - draft-chen-rdns-urn
draft-chen-rdns-urn
Internet Draft I. Chen
<draft-chen-rdns-urn-07.txt> Ericsson
Category: Informational
Expires in 6 months September 19, 2016
A Uniform Resource Name (URN) Namespace for Enterprise YANG Modules
<draft-chen-rdns-urn-07.txt>
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 September 19, 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 September 19, 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 September 19, 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: <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> | <other>
<rdns-hex> ::= <number> | "a" | "b" | "c" | "d" | "e" |
"f"
<lower>, <number>, and <other> are the same as those defined in
[RFC2141].
Chen Expires in 6 months [Page 4]
Internet Draft rdns URN September 19, 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
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 September 19, 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
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 <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.
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 September 19, 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-
editor.org/info/rfc6020>.
[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-
names-20091208>.
Chen Expires in 6 months [Page 7]
Internet Draft rdns URN September 19, 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-
editor.org/info/rfc3986>.
[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-
editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc5890>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[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,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <http://www.rfc-
editor.org/info/rfc3688>.
[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-
editor.org/info/rfc2616>.
Author's Address
Chen Expires in 6 months [Page 8]
Internet Draft rdns URN September 19, 2016
I. Chen
ichen@kuatrotech.com
Chen Expires in 6 months [Page 9]
