Re: I-D Action: draft-rsalz-termlimits-00.txt

Jared Mauch <jared@puck.nether.net> Wed, 20 October 2021 22:11 UTC

Return-Path: <jared@puck.nether.net>
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 2BC753A0788 for <ietf@ietfa.amsl.com>; Wed, 20 Oct 2021 15:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 yGpc5MUB4J9O for <ietf@ietfa.amsl.com>; Wed, 20 Oct 2021 15:11:40 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A84B3A0776 for <ietf@ietf.org>; Wed, 20 Oct 2021 15:11:40 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2602:fe55:64:0:4c6e:8202:4e00:8930]) (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 puck.nether.net (Postfix) with ESMTPSA id 9E10B54009A; Wed, 20 Oct 2021 18:10:20 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-3C86E156-7397-4379-890D-E65EC88425BA"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: I-D Action: draft-rsalz-termlimits-00.txt
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <f7d31a4d-344e-9a7d-7397-7984c958f340@gmail.com>
Date: Wed, 20 Oct 2021 18:10:18 -0400
Cc: John C Klensin <john-ietf@jck.com>, IETF discussion list <ietf@ietf.org>
Message-Id: <297B1937-66F6-48B9-98FE-CAA3204BDC29@puck.nether.net>
References: <f7d31a4d-344e-9a7d-7397-7984c958f340@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: iPhone Mail (19A404)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/PLJf237Dno2j1s6o6nGhXlXg4_A>
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: Wed, 20 Oct 2021 22:11:45 -0000

I must agree with this. We have seen the impacts of this in my state. They were enacted likely with similar well intentions - the outcome is people cycling through so fast the incentives change. (At least in our statewide politics).  

- Jared 

https://crcmich.org/press-releases/twenty-five-years-later-term-limits-have-failed-to-deliver-on-their-promise-but-theyre-probably-here-to-stay

Sent via RFC1925 complaint device

> On Oct 20, 2021, at 4:36 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> Well, I am not convinced. *Guidance* to NomCom along these lines
> would be a fine idea, but a firm rule, IMHO, would over-constrain
> an already constrained solution.
> 
> Regards
>   Brian
> 
>> On 21-Oct-21 09:29, John C Klensin wrote:
>> 
>> 
>> --On Thursday, October 21, 2021 08:32 +1300 Brian E Carpenter
>> <brian.e.carpenter@gmail.com> wrote:
>> 
>>> Well, this is a bad idea that was repeatedly rejected in the
>>> past.
>> 
>> Brian, I believe that hard limits were rejected in the past for
>> two reasons:
>> 
>> (i) There will certainly be specific cases for which they are
>> the wrong answer.  We can imagine many such cases.
>> 
>> (ii) There has been at least a suspicion in the community that
>> the IESG is opposed to anything that would put additional
>> constraints on incumbents (e.g., themselves).
>> 
>>> Why? Because it's always hard to fill all the positions, and
>>> this would make it harder.
>> 
>> I suggest there is a different way to look at that.  If we have
>> a position that cannot be filled by someone able, willing,
>> competent, and with adequate time and resources, a Nomcom would
>> be doing the community a big favor by not filling it and thereby
>> forcing a review of whether we need that position, whether the
>> role that position is supposed to satisfy is correctly defined
>> for needs at the time or whether some reorganization would serve
>> us better, whether our ambitions for what should be done are
>> realistic, and so on.  Probably the same principle should apply
>> when there is only one candidate whom the Nomcom (or other
>> appointing body) would not consider acceptable if there were any
>> other choices.
>> 
>> As a specific example that has come up before, if there is an
>> area with two ADs and one of those slots cannot be filled, it
>> should trigger a review of whether that area can get by on one
>> AD, whether we need the Area at all any more (so that the remain
>> AD should be charged with winding it down), whether some of the
>> WGs in the Area should be trimmed, and whether the IESG is in
>> need of a reorganization.  
>> 
>> Moving forward with a least-bad candidate because it was hard to
>> recruit people may help patch a problem but I suggest it is bad
>> for the IETF in the long term.
>> 
>> And that suggests there is actually value in term limits:  if we
>> know, a year in advance, that a position will be open, it allows
>> far more time to think about candidates, twist arms, line up
>> resources, etc.,  and even whether some of the above thinking
>> about the organization or the Area or the IETF would be in
>> order.  in addition, telling organizations who support
>> Nomcom-selected people during their terms that it for a maximum
>> of two such terms might make it easier to get agreement than if
>> it is a potential lifetime commitment (assuming, of course, that
>> organizations are not supporting people for those positions
>> because of a belief that having people in them brings prestige,
>> credibility, or power to the company).
>> 
>> 
>>> If someone is incompetent, NomCom will not reappoint them even
>>> once, let alone twice.
>>> 
>>> We all agree that ossification is unwelcome, but artificial
>>> turnover is not the way to avoid that.
>> 
>> I think we have seen people who have ossified in place but who
>> are then selected for an additional term before retiring or
>> being forced out.  I agree that rigid term limits are not the
>> right solution, but hoping the Nomcom will figure it out may not
>> be the optimal solution either.
>> 
>> Finally, the "one term out" rule in Rich's proposal ensures
>> rotation, not retirement, and there is a difference.  Even a
>> person who has done a great job might benefit from some time in
>> the community between terms... and the community would almost
>> certainly benefit from the more recent and closer to bottom-up
>> perspective on what it takes to get work done in the IETF.
>> 
>>   best,
>>    john
>>