Re: [urn] 3406bis-07 - substantive comments

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

On 1/21/14, 11:54 PM, John C Klensin wrote:
> Hi.
>
> Apologies for the long silence.

Me too. I've had a change of jobs so I have been quite busy with that 
transition. However, I am committed to completing this work!

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

Experiment namespaces were never registered.

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

I suggest adding the following sentence to that paragraph:

    Because experimental namespaces were never
    registered, removing the experimental category has no impact on the
    existing registries or future registration procedures.

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

That's a good idea, just in case. I suggest the following text:

    5.  It MUST NOT start with the string "xn--", which is reserved for
        potential representation of DNS A-labels in the future [RFC5891].

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

Agreed. I suggest the following change.

OLD

    Informal namespaces are full-fledged URN namespaces, with all the
    associated rights and responsibilities.  Informal namespaces differ
    from formal namespaces in the process for assigning a NID: for an
    informal namespace, IANA will assign an NID consisting of the string
    'urn-' followed by one or more digits (e.g., "urn-7").

NEW

    Informal namespaces are full-fledged URN namespaces, with all the
    associated rights and responsibilities.  Informal namespaces differ
    from formal namespaces in the process for assigning a NID: for an
    informal namespace, the registrant does not designate the NID;
    instead, IANA assigns a NID consisting of the string 'urn-' followed
    by one or more digits (e.g., "urn-7") where the digits consist of the
    next available number in the sequence of positive integers assigned
    to informal namespaces.

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

Noted.

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

I suggest:

OLD
    A pointer to an Internet-Draft, RFC, non-IETF specification, or other
    published document that provides further information about the
    namespace.

NEW
    A pointer to an RFC, a specification published by another standards
    development organization, or another stable document that provides
    further information about the namespace.

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

Yes.

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

Agreed. We'd in general do well to avoid the passive voice.

Thus...

OLD
    although the registration policy for formal namespaces is Expert
    Review and a specification is not required, the designated experts
    for NID registration requests are encouraged to prefer that a
    specification exist documenting the namespace definition.

NEW
    although the registration policy for formal namespaces is Expert
    Review and stable a specification is not strictly required, the
    designated experts for NID registration requests ought to encourage
    applicants to provide a stable specification documenting the
    namespace definition.

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

Maybe. Let's discuss that a bit more on the list here.

Peter

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