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

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 Feb 2014 13:12:06 -0700

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/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 Feb 2014 14:15:49 -0700

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

Is the appeals process perhaps covered by Section 7 of RFC 5226, which 
in turn references Section 6.5 of RFC 2026?

Or would we prefer something a bit less heavy?

Peter

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 Feb 2014 15:52:22 -0500

--On Tuesday, 11 February, 2014 14:15 -0700 Peter Saint-Andre
<[email-masked]> wrote:

> Is the appeals process perhaps covered by Section 7 of RFC
> 5226, which in turn references Section 6.5 of RFC 2026?
> 

It seems to me that it would be useful to devise some sort of
mediation process in which experts with different perspectives
could examine things as a group.   The difficulty with
2026-style appeals processes and URNs is that, as we have seen
in this WG, there may be fundamental differences in perspective
and assumptions among experts and those who think they are.
There is no particular reason to believe that the IESG, as a
group and long term, will have the expertise needed to
facilitate a useful discussion, much less be able to reach
conclusions/ judgments that everyone will trust and accept.

On the other hand, I don't know whether this WG has the
expertise or energy needed to devise such a system.

    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 Feb 2014 16:00:56 -0500

--On Tuesday, 11 February, 2014 13:12 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>> as an NID, but clarity might benefit by mentioning that in
>> this Note or in the syntax description bullets of Section 4.1.
> 

wfm

>         potential representation of DNS A-labels in the future

Probably 5890, which is where A-labels and the constraints on
them are actually defined but otherwise yes.

>     next available number in the sequence of positive integers

Yes, that does the job.

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

wfm 

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

s/stable a/a stable/
And I dislike playing games with "ought to" to avoid saying
"should" (or "SHOULD") -- just very  clumsy English, IMO.  But
my name isn't at the top of this one, so suit yourself.
 
>...

   john

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 Feb 2014 19:07:43 -0700

> expertise or energy needed to devise such a system.

True.

Perhaps we can say something like this:

    Naming can be difficult and contentious. Therefore the
    designated experts and applicants ought to work together
    in a spirit of good faith and mutual understanding to
    achieve rough consensus on progressing registrations
    through the process.

I know, it sounds like "motherhood and apple pie", but it might be the 
best we can do.

Peter

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Feb 2014 00:22:23 -0500

--On Tuesday, 11 February, 2014 19:07 -0700 Peter Saint-Andre
<[email-masked]> wrote:

> I know, it sounds like "motherhood and apple pie", but it
> might be the best we can do.

Yes.  How about adding an addition sentence which actually
doesn't say much more but may convey the spirit a little better:

	"They are encouraged to bring additional expertise into
	the discussion if that would be helpful in adding
	perspective or otherwise resolving issues."
	
Does that help?
   john

---

From: Juha Hakala <[email-masked]>
Date: Wed, 12 Feb 2014 10:55:23 +0200

Hello,

The current 3406bis says:

> A formal namespace registration can be revised by updating the
>     registration template, following the same steps outlined above for
>     new registrations.

Can we add something to the effect that if a URN namespace is based on 
existing identifier specification, the registration should be revised 
when a new version of that specification is published, especially if the 
revision changes the purpose, syntax of the assignment process of the 
identifier. An example of this is the on-going revision of the ISRC 
(International Standard Recording Code); if there were an ISRC 
namespace, it would be necessary to update the registration of it since 
the ISRC assignment process will change radically (although the purpose 
and syntax of ISRC remain the same).

Is it necessary to always follow exactly the procedure outlined in 7.1 
when a namespace is revised? We might allow the applicants to describe 
just the novel features (for instance, it may happen that just the 
registrant changes). This would make the life easier both for the 
registrants and the reviewers.

A detail about 7.1: would it be better to say just "review" in step 2, 
instead of "technical review". The latter wording might give some people 
a wrong impression that non-technical information supplied in the 
registration request will not have an impact on the outcome of the 
review process.

On 12.2.2014 7:22, John C Klensin wrote:
>> Perhaps we can say something like this: Naming can be difficult and 
>> contentious. Therefore the designated experts and applicants ought to 
>> work together in a spirit of good faith and mutual understanding to 
>> achieve rough consensus on progressing registrations through the 
>> process. I know, it sounds like "motherhood and apple pie", but it 
Yes, this will do for me. And I don't think that it is necessary / 
useful to go beyond this in rfc3406bis.

It is important to make the namespace registration process as simple as 
possible, but not simpler. If registration process is considered to be 
too complicated, the risk that some communities invent their own 
namespaces (which is not discussed in the security considerations 
section of the 3406bis for the time being) may increase. On the other 
hand, the reviewers should have all the relevant information available.

Juha

>     john
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Feb 2014 06:50:46 -0700

> 	perspective or otherwise resolving issues."

Works for me. In my working copy I now have:

    Naming can be difficult and contentious; the designated experts and
    applicants are strongly encouraged to work together in a spirit of
    good faith and mutual understanding to achieve rough consensus on
    progressing registrations through the process.  They are also
    encouraged to bring additional expertise into the discussion if that
    would be helpful in adding perspective or otherwise resolving issues.

By the way, this is a new paragraph in Section 8.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Feb 2014 06:56:23 -0700

Hi Juha,

> registrants and the reviewers.

That's a good point. How about this?

OLD
    new registrations

NEW
    A formal namespace registration can be revised by updating the
    registration template, following the same steps outlined above for
    new registrations.  A revised registration should making special note
    of any relevant changes in the underlying technologies or namespace
    management processes.

I'm not comfortable with saying that a revised registration can describe 
only the novel features, but in my opinion it should be rather easy to 
modify the old registration request -- it's not as if the registrant 
needs to write the whole thing again anew.

> registration request will not have an impact on the outcome of the

Yes, agreed.

Thanks for your feedback.

Peter

---

From: Juha Hakala <[email-masked]>
Date: Thu, 13 Feb 2014 08:51:55 +0200

Hi Peter,

>    of any relevant changes in the underlying technologies or namespace

With the exception of "should making" the new formulation looks fine to me.

>
> I'm not comfortable with saying that a revised registration can 
> describe only the novel features, but in my opinion it should be 
> rather easy to modify the old registration request -- it's not as if 
> the registrant needs to write the whole thing again anew.

OK.

I have just one more comment: in chapter 8 we might make it more clear 
that different namespaces may have very different level of 
administration. The current wording gives an impression that we expect 
some level of uniformity and that there has to be a clearly formulated 
"contract" with the intended user community.  While this may be true for 
some existing namespaces, there are other namespaces where both the 
intended user community and the "contract" are not and cannot be clearly 
specified.

  Juha

-- 

  Juha Hakala
  Senior advisor

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 14 Feb 2014 17:03:25 -0700

Noted.

> intended user community and the "contract" are not and cannot be clearly

I *think* that makes sense. Perhaps we could at least try to describe 
when we expect a certain level of service, and when we don't?

Peter

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

---

From: Juha Hakala <[email-masked]>
Date: Mon, 24 Feb 2014 16:00:32 +0200

Hello,

> when we expect a certain level of service, and when we don't?

We may claim that if a namespace is based on an established (standard) 
identifier, there may be a well specified process of identifier 
assignment, and an organization (international center, supported by 
national / regional centers) which is overseeing the work. If there is 
no such administrative infrastructure, users of the identifier may not 
get much external support.

Some other PID communities make it clear that the level of 
administration may also have a major impact on longevity / reliability 
of the identifier. So the most significant difference between Handle and 
DOI is that the latter is better administered. Within the URN system 
similar differences will exist between namespaces. IMO it is important 
to make it clear that we have not and we do not intend to specify - at 
least in any level of detail - the minimum level of administration 
required.

Juha

-- 

  Juha Hakala
  Senior advisor