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

From: "Ing-Wher (Helen) Chen" <[email-masked]>
Date: Tue, 3 May 2016 14:10:39 +0000

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Thursday, April 28, 2016 5:39 AM
> To: Ing-Wher (Helen) Chen <[email-masked]>
> Cc: Martin Bjorklund <[email-masked]>; [email-masked]
> Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models
> 
> On Wed, Apr 20, 2016 at 03:24:25PM +0000, Ing-Wher (Helen) Chen wrote:
> >
> > The technical problem of generalizing is the difficulty in creating a
> > URN based on domain names that is also persistent.  Limiting the scope
> > of the "rdns" URN namespace to only YANG modules means that there is a
> > smaller persistency problem to solve and that it can be solved by
> > taking advantage of properties specific to YANG modules.
> >
> 
> Can you detail which properties specific to YANG modules make the smaller
> persistency problem solvable?

It's both what YANG module namespaces don't need to have and the limited
case where a non-persistent namespace results in a collision.

The property that YANG module namespaces don 't need to have is that
YANG module namespaces are not used to provide global resolution, where
the persistence of a namespace is particularly important.  (Please see RFC
3406 top of page 13 <https://tools.ietf.org/html/rfc3406#page-13> for the
Identifier persistence discussion.)

The potential collision of a non-persistent namespace is described In the
example in <http://www.ietf.org/mail-archive/web/netmod/current/msg15818.html> .
When a namespace collision does occur, the problem is limited to a device that
has an administrator and the solution is simple.  This is also stated in
draft-chen-rdns-urn , in the "Identifier Persistence Considerations" section at
the bottom of page 5 <https://tools.ietf.org/html/draft-chen-rdns-urn-06#page-5> .

Thanks,
Helen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 May 2016 15:11:46 +0200

On Wed, Apr 20, 2016 at 04:47:55PM +0200, Martin Bjorklund wrote:
> 
> If you really want to limit it to YANG module namespaces, maybe it
> should be called urn:yang-rdns:  or something.

I tend to agree, if this is YANG specific, it should say so. Perhaps it
should be:

  "rdns" URN       ::= urn:yang:<reverse-dns>:<module-name>

An example would be:

  urn:yang:com:acme:acme-interfaces

/js

PS: This is not as 'compact' as a solution where the module name would
    include the rdns part and thus we would not need to have the
    <reverse-dns> part, i.e., we would have just

      "rdns" URN       ::= urn:yang:<module-name>

    which gives us

      urn:yang:org-acme-interfaces

    and this could even make the explicit namespace definition in YANG
    modules go away (with the default that the module org-acme-foo uses
    the namespace URN urn:yang:org-acme-foo).

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Alex Campbell <[email-masked]>
Date: Fri, 27 May 2016 00:53:41 +0000

> From: netmod <[email-masked]> on behalf of Ing-Wher (Helen) Chen <[email-masked]>
> Sent: Thursday, 21 April 2016 2:40 a.m.
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> > Sent: Tuesday, April 19, 2016 2:23 PM
> > Cc: [email-masked]
> > On Tue, Apr 19, 2016 at 04:23:51PM +0000, Ing-Wher (Helen) Chen wrote:
> > > 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.)
> >
> > You write "happen to prefer to use URN" - why?

> draft-chen-rdns-urn Section 4 <https://tools.ietf.org/html/draft-chen-rdns-urn-06#section-4>
> discusses why an enterprise might prefer to use URN over URL.  URL provides
> resource access mechanism, which might mislead a customer to request that
> the YANG module be accessible at a specific location.  It's true that the device
> does not care that the YANG module is not at a particular URL, but I can still
> imagine getting a bug requesting that the YANG module be accessible at the URL.

URLs are frequently used as namespaces in XML, without referring to a particular resource (and most of them are HTTP URLs that return generic error-404 pages).
Does this proposal suggest that YANG namespaces should be treated differently from XML namespaces?