RE: two-week review: registering formal "rdns" NID

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

Hi Dale,

Thanks for the review.  I uploaded revision -02 to address your comments. 

URL:       <https://www.ietf.org/internet-drafts/draft-chen-rdns-urn-02.txt>
Status:   <https://datatracker.ietf.org/doc/draft-chen-rdns-urn/>
Htmlized:       <https://tools.ietf.org/html/draft-chen-rdns-urn-02>
Diff:        <https://www.ietf.org/rfcdiff?url2=draft-chen-rdns-urn-02>

Please see below for my in-line responses.

> -----Original Message-----
> From: Dale R. Worley [mailto:[e-mail]]
> Sent: Thursday, February 11, 2016 3:11 PM
> To: Ing-Wher (Helen) Chen <[e-mail]>
> Cc: [e-mail]
> Subject: Re: two-week review: registering formal "rdns" NID
> 
> Comments on draft-chen-rdns-urn-00:

[Helen]  Just a note that at the time that I submitted to
               [e-mail] for review, the latest version was -01.

> 
> I don't know how much this matters, but the owner of a domain name can
> change over time.  This gave us some trouble when writing RFC 7462, and
> eventually we gave up on using domain names as a basis for URNs.
> There's a URN NID which I can't find right now which bases uniqueness on
> domain names, but the URNs include a timestamp of creation.

[Helen]  I added a new paragraph to about this in the section on
               "Identifier persistence considerations".  "rdns" URNs are only
               Meaningful within a managed device that installs YANG modules
               using "rdns" URNs, and so collisions due to domain name ownership
               changes are expected to be caught.  Furthermore, it is unlikely that
               changing domain name ownerships will result a problem caused by
               a single device installing modules to have identical "rdns" URNS,
               because this would require that the device install a new YANG
               module from the new owner of a domain name and also install the
               stale YANG module from the old owner of the domain name.  It is
               more likely that a device continues to install two stale YANG
               modules with two "rdns" URN  that don't collide.

> 
> The rule for lexical equivalence can't be implemented because there is no
> algorithm for parsing an "rdns" URN into <reverse-dns> and <dss>, and the
> lexical equivalence rule specifies that <reverse-dns> is case-insensitive and
> <dss> is case-sensitive (as far as I can tell; you should update the wording).

[Helen]  I updated the section on "Rules for Lexical Equivalence".  On second
               thought, because "rdns" URNs are meant to be XML namespaces of
               enterprise YANG modules, I think the rules for lexical equivalence for
               "rdns" URNs should be as defined for those of XML namespaces.

> 
> The nonterminal "revers-dns" is used in some places, and in other places,
> "reverse-dns" is used.  I suggest cosistently using the latter.
> 

[Helen]  Fixed.  They should all read "reverse-dns".

> I suggest consistently using <...> around nonterminal names.

[Helen]  Fixed.

> The grammar of <reverse-dns> is implicitly given by the grammar of domain
> names, but the grammar of <dss> is unspecified.  I suggest that you add
> 
>     <dss> ::= 1*<URN chars>

[Helen]  Added to the section on "Declaration of syntactic structure".

>
> Given that internationalized domain names are coming into use, you should
> specify that <reverse-dns> is based on the A-label form [RFC 5890] for
> internationalized labels, i.e., the labels as turned into ASCII by Punycode.

[Helen]  Added to "Declaration of syntactic structure" paragraph 2 and
               "Relevant ancillary documentation".

> 
> Dale

Thanks,
Helen