Re: [Gendispatch] draft-rsalz-termlimits

John C Klensin <> Sat, 23 October 2021 15:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC3613A0BA0 for <>; Sat, 23 Oct 2021 08:14:26 -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 Zc8oT5Id2tjR for <>; Sat, 23 Oct 2021 08:14:23 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D88C83A0B95 for <>; Sat, 23 Oct 2021 08:14:22 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1meIiq-000ETZ-03; Sat, 23 Oct 2021 11:14:12 -0400
Date: Sat, 23 Oct 2021 11:14:06 -0400
From: John C Klensin <>
To: "Salz, Rich" <>, Lars Eggert <>
cc: Barry Leiba <>, Carsten Bormann <>,
Subject: Re: [Gendispatch] draft-rsalz-termlimits
Message-ID: <4506E7DA9EF80C64C6AE9432@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: Sat, 23 Oct 2021 15:14:28 -0000

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

>>   I'm wondering what the opinions are on how a NomCom
>>   should weigh the importance of a gap year (or similar
>>   concept) against other considerations they have been told
>>   to pay attention to, such as no more that two members in a
>>   body with the same affiliation, other diversity guidance,
>>   etc.?
> Which is another reason why I propose not putting it in
> Nomcom's hands.
> Jane at Example, Inc. has been an AD for three terms, and Bob
> and Sue are potential AD's also from Example Inc.  Bob has
> nobody else standing in competition and Sue has never been an
> AD.  What should they choose?  Suppose Jane is also unopposed?


While I think I understand your example (and Lars's question), I
don't think the answer is either forcing Jane to step down
independent of other considerations or that we need to either
throw up our hands and do nothing or try to tie the Nomcom up so
much in guidance that they have to mechanically follow a script.

At a very abstract level, Barry's proposal says "hey Nomcom,
third terms are generally a bad idea and, unless there are other
considerations you consider overwhelming (see next note), people
finishing a second term should be given a gap year (or, if one
prefers, a vacation) from leadership roles".  And mine says
"evaluate Jane and see if she is so good and keeping her in that
role is so fundamentally important that she should be returned
for a third term... only if the answer to that is 'no', start
looking for others for that slot".  

Both address Lars's question but in different ways.  In Barry's
scenario as I understand it, there is a strong bias coming into
the Nomcom process for Jane taking a gap year.  If Bob and Sue
are also plausible candidates for positions, that presumably
further increases the preference for Jane getting some time off
(whether she thinks she wants it or not).   In my scenario, the
Nomcom may not know, especially in terms of formal candidacies,
whether Jane is running (I hate that term and consider it part
of the problem) unopposed or not.  The proposal is that they
evaluate Jane's performance on the basis of Jane's performance.
If Jane has either done a terrible job or has done a great one
and is ready for a vacation, the decision they should make for
her is "gap year".  If there are no other candidates, the IETF
has a problem that we should be addressing: beyond whatever
beating of the bushes the Nomcom thinks appropriate and
potentially deciding to leave the position unfilled as a forcing
function, most possible solutions to that problem are not in the
Nomcom's purview.

I am not convinced we need to write all of that down, at least
in the form of explicit guidance.