[urn] 3406bis-07 - substantive comments

[John C Klensin <[e-mail]>]

Hi.

Apologies for the long silence.

The comments below are ones that WG participants should review
because they contain suggestions for changes to the Namespace
Definition Mechanisms spec
(draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07) that some may
consider substantive.   Editorial comments that are mostly for
Peter by that I will post for the information of the WG will
follow, as will an updated version of the transition I-D.

best wishes to all for what is left of 2014

    john

-------------------------

(1) End of Section 4 proper (before 4.1): It seems to me that
you need to say what happens with any Experimental namespaces
that are in the registry.  You should either say "there aren't
any", specify that they are automatically reclassified as
"formal", or specify that they have to be registered or
re-registered using this document's template and indicate that
formal namespaces starting in "x-" are explicitly allowed.
Presumably the prohibition of trailing hyphens in 2141bis
eliminates the possibility of someone registering "x-" itself
as an NID, but clarity might benefit by mentioning that in this
Note or in the syntax description bullets of Section 4.1.

(2) End of Section 4.1: Just a question, but would there be
any point in further reserving "xn--".

(3) Section 4.2 or IANA Considerations (Section 9): I think
this document needs to be clear about whether the expectation
is that IANA will assign the next available number or whether
applicants get to pick their favorite number as long as it
isn't assigned already.   I don't have a preference about the
choice, but I think the document needs to give IANA clear
instructions.

(4) Given the recent and ongoing privacy snit, there are
several places in this spec where at least a nod to potential
privacy issues would be in order.  For example, Section 5.4
might indicate that any privacy issues other than "leakage
of..." should be described and the second paragraph of Section
10 might say "...potential security and privacy issues...".

(5) Sections 6.9 and 8: I'd be a lot happier with this if there
was a clear preference expressed for what the RFC Editor
traditionally describes as a "stable specification", especially
since IANA has seemingly gone out of the business of keeping
library of documents submitted in support of registrations.
That is expecially important given the formal non-archival
status of I-Ds and the observation that "published document"
doesn't have nearly as much meaning today as it might have had
20 or 30 years ago.  If you/we really want to allow I-Ds, I
recommend "Any Internet-Draft, RFC, specification, or other  
stable document..." in 6.9 and "...Expert Review and a stable
and clear specification is not required, the designated
experts for NID registration requests are encouraged to prefer
that a stable specification exist documenting the namespace
definition." in Section 8.

I think the intent of that sentence in Section 8 might be a bit
more clear if it said "...experts for NID registration requests
should strongly encourage applicants to provide a stable
specification that documents...".

(6) Section 7.1, item 4: It seems to me that this allows a
possibility in which the designated experts simply refuse to
approve and application, perhaps by engaging in never-ending
nitpicking.   Do we need an appeal procedure?