Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07)

Mirja Kuehlewind <ietf@kuehlewind.net> Mon, 03 January 2022 15:24 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 28ADE3A0A19; Mon, 3 Jan 2022 07:24:04 -0800 (PST)
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, HTML_MESSAGE=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 bVvPUAFmUHGB; Mon, 3 Jan 2022 07:23:58 -0800 (PST)
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 988393A0A13; Mon, 3 Jan 2022 07:23:58 -0800 (PST)
Received: from p200300dee733e700114c3388f1dd340c.dip0.t-ipconnect.de ([2003:de:e733:e700:114c:3388:f1dd:340c]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1n4PBh-0005kC-FW; Mon, 03 Jan 2022 16:23:53 +0100
From: Mirja Kuehlewind <ietf@kuehlewind.net>
Message-Id: <CAFB3EA8-11D9-4D55-924A-B66294309869@kuehlewind.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8FAEAA3E-86BD-4680-938F-3FA6105BE0A6"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 03 Jan 2022 16:23:52 +0100
In-Reply-To: <de858e02-a6ff-613b-3d2c-db85d5ea42b1@lear.ch>
Cc: Jay Daley <exec-director@ietf.org>, John C Klensin <john-ietf@jck.com>, rfced-future@iab.org, Michael StJohns <msj@nthpermutation.com>
To: Eliot Lear <lear@lear.ch>
References: <F0016CA1725A561034951054@PSB> <7D28CA5F-594B-4212-9155-86669654A504@ietf.org> <A1A5EDBA-7598-4E74-ACEE-B7A39A8010F5@kuehlewind.net> <de858e02-a6ff-613b-3d2c-db85d5ea42b1@lear.ch>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1641223438;5f5d6403;
X-HE-SMSGID: 1n4PBh-0005kC-FW
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/xZ4Yi0Nn_RCMBX9FzZdzbyoOuv0>
Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07)
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: Mon, 03 Jan 2022 15:24:04 -0000

Hi Elliot,

I’m not disagreeing, nor do I want to reopen this issue but now that you state it this way it feels to me it needs a bit of clarification.

First I was assuming that when we say IETF LLC here, we actually mean the Board as the IETF LCC Board is defined as "multi-member "manager" of the IETF LLC” in RFC8711. Decision have to be made by humans and not an abstract entity and therefore the board would be responsible here.

Further, the IETF LLC is mention two times here: 1) to form the selection committee, 2) to make a final decision on the RSCE. The board can delegate the task to “create” the search committee to anybody any time, however, the responsibility for these decisions stays with the board from my point of view. I don’t think they can actually delegate a “decision”.

Mirja

P.S.: I reviewed the notes you linked below and if you read them at whole and particularly Jay’s comments (e.g. "the LLC board is the final sign-off”), I believe this also reflect my assumption that then board is responsible when we say IETF LLC in the text. The sentence you cited is out of context is from the beginning of the discussion and not the end. At that point the discussion was about the question if we need to mention a search (or selection) committee at all in the document or lave this entirely to the LLC.



> On 3. Jan 2022, at 15:51, Eliot Lear <lear@lear.ch> wrote:
> 
> Hi Mirja,
> 
> On 03.01.22 14:43, Mirja Kuehlewind wrote:
>> This is the text in draft:
>> 
>> "The IETF LLC will form a selection committee, including members from the community, that will be responsible for making a recommendation to the IETF LLC for the RSCE role.”
> 
>> [snip]
> 
>> However, I would also like to note that th text says the LCC Board forms the selection committee and not the ED. While these are internals on how the LLC Board manages itself, I would assume that’s rather a job for the LLC Board chair with approval of the whole (community-selected) board than the ED. This issue was discussed and confirmed (changing responsibility from the ED to the whole LLC board in GitHub issue #40).
> Yes, that was indeed Issue 40 which you opened in April and was closed after we discussed it in detail and came to a conclusion in July.  However, by design, the text above does not refer to the board, but rather to the LLC.  The sentiment that carried the day at the time was perhaps best summarized by Martin Thomson:
> 
> 
>> Split the difference and say the LLC is responsible, this would likely fall to the Executive Director, but no need to explicitly specify that
> (See the notes <https://notes.ietf.org/notes-ietf-111-rfcefdp#>).
> 
> It's not that the LLC board DOES decide or that the ED decides on the RSCE position, but rather it is for the the LLC board to decide whether to delegate that decision.
> 
> What I am drawing from all of this, by the way, is the importance of closing this document, because people really are losing context of the decisions that have been made.  The chairs will have more to say on that shortly.
> 
> Eliot
> 
> <OpenPGP_0x87B66B46D9D27A33.asc>