Re: [Rfced-future] Consensus check: Issue 22 – new stream for RFC Editor

Mirja Kuehlewind <ietf@kuehlewind.net> Fri, 25 June 2021 16:12 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3416F3A0812 for <rfced-future@ietfa.amsl.com>; Fri, 25 Jun 2021 09:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 0XJwPw9o91_o for <rfced-future@ietfa.amsl.com>; Fri, 25 Jun 2021 09:12:35 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 92D0F3A07E2 for <rfced-future@iab.org>; Fri, 25 Jun 2021 09:12:35 -0700 (PDT)
Received: from p200300dee70cfa000c59a854c52a9569.dip0.t-ipconnect.de ([2003:de:e70c:fa00:c59:a854:c52a:9569]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lwoRS-00069c-KS; Fri, 25 Jun 2021 18:12:30 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <c9111b13-e93d-c2f0-9339-517ab728252f@joelhalpern.com>
Date: Fri, 25 Jun 2021 18:12:29 +0200
Cc: rfced-future@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E548D84C-E03F-420E-BF04-F84FAEFAFD5C@kuehlewind.net>
References: <3f4c264e-4639-4d6b-cf22-0a2be503decc@joelhalpern.com> <3D3EC062-7B1A-43C4-99D5-A204A4565ECE@ietf.org> <cf2921d8-fd1f-d9c9-da72-ff760eda347c@lear.ch> <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com> <9fdeb823-9470-00a8-b1b1-91630b996c8c@gmail.com> <351774DB-C6DC-439F-9B5C-FB427EC9F6FE@ietf.org> <ac1aea74-da8e-405d-2a73-fbc6fc97ce24@gmail.com> <D1D7247E-6F03-475A-88F4-50E45A8B6F0E@eggert.org> <0a778f3b-c32e-abba-6e7f-305387adf3ad@it.aoyama.ac.jp> <0d91a5c0-8dd5-cbe8-2ff9-c5b3fed3cbb2@gmail.com> <CDE14B2F-558D-4864-A9E4-66EEEA07B504@kuehlewind.net> <c9111b13-e93d-c2f0-9339-517ab728252f@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1624637555;e2d5e645;
X-HE-SMSGID: 1lwoRS-00069c-KS
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/6jw_It1AHq89yy9dId1OclElgWY>
Subject: Re: [Rfced-future] Consensus check: Issue 22 – new stream for RFC Editor
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2021 16:12:41 -0000

If we would keep using the IAB stream (and I’m not stating any opinion here; just trying to outline what that could mean process-wise), I think we still need some kind of IAB approval, because I think the IAB wants to retain some control about what happens on their stream. However, I think we could easy define something like the IAB can only not-approve based on formal procedural problems but cannot rejecting based on the content that already has community consensus at that point. Yes, it would be an additional process step but I think we can make that very light-weight. However, these are only my personal initial thoughts and it would probably be good to also check with the rest of the IAB if that is considered an option.

P.S.: The IAB reviews all IAB documents to some extend (workshop report are usually written by IAB members) but during approval of those documents everybody understands that we don’t need to have consensus on the content of the document but are rather approving on the basis that the document is considered appropriate and ready for publication.


> On 25. Jun 2021, at 16:43, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> 
> There are a lot of nuances that matter here.
> 
> I could probably live with declaring thatt RSWG / RSAB documents are on the IAB stream if the RFC that said that also said that the IAB could not make any substantive changes to the document and did not have the right to refuse to progress the document.
> 
> All the other cases you cite are ones where the IAB chooses to not review.  This is somewhat different.
> 
> Yours,
> Joel
> 
> On 6/25/2021 4:59 AM, Mirja Kuehlewind wrote:
>> The IAB doesn’t necessarily need to label all IAB documents as IAB “opinions” but all IAB documents need IAB approval. However, such things as workshop reports or also documents published by the RSE are usually not seen as an outcome of the IAB and we often even add a clause to the abstract that explicitly says that the document does not reflect IAB opinions. For things that do reflect an IAB opinion when usually even add the list of names of IAB members at the time of approval, to make clear whose opinions are reflected given the IAB also changes all the time (any thereby potentially also its opinions).
>> Mirja
>> P.S.: As a small side note an a statement that Jay made. The stream mangers do discuss procedures with the RPC but usually the managers would go back to their stream approval body and double-check, e.g. that’s what is currently happening for the terminology guidance. So for me, the stream manager is really just the dedicated contact person here, while the stream “owner” is the approval body.
>>> On 24. Jun 2021, at 22:35, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>> 
>>> On 24-Jun-21 20:57, Martin J. Dürst wrote:
>>>> Hello Lars, others,
>>>> 
>>>> On 2021-06-24 17:46, Lars Eggert wrote:
>>>>> Hi,
>>>>> 
>>>>> On 2021-6-24, at 7:57, Brian E Carpenter <brian.e.carpenter@gmail.com>
>>> wrote:
>>>>>> As somebody else said, this stream by its very nature is going to be special and even self-referential. The notion we have of a stream being a
>>> client of the RFC Series just doesn't apply, so the normal notion of a stream manager doesn't apply**. But surely we need someone to act as progress chaser and nit resolver when a document has left the RSAB and is inside the RPC? And who will that be if it's not the RSEA?
>>>>> 
>>>>> I still remain unconvinced that we even need a new stream. I may be in
>>> the rough, but I would be OK with using the IAB stream and leaving the IAB a role here.
>>>> 
>>>> What would that role be exactly? Giving the label "IAB stream" to these
>>> 
>>>> documents without actually being able to approve or decline any of them?
>>> 
>>> I think that's exactly the problem. The IAB stream labels documents as
>>> representing the IAB's opinion, and would imply that the IAB is
>>> approving the RSAB's opinion, which is not the new model at all.
>>> 
>>>   Brian
>>> 
>>> -- 
>>> Rfced-future mailing list
>>> Rfced-future@iab.org
>>> https://www.iab.org/mailman/listinfo/rfced-future
>