Re: [Gendispatch] draft-rsalz-termlimits

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

Return-Path: <jmh@joelhalpern.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 BDD5D3A093A for <ietf@ietfa.amsl.com>; Sat, 23 Oct 2021 10:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 wcq1MJa7SoiZ for <ietf@ietfa.amsl.com>; Sat, 23 Oct 2021 10:38:50 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 182AA3A08F6 for <ietf@ietf.org>; Sat, 23 Oct 2021 10:38:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Hc7k14fdvz1nvNH; Sat, 23 Oct 2021 10:38:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; 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 b2.tigertech.net
Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4Hc7k11828z1nthx; Sat, 23 Oct 2021 10:38:48 -0700 (PDT)
Message-ID: <d8bbebb2-f582-1d64-3b4c-d957e663d97a@joelhalpern.com>
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" <rsalz=40akamai.com@dmarc.ietf.org>
Cc: "ietf@ietf.org" <ietf@ietf.org>
References: <394BBA1E-FA83-4E80-A143-BE3F0764DCDA@tzi.org> <F2D8B2B0-1005-424F-9984-3AC6F951E02F@eggert.org> <CDD17BF9-BBF6-413F-80A6-2928995807C1@akamai.com> <4506E7DA9EF80C64C6AE9432@PSB> <C3ECF081-E47E-4E2B-B17F-F5D39111B114@akamai.com> <7102767AA0D5C9F679E9B61C@PSB> <FBF0A987-8280-4BB6-8EBD-181F09798993@akamai.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
In-Reply-To: <FBF0A987-8280-4BB6-8EBD-181F09798993@akamai.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/j7wOvFdmpwt9UBKMvMQgQpitlXc>
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: 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.

Yours,
Joel

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, https://www.ietf.org/blog/ietf-community-survey-2021/ and I honestly wonder how many years we have left if we don't enact real change.
> 
> 
>