Re: [Gendispatch] draft-rsalz-termlimits

John C Klensin <> Sat, 23 October 2021 16:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E4FF3A0890 for <>; Sat, 23 Oct 2021 09:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N-nOG95U3MJc for <>; Sat, 23 Oct 2021 09:39:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2457D3A088F for <>; Sat, 23 Oct 2021 09:39:36 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1meK3N-000Eah-5C; Sat, 23 Oct 2021 12:39:29 -0400
Date: Sat, 23 Oct 2021 12:39:23 -0400
From: John C Klensin <>
To: "Salz, Rich" <>, Lars Eggert <>
cc: Barry Leiba <>, Carsten Bormann <>,
Subject: Re: [Gendispatch] draft-rsalz-termlimits
Message-ID: <7102767AA0D5C9F679E9B61C@PSB>
In-Reply-To: <>
References: <> <> <> <4506E7DA9EF80C64C6AE9432@PSB> <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 Oct 2021 16:39:42 -0000

--On Saturday, October 23, 2021 15:52 +0000 "Salz, Rich"
<> wrote:

> My proposal takes the hard decision-making out of Nomcom's
> hands, and puts it into the IETF community.
> We've been saying it's everyone's job to find and groom
> candidates. One way to think of my proposal is that it is a
> forcing function for that.


Absolutely, including the advantages of putting more
responsibility and pressure on the community to find and groom
candidates.  That has considerable appeal to me.  That is
balanced or countered in my mind by two things:

(1) I'm concerned about edge cases in which an extra (i.e.,
third) term would be in the interest of the incumbent and the
community.  If you allowed for an exception procedure --whether
the exception were made my the Nomcom or some community action--
I'd be much more comfortable about it.  It that exception
procedure were hard to use... so much the better as long as it
is plausible.

(2) Overlapping the above, I've got a general distrust of trying
to do things by rigid rules in the IETF.  We've historically
been much better off delegating responsibility and and authority
to groups or clusters of people, letting them do their work, and
then holding them accountable for it.  The big problem with the
Nomcom in that regard is that they do whatever they do, their
internal discussions and the information they base them on are
largely confidential, and there is no accountability mechanism.
I don't have any idea how to "fix" that which isn't worse than
the problem -- and making rigid rules may be in that category of
fix.  However, IMO, if we don't like giving guidance to the
Nomcom and then letting them exercise discretion, we should
probably be looking at how we select our leadership more
generally rather than imposing more rules on the current
process.  YMMD, of course.

Finally, I don't see your proposal the same way you describe it
in your first paragraph.  If one thinks about individual cases
and candidacies, it seems to me that what the proposal does is
to deprive the Nomcom of the option of making one particular
type of hard decision while shifting no responsibility for those
decisions to the community at all (even if it increases the
pressure on the community to generate more candidates).