Re: [Gendispatch] draft-rsalz-termlimits

"Joel M. Halpern" <> Sat, 23 October 2021 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDD5D3A093A for <>; Sat, 23 Oct 2021 10:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wcq1MJa7SoiZ for <>; Sat, 23 Oct 2021 10:38:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 182AA3A08F6 for <>; Sat, 23 Oct 2021 10:38:50 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4Hc7k14fdvz1nvNH; Sat, 23 Oct 2021 10:38:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1635010729; bh=cA2ijxaWAeUE+jeAlgx5IrFiuK3qdVqMip9p5uSwke4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=bu/HvqVbuPOpsdbxRDcNwtl+/gjWP64ETK4EvDb0drtFrKLDrHYqZ1bt2d1DEn+te Jsp0BF5g8MwzBGlmBlyEj0FtQFQfS+YjCiOvPXneBdlzlMFMOvW5cVrvOr/xrF7itv PBSGC+bp4UObLpdYcnjhcDtabYZAU2t+7QRWkSD4=
X-Quarantine-ID: <CN7a0aZUupV4>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 4Hc7k11828z1nthx; Sat, 23 Oct 2021 10:38:48 -0700 (PDT)
Message-ID: <>
Date: Sat, 23 Oct 2021 13:38:48 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1
Subject: Re: [Gendispatch] draft-rsalz-termlimits
Content-Language: en-US
To: "Salz, Rich" <>
Cc: "" <>
References: <> <> <> <4506E7DA9EF80C64C6AE9432@PSB> <> <7102767AA0D5C9F679E9B61C@PSB> <>
From: "Joel M. Halpern" <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Sat, 23 Oct 2021 17:38:56 -0000

"Untenable" is a pretty extreme word to use to describe the current 
situation.   Given that in fact we generally turn ADs over after either 
2 or 3 terms (usually 2), it is really hard to see how making that a 
hard rule is a fix to an untenable situation.

Given the difficulties some nomcoms have had in finding candidates for 
open seats, I do not see any evidence that the forcing function you want 
to create will actually help anything.

I have no problem with strengthening the guidance about 2 terms, 3 
terms, 4 terms.  I can live with guidance for a gap year.  But creating 
a hard rule seems, as has been said by multiple to people, to be taking 
the hard task of finding leadership for the IETF and making it harder.


On 10/23/2021 1:26 PM, Salz, Rich wrote:
>>     (1) I'm concerned about edge cases in which an extra (i.e.,
>      third) term would be in the interest of the incumbent and the
>      community.
> All things being considered -- notably the lack of diversity and tendency to entrenchment among the leadership -- I find it hard, if not impossible, to find such an edge case. Surely we can find someone capable of doing the job, and maybe a secondary forcing function is that the job description changes. We'll see.  I find the current situation untenable.  As we used to say in Usenet, "death of the net predicted."
> Note that this is a draft, and could be modified if somehow adopted. If the community wants to handle edge cases or exceptions, that's certainly our right and ability.
>> I've got a general distrust of trying
>      to do things by rigid rules in the IETF.  We've historically
>      been much better off delegating responsibility and and authority
>      to groups or clusters of people, letting them do their work, and
>      then holding them accountable for it.
> Sure, I don't disagree.  Except we've talked for years and years about how to change the AD jobs and nothing has happened.  Who is accountable for having mostly the same-old same-old people in leadership, and little diversity?  NomCom changes every year, so it can't be them.  Heck, we don't even have a mechanism for passing on lessons to future NomCom's based on past experiences.
>>   The big problem with the
>      Nomcom in that regard is that they do whatever they do, their
>      internal discussions and the information they base them on are
>      largely confidential, and there is no accountability mechanism.
> Yes.  It's a black box. To me, the only possible change that will work is to change the inputs; i.e., those are nominated.
>> it seems to me that what the proposal does is
>      to deprive the Nomcom of the option of making one particular
>      type of hard decision while shifting no responsibility for those
>      decisions to the community at all (even if it increases the
>      pressure on the community to generate more candidates).
> The "hard decision" is to pick status quo. That is generally considered to be a safe decision, not hard. Worst-case, nobody is nominated for AD and the position is left open until the situation is fixed. Your draft allows for that IIRC.  You can't pressure a community without a "crisis"  Without a real change, we'll get more of the same. I took the community survey to heart, and I honestly wonder how many years we have left if we don't enact real change.