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

Joel Halpern Direct <jmh.direct@joelhalpern.com> Wed, 23 June 2021 09:06 UTC

Return-Path: <jmh.direct@joelhalpern.com>
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 B2E333A3067 for <rfced-future@ietfa.amsl.com>; Wed, 23 Jun 2021 02:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level:
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.338, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 cOUP86Vrobnv for <rfced-future@ietfa.amsl.com>; Wed, 23 Jun 2021 02:06:45 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 7F79C3A3065 for <rfced-future@iab.org>; Wed, 23 Jun 2021 02:06:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4G8y7T1z2wz1nsL9; Wed, 23 Jun 2021 02:06:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1624439205; bh=hHU5vlul29HV52ej1AsenS80wgG5577/5HfpioNubgw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=iuGhVNddTReFkHjw7bC20U41IRL3yngdl/G/+eed1FxQfNDQLxSpRo9fiCdOQGv6w yKUCmgFy8GmbX1+eOcCOKz8RtG8P4CS/GPo64tioE7fvnBjqvAi+etZ1LFfz1/0yJ6 6PlbXlaIExaaY3tpK8hVTSESr2/Grvqhm5EeWuys=
X-Quarantine-ID: <USuQW_MwfZWQ>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4G8y7S4wpJz1ns8G; Wed, 23 Jun 2021 02:06:44 -0700 (PDT)
To: Eliot Lear <lear@lear.ch>, Jay Daley <jay@ietf.org>
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>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <3b4b6d91-64e3-d0d7-bcbc-284f29a46fb7@joelhalpern.com>
Date: Wed, 23 Jun 2021 05:06:44 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <cf2921d8-fd1f-d9c9-da72-ff760eda347c@lear.ch>
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/rfced-future/pWrSxabXFq1qaB6yFY0IgAUUcnk>
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: Wed, 23 Jun 2021 09:06:50 -0000

I am wondering if we are mixing the concept of stream manager with 
stream content owner.  The IESG is responsible for the content of the 
IETF stream.  The IETF Chair or their delegate is the IETF stream 
manager.  That role is making sure that there are no issues with the 
practical publication of the stream, including interacting with the RPC.

Declaring the RSAB to be the stream manager hurts my head.  That is not 
a person.  And will create confusion about the role of the RSAB.  WHile 
the obvious analogy is to declare that the RSAB chair is the stream 
manager for this new stream, it seems to me that creates confusion since 
that person is (unless they are the RSE/A) the stream head for some 
other stream.

Yours,
Joel

PS: One answer may be that there is no stream manager for this stream? 
Because the role is redundant with the defined roles for the RSAB?

On 6/23/2021 4:56 AM, Eliot Lear wrote:
> If you're suggesting that the RSAB itself hold the stream, that's 
> certainly an alternative.  However, the RSAB should probably be bound by 
> policies of This document in the use of the stream.  This would be 
> similar in nature to how the IAB stream is operated.
> 
> On 23.06.21 10:49, Jay Daley wrote:
>>
>>> On 23/06/2021, at 8:18 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>>
>>> From my perspective, you are correct that it is a bit of a 
>>> misalignment.  But...   A committee is not a stream manager.  And 
>>> giving any of the members of the RSAB a second stream confuses the 
>>> streams identity.
>> It’s not a “content” stream though - it’s a “meta” stream that all the 
>> other streams have a strong stake in, which gives it a distinct identity.
>>
>>>   Thus, we bend / stretch the RSEA role a bit?
>> But what does that mean in practice given that all the decisions about 
>> this stream are made by the RSWG? If I may introduce a useful English 
>> expression into IETF discourse, it’s as much use to the RSEA as a 
>> chocolate teapot.
>>
>> Jay
>>
>> (sent from my phone)
>>
>