Re: Agenda item request

John C Klensin <> Wed, 20 October 2021 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AAEB3A087C; Wed, 20 Oct 2021 09:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0rBwsXZMW1Oc; Wed, 20 Oct 2021 09:54:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF7193A0819; Wed, 20 Oct 2021 09:54:11 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1mdEqv-0004iq-Nh; Wed, 20 Oct 2021 12:54:09 -0400
Date: Wed, 20 Oct 2021 12:54:03 -0400
From: John C Klensin <>
To: "Salz, Rich" <>,
cc:, Spencer Dawkins <>
Subject: Re: Agenda item request
Message-ID: <C89DD0642CF7A15DECA77978@PSB>
In-Reply-To: <>
References: <>
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: Wed, 20 Oct 2021 16:54:17 -0000

I concur with Rich's request and favor a discussion but, if we
are going to do that, I request that draft-klensin-nomcom-term
(yes, from 2005-2006) be added as well.  Unless Spencer has
vigorous objections, I'll try to find the original and get a
version with current dates, affiliations, etc., posted within
the next several days.

The abstract of that I-D read:

	A consensus is emerging in the IETF that very long
	tenure in leadership roles is not in the best interests
	of the community. While, in theory, that advice could
	simply be given to the NomCom, there is reason to
	believe that a different model for consideration of
	renewal or replacement for members of the leadership
	would be more efficient for the NomCom and would impose
	less hardship on incumbents and the community. This
	document outlines that alternate method.

In addition to proposing an approach that would limit most
Nomcom appointees to two terms and change the way Nomcoms review
appointees, Section 3 (of -01) reviews the discussions at the
time about other alternatives including hard term limits.


--On Wednesday, October 20, 2021 14:37 +0000 "Salz, Rich"
<> wrote:

> I would like to have this on the next GENDISPATCH agenda.
>     Name:		draft-rsalz-termlimits
>     Revision:	00
>     Title:		Term limits for IETF Leadership Positions
>     Document date:	2021-10-20
>     Group:		Individual Submission