Re: [urn] Adam Roach's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT)

[Adam Roach <[e-mail]>]

On 8/1/17 5:29 PM, John C Klensin wrote:
>
>> Major comment:
>>
>> Section 3 has suggested changes for RFC3188 for the next time
>> it is revised. It's not clear, outside of institutional
>> knowledge (which is a very fragile construct) how the
>> indicated changes are going to be properly remembered when
>> such revision takes place. Is there a good reason this
>> document doesn't simply update RFC3188 by indicating an
>> updated template directly? If this doesn't make sense, I would
>> think that we need at least an erratum associated with RFC3188
>> that indicates the nature of update that needs to be performed.
> The problem is this.  RFC 3188 was never an IETF WG document.
> It will be replaced by a new RFC, most likely in the Independent
> Stream unless you are one of your colleagues are interested in
> sponsoring it as an Informational individual submission.

Have you asked?

> Juha
> and I have been working intermittently on a draft; the hold-up
> right now is mostly me, for which I apologize but I have been
> tied up with other IETF-related work that seemed to be more
> pressing.  There are twp reasons why an updated template is not
> directly referenced: it isn't ready due to evolution in NBNs and
> it seemed inappropriate for the WG to make promises about what
> would be in it.  FWIW, the specific things that this draft calls
> out have already been incorporated in the working draft for
> 3188bis.

The fact that a document revision is actually underway does assuage my 
concern for the most part. Could you cite the 3188bis document as a work 
in progress? I think it would be useful for consumers of this document 
to know that a revision is actively in progress, and to have a document 
name to look for.

>
>> Minor comments:
>>
>> The draft header indicates that this document obsoletes
>> RFC3044 and RFC3187, but the abstract doesn't mention this,
>> which it should.
> Disagree.  Those are informational documents, not standards
> track ones, the abstract correctly reflects what the document
> does, and the relationships are carefully explained in Section
> 2.  Cluttering up the abstract by putting in those RFC numbers
> seems neither desirable nor appropriate and this should
> reasonably be an editorial matter under the control of the RFC
> Editor, not something specified by the IESG.

Rather than engaging on the broader topic of indicating Obsoletes and 
Updates in the abstract in general, I'll point out that *this* document 
is paired with a request to reclassify 3044 and 3187 as Historic. There 
is long-standing IESG guidance on this topic 
<https://www.ietf.org/iesg/statement/designating-rfcs-as-historic-2011-06-27.html>, 
which includes the provision "If authors wish to change the status of 
RFCs that are in the obsoletes header to Historic, then the authors must 
include an explicit statement for the RFC editor to do so; *preferably 
in the abstract and introduction*."

You may, of course, choose to ignore this officially stated IESG 
preference, but doing so would unnecessarily go against convention.

In terms of RFC Editor policy: while the RFC Style Guide does not 
explicitly require obsoleted RFCs to be listed in the abstract, I find 
it rather telling that it does, itself, do so. This is quite possibly 
because RFC Abstracts (according to said style guide) are required to 
give a "concise and comprehensive overview of the purpose and contents 
of the entire document," and some substantial portion of the purpose of 
*this* document is obsoleting existing RFCs -- thus failing the 
"comprehensive" portion of that requirement. So while it may well be 
outside my purview as a member of the IESG to require you to fix this 
defect, it seems quite probable that you'll have this conversation again 
with a member of the RPC in a short while.

/a