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.