Re: NomCom eligibility & IETF 107

Alissa Cooper <> Tue, 31 March 2020 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B778E3A25F7 for <>; Tue, 31 Mar 2020 10:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=HeVyjzJ0; dkim=pass (2048-bit key) header.b=YQIFpRrn
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RbC0FLZOrGln for <>; Tue, 31 Mar 2020 10:56:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFB1A3A25F5 for <>; Tue, 31 Mar 2020 10:56:21 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id F223D5C0578; Tue, 31 Mar 2020 13:56:20 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Tue, 31 Mar 2020 13:56:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=M ms4vJbYdz7/M22KCifIXA+/qnuzbqOa86KPvR+jfQI=; b=HeVyjzJ0no9UB34+S MRiWtv9MCwCz6K41G7QEghazixa9AU0Lm7ia20c1Ds5E55p5oZkyiDdSYqoNJv8k rV+Nz+2QNB/sN+PA8PYQY6c9Ir003IVm8XeBhv1qFeLWFZfnrM2l9/UNSxt+WM/h FNTSCF7nQ4n64nmO7MqYFNxogA9ABD+sc5mS4Rhm3jHH+bb3FM0rVVi2IQfLCfzT S/c5Yn8sTdI8eR4V8rNCEiJA1oujrt+DMMB/zlm0YHpSfvI+RTmgbNqtyP9J3QPD bOTqGHA4xdx09fARF3d0ijtibA22bmMeR6FVul2nZyadGsxFeXlMCHVSXjOWglYj +ONkA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc: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=Mms4vJbYdz7/M22KCifIXA+/qnuzbqOa86KPvR+jf QI=; b=YQIFpRrn0NFp/lH7FUho19TEY4189yKlDWsiLp6ECWvs0YqjzRya2JoAY pK6sEZ7Fj2YeOhDsmtOtVVDYVDiGlcEAtbm7KQcZVLqRA3uiDmZ65QnKDfV5i/2V HFx7rtZ7KjIYh66nvP4Iy9dpWsmlJ08Sb4Ex5/Qe2IVQWl5HARvQTeYHeirXvM64 YHnSfleg4r1mymI335al2WP4sXVFF+DbnajEiLrv+fJuIcwNg9WlmuLd8oj3CMqe QA1uLcLj4VzzkQsSXQ7PqM5s0WUxZf//xmHZY87f2kWTEH31fd8BnhC0LCrBBJxA 6KHei/aMuWbjDt8oQGxLFCeFrdl9A==
X-ME-Sender: <xms:RISDXl0btJOLo0weJbchW4Xh9BCZdOwpUcCPfGpgO3dnafRO92ksVw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtddtgdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpegvphhishhtvghmvgdrnhgvthenucfkphepuddtkedrhedurddutddurdelkeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrg estghoohhpvghrfidrihhn
X-ME-Proxy: <xmx:RISDXmpC6wHalPk9ucDSJlrw5U4G577yMLJaG6NW_TnR3AhYkj7_NQ> <xmx:RISDXieRri3Q_I_6Es8jwN6n6vis4uMi6zfPZZ2S5umsb49VVfXL_Q> <xmx:RISDXloN8phwUIiIH8wDYO24qh6XGnrO71ZZP1QiU_1okoxXlaHKNg> <xmx:RISDXjOmmJQiMXaqzkq9Ps4uP1QsP_YFxVorOKWsQq0s2rmekE7HtQ>
Received: from alcoop-m-c46z.fios-router.home ( []) by (Postfix) with ESMTPA id 6B649306CBC9; Tue, 31 Mar 2020 13:56:20 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Subject: Re: NomCom eligibility & IETF 107
From: Alissa Cooper <>
In-Reply-To: <>
Date: Tue, 31 Mar 2020 13:56:19 -0400
Cc: Barry Leiba <>, IETF discussion list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Pete Resnick <>
X-Mailer: Apple Mail (2.3445.9.5)
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 17:56:24 -0000

Hi Pete,

My individual opinion is below.

> On Mar 31, 2020, at 1:12 AM, Pete Resnick <> wrote:
> On 30 Mar 2020, at 23:25, Barry Leiba wrote:
>> 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.
> Barry, I think the IESG has made an error, specifically on this point. Last-calling a document for 4 weeks is precisely designed for the situation where most (if not all) of the community has not had a chance to comment on it. And in the only specifically documented variance procedure in the IETF (2026 section 9), this kind of thing is exactly what it anticipates: The IESG writes up what it thinks it's heard about what the variance should be, it immediately puts it out for Last Call, it takes those 4 weeks to assess the consensus of the IETF and adjusts the document to suit, and then it publishes. Following that same model has a much better chance of standing up to questions of legitimacy than the IESG proposal: collecting opinions with no text to look at, and then in 4 weeks writing some text that the IESG thinks represents the consensus and calling it approved. That is inviting a great deal of contention.
> You (or I or any number of other people in this discussion) can write up and post a draft in less than 24 hours. The IESG can immediately Last Call it. Folks can then discuss the document and the IESG to make adjustments to it over the next 4 weeks. It can be acted upon once approved. To do otherwise goes against the openness of our processes.
> Please, IESG, reconsider your decision on this, and quickly. You can do the right thing in a reasonable amount of time without trying to do something that is inviting a protracted process fight.

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. But if the community can never reach consensus, then either the nomcom chair will have to figure this out on his or her own, or the nomcom can never be seated, or the IESG will have to illegitimately declare consensus, as Barry implied. The first option might work, but presumably is more objectionable to people such as yourself than what Barry outlined. The second option means people will start rotating off the leadership in 2021 until consensus can be reached and a nomcom can eventually be seated, potentially yielding a period of time where up to half of the IESG and IAB seats are vacant. The third option undermines the value of the consensus process itself.

We made much larger changes to the nomcom process a couple of years ago long before any consensus documents were published. The changes made to the nominations process for the IETF Trust and the LLC Board were reflected in the work of both the 2018 nomcom and the 2019 nomcom, but the documentation of them didn’t finish IETF last call until June 24, 2019. There is no reason why the current circumstances should be held to a different standard.

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


> pr
> -- 
> Pete Resnick
> All connections to the world are tenuous at best