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