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

Jared Mauch <> Wed, 20 October 2021 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BC753A0788 for <>; Wed, 20 Oct 2021 15:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yGpc5MUB4J9O for <>; Wed, 20 Oct 2021 15:11:40 -0700 (PDT)
Received: from ( [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A84B3A0776 for <>; Wed, 20 Oct 2021 15:11:40 -0700 (PDT)
Received: from (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 (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 <>
In-Reply-To: <>
Date: Wed, 20 Oct 2021 18:10:18 -0400
Cc: John C Klensin <>, IETF discussion list <>
Message-Id: <>
References: <>
To: Brian E Carpenter <>
X-Mailer: iPhone Mail (19A404)
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: 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

Sent via RFC1925 complaint device

> On Oct 20, 2021, at 4:36 PM, Brian E Carpenter <> 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
>> <> 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