Subject: [urn] editorial comments on draft-ietf-urnbis-ns-reg-transition-01

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Feb 2014 09:10:52 -0700

Thanks to John and Juha for working on this document. Overall I think 
the substance is fine. Here are a few small editorial issues I noticed.

1. Expand URN on first use:

    As a part of the initial development of the Uniform Resource Name
   (URN) system...

2. This is a bit awkward:

    model that focuses more on attempting to get all namespaces that
    follow the syntax of formal ones registered

I suggest:

    model that focuses more on encouraging registration of all
    namespaces that follow the formal namespace syntax

3. There's a stray word here:

    collected as a possible consistent with that goal

Should be:

    collected as possible consistent with that goal

4. A missing and:

   [RFC3044], International Standard Book Numbers (ISBNs) [RFC3187]

Should be:

   [RFC3044] and International Standard Book Numbers (ISBNs) [RFC3187]

5. This text might be slightly ambiguous:

    For both ISSN and ISBN URNs, it is intended that the registrations
    track the evolution of ISO standardization without requiring
    resubmission of the templates or other formal IETF or IANA
    registration update approval procedures.

I assume that refers to the current registrations, not any future 
registrations.

6. This is a bit of a run-on sentence:

    The revised ISBN namespace reflects the updated version of the ISO
    Standard for ISBNs, ISO 2108:2005 [ISO-ISBN-b] and allows for the use
    of both the ten character numbers described in RFC 3187 and the
    earlier ISO 2108:1992 [ISO-ISBN-a] (known as ISBN-10) and the
    expanded ones of the revised standard (known as ISBN-13).

Perhaps:

    The revised ISBN namespace reflects the updated version of the ISO
    Standard for ISBNs, ISO 2108:2005 [ISO-ISBN-b].  The namespace
    allows for the use of both the ten character numbers described in
    RFC 3187 and the earlier ISO 2108:1992 [ISO-ISBN-a] (known as
    ISBN-10), as well as the expanded ones of the revised standard
    (known as ISBN-13).

7. Typo here:

    IANA is requested to update the registry entries for URN ISSNs,
    ISBNs, and NRNs

I assume that "NBNs" is meant instead of "NRNs".

8. I sense some ambiguity here:

    IANA is requested to update the registry entries for URN ISSNs,
    ISBNs, and NRNs to reflect the new, RFC 3406bis-complaint templates
    as soon as they are available and to no longer reference the now-
    historic RFCs.  Other registrations and templates conforming to the
    newer rules may be substituted for the older ones when they are
    available.  However, neither this document nor RFC 3406bis
    invalidates existing registrations other than those listed above, so
    IANA needs to be prepared to maintain a registry whose contents
    reflect both old and new templates.

I think "other registrations and templates" might be referring to 
registrations and templates for namespaces other than ISSN, ISBN, and NBN.

I think "supersedes" might be more appropriate than "invalidates".

And I think "a registry whose contents reflect both old and new 
templates" does not imply that IANA would point to both an old and a new 
template for the same namespace, but for different namespaces.

Thus I suggest:

    IANA is requested to update the registry entries for URN ISSNs,
    ISBNs, and NBNs to reflect the new, RFC 3406bis-complaint templates
    as soon as they are available and to no longer reference the now-
    historic RFCs for those namespaces.  With respect to namespaces
    other than those listed above, registrations and templates
    conforming to the newer rules may be substituted for the older ones
    when they are available.  However, neither this document nor RFC
    3406bis supersedes existing registrations other than those listed
    above.  Therefore, IANA needs to be prepared to maintain a registry
    whose contents reflect old templates for some namespaces and new
    templates for other namespaces.

Peter

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Feb 2014 15:14:18 -0500

Hi.

Having heard no comments about Peter's suggestions from the WG
list, all have been incorporated except as noted below.  The
revised draft will be posted Monday (if I remember) but the
difference between 01 and 02 will be only these changes, so, if
you want to read something today, 01 is safe.

There is, however, at least one question below to which a WG
response it needed.  If there seems to be a clear answer before
Monday, I'll get it into the next draft (subject to revision and
yet another I-D version if Andy tells me otherwise).

Observation from a participant in this WGs who thinks the work
is very important and who has some experience with how the IETF
works, but no official role in the WG other than being willing
to help with writing: When WG drafts are posted and met with
dead silence (or silence except from an extremely small number
of people, the usual IETF tendency is to assume that the WG is
dead, no one cares, and that, if it produces any work, that work
doesn't represent enough meaningful consensus to be moved
forward.  Barry has been extremely patient, I think because he
shares my/our sense of importance, but I'm very concerned about
how we move forward this way.   This is especially important
because a few of us have been thinking about a very radical move
to get the various issues of syntax, properties of the name or
named object versus things that can be done only after it is
retrieved, and so on unstuck.  That move would be, IMO,
impossible without strong backing from the WG.  Because just
raising it would probably stir up a lot of controversy, I (at
least) haven't even been willing to explain it on this mailing
list.

So, nay I ask (and recommend) that those of you who are reading
drafts, saying "seems ok" to yourselves, and moving on start
posting "I have read this and seems ok" (or "I have read it and
it is hopeless" if that is that better reflects your views)
notes to the list.  And those of you who haven't been reading
drafts should start soon -- the silence will kill us, if not by
action from the IESG than by the authors giving up.

Again, a few notes on Peter's comments below

thanks,
  john

--On Wednesday, February 12, 2014 09:10 -0700 Peter Saint-Andre
<[email-masked]> wrote:

> Thanks to John and Juha for working on this document. Overall
> I think the substance is fine. Here are a few small editorial
> issues I noticed.
> 
>...
>...
>...
>...

> I assume that refers to the current registrations, not any
> future registrations.

Actually, I was trying to finesse a problem.  This really needs
input from you and the read of the WG.   Let me keep it separate
from the editorial issues by writing a separate note.
 
>...
>...
> I think "other registrations and templates" might be referring
> to registrations and templates for namespaces other than ISSN,
> ISBN, and NBN.

Yes.  And it needed to spelled out a bit more even where it
wasn't ambiguous.    I've substituted your proposed sentence,
which is probably good enough.

Suggestions for less tedious wording are welcome.
	
> I think "supersedes" might be more appropriate than

I really did mean "invalidate", partially because of aspects of
the ongoing "obsoletes" versus "historic" debate.   In addition,
in theory this document or 3507bis could declare all existing
registrations invalid without any superceding documentation or
registration (in some sense, it does make tham obsolete because
the information required is different).   We've decided (I
think) to not do that and I thought it was worth making
explicit.  But I've changed the word to "supercedes".  It can be
changed back if anyone feels strongly about it.

> And I think "a registry whose contents reflect both old and
> new templates" does not imply that IANA would point to both an
> old and a new template for the same namespace, but for
> different namespaces.

One would hope that, in the former case, a new NID would be
assigned.

>     templates for other namespaces.

Smoothed a bit but basically incorporated.

Thanks for the careful reading,
   john

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Feb 2014 15:15:23 -0500

The other note I promised...

> I assume that refers to the current registrations, not any

As I said, this needs WG thought and input.

As we have seen with the revisions that specified the longer
identifiers for ISBNs, these underlying ISO standards change.
The good news is that, at least in my opinion, changes that
would make older identifiers invalid are just not going to
happen: they would be extremely disruptive and costly to a
community that is very dependent on stability over periods the
IETF has trouble thinking about.  My instinct is to trust that
and allow a registration that does not require revision or
updating to move from one version of an underlying ISO standard
for the identifier to another.  The current reference version
of the underlying standard, syntax, assignment rules, etc., are
what ISO says they are with no IETF, Expert, or registrant
action being required (even though I'm sure we would welcome
explanatory updates).  

I don't know whether that generalizes beyond ISSNs and ISBNs
(and, maybe, if the IAB decides to go in that direction, the
ISO version of DOIs).  We would certainly want to have a very
serious discussion if someone wanted to register a URN
namespace that was dependent on a possibly more volatile set of
references.  But, for this case, it makes sense to me and would
eliminate possible uncertainties between the time an ISO
standard is updated and published and when someone gets around
to updating the URN registration.  Experience leds me to hate
those sorts of timing dependencies, especially when they can be
avoided.

So, two questions (I'll try to interpret the answers, but the
decision about agreement, as I noted earlier, belongs to Andy):

(1) Does the WG agree with my analysis and believe that having
the registration based on the "current version" of the ISO
standard, whatever that version is at a given time, is wise?

(2) If so, how should this be said?  Note that it might (or
might now) require some tuning to 3507bis to get an explicit
statement in the registration template as to whether the
referenced external standard is the version as of some specific
date (and/or version number) or whether it always follows the
versions of the external standard as I'm suggesting here.

thanks,
    john