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

["Ing-Wher (Helen) Chen" <[e-mail]>]

I'm not an expert on XML namespaces and I'm a little confused by some of
the questions, so I apologize if my response below does not quite answer the
questions.  I'd like to point out that the request for "rdns" URN is not to prevent
the use of URLs. The request for "rdns" URN is to allow an enterprise to easily
create a URN namespace, if the enterprise happens to prefer to use URN as a
YANG module namespace.  I also think that the problems that arise when a
YANG module uses a URN based on an enterprise's domain name are the same
problems that arise when a YANG module uses a URL based on an enterprise's
domain name.  (Of course, this is not an excuse to fix the problems that should
be fixed.)

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Friday, April 15, 2016 7:43 PM
> To: Ing-Wher (Helen) Chen <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models
> 
> 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)?

I found some XML namespaces that are URLs,
e.g. http://www.w3.org/1999/XSL/Transform , that look like they're centrally
managed and should have uniqueness and persistence characteristics.  There
are also examples of URLs that do not have a centralized authority to manage
URLs and results in URLs not being persistence, e.g. confluence wiki pages create
URLs based on web page titles and so the wiki page URLs can change at random,
even though the page contents don't change.  (However, confluence wiki pages'
URLs are not used as XML namespaces, and so the lack of persistence is not an
issue.)  So, it seems that it's all about how URLs are managed---in particular,
centrally managed URLs can have uniqueness and persistence characteristics.
I think that this type of centralized management might be problematic for
enterprise YANG modules, which have no centralized authority.

> 
> > 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'd like to flesh out this example to illustrate what I had in mind when I wrote
that YANG model namespaces are only used to uniquely identify a model within
a device.

Assume that device "R" currently implements/installs YANG module "ospf"
from company "A" which, at time T, owns domain "bar.foo", i.e. company "A's"
"ospf" YANG module's namespace is "urn:rdns:foo:bar:ospf".  At time T+delta,
company "A" gives up "bar.foo" and company B buys "bar.foo".  For whatever
reason, company "B" creates some other module "ospf", i.e. company "B's"
new "ospf" YANG module's namespace is also assigned "urn:rdns:foo:bar:ospf",
though this module presumably has contents different from company "A's"
"ospf" YANG modules.  If device "R" decides to implement module "ospf" from
company "A" and module "ospf" from company "B", then there is a collision on
this device "R".  When a NETCONF client attempts to manage device "R" and uses
"urn:rdns:foo:bar:ospf" to identify an "ospf" module, there is a problem, because
device "R" doesn't know which "urn:rdns:foo:bar:ospf" the client is referring to.
If some other device "Q" only implements one single "ospf" module (regardless
of whether the "ospf" module is from company "A" or from company "B"), then
the namespace "urn:rdns:foo:bar:ospf" identifies the one "ospf" module installed
on device "Q", and there are no ambiguities in the event that a NETCONF client
attempts to reference the module identified by "urn:rdns:foo:bar:ospf" on device "Q".
So, the problem of non-unique YANG module namespaces only manifests within
a device.

> 
> 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?

By "administrator", I meant the administrator of the device.

Using the example I fleshed out above, where company "A" initially owns
domain "bar.foo" and creates module "ospf" with namespace
"urn:rdns:foo:bar:ospf", but company "B" later purchases domain "bar.foo"
and also creates its own module "ospf" and gives it namespace
"urn:rdns:foo:bar:ospf". 

While it's true that <https://datatracker.ietf.org/doc/draft-chen-rdns-urn/>
allows this situation to occur, this situation only results in a problem in the
case of device "R" above, after device "R" implements both company "A's" "ospf"
module with namespace "urn:rdns:foo:bar:ospf" and company "B's" "ospf"
module also with namespace "urn:rdns:foo:bar:ospf".  Getting device "R" to
implement both modules is not trivial.  It actually requires obtaining both
modules, installing them on device "R", and perhaps even upgrading device "R's"
software to handle the second module.  In other words, I think that the
collision resulting from non-unique namespaces on device "R" is limited within
a device, therefore the solution can also be limited to the administrator detecting
and rectifying the collision.  I also think that this example holds true in the case
where an enterprise chooses to use URLs based on domain names as YANG
module namespaces.

> 
> [...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>).

This approach would require registering "yang" URN and also would place
constraints on <modulename>.  These constraints might result in the same
questions that we're struggling with now, with URN/URL based on domain
names that can come and go.

Thanks,
Helen