Re: NomCom eligibility & IETF 107

Nico Williams <nico@cryptonector.com> Tue, 31 March 2020 06:02 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 C9AE43A1BDC for <ietf@ietfa.amsl.com>; Mon, 30 Mar 2020 23:02:46 -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 2wLS0re1MHJv for <ietf@ietfa.amsl.com>; Mon, 30 Mar 2020 23:02:45 -0700 (PDT)
Received: from brown.elm.relay.mailchannels.net (brown.elm.relay.mailchannels.net [23.83.212.23]) (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 6E0433A1BDB for <ietf@ietf.org>; Mon, 30 Mar 2020 23:02:44 -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 A11336406FB; Tue, 31 Mar 2020 06:02:43 +0000 (UTC)
Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-96-6-10.trex.outbound.svc.cluster.local [100.96.6.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0E2A1640848; Tue, 31 Mar 2020 06:02:43 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a18.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 06:02:43 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Eight-White: 3ebaa49423fc156a_1585634563503_968130509
X-MC-Loop-Signature: 1585634563503:1967436144
X-MC-Ingress-Time: 1585634563503
Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id BC90DB26AC; Mon, 30 Mar 2020 23:02: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:content-transfer-encoding; s= cryptonector.com; bh=eo3tO6AufjIpN7oGo3w55T3D4x0=; b=vJps6yhCeJV 35m2qB41GineefktAjqssMGI5TJ3qf012qsLv1YL29ZmpSoGr/jOPEmiv5MLNVhE 1pKSsp6NT9OFjl/lBNo3LnDots7gHxP5RRkQEO2JdGXQFIyUXAiA5UEjZ7Rz18fs PxOTHDvBrtQDpcmdjhSo7G6mHPc28UPk=
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-a18.g.dreamhost.com (Postfix) with ESMTPSA id CBD3DB2680; Mon, 30 Mar 2020 23:02:41 -0700 (PDT)
Date: Tue, 31 Mar 2020 01:02:39 -0500
X-DH-BACKEND: pdx1-sub0-mail-a18
From: Nico Williams <nico@cryptonector.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: IETF discussion list <ietf@ietf.org>
Subject: Re: NomCom eligibility & IETF 107
Message-ID: <20200331060238.GR18021@localhost>
References: <CALaySJ+kFVXrVAkYLaO6MaPqDA29MzXhVFcxG0c6hZcBs-LqnQ@mail.gmail.com> <CAC4RtVAhfFLYwzqw6Qch3BpuMvqjZPzFJ5o1iTOwR+yqH8j-Aw@mail.gmail.com> <CAC4RtVCzMPGuunYZBCSh90ddY2kKJ_Hqnot0s1jmhNQ7qT0xkg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAC4RtVCzMPGuunYZBCSh90ddY2kKJ_Hqnot0s1jmhNQ7qT0xkg@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeiiedguddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/W9tTv6KIf1d7TMUqDcgF1hnVxOM>
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 06:02:47 -0000

On Tue, Mar 31, 2020 at 12:25:35AM -0400, 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.

But earlier you wrote:

| If you haven't already weighed in on this, please post your comment
|here, in this thread on <ietf@ietf.org>, by 30 April 2020.

That's... four weeks.  You don't have to get the BCP published, just
approved, and four weeks is enough time, isn't it?

> 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

A last call *is* a normal period of discussion.  Sure, there would be no
preceding discussion, but that's OK -- the minimum time is 4 weeks, and
you've got 28 days + two to spare.

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

Perhaps, but it's much better not to even require a debate about that
and follow the standard process.

> 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 the input collection happens on the ietf@ietf.org list, then how is
this different from running an actual IETF Last Call?

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

You can do it all in a single last call.

Are you concerned that the LC would be inconclusive?

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

Sure.

Nico
--