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

[Peter Saint-Andre <[e-mail]>]

On 6/27/12 5:17 PM, SM wrote:

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

Good edit.

>   "To actually leverage the potential synergetic advantage of this
>    unification"
> 
> This is not a document about pharmaceuticals. :-)

Yes, that's some kind of marketing-speak.

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

Sure it could: "This document defines procedures for registering URN
Namepace Identifiers (NIDs) with IANA."

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

I don't think so.

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

That seems sensible.

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

I think it would be helpful to register the 'example' NID
(urn:example:*) and deprecate the experimental NIDs. I'd be happy to
write an I-D registering the NID.

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

I doubt it.

>   "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.

Sure.

> 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".

Good point.

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

Perhaps the author meant the designated 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.

Agreed.

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

Yeah, there's a lot of step-by-step information here. I'm not sure how
useful it is. I'd prefer to tell people the general rules and then
recommend that they look at some of the recent registration documents.

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

It isn't.

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

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/