Re: NomCom eligibility & IETF 107

Keith Moore <> Tue, 31 March 2020 16:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 361133A181B for <>; Tue, 31 Mar 2020 09:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WuZrOUgB7XCE for <>; Tue, 31 Mar 2020 09:30:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 822953A23DE for <>; Tue, 31 Mar 2020 09:30:20 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 8606C5C0598; Tue, 31 Mar 2020 12:30:19 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Tue, 31 Mar 2020 12:30:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=JQY5+5/RkOfzOiRYW2g7s24Pr+AVydzmItc6cdjwz JU=; b=Z/DJzxe1N841m+Fs/osRzDYpV+OuoeTsyqFDJsar1G4S4irL9Llw6BS/x NKIml51LQiXqY2VydD2MJ/cDm2ZXV9Xxys3hNG+Eq2ScuObDhvNVx/p7gw//60mn 4smWpDV20JIDL+eaw2KRVBQ6RnliS69n10cNfQ1EfO7y4BMxISAFyPr3juO+vdUs NxCUOU1HSpMhuRxTXmIOa6kYoVpvRrN3vy68dRucCj3gdwgbv/hJskGdd7ggnSoD 4bbAvH3/DJ5jEah816WhEbBznbUV5c2Fj+FvyyL7XzeS2JV+sK1he7750HhHEC/o WUGv+6N7TbMvSKJ7CL4nZLXLrXUlg==
X-ME-Sender: <xms:G3CDXm5Fo_MuL2V-PfZVm33LF10KmJZw_KZPznDLXiB_VCXVFpyReg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtddtgdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecukfhppedutdekrddvvddurddukedtrdduhe enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohho rhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:G3CDXgpoFVX8rFEGlNd61ISrDAbrlndzL45cVBOP531YTtZf3zHxXw> <xmx:G3CDXlFZP11AvwC9zxRjkBH-_rgvz92IYlaEDdjJGNDwMyx3UlLObQ> <xmx:G3CDXsVUUDJDjIpajYAwwgeFEtt36ohMjq6-D4MJg_3H912QgQMk7A> <xmx:G3CDXhtCYUXsFv0HSDfBQYeGYHQGz_gJqvpUKuX51jKoqRYhGK08eg>
Received: from [] ( []) by (Postfix) with ESMTPA id CFA7C3280069; Tue, 31 Mar 2020 12:30:18 -0400 (EDT)
Subject: Re: NomCom eligibility & IETF 107
References: <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Tue, 31 Mar 2020 12:30:17 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Mar 2020 16:30:22 -0000

On 3/31/20 12:25 AM, Barry Leiba wrote:
> The IESG has discussed what the best way is to handle a decision for 
> eligibility for the 2020/21 NomCom, given the timeframe involved and 
> the discussions that are already happening.
> 1. We are concerned that a normal process for discussing a draft, 
> conducting a last call, and approving a BCP would take too long.
> 2. We are concerned that rushing such a process by, for example, 
> posting a draft now and immediately last-calling it without a normal 
> period of discussion would call into question the legitimacy of our 
> consensus process and would set a bad precedent.  We also note that 
> have already stated that we’d like community comments by 30 April, and 
> we are concerned about cutting that time short in order to write such 
> a draft.
> 4. We believe the IESG does have — and must have — the latitude to 
> address exceptional situations such as this and to make exceptions to 
> our processes.  At the same time, we appreciate and agree with 
> concerns about overstepping, and we agree that maintaining 
> accountability and appropriate checks and balances is important.
> The IESG, therefore, plans to continue collecting input and evaluating 
> the community’s rough consensus about the immediate NomCom-eligibility 
> question through 30 April, as stated.  We will then post a statement 
> and inform the ISOC Board of Trustees, as we would do with a process 
> BCP.  That statement will serve as the basis for eligibility to serve 
> on this year’s NomCom, and this year’s only; it will NOT remain in 
> effect beyond that brief timeframe, and will make that aspect clear.
> If rough consensus of the community is that it is important for the 
> IESG’s decision to be published as a BCP, we will do so, handling that 
> after the immediate need for a quick decision has passed and making 
> the publication for archival purposes.
> We also encourage the community to continue and complete the two 
> efforts that have been started, to formally define an exception 
> process, and to update NomCom eligibility requirements to account for 
> virtual meetings and for remote participation.
> Barry, for the IESG
After thinking a bit more about this:

a) Without a definite and easily-referenced proposal, it will be much 
more difficult for the IESG to gauge community consensus. An email 
proposal really isn't sufficient because it's not very easily 
referenced.   Also email conversations tend to shift rather quickly so 
that different reviewers will have different ideas about the current 
state of a proposal, again making community input harder to evaluate.   
So IMO it's necessary to have a proposal written up as an Internet-Draft 
and for the Last Call to reference that specific document.

b) Even if IESG has "latitude" such as you describe (which I'm actually 
dubious about), I believe it can only have such latitude to the extent 
that it follows established IETF consensus procedures as closely as 
possible.   So for instance, publishing a BCP (assuming you get 
consensus on it) is not optional, nor is it something that requires an 
additional determination of consensus, because that deviation from 
process is not made necessary by the current emergency.

A good faith effort on IESG's part would look like publishing an I-D, 
like, tomorrow, and Last Calling it.   It's not necessary that the 
proposal be perfect; it's only necessary that it put enough of a stake 
in the ground that the community can evaluate the proposal and IESG can 
make sense of the responses.   If IESG sees from the feedback that 
slight changes are needed to win consensus, making those slight changes 
can be done without another Last Call as quite often happens with other 
IETF consensus documents.

I believe that the community will support any reasonable proposal for 
nomcom eligibility in this one specific instance of nomcom selection, as 
long as that proposal is submitted expeditiously. I have, uh, less 
confidence that the community will support IESG making up its own rules.