Re: [Gendispatch] draft-rsalz-termlimits
John C Klensin <john-ietf@jck.com> Sat, 23 October 2021 15: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 717923A0A7B for <ietf@ietfa.amsl.com>; Sat, 23 Oct 2021 08:29:58 -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 WYvDcKTskHYq for <ietf@ietfa.amsl.com>; Sat, 23 Oct 2021 08:29:57 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 F36A83A0A79 for <ietf@ietf.org>; Sat, 23 Oct 2021 08:29:56 -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 1meIxy-000EUQ-RD; Sat, 23 Oct 2021 11:29:50 -0400
Date: Sat, 23 Oct 2021 11:29:45 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Salz, Rich" <rsalz@akamai.com>, Lars Eggert <lars@eggert.org>, Carsten Bormann <cabo@tzi.org>
cc: Barry Leiba <barryleiba@computer.org>, ietf@ietf.org
Subject: Re: [Gendispatch] draft-rsalz-termlimits
Message-ID: <78EA1E0ED5529A46030F636D@PSB>
In-Reply-To: <CDD17BF9-BBF6-413F-80A6-2928995807C1@akamai.com>
References: <394BBA1E-FA83-4E80-A143-BE3F0764DCDA@tzi.org> <F2D8B2B0-1005-424F-9984-3AC6F951E02F@eggert.org> <CDD17BF9-BBF6-413F-80A6-2928995807C1@akamai.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/Iv0iZg3p9qjJS_a1R3nKr5k8QNg>
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: Sat, 23 Oct 2021 15:29:59 -0000
(decided to separate this note because it is almost a separate topic and to keep the prior one from getting really long) I've been asked, offlist, what I think would constitute justification for terms beyond the second. Maybe an example with a historical analogy would help. Suppose we were considering, as a community, something as fundamental to the future of the Internet as IPng (eventually IPv6 for those whose memories don't go back that far) and that we had already figured out just how many moving parts and considerations there were (at least IMO we didn't back then but we did consider the issue important enough to create a special pseudo-Area) to the point of creating multiple WGs to look at different parts of the problem. Now, assume there were a single AD responsible for that work (even if there were another AD in the Area and noting that how work is organized is in the IESG's scope, not Nomcom's) and that AD were doing a good job of keeping everything coordinated and moving along smoothly. If that AD were willing to continue into a third term, it might well be in the best interests of the IETF (and the Internet) to let them continue.. and a bad idea to have a rigid rule get in the way. Of course, such situations arise very rarely -- we've had one example in pushing 30 years -- but that one is an example of why a rigid rule is a bad idea even if it is concretely a bad idea only infrequently (I think the general idea of depriving the Nomcom of discretion is a bad idea, but that is a separate issue from this sort of concrete case). Scenarios like that one also have the property that they will be visible to almost everyone in the community -- no confidential information about what is going on. FWIW, a place where versions of the three proposals might come together is that, if you, or someone else, took the position that, if we need someone in place more than three (or four?) terms to address a problem, that would be a symptom of a problem the IETF needs to rethink. It is not one we should "solve" by returning someone for another term in the hope that doing the same thing over again will produce different and better results. Nor should the automatic response be passing the bag of vipers onto someone else. So, if you (or someone else) said "Barry's or my approach for terms two, three, or maybe even four but then there is a hard stop and a forced break regardless of circumstances", I'd probably agree. john p.s. I agree with Barry that trying to tell the Nomcom how to weight or rank various considerations would probably not be a good idea.
- Re: [Gendispatch] draft-rsalz-termlimits Lars Eggert
- Agenda item request Salz, Rich
- Re: Agenda item request John C Klensin
- Re: [Gendispatch] draft-rsalz-termlimits Salz, Rich
- Re: [Gendispatch] draft-rsalz-termlimits Michael StJohns
- Re: [Gendispatch] draft-rsalz-termlimits Salz, Rich
- Re: [Gendispatch] draft-rsalz-termlimits Salz, Rich
- Re: [Gendispatch] draft-rsalz-termlimits Brian E Carpenter
- Re: [Gendispatch] draft-rsalz-termlimits Barry Leiba
- Re: [Gendispatch] draft-rsalz-termlimits Salz, Rich
- Re: [Gendispatch] draft-rsalz-termlimits Joel M. Halpern
- Re: [Gendispatch] draft-rsalz-termlimits Barry Leiba
- Re: [Gendispatch] draft-rsalz-termlimits Carsten Bormann
- draft-leiba-term-limit-guidance-00 [was: draft-rs… Brian E Carpenter
- Re: [Gendispatch] draft-rsalz-termlimits John Levine
- Re: [Gendispatch] draft-rsalz-termlimits John C Klensin
- Re: [Gendispatch] draft-rsalz-termlimits Salz, Rich
- Re: [Gendispatch] draft-rsalz-termlimits Carsten Bormann
- Re: [Gendispatch] draft-rsalz-termlimits Salz, Rich
- Re: [Gendispatch] draft-rsalz-termlimits Barry Leiba
- Re: [Gendispatch] draft-rsalz-termlimits Barry Leiba
- Re: [Gendispatch] draft-rsalz-termlimits Carsten Bormann
- Re: [Gendispatch] draft-rsalz-termlimits John C Klensin
- Re: [Gendispatch] draft-rsalz-termlimits John C Klensin
- Re: [Gendispatch] draft-rsalz-termlimits Salz, Rich
- Re: [Gendispatch] draft-rsalz-termlimits John C Klensin
- Re: [Gendispatch] draft-rsalz-termlimits Barry Leiba
- Re: [Gendispatch] draft-rsalz-termlimits Salz, Rich
- Re: [Gendispatch] draft-rsalz-termlimits Joel M. Halpern
- Re: [Gendispatch] draft-rsalz-termlimits Salz, Rich
- Re: [Gendispatch] draft-rsalz-termlimits Keith Moore
- Re: [Gendispatch] draft-rsalz-termlimits Scott O. Bradner