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
- Re: I-D Action: draft-rsalz-termlimits-00.txt Brian E Carpenter
- Re: I-D Action: draft-rsalz-termlimits-00.txt John C Klensin
- Re: I-D Action: draft-rsalz-termlimits-00.txt Brian E Carpenter
- RE: I-D Action: draft-rsalz-termlimits-00.txt Adrian Farrel
- Re: I-D Action: draft-rsalz-termlimits-00.txt Salz, Rich
- Re: I-D Action: draft-rsalz-termlimits-00.txt John C Klensin
- Re: I-D Action: draft-rsalz-termlimits-00.txt Jared Mauch
- Re: I-D Action: draft-rsalz-termlimits-00.txt John Levine
- Re: I-D Action: draft-rsalz-termlimits-00.txt Keith Moore
- Re: I-D Action: draft-rsalz-termlimits-00.txt Carsten Bormann
- RE: I-D Action: draft-rsalz-termlimits-00.txt Vasilenko Eduard
- Re: I-D Action: draft-rsalz-termlimits-00.txt Jared Mauch
- Re: I-D Action: draft-rsalz-termlimits-00.txt Joel M. Halpern
- Re: I-D Action: draft-rsalz-termlimits-00.txt Salz, Rich
- Re: I-D Action: draft-rsalz-termlimits-00.txt Joel M. Halpern
- Re: I-D Action: draft-rsalz-termlimits-00.txt Salz, Rich
- Re: I-D Action: draft-rsalz-termlimits-00.txt Joel M. Halpern
- Re: I-D Action: draft-rsalz-termlimits-00.txt Michael Richardson
- Re: I-D Action: draft-rsalz-termlimits-00.txt tom petch
- Re: I-D Action: draft-rsalz-termlimits-00.txt Michael StJohns
- Re: I-D Action: draft-rsalz-termlimits-00.txt Barry Leiba
- Re: I-D Action: draft-rsalz-termlimits-00.txt Keith Moore
- Re: I-D Action: draft-rsalz-termlimits-00.txt John Levine
- Workload constants [was I-D Action: draft-rsalz-t… Brian E Carpenter
- Re: Workload constants [was I-D Action: draft-rsa… Keith Moore
- Re: I-D Action: draft-rsalz-termlimits-00.txt tom petch
- Re: Workload constants [was I-D Action: draft-rsa… Salz, Rich
- Re: Workload constants [was I-D Action: draft-rsa… Keith Moore
- Re: Workload constants [was I-D Action: draft-rsa… Christian Huitema
- Re: Workload constants [was I-D Action: draft-rsa… Salz, Rich
- Re: Workload constants [was I-D Action: draft-rsa… Keith Moore
- Re: Workload constants [was I-D Action: draft-rsa… Colin Perkins
- Re: I-D Action: draft-rsalz-termlimits-00.txt Phillip Hallam-Baker
- Re: I-D Action: draft-rsalz-termlimits-00.txt Mary B
- Re: I-D Action: draft-rsalz-termlimits-00.txt Deen, Glenn (NBCUniversal)
- Re: I-D Action: draft-rsalz-termlimits-00.txt Mary B
- Re: I-D Action: draft-rsalz-termlimits-00.txt Salz, Rich