Re: draft-sullivan-nomcom-chair-select-00

Eliot Lear <lear@lear.ch> Mon, 14 February 2022 16:23 UTC

Return-Path: <lear@lear.ch>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6443A1130 for <ietf@ietfa.amsl.com>; Mon, 14 Feb 2022 08:23:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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.714, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 McBjIz5RYD-0 for <ietf@ietfa.amsl.com>; Mon, 14 Feb 2022 08:22:58 -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 29E903A1129 for <IETF@ietf.org>; Mon, 14 Feb 2022 08:22:57 -0800 (PST)
Received: from [IPV6:2001:420:c0c0:1011::6] ([IPv6:2001:420:c0c0:1011:0:0:0:6]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 21EGMsnN113241 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 14 Feb 2022 17:22:55 +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=1644855775; bh=RySpzKSQTFH+m5QP/3ZGBzczw/4uLldXrlFFW3PdBvQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=OJVeJ/3MIFraak/LN+rhHRSfkt3GLMmNCSmpeCTlE0baD93Fx1ZDu/H9XRZUIw5K5 t0y5hyY5Aylp2A2HWphnKL9Nz0+V3gpdfsHzxpk3pbSXwUnpVK5rOHXJsaVYxlGTN4 txAy1fpVY6NyeQL7J6ezo1m8OxGlRRdKQUHPdoxI=
Message-ID: <34eadbdb-3abb-3125-3cb0-62093b4b0b8e@lear.ch>
Date: Mon, 14 Feb 2022 17:22:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1
Subject: Re: draft-sullivan-nomcom-chair-select-00
Content-Language: en-US
To: Andrew Sullivan <sullivan@isoc.org>
Cc: ietf <IETF@ietf.org>
References: <20220214055405.v7qujqp5lmqynga5@outlook.office365.com> <c461ab52-8611-f3aa-357d-18d2539a3e0b@lear.ch> <20220214140213.avczhkmgbfh5szle@outlook.office365.com>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <20220214140213.avczhkmgbfh5szle@outlook.office365.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------60Kn1BroI8aWm7IymZwhNmYY"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/NBlkRWZYFczRrPnaQTvr4ekKHf0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Feb 2022 16:23:04 -0000

Yeah, the bootstrapping work would need to shift from the chair. I guess 
the underlying question here is this: do we (really you) have a problem 
getting chairs?  Do we need to find new methods? If so, then let's get 
on it.  And yeah, that would require an update of some form to 8713.  
I'm sorry I jumped into the solution space a bit fast.

Eliot

On 14.02.22 15:02, Andrew Sullivan wrote:
> That would require a change to RFC 8713.  Certainly, if the community 
> wants to make that change I would not oppose it, but it would be 
> pretty hard to arrange as it works right now, since the Chair is 
> responsible for operating the procedure by which the NomCom is 
> seated.  So there's a bootstrap problem to this approach. Regardless, 
> it's definitely beyond the scope of this document, because I have no 
> power to alter the process as it exists (and would refuse, if offered, 
> to have that target painted anywhere in my vicinity, much less on my 
> body).