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

Eliot Lear <lear@lear.ch> Fri, 25 June 2021 16:18 UTC

Return-Path: <lear@lear.ch>
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 CB27C3A085E for <rfced-future@ietfa.amsl.com>; Fri, 25 Jun 2021 09:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.228
X-Spam-Level:
X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 KcFygKX5dHgC for <rfced-future@ietfa.amsl.com>; Fri, 25 Jun 2021 09:18:12 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 751613A085A for <rfced-future@iab.org>; Fri, 25 Jun 2021 09:18:12 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15PGI4uG495869 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 25 Jun 2021 18:18:09 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1624637890; bh=NpT4GjM5d57651/j5W480OM8fdD08Uvr6msIfWUip2w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=QcAZPzrQWshKe9VlH1WEGsuC2RsN+9mH7w3SlWoO0QQWuvnVFIGDI03APNUXfHMBM VansWWn7KKkSg8+J7yDfosn1IGvFxQoasN/vU7urZkh4wo4NirnXjNSlhMLF9XPjc0 rathxzGiVHsPgHsHz9tztW9GrFMZ4hJTmeye5Mtw=
To: Mirja Kuehlewind <ietf@kuehlewind.net>, "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: rfced-future@iab.org
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> <E548D84C-E03F-420E-BF04-F84FAEFAFD5C@kuehlewind.net>
From: Eliot Lear <lear@lear.ch>
Message-ID: <72d46ce5-f733-7cf2-b640-18bbef8709c4@lear.ch>
Date: Fri, 25 Jun 2021 18:18:03 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <E548D84C-E03F-420E-BF04-F84FAEFAFD5C@kuehlewind.net>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="z20bjVXQRRMpjb9aspK62YUDhmbaRMdFN"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/4QxwkkO5rCrADpNVDuiCv3Dt4V0>
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:18:18 -0000

Mirja,

The implication in your note is that there is some great difficulty in 
creating a new stream for this purpose.  Is that really the case?  The 
only real issues we have identified, so far as I understand it, is who 
will represent the stream to the RPC when documents get pushed through, 
and whether someone needs to represent the stream in the RSAB.  Are 
there other issues?

Eliot

On 25.06.21 18:12, Mirja Kuehlewind wrote:
> 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