Re: [netmod] update on "rdns" URN for enterprise YANG models

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Apr 15, 2016 at 03:53:04PM +0000, Ing-Wher (Helen) Chen wrote:

> Section 4 of the draft <https://tools.ietf.org/html/draft-chen-rdns-urn-06#section-4> 
> documents why a URN is better than  URL as a namespace.  While a URL is globally
> unique, a URL is also a resource locator, providing access information.  For an enterprise
> that does not wish to publish the access information of its YANG models, a URN is a better
> choice.

Continuing as devil's advocate...

The YANG specifications (both 1.0 and 1.1) has a normative reference to

  https://www.w3.org/TR/2009/REC-xml-names-20091208/

which states in section 3:

  [...] The namespace name, to serve its intended purpose, SHOULD
  have the characteristics of uniqueness and persistence. It is not a
  goal that it be directly usable for retrieval of a schema (if any
  exists). Uniform Resource Names [RFC2141] is an example of a syntax
  that is designed with these goals in mind. However, it should be
  noted that ordinary URLs can be managed in such a way as to achieve
  these same goals.

Do we have evidence that managing ordinary URLs in such a way as to
achieve these same goals (of uniqueness and persistence) is a problem?
If so, why does this only apply to YANG modules (only one of many uses
of XML namespaces)?

> As required by RFC 3406, Section 3 of the draft, at the bottom of page 5
> <https://tools.ietf.org/html/draft-chen-rdns-urn-06#page-5> under "Identifier Persistence
> Considerations", addresses the question of identifier persistence.  The main concern
> for "identifier persistence" is in the case where an identifier is used for global resolution.
> Because YANG model namespaces do not provide global resolutions (actually YANG
> model namespaces are only used to uniquely identify a model within a device),
> the identifier persistence consideration is not as crucial.  (Please see RFC 3406
> top of page 13 <https://tools.ietf.org/html/rfc3406#page-13> for the identifier
> persistence discussion.)

I am not sure I agree that the scope of a YANG namespace is limited to
a device. There is nothing that prevents some random device to
implement some random YANG model. If the org currently owning bar.foo
publishes a module using urn:rdns:com:foo:bar as a namespace then
other orgs can implement this module as well if they think this is a
good idea.

I read:

     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
     "rdns" URNs.

Who is the 'administrator' that consciously installs YANG modules in a
device here? Administrator of what - the namespace or the device? In
case you mean the administrator of the namespace then what happens in
the case where this role changes because some other org took over the
domain name?

If a module uses urn:rdns:com:foo:bar and I later buy the domain
bar.foo than do I get change control of the YANG module using this
particular namespace as a side effect?

[...break...]

Taking a step back, we do have the tension between XML namespaces
(that are identified by URIs and used in the XML encoding) and 'JSON
namespaces' identified by module names (and used in the JSON
encoding). The former is relying on the uniqueness of a URI while the
later is relying on the uniqueness of the YANG module name. So from
this perspective, assuming the YANG module name is already
sufficiently unique, perhaps the right thing to do is to simply use

   urn:yang:<modulename>

for all XML namespaces and to essentially get rid of the namespace
declaration in YANG (which then defaults to urn:yang:<modulename>).

Now I need a break to think about this...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>