Re: NomCom eligibility & IETF 107

Nico Williams <nico@cryptonector.com> Tue, 31 March 2020 18:42 UTC

Return-Path: <nico@cryptonector.com>
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 5C1413A26A0 for <ietf@ietfa.amsl.com>; Tue, 31 Mar 2020 11:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 7Ok5S-66Eb9o for <ietf@ietfa.amsl.com>; Tue, 31 Mar 2020 11:42:50 -0700 (PDT)
Received: from crane.ash.relay.mailchannels.net (crane.ash.relay.mailchannels.net [23.83.222.43]) (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 886FF3A0D3A for <ietf@ietf.org>; Tue, 31 Mar 2020 11:42:48 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0ECC321087; Tue, 31 Mar 2020 18:42:44 +0000 (UTC)
Received: from pdx1-sub0-mail-a91.g.dreamhost.com (100-96-1-39.trex.outbound.svc.cluster.local [100.96.1.39]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D9C1D20CE0; Tue, 31 Mar 2020 18:42:42 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a91.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Tue, 31 Mar 2020 18:42:43 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Cellar-Befitting: 0d5687674c391a37_1585680163755_2108139144
X-MC-Loop-Signature: 1585680163755:3110649775
X-MC-Ingress-Time: 1585680163755
Received: from pdx1-sub0-mail-a91.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a91.g.dreamhost.com (Postfix) with ESMTP id 3B9F2B118E; Tue, 31 Mar 2020 11:42:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=O6X0m8zG7RgVTg +XazITYuGb+eI=; b=ZEXP3xiy34npripcJrpORhaoewgJndEwL4mV2wX0Eyz9Gc flOprFAgCST/JakEL2+fxu+EgDSouzJ4Zc5r4MCceURtbMPZYMplErOIljvALLn3 epUEpSwTGjY4PPDVftzr6ve0Ilr/Gl2L/e1sYW2jhwTfuQRryCA3MczXAX7Xk=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a91.g.dreamhost.com (Postfix) with ESMTPSA id 1DF8CB118C; Tue, 31 Mar 2020 11:42:39 -0700 (PDT)
Date: Tue, 31 Mar 2020 13:42:37 -0500
X-DH-BACKEND: pdx1-sub0-mail-a91
From: Nico Williams <nico@cryptonector.com>
To: Pete Resnick <resnick@episteme.net>
Cc: Alissa Cooper <alissa@cooperw.in>, Barry Leiba <barryleiba@computer.org>, IETF discussion list <ietf@ietf.org>
Subject: Re: NomCom eligibility & IETF 107
Message-ID: <20200331184236.GT18021@localhost>
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> <1E702B62-9982-48F2-B8D6-F4F80A8DE168@episteme.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1E702B62-9982-48F2-B8D6-F4F80A8DE168@episteme.net>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrtddtgdelgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/bwQQwGHhJkrYDqMatWTz66gdJ7A>
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:42:52 -0000

On Tue, Mar 31, 2020 at 01:28:43PM -0500, Pete Resnick wrote:
> On 31 Mar 2020, at 12:56, Alissa Cooper wrote:
> > 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:

Moreover, if there is no consensus at the end of the LC, the IESG could
call it anyways and anyone who feels strongly enough about it can appeal
the call.  That would put the final outcome in exactly the right place:
the IETF Chair and the IAB.

Whereas the IESG just making a decision w/o a Last Call based on a claim
to authority that is -presumably?!- not subject to appeal... strikes me
as even more negative an outcome than an inconclusive LC.

The risk of lack of consensus is overstated anyways.  The options to
choose from are reasonable.  We'll have individual preferences, but none
of the options should be particularly upsetting.

> > 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.

Indeed.  The appeal authorities should be instead.

> > or the nomcom can never be seated
> 
> A non-choice. That's simply "The IETF self-destructs". We all agree, not an
> acceptable outcome.

True.  Supposing it could happen, that would be a reason to possibly
eschew whatever path might end up in that outcome.  However, I don't
think it's possible, and the IESG calling a consensus (subject to
appeal) even with an inconclusive LC would be just fine.

Nico
--