[urn] Comments on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02

[SM <[e-mail]>]

Hi,

This comments are on draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.  The 
Abstract Section is too long.  The draft is about procedures to 
register a URN namespace.

In the Introduction Section:

   "URNs are part of the larger Uniform Resource Identifier (URI) family
    (see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF
    STD 66, RFC 3986 [RFC3986]) with the specific goal of providing
    persistent naming of resources."

The first line is useful; the rest is unnecessary information.

   "To actually leverage the potential synergetic advantage of this
    unification"

This is not a document about pharmaceuticals. :-)

   'The purpose of this document is to outline a mechanism and provide a
    template for explicit URN Namespace definition, as well as provide
    the mechanism for associating an identifier (called a "Namespace ID",
    or NID), which is registered with the Internet Assigned Numbers
    Authority (IANA) [IANA] in the URN Namespaces registry maintained at
    [IANA-URN].'

Could this text be made shorter?

   "The URN Namespace definition and registration mechanisms originally
    have been specified in RFC 2611 [RFC2611], which has been obsoleted
    by BCP 66, RFC 3406 [RFC3406].  Guidelines for documents prescribing
    IANA procedures have been revised as well over the years, and at the
    time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative
    document.  This document is a revision of RFC 3406 based on the
    revised URN Syntax specification RFC 2141bis
    [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226."

There is ample historical information.  Is it necessary in the introduction?

The discussion about URN namespace (Section 2) should be moved to 
draft-ietf-urnbis-rfc2141bis-urn-02.

In Section 3.1:

   "No provision is made for avoiding collision of experimental NIDs;
    they are intended for use within internal or limited experimental
    contexts.  However, as described below in Section 4.1, these are
    designated by a specific form of the NID to allow differentiation
    (without preexisting knowledge of details) from the other URN
    Namespace types."

This could be formulated as guidance about when NIDs should be 
registered.  Given the discussion about X- for other protocols, it's 
better to also drop it here.

In Section 4:

   "The IANA Considerations Guidelines document (BCP 26 [RFC5226])
    suggests the need to specify update mechanisms for registrations --
    who is given the authority to do so, from time to time, and what are
    the processes."

Why is this text needed in this draft?

   "The official list of registered URN Namespaces is currently
    maintained by IANA at [IANA-URN]."

The "who" is not important.  What is important is to point the reader 
to the location of the list of URN Namespaces.

In Section 4.3:

   "The designated expert(s) for URN Namespace registrations are
    nominated by the IESG, and their role adheres to the regulations
    in BCP 26, unless specified otherwise below."

BCPs are not about regulations.  I suggest using the term "guidelines".

   'Applicants, in concert with the IANA experts, should ensure that
    the sought NID strings are "proper" for the designated purpose,
    according to common sense (and applicable legal rules).'

Who are the IANA experts?

   '"IETF Review" (per [RFC5226]) means that the Formal NID application
    is made via submission to the IETF of an Internet-Draft that contains
    the Namespace definition and targets publication as an RFC of
    Informational or Standards-Track category, which needs to be approved
    by the IESG after performing an IETF Last Call on the document and
    evaluating review comments.  The applicant can be an individual or an
    IETF working group, in alignment with the designation of the
    Internet-Draft.  The actual choice should be properly considered by
    applicants, but it is RECOMMENDED that the registration documents for
    NIDs belonging to an established standard namespace aim at Standards-
    Track, whereas other applications aim at Informational RFC.'

There is a reference to RFC 5226 in this draft.  The reader 
interested in the details of "IETF Review" can find the information 
in that RFC.  I don't think that it is a good idea to explain about 
IETF process in this draft.

In Section 4.4.3:

   'According to the general procurements for RFCs, URN Namespace
    definition documents must include a "Security Considerations" section
    (cf. BCP 72 [RFC3552]).  That section has to identify the security
    considerations specific to the subject URN Namespace.'

The above should be trimmed.  Provide the reader with actionable 
information so that the person knows what security issues to look out for.

Why is Section 4.4.4 needed?  This should be more about how to devise 
an appropriate registration request.  This section seems like 
registration guidelines.

In Section 6:

   "Until recently, that registry has been available in HTML, XML, and
    plain text from the generic web page at
    <http://www.iana.org/assignments/urn-namespaces/> [IANA-URN]"

Why is it important to tell IANA that the registry is available in 
three formats?

Appendix A is informative for the registrant.  I suggest separating 
the template and the "how to fill" information.

AppendiX B reminds me of another RFC where the WG replicated 
information about procedures to help future authors.  The draft 
should be about the registration steps in practice instead of a 
"formal" section and the actual steps.

The draft is well-written.  It should be ready with a little more work.

Regards,
-sm

P.S. I did not cross-check all the details due to time constraints.