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

John C Klensin <john-ietf@jck.com> Wed, 20 October 2021 20:29 UTC

Return-Path: <john-ietf@jck.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 A11093A098B for <ietf@ietfa.amsl.com>; Wed, 20 Oct 2021 13:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 8bcuiJv_cqfX for <ietf@ietfa.amsl.com>; Wed, 20 Oct 2021 13:29:11 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F473A09D9 for <ietf@ietf.org>; Wed, 20 Oct 2021 13:29:10 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1mdICz-00052s-8S; Wed, 20 Oct 2021 16:29:09 -0400
Date: Wed, 20 Oct 2021 16:29:02 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, IETF discussion list <ietf@ietf.org>
Subject: Re: I-D Action: draft-rsalz-termlimits-00.txt
Message-ID: <56F811BE6546B57096E171B6@PSB>
In-Reply-To: <2a65cc6e-3a39-d209-491f-f4ad67cca151@gmail.com>
References: <163474046003.5194.1851617977740027365@ietfa.amsl.com> <2a65cc6e-3a39-d209-491f-f4ad67cca151@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wwZM1fy8L8nI866G356Zt39ZGWE>
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 20:29:15 -0000


--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