A Uniform Resource Name (URN) Namespace for Enterprise YANG Modules
draft-chen-rdns-urn-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | I. Chen | ||
| Last updated | 2016-02-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-rdns-urn-01
Internet Draft I. Chen
<draft-chen-rdns-urn-01.txt> Ericsson
Category: Informational
Expires in 6 months February 9, 2016
A Uniform Resource Name (URN) Namespace for Enterprise YANG Modules
<draft-chen-rdns-urn-01.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 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: <when submitted to IANA>
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:<revers-dns>:<dss>
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 <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
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 <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 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 <reverse-dns>
portion of the URN is case-insensitive for matches. For the <dss>
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 <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.
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, <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-
Chen Expires in 6 months [Page 6]
Internet Draft rdns URN February 9, 2016
names-20091208>.
[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>.
[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>.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
May 1997, <http://www.rfc-editor.org/info/rfc2141>.
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,
<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
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]