Subject: [urn] draft-ietf-urnbis-semantics-clarif-03

From: John C Klensin <[email-masked]>
Date: Sat, 06 Feb 2016 14:41:26 -0500

I've just posted a new version of
draft-ietf-urnbis-semantics-clarif, largely because -02 was
scheduled to expire next week.  I have gone through it and
updated some of the text to reflect the last few versions is
2141bis, e.g., by dropping comments about p-components and
mentioning r-components.  I've also tidied up the language and
explanations in several places.  

I don't believe that any of the changes are really substantive,
but the WG should review the revised draft to be sure I haven't
messed anything up.

     john

p.s. An update for the registration transition I-D,
draft-ietf-urnbis-ns-reg-transition will follow in a few days,
probably with almost no changes other than an update to the date.

---

From: Sean Leonard <[email-masked]>
Date: Sat, 20 Feb 2016 21:22:58 -0800

> explanations in several places.

Editorial review of urnbis-semantics-clarif-03:

Section 1:
requiremnts -> requirements

Appendix B.3:
discused -> discussed

Appendix B.5:

oMade a few substantive updates to reflect evolution in 2141bis,

particularly the elimination of p-component as a separate category

and the added distinction between q-component and r-component..

Remove second period.

I honestly do not see the need for Section 8. IANA Considerations. This 
document is something of a missive; it does not define an actionable 
(technically implementable) standard so I believe it can dispense with 
the general advice that the majority of RFCs ought to have IANA 
Considerations sections.

Sean

---

From: John C Klensin <[email-masked]>
Date: Sun, 21 Feb 2016 10:50:58 -0500

--On Saturday, February 20, 2016 9:22 PM -0800 Sean Leonard
<[email-masked]> wrote:

>...

Changes above made.  Thanks for the careful reading, but these
are the sorts of things than can normally be left to the RFC
Editor to find and fix.

> I honestly do not see the need for Section 8. IANA
> Considerations. This document is something of a missive; it
> does not define an actionable (technically implementable)
> standard so I believe it can dispense with the general advice
> that the majority of RFCs ought to have IANA Considerations
> sections.

First, if the IANA Considerations section is removed at this
point, the automated posting and nit-finding tools will complain
and reject the document.  If you think the requirement to have
it, even if it says "nothing required, please remove before
publication", is unreasonable, take it up with IANA and the IESG
but I can tell you that, in prior years, the judgment and
experience was that leaving it out of I-Ds resulted in far more
problems than the noise of having it there.

Second, the second paragraph is actually substantive in the
sense that it is common for IANA to come back during their
pre-publication check and say "this seems to change what should
be in the registry; what should be done with the old entries?"
Providing an answer to that question in the document saves quite
a bit of otherwise-wasted time. 

Personal opinion: To some extent, the above, and maybe your
"missive" comment, argue for collapsing the substance into
2141bis.  IIR, the WG has decided to keep them separate, at
least for the present, because merging them would create a risk
of introducing errors and arguing about what can be dropped
entirely would take (IMO, waste) a lot of time.  FWIW, if we
weren't years overdue, I'd feel differently about this but,
right now, I think we should get documents that are clear and
correct technically finished, approved, and out ASAP and defer
even spending time on this type of editorial/ document
organization issue for a Full Standard 2141ter (if there is ever
the energy to produce that).

However, this type of issue is up to the WG Co-Chairs, whom I
hope will speak up.

    john

---

From: Barry Leiba <[email-masked]>
Date: Sun, 21 Feb 2016 09:30:39 -0800

> (technically implementable) standard so I believe it can dispense with the
> general advice that the majority of RFCs ought to have IANA Considerations
> sections.

It's not general advice and it's not just a majority.  It's a pretty
strong rule and it's essentially all drafts that are going to the IESG
for approval.  Let's not argue this point any more; there's no future
in it, and arguing it won't make the document better.

We can argue that this document doesn't need to be published
separately -- it was done this way as a WG-management thing.  Anyone
making that argument should say *specifically* how the salient
information should be folded into 2141bis.

Barry