Re: NomCom eligibility & IETF 107

John C Klensin <> Fri, 13 March 2020 15:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 832F63A0AA0 for <>; Fri, 13 Mar 2020 08:19:55 -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 uko93uzp4o30 for <>; Fri, 13 Mar 2020 08:19:53 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74F8C3A0ACF for <>; Fri, 13 Mar 2020 08:19:53 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jCm6I-0002F4-JW; Fri, 13 Mar 2020 11:19:50 -0400
Date: Fri, 13 Mar 2020 11:19:45 -0400
From: John C Klensin <>
To: Barry Leiba <>
cc: IETF discussion list <>
Subject: Re: NomCom eligibility & IETF 107
Message-ID: <9F5F463371015B85949AF92E@PSB>
In-Reply-To: <>
References: <> <E6FB26B505C8B7952BB81CEA@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: Fri, 13 Mar 2020 15:19:56 -0000

--On Friday, March 13, 2020 10:43 -0400 Barry Leiba
<> wrote:

> Thanks, John: that's a valid third choice, and I think it
> could be workable.
> On the other hand, noting this:
>> The difficulty with simply ignoring IETF 107 is that, while it
>> was fairly arbitrary, that "five meeting" rule was intended to
>> restrict the Nomcom to recent participants, not just those who
>> have participated.  Whether that was the right way to
>> accomplish that goal or the right formula is part of the
>> longer-term question, but it seems to me that pushing the
>> formula to what would effectively a "three of the last six
>> normal meeting cycles" is not a change we should make lightly.
> Speaking for myself only and not for the IESG as a whole: as
> the IESG noted in the message, this is a one-time thing to
> deal with the imminent formation of this year's NomCom.  I
> would absolutely agree with you about making a lasting change.
> I have no heartburn at all about making a decision now for
> this cycle, which decision might be a slight variation on the
> BCP rules.

I would agree except I think that carrying "one-time thing" too
far gets us into a situation in which we have to keep evaluating
exceptions, and exceptions to the exceptions, and so on.
Trivial example: If we say "for purposes of forming the
2020-2021 Nomcom, IETF 107 is treating as not existing and we
count 102, 103, 104, 105, and 106 as the "last five meetings"
then, for the 2021-2022 Nomcom, the list is presumably 104, 105,
106, 108, 109.  But 104 would then be getting fairly far away,
so we might have to start thinking up another ad-hoc rule.  If
we can't manage to hold 108 as planned (see other note) it, and
the ad-hocery, gets even worse.   Saying, as we have essentially
said for other purposes, the IETF 107 is a real meeting that we
just happened to hold virtually (and as the meeting page, etc.,
now say) is, IMO, just much more stable.  And, in the unlikely
event that we have to make 108 (or 109 -- there is a
epistemologically-plausible scenario for that too) virtual, we
have a model that would probably need tweaking but not a fragile
and ad hoc solution.


p.s. It may be worth remembering that we have other things tied
to Nomcom eligibility in addition to the Nomcom itself.  Unless
we want to enumerate those other things and figure out which
rules apply to which ones, it would be good to make a decision
about the Nomcom that would reasonably extend to those other
situations without having to do a case-by-case analysis.  Some
formula that treats IETF 107 as a "real" meeting and then
tinkering with how attendance is countered (essentially what I'm
proposing, with other formulas probably being equally
reasonable) would help keep us out of that case-by-case problem.
People interested in other formulas might find reviewing pars of
the discussion of recall eligibility a few months ago (including
but not limited to that of draft-moonesamy-recall-rev)