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

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

--On Wednesday, August 2, 2017 13:18 -0500 Adam Roach
<[e-mail]> 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