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

Eliot Lear <lear@lear.ch> Mon, 03 January 2022 16:10 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 68EBB3A073D; Mon, 3 Jan 2022 08:10:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.603
X-Spam-Level:
X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, 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 Qs726QbYoLBj; Mon, 3 Jan 2022 08:10:07 -0800 (PST)
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 E23FA3A06E7; Mon, 3 Jan 2022 08:10:06 -0800 (PST)
Received: from [192.168.0.129] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 203GA3fW2464819 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 3 Jan 2022 17:10:03 +0100
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=1641226203; bh=PXQFvr0WcEHUqrVdhiboZcR/g+PTszwWFQOrbcCkXYk=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=lzf15QGqhyJGjnERvz2+zxrLLe2VLqj2HwSBqU/qTrIC8CZklYg4SOhzY0XFlVkE3 74zBdoWdy2dyKV+79dlSehOjnhVc/zFSssXpvg8alVDPmN46We3sSCwc5Uo6UEXS7H IHOeNXprWKcViIXwKyfHVBwZicot+5hIStkHt23c=
Message-ID: <37a4179f-b1ac-4cb8-d69d-f1b65d1c08f7@lear.ch>
Date: Mon, 03 Jan 2022 17:10:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
Content-Language: en-US
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: Jay Daley <exec-director@ietf.org>, John C Klensin <john-ietf@jck.com>, rfced-future@iab.org, Michael StJohns <msj@nthpermutation.com>
References: <F0016CA1725A561034951054@PSB> <7D28CA5F-594B-4212-9155-86669654A504@ietf.org> <A1A5EDBA-7598-4E74-ACEE-B7A39A8010F5@kuehlewind.net> <de858e02-a6ff-613b-3d2c-db85d5ea42b1@lear.ch> <CAFB3EA8-11D9-4D55-924A-B66294309869@kuehlewind.net>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <CAFB3EA8-11D9-4D55-924A-B66294309869@kuehlewind.net>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------XLkMaGfXg8oENOKBJX0qFVpd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/i4yctJNsf2eozvPOo3VOk08iJWk>
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 16:10:12 -0000

Hi Mirja

On 03.01.22 16:23, Mirja Kuehlewind wrote:
> 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.

While I am fully confident that Jay's statement was and probably remains 
true, the board can never-the-less decide to delegate later.   Nowhere 
does it say they cannot; and our text actually reaffirms that (we 
explicitly call out the board elsewhere in the doc, but not there).  My 
point is simply that you should not make the assumption that this text 
constrains the current board or future boards to not delegate; and you 
may wish to take that into account in terms of how you consider the 
current matter.  As a practical matter, I doubt they would delegate this 
hiring decision for at least the foreseeable future, but that is me 
merely speculating.

Eliot