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

Hello John, Adam,

I'm currently on a plane heading for vacations, so I very much hope that 
by the time you get this email, things have cooled down a bit rather 
than escalating further.

I seriously think that exchanges like this are not worth the time of two 
busy people like you, not to speak of the rest of the IESG and the WG 
(or those in the WG who still read its mail).

It may seem like Adam is singling out this draft, but he only recently 
became an AD, and to support that claim, it would be necessary to show 
that he on-purpose ignored the same issue in other drafts that have 
recently come up to the IESG. Maybe he's just trying to do his best as a 
new AD. Or maybe he is just trying to give a bit more attention to an 
issue that is somewhat more important to him than to other IESG members; 
that's definitely not something that other ADs haven't done in the past.

As for RFC numbers in abstracts, how exactly to show them can be left to 
the RFC Editor. Every reader will know how to get more information by 
going to the references section of the main document even if the number 
isn't styled as a reference. The concept of 'well-known RFC number' is 
very relative; there may be RFC numbers that the potential readers of 
the document know quite well even though the 'average' RFC reader won't. 
Also, if I as a reader don't know an RFC number that's obsoleted, then 
that's a very good signal that I may not have to care. If we still want 
to help the reader more, an additional phrase giving the title may also 
help. I'm not saying that because I think that these RFC numbers need to 
be in the abstract, just to say that it won't be the end of the world if 
they are.

As for WG consensus, I'm not the one who judges that, but I'd think that 
questions like whether to put RFC numbers in the abstract or not haven't 
been discussed seriously, and the average WG member could care less 
about it either way.

I strongly suggest that John take down his threat of an appeal, and Adam 
take down the discuss, and that you both, if necessary with the help of 
others, figure this out with less heat.

Regards,   Martin.

On 2017/08/03 21:49, John C Klensin wrote:
> --On Wednesday, August 2, 2017 13:18 -0500 Adam Roach
> <adam@nostrum.com> wrote:
> 
>> On 8/2/17 10:04, John C Klensin wrote:
>>> If "preferably"
>>> is turning in "mandatory", we need to have two discussions,
>>> one about the authority boundary between the IESG and the RFC
>>> Editor and the other about where in RFC 2026 and its updates
>>> the IESG is given authority to make policy by issuing
>>> statements rather than determining and reflecting IETF
>>> community consensus.
>>
>>
>> Thanks for sending me down the path of determining authority
>> here, as it has made me realize that I was confused about the
>> basis for insisting that Obsoleted documents be explicitly
>> listed in the Abstract.
>>
>> It turns out that the 2011 IESG statement of "preferably" is a
>> weak restating of a 2008 IETF-consensus decision to approve
>> version 1.9 of the "ID-Checklist" document, which clearly
>> states that the Abstract of a document needs to list obsoleted
>> and/or updated documents (cf.
>> <https://www.ietf.org/id-info/checklist.html#anchor6>; §3,
>> 1.D, first bullet: "if your document obsoletes or updates a
>> previous RFC, then... say so in the abstract").
>>
>> And so I am forced to concede that my "No Objection" was made
>> in error. Since the form of this document actively goes
>> against IETF community consensus regarding the form of
>> IETF-stream RFCs, I realize that this should have been a
>> "Discuss." I will be adjusting my ballot accordingly. Thank
>> you again for pointing me in the correct direction, and I
>> apologize for the error.
>> ...
> 
> Adam,
> 
> Silly me.  I was about to propose a compromise in this area --
> one that I hoped would allow the document to move forward, for
> me to be able to get back to RFC 3188bis and for you and the
> IESG to get back to more important work --  and either didn't do
> it soon enough or should have just kept my mouth shut and sorted
> this out with the RFC Editor.  I was sufficiently appalled by
> your decision that I needed to take overnight to raise my
> confidence that I was not overreacting.
> 
> Sadly, I don't think I was overreacting.  Consequently, unless
> this DISCUSS can be resolved in some other way today, I will
> submit a formal appeal against your use of a blocking DISCUSS on
> an essentially editorial matter that puts form over substance
> and that is abusive of working group decisions and the Last Call
> and IESG review processes.
> 
> In addition to the narrow issues in this particular case, the
> appeal is likely to raise the following issues:
> 
> (1) The need to clarify the boundary between the IESG's
> authority, reflecting community consensus, over matters of
> content for documents in the IETF Stream and the RFC Editor's
> authority over editorial matters.  General guidance and
> statements of preference notwithstanding, I believe that
> existing documents and long-standing tradition make rules about
> the editorial (as distinct from substantive) content and
> structure the exclusive province of the RFC Editor, with the
> only important exception being the provision for the IESG to
> demand "as is" publication of IETF Stream documents.  The
> requirement is
> 
> (2) The pattern of migration of "guidance" or "recommendations"
> into firm requirements ("rules") on which a blocking DISCUSS can
> be based and publication of such requirements only in IESG
> statements rather than archival documents of record.  I note
> that Section 5 of RFC 3710 (the IESG Charter) makes a
> distinction between "problems and how to avoid them" and
> "commonly used guidelines" on the one hand and "rules" on the
> other.  While that document says that the latter are "commonly
> published as BCP RFCs", I suggest that substituting
> poorly-indexed and non-archival "statements" or "checklists" for
> such RFCs sets a trap for the inexperienced or unwary and is
> hence inconsistent with a predictable and fair process.
> 
> (3) Imposition of specific blocking rules involving the use or
> applicability of terms such as "obsolete[s]" and "historic" is
> inappropriate when it is generally recognized in the community
> that those terms are insufficiently defined and inconsistently
> applied.  The way to solve those problems of definition and
> application involves a proposal for what should be done,
> community discussion and consensus, and RFC publication, not
> dropping a DISCUSS on a single document that was either
> arbitrarily chosen or that was singled out because one of the
> author-editors chose to push back on an editorial "preference".
> The observation that the IESG has not seen fit to initiate a
> community-based effort (such as a WG) to clarify those
> definitions makes a DISCUSS based on the use of those terms
> particularly questionable.
> 
> (4) There are some specific issues with the checklist statement
> you cite that make it subject to different interpretations and
> highlight the issues identified in (2) above.  For example:
> 
> (4.1) As noted in erratum 5076, a statement similar to "this
> document obsoletes RFC 4687" is a citation whether an anchor
> appears there or not, yet C(1)(B) of the checklist prohibits
> citations.
> 
> (4.2) C(1)(C) references "section 4.5 in
> https://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt"
> in a context that can only be interpreted as normative, yet that
> link is dead (leads to a 404 error) and the document to which it
> referred became obsolete (sic) when RFC 7322 was published if
> not earlier.  To save you the time of checking, Section 4.5 of
> RFC 7322 is not about abstracts.
> 
> (4.3) C(1)(D), which you have cited in support of the presumed
> requirement, says "if your document obsoletes or updates a
> previous RFC, then: say so in the abstract".  However, "say so"
> appears to be general guidance, not a requirement for specific
> language.  The abstract in
> draft-ietf-urnbis-ns-reg-transition-08 includes "This document
> clarifies the status of relevant older RFCs...", which I contend
> is consistent with the checklist "say so" statement.  Had you
> requested that statement be expanded to say "...document
> clarifies the status of relevant older RFCs and formally makes
> two of them historic...", I would have made a bad face but,
> unless my co-author, the WG Chairs, or the WG disagreed, I would
> have made the change and we would not be having this discussion.
> 
> If the IESG (or even a single AD) is going to treat a particular
> document as a set of requirements that justifies a blocking
> DISCUSS, then it is obligated to maintain them so that
> statements are clear and normative references are usable.
> Failure to do so makes application of the documents or
> statements in that way fundamentally unfair.
> 
> (5) Even if none of the considerations outlined above applied,
> it would be inappropriate to use a blocking DISCUSS because the
> guidance in a particular document violates a "rule" or
> "checklist item" when that guidance has existed for a long time
> and has never been enforced consistently.
> 
> regards,
>      john
> 
> 
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
> 

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan