Re: [Last-Call] Last Call: <draft-halpern-gendispatch-consensusinformational-02.txt> (IETF Stream Documents Require IETF Rough Consensus) to Best Current Practice

Benjamin Kaduk <kaduk@mit.edu> Fri, 31 January 2020 04:25 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AA2120168 for <last-call@ietfa.amsl.com>; Thu, 30 Jan 2020 20:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAapj-gWjYyz for <last-call@ietfa.amsl.com>; Thu, 30 Jan 2020 20:25:45 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C18F12006D for <last-call@ietf.org>; Thu, 30 Jan 2020 20:25:44 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00V4Pc4P011474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jan 2020 23:25:40 -0500
Date: Thu, 30 Jan 2020 20:25:37 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rob Sayre <sayrer@gmail.com>
Cc: Christopher Wood <caw@heapingbits.net>, last-call@ietf.org
Message-ID: <20200131042537.GD24@kduck.mit.edu>
References: <CAChr6SyNTsz9uZNiN16OHLj6e=Xhcn1A8pr105Of+y_Jw8HSFw@mail.gmail.com> <994c4462-ef24-6d46-3bec-8aa5e14b9f78@joelhalpern.com> <CAChr6Sy80-74g4cgKESwmdn3WSNjU_2XsjkChH9_8-ELnytC_Q@mail.gmail.com> <20200125184550.GF77560@kduck.mit.edu> <CAChr6SzXFPbcPL++gftey9T_nCVBds+Sb1Z4MpkC2GraZCNfKw@mail.gmail.com> <c220d99f-d69a-ede0-630b-2f593412daca@joelhalpern.com> <CAChr6Sy9=1Gewkq-E=+d9sLFrGS0kL33RUNLxvs44tX0czoUCg@mail.gmail.com> <b6b6bc7a-998b-4cd7-3684-18df02c6a537@joelhalpern.com> <238b2086-80cb-4227-947e-aa7bd565e79e@www.fastmail.com> <CAChr6SyzoTxJd1eMy+z_xLPhdE7v7UDE4LTop9JjooHkzvGEiQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAChr6SyzoTxJd1eMy+z_xLPhdE7v7UDE4LTop9JjooHkzvGEiQ@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/_cBL0unbwie-3tAVygz9wZnai4k>
Subject: Re: [Last-Call] Last Call: <draft-halpern-gendispatch-consensusinformational-02.txt> (IETF Stream Documents Require IETF Rough Consensus) to Best Current Practice
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2020 04:25:47 -0000

On Sun, Jan 26, 2020 at 03:03:53PM -0800, Rob Sayre wrote:
> On Sun, Jan 26, 2020 at 12:10 PM Christopher Wood <caw@heapingbits.net>
> wrote:
> 
> > On Sat, Jan 25, 2020, at 12:30 PM, Joel M. Halpern wrote:
> > > With regard to citing RFC 5742, I will leave it to the judgment of the
> > > document shepherd and AD as to whether they believe that is called for.
> > > It seems more distracting than useful to me, but I will act as they
> > direct.
> >
> > For the reason above, I do not think citing RFC 5742 is necessary.
> >
> 
> There are 4 cases that could happen now:
> 
> Document Actions (WG) [ No IETF Last Call Issued ]
> Document Actions (WG) [ Last Call Issued, No Consensus ]
> Document Actions (Individual to AD) [ No IETF Last Call Issued ]
> Document Actions (Individual to AD) [ Last Call Issued, No Consensus ]
> 
> For each of these cases, there will be some interaction with RFC 5742 if
> the document is to be published on another stream (the alternative proposed
> in the draft).
> 
> Whether or not this draft is edited, it would be helpful to know what
> people think is going to happen to these cases. No publication at all? Or
> publication with one of the IESG messages in 5742? I looked for some
> Informational and Experimental documents languishing in the IESG queue,
> since the authors don't seem comfortable discussing the concrete examples
> they are reacting to.

I don't think there's a universal answer here, and what happens would be
evaluated on a case-by-case basis.  I could imagine some documents that are
controversial in the IETF and fail to gather consensus but describe
protocols that do not harm the Internet and do not try to modify or usurp
IETF protcols; the ISE is a fine venue for such documents.  On the other
hand, if the failure to attain IETF consensus was due to attempting to
change the normative behavior of an existing IETF specification, then an
attempt to publish via the ISE would receive a conflict-review response
that notes the conflict with IETF work and indicates the harm of publishing
the document anyway.  That said, as is well-covered in this thread, the
IESG conflict-review response is just a recommendation as far as the ISE is
concerned, and the ISE will act wholly independently in deciding whether or
not to publish.

-Ben