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

[John C Klensin <[e-mail]>]

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
<[e-mail]> 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.
> 
> 1. Expand URN on first use:
>...
> 2. This is a bit awkward:
>...
> 3. There's a stray word here:
>...
> 4. A missing and:
>...

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

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.
 
> 6. This is a bit of a run-on sentence:
>...
> 7. Typo here:
>...
> 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.

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

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.

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

Smoothed a bit but basically incorporated.

Thanks for the careful reading,
   john