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

[Adam Roach <[e-mail]>]

On 8/3/17 7:49 AM, John C Klensin wrote:
> 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.


John --

Thanks for sharing your rather extensive thoughts on this topic. I 
apologize that I was unable to meet your deadline of "today," as I was 
physically located in a part of the world that had limited to no data 
connectivity by the time you had sent it.

As Martin points out, I'm still rather junior at this position, and have 
been led to believe that the Discuss Criteria 
<https://www.ietf.org/iesg/statement/discuss-criteria.html> has some 
fundamental authority to it. You will note, for example, that the 
DISCUSS ballot I entered was carefully selected, in a word-for-word 
fashion, from that document. I'm also under the impression that the 
current version of the ID-Checklist 
<https://www.ietf.org/id-info/checklist.html>, having had extensive 
discussions on the IETF mailing list, is a reflection of IETF consensus 
regarding the form and format of documents to be turned over to the RFC 
editor. Interpreted that way, I have concerns that I would be derelict 
in my duties if I allowed an author to unilaterally ignore guidance that 
has received IETF-wide review. I'll return to this in a moment.

I do very much appreciate that you had already formulated a compromise 
proposal with the intention of sharing it at some point. I find your 
intended formulation (as hinted by the snippet you included) to satisfy 
both word and spirit of the ID-Checklist provision for abstracts to 
indicate document obsoletion.

At the same time, you have raised a host of collateral points of 
interest regarding the provenance and maintenance of Discuss Criteria 
and ID-Checklist. If we had a common understanding of their authority, 
then the path forward would be clear: if these documents are merely 
advisory and have no power to bind, then I'm free to concede the point 
and allow you to push forward with a document that does not conform to 
their contents -- and would likely do so at this point. Alternately, if 
they are expected by the IETF community to be binding, then it would 
seem my duty to assist in their enforcement. We could hold the 
publication of this document until we were able to resolve which of 
these two situations is true, but it seems a mild disservice to the 
URNBIS working group to do so.

In an attempt to avoid delaying this document unnecessarily, I propose 
the following path forward:

 1. You provide your aforementioned compromise text to Alexey (in his
    role as sponsoring AD) for inclusion as an RFC Editor Note, and I
    will clear my DISCUSS position.

 2. As a tactical matter, you propose to the IESG a set of
    administrative updates to the ID-Checklist document reflecting those
    areas you believe it has fallen out of maintenance (e.g., the
    reference to an older version of the RFC style manual).  I would
    expect these to be mechanical and uncontroversial to apply.

 3. As a strategic matter, you or we begin a conversation with the IETF
    community at large regarding the provenance and authority of the
    Discuss Criteria and ID-Checklist documents. I do not want to
    presuppose the outcome of those conversations, so I suggest no
    specific potential conclusions. I'm happy to help you with
    formulation of the question, if you'd like, but I don't feel
    compelled to insert myself in doing so if you'd prefer to ask in
    your own terms.

 4. Subsequent to conclusion of that conversation, and contingent on its
    outcome, we begin a conversation with the IETF community at large
    regarding the ambiguities you perceive as being present in the
    ID-Checklist so that we can more precisely reflect an IETF consensus
    position in its contents.


/a