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

"Joel M. Halpern" <jmh@joelhalpern.com> Sat, 25 January 2020 06:42 UTC

Return-Path: <jmh@joelhalpern.com>
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 06B2212006B for <last-call@ietfa.amsl.com>; Fri, 24 Jan 2020 22:42:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.635
X-Spam-Level:
X-Spam-Status: No, score=0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 Pmrn41u4RYx7 for <last-call@ietfa.amsl.com>; Fri, 24 Jan 2020 22:42:30 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 424D912004E for <last-call@ietf.org>; Fri, 24 Jan 2020 22:42:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 484RJk1Mn3z6GF0g; Fri, 24 Jan 2020 22:42:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1579934550; bh=eVkhvl7Q0PfioY9R+Hja4phXQg4r1INCPFRnQecM9j0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fmEOzjJL3Z1/IcIS+j3OGaqzVfYI4N6LnNW2iMCVpF7mvPp/gB8Pu8XIiOn8n2UQX VhRcbfRsf8jVWUtuFs9qoKTTYmC/i4yE/avvQQN0QRTsuIriMUgQ+qRJ+YsaXMVTG5 TtsF2t5prEu1oXAj6Y2g2vZKxzuULBhtdYl0cTV8=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 484RJj4NPkz6GDbT; Fri, 24 Jan 2020 22:42:29 -0800 (PST)
To: Rob Sayre <sayrer@gmail.com>
Cc: last-call@ietf.org, Eric Rescorla <ekr@rtfm.com>
References: <CAChr6Sy5-ejdjw5zgZgiF1hSyuiAErmas-dbWFmx1b+1vftT1Q@mail.gmail.com> <CABcZeBOMVYpEYaEUzYsa0ApDfGtA6oD5P67A40=HQVBN+yTuKQ@mail.gmail.com> <CAChr6Sz7vihWaoeG8H11JzQ5YqrbYLPLneuY3PD4syMYEaKQ4w@mail.gmail.com> <99d34ee9-8ea6-a77f-39fc-f1889a050358@joelhalpern.com> <CAChr6SwHd2=Qf2SSbQeKs1CS_c1UuBqPEtO_x4MmF71iv0zE9Q@mail.gmail.com> <CABcZeBMdonehuZ3re4UnGY2_B6A2sOBqkoE+m4SfBa8N3vYEhg@mail.gmail.com> <CAChr6Sw1LSXj=L2WAu=R1QfBi4UFDXC5Z6EODqwJ6-z9o5Z5vw@mail.gmail.com> <CABcZeBPBhGZDxnh2p=trL8yHveBiMsy38+-G_7oQu_eR+45d5w@mail.gmail.com> <CAChr6SyNTsz9uZNiN16OHLj6e=Xhcn1A8pr105Of+y_Jw8HSFw@mail.gmail.com> <994c4462-ef24-6d46-3bec-8aa5e14b9f78@joelhalpern.com> <CAChr6Sy80-74g4cgKESwmdn3WSNjU_2XsjkChH9_8-ELnytC_Q@mail.gmail.com> <7829860d-7f8e-8c6b-e2c2-189e0946e35e@joelhalpern.com> <CAChr6SwkV05Qe_Wk0mV6_tuPrc4w-YL3wJ4ee1DTemTUWOezeg@mail.gmail.com> <1d310bb5-f219-1c83-e3ec-d00741e62cc6@joelhalpern.com> <CAChr6Sz=VZXr8Wa4pxd+opF80EqPtx8cZ-SjAR0__aCBToqeAQ@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <b370521b-8c31-c580-e772-5454016b81e5@joelhalpern.com>
Date: Sat, 25 Jan 2020 01:42:27 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CAChr6Sz=VZXr8Wa4pxd+opF80EqPtx8cZ-SjAR0__aCBToqeAQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/BdZnaNpRSkd7pGidwYpK9tO6ams>
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: Sat, 25 Jan 2020 06:42:31 -0000

The problem is that the current rules permit the IESG to publish 
Informational or Experimental documents without IETF consensus on the 
IETF stream.  This recently came up because someone thought it might 
actually be a good idea to do so to solve a problem.  I do know of one 
case where it was actually done.  The only way you can tell is that 
there is a line missing in the boilerplate of the RFC.  But I see no 
value in pointing to that example.

The case that brought this to my attention, and prompted the document, 
does not exist because the AD in question agreed after discussion that 
using the possible loophole would have been a bad idea.

The other example I know of (the published RFC) is complicated because 
there was a lot of politics.  So trying to analyze what would or should 
have happened if this rule were in place is just a game of what-if.  Not 
useful.

Rather, by publishing this document the community is saying that no, 
this is not an IESG choice.  The rules are fixed to prohibit it.

 From your notes, you seem to be trying to figure out if changing the 
rule would create a problem.  Given the existence of the other channels 
for publishing RFCs, which are NOT affected by this change, I do not see 
how it could be a major problem.   Whereas leaving the loophole in place 
struck me, and others, as a bad risk.  The loophole is an effect of the 
evolution of our processes over MANY years since RFC 2026.

Yours,
Joel

On 1/25/2020 1:28 AM, Rob Sayre wrote:
> On Fri, Jan 24, 2020 at 10:23 PM Joel M. Halpern <jmh@joelhalpern.com 
> <mailto:jmh@joelhalpern.com>> wrote:
> 
>     I have no idea what you are asking for.
> 
> 
> Really?
> 
>     The existing rules permit certain behavior which, if the community
>     approves this document, will now be prohibited.  that is all it does.
>     There are very few if any examples of documents that were permitted but
>     would now be prohibited.
> 
> 
> I just wrote "I asked for some example documents. Could you provide some?"
> 
> Are there "very few" examples, or none?
> 
> If the answer is none, what problem does the document solve?
> 
> thanks,
> Rob
>