Re: [Rfcplusplus] IRTF stream considerations

Adam Roach <adam@nostrum.com> Thu, 12 July 2018 05:09 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: rfcplusplus@ietfa.amsl.com
Delivered-To: rfcplusplus@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE8D130E43 for <rfcplusplus@ietfa.amsl.com>; Wed, 11 Jul 2018 22:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 f4u9sjn3drmm for <rfcplusplus@ietfa.amsl.com>; Wed, 11 Jul 2018 22:09:40 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1EB129C6A for <Rfcplusplus@ietf.org>; Wed, 11 Jul 2018 22:09:40 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6C59cSo064292 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 12 Jul 2018 00:09:39 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Allison Mankin <allison.mankin@gmail.com>, "Rfcplusplus@ietf.org" <Rfcplusplus@ietf.org>
References: <CAP8yD=vm+jRxdi3ZUncoFZNDYKOQKvFaphT7gxb5o1tDXWmumA@mail.gmail.com> <b69b370c-317b-284f-85d1-1353c67a3043@gmail.com> <8f98deb9-7ed3-3303-356a-e6d3dc5a80c0@nostrum.com> <08e8650b-2f33-943e-ddcb-a6bf6c45b2ce@gmail.com> <c2c450a6-4f14-6325-8c54-6ecee4e0983f@nostrum.com> <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <77486708-e38d-03d3-f4d0-0f0b67797542@nostrum.com>
Date: Thu, 12 Jul 2018 00:09:33 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <22b91a2a-82ff-af78-4b79-c58eb305cec6@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfcplusplus/TkNGqzxbH0mRmKIbx_783SqptNw>
Subject: Re: [Rfcplusplus] IRTF stream considerations
X-BeenThere: rfcplusplus@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: For discussion of the RFC++ BoF proposal and related ideas <rfcplusplus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfcplusplus/>
List-Post: <mailto:rfcplusplus@ietf.org>
List-Help: <mailto:rfcplusplus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2018 05:09:42 -0000

On 7/11/18 10:54 PM, Brian E Carpenter wrote:
> On 12/07/2018 15:37, Adam Roach wrote:
> ...
>> The RFC format work was an IETF BOF too [1] (three, actually), and those
>> specific BOFs resulted in input that went well beyond impacts on the
>> IETF stream. I believe your original statement about the scope of
>> discussions that can take place in such a venue is more refuted than
>> supported by the precedent you cite.
> There's a real difference, in my opinion, in that the definition of
> the streams was a codification of existing practice, and the format
> update was something people have been requesting for many years.
> Neither of them showed any signs of being fundamentally contentious.

Your understanding of the potential, in the IETF 83 timeframe, for 
controversy around the RFC format change is completely different than 
mine. I recall the issue coming up repeatedly at plenaries and in 
hallways with well more than a hint of contention surrounding it.

We are free to disagree on our recollections here, of course, but if you 
check the minutes for the administrative plenary at IETF 79 -- a scant 
four meetings before the RFCFORM BOF -- Stewart Bryant used the phrase 
"this is a controversial subject" to describe this exact topic. The 
benefit of time between now and then may make it seem far less so in 
2018, but that has little bearing on the fact that it *was* expected to 
be controversial by many at the time.

> This time, we've seen a much more radical proposal which, if carried
> forward, would fundamentally change the series. In that case you can't
> duck the question of authority and who calls consensus.

It feels like you're trying to move the goalposts. Your original 
statement was that this is "an IETF BOF and that limits its direct input 
to IESG decision making." If I carefully parse what you've written 
above, it seems that you want to amend that to only apply when some 
(potentially small) subset of the IETF population thinks it won't be 
contentious, but that doesn't seem quantifiable enough to be a rule.

/a