Re: NomCom eligibility & IETF 107

Pete Resnick <resnick@episteme.net> Tue, 31 March 2020 18:29 UTC

Return-Path: <resnick@episteme.net>
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 E45C73A0945 for <ietf@ietfa.amsl.com>; Tue, 31 Mar 2020 11:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[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 zHcXXb_JOAB6 for <ietf@ietfa.amsl.com>; Tue, 31 Mar 2020 11:29:08 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7E03A2760 for <ietf@ietf.org>; Tue, 31 Mar 2020 11:28:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id DAAD9A5FCA31; Tue, 31 Mar 2020 13:28:44 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQZk6hj5aCxw; Tue, 31 Mar 2020 13:28:44 -0500 (CDT)
Received: from [172.16.1.18] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id EC8F3A5FCA28; Tue, 31 Mar 2020 13:28:43 -0500 (CDT)
From: "Pete Resnick" <resnick@episteme.net>
To: "Alissa Cooper" <alissa@cooperw.in>
Cc: "Barry Leiba" <barryleiba@computer.org>, "IETF discussion list" <ietf@ietf.org>
Subject: Re: NomCom eligibility & IETF 107
Date: Tue, 31 Mar 2020 13:28:43 -0500
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <1E702B62-9982-48F2-B8D6-F4F80A8DE168@episteme.net>
In-Reply-To: <0C31D020-46FA-424E-8FFD-64BBE8F952E9@cooperw.in>
References: <CALaySJ+kFVXrVAkYLaO6MaPqDA29MzXhVFcxG0c6hZcBs-LqnQ@mail.gmail.com> <CAC4RtVAhfFLYwzqw6Qch3BpuMvqjZPzFJ5o1iTOwR+yqH8j-Aw@mail.gmail.com> <CAC4RtVCzMPGuunYZBCSh90ddY2kKJ_Hqnot0s1jmhNQ7qT0xkg@mail.gmail.com> <89730DD8-0451-4658-A0CD-83A85E2055FE@episteme.net> <0C31D020-46FA-424E-8FFD-64BBE8F952E9@cooperw.in>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/VhlemFkPN88opxXN2w6uTQbxayg>
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: Tue, 31 Mar 2020 18:29:10 -0000

On 31 Mar 2020, at 12:56, Alissa Cooper wrote:

> My individual opinion is below.

Understood.

> I think what you suggest is a recipe for either delegitimizing the 
> IETF or causing it to enter a state of dysfunction. It assumes there 
> will be consensus at the end of four weeks.

It does not assume that, and I don't think you've actually run through 
all of the reasonable outcomes. First of all, this has been discussed 
for two weeks already. I think the IESG has a pretty good idea of the 
leaning of the community and can draft something that has a high 
likelihood of achieving rough consensus. (And remember, rough is good 
enough.) But let's assume the worst case scenario you pose:

> But if the community can never reach consensus, then either the nomcom 
> chair will have to figure this out on his or her own

A bad choice for the reasons you mention below. The NomCom chair should 
not be put in that position.

> or the nomcom can never be seated

A non-choice. That's simply "The IETF self-destructs". We all agree, not 
an acceptable outcome.

> or the IESG will have to illegitimately declare consensus, as Barry 
> implied.

No. At the point where the community really does deadlock and a decision 
needs to be made, the IESG then does have an emergency on its hands. It 
then says, "The community is not coming to consensus about how to deal 
with 107. A choice needs to be made. This regards a BCP, so it's left to 
us, so we are going to take what we read as the closest to IETF 
consensus, add our best judgement as needed, and publish it as an IESG 
statement. Let the chips fall where they may." In that scenario, the 
IESG will have done exactly what it proposed now, with the difference 
being that it's now clear that the community could not come to a rough 
consensus, so the IESG had to make a call. Yes, that could be appealed, 
or cause upset, but those are the situations where the IESG correctly 
has to exercise authority and be comfortable with, "Yes, we might all be 
recalled, but this was the right thing to do."

This way you have given the consensus process a chance to work out the 
problem, but catch it if it falls. The way the IESG has proposed to move 
forward undermines the consensus process and makes an executive 
decision, a much worse outcome.

> We made much larger changes to the nomcom process a couple of years 
> ago...

I'm inclined not to have a discussion about the merit of that in this 
context.

> Being so rule-bound that we jeopardize the mere ability to renew the 
> leadership in the future seems clearly to be the wrong choice.

Nothing I have proposed jeopardizes the ability to renew leadership. 
It's just giving the community a chance to do the right thing.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best