Re: Challenge: was Re: Updated Nomcom 2020-2021: Result of random selection process

John C Klensin <john-ietf@jck.com> Fri, 10 July 2020 18:28 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 65D333A0813 for <ietf@ietfa.amsl.com>; Fri, 10 Jul 2020 11:28:08 -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 vkX7z70D2wcV; Fri, 10 Jul 2020 11:28:07 -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 D50983A080C; Fri, 10 Jul 2020 11:28:06 -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 1jtxkj-000HJk-2v; Fri, 10 Jul 2020 14:28:05 -0400
Date: Fri, 10 Jul 2020 14:27:59 -0400
From: John C Klensin <john-ietf@jck.com>
To: Michael StJohns <mstjohns@comcast.net>, NomCom Chair 2020 <nomcom-chair-2020@ietf.org>
cc: ietf@ietf.org
Subject: Re: Challenge: was Re: Updated Nomcom 2020-2021: Result of random selection process
Message-ID: <2085D0ED888C7E7E50DCE8B4@PSB>
In-Reply-To: <b4f5a3cf-5fab-8188-926a-a4100f776610@comcast.net>
References: <159422819660.27889.6475902734358747001@ietfa.amsl.com> <b4f5a3cf-5fab-8188-926a-a4100f776610@comcast.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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/vtOK0ladqf1OomRx1cOXk7CiFXc>
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: Fri, 10 Jul 2020 18:28:09 -0000

Mike,

I (somewhat reluctantly for sa few reasons) agree.  Once
disqualified, always disqualified for that Nomcom.  While I'm
confident that no such thing happened here, it also suggests
something about which I think the rules are unclear and that we
might want to work on for the future.

The attack scenario would be: suppose EvilCo [1] wants to get,
not only two people on the Nomcom but, if possible, two of their
most skilled committee-manipulators.  In that case, they put
_many_ people into the Nomcom candidate pool, enough to create,
not only high odds of getting two positions in the top ten but
good odds of getting several of slots 11-15 as well.  Then those
who are selected stop down in favor of of the preferred
manipulators.  Note that redoing the random draw would not
effect that scenario and the likelihood that more people in the
pool would yield more top slots (as sell as more bottom slots of
course)-- it would just reshuffle the deck.  

At least statistically, the right solution for this is that, as
soon as a company gets two people in the top 10, every other
member of the pool from that company is eliminated from the
rankings.  If one of the people from that company steps down
(change of affiliation, change of time availability, loss in
argument with the proverbial truck, ...) or is removed for an
unrelated reason, the company just loses that second seat
(nothing both Michael's "1 of 10" arguments and the theory that
those people are not supposed to be representing the company or
its interests in any way, that should not make much difference).

There is a related scenario that we should consider eventually
but that fortunately did not arise in this case.  It may
indicate the wisdom or your analysis.  Assume for purposes of
discussion that, instead of going to work for Huawei, Luigi had
gone to work for Juniper before or just after the selections
were announced.  There are already two Juniper employees on the
list, one of whom ranked lower than Luigi.  So, Luigi announces
that he has just gone to work for Juniper.  If he didn't
voluntarily step down, I think that retroactively eliminates
Tony and takes us to the next (not already eliminated or Juniper
employee) on the list.  But I'm not sure that is clear.  

Having not studied the rule carefully in recent weeks, I'm also
not sure they are clear about what is supposed to happen, if the
Nomcom were to get well into the interview stage or beyond and a
voting member were to switch affiliations to a company that
already had two seats.

But let's hope we can think about that at our leisure, maybe in
the eligibility-discuss context, rather than having to wrestle
with it this year.

When the Nomcom mechanisms were first being designed, there was
an implicit assumption that the IETF and the collection of
people who were likely to volunteer for the Nomcom pool were
sufficiently diverse that we didn't need special rules for,
e.g., multiple people from one company: the randomization
process would work well enough to much more than one person per
company a vary rare event (and "1 of 10") a good answer to
almost any question.  As the industry became more concentrated
we felt a need to at the "no more than two" rule but, I think,
expected that it would not be exercised often.   Noting that the
latest list contains two people from each of Cisco, Huawei, and
Juniper (and with no assumption that they would collaborate in
any way but one could still be concerned about large-company
influences in the leadership selection process), we may need to
some more fundamental thinking about Ncomom selection above and
beyond random selection from a not-so-random pool.  Again, not
this year.

best,
    john

[1] There is, AFAIK, no company of that name or inclination
involved (or with its employees involved) in the IETF today or
in the past.  But this is all about future planning and one can
never tell what might happen.

--On Friday, July 10, 2020 12:04 -0400 Michael StJohns
<mstjohns@comcast.net> wrote:

> Hi -
> 
> I hate to do this, but I'm going to be challenging this
> particular outcome as it isn't strictly following the rules -
> basically, Luigi may not be replaced by Tal.  He either
> serves, or if he declines to serve, the next person on the
> list - not Tal - will be selected.
> 
> Here's my reasoning:
> 
> After Luigi belatedly indicated his association with Huawei,
> the defined process results in him remaining on the list but
> Tal being disqualified (as there being 2 previous Huawei
> people selected before him).   If Luigi - at a later time -
> decided he couldn't serve, *_we don't reach back on the list
> for the previously disqualified people, we look forward_* -
> e.g. Tal once disqualfied is no longer a candidate for future
> pulls.  If the next selected (#13 I think) is Huawei, they
> could serve as Luigi's departure would move the Huawei count
> back down to 1.
> 
> The whole idea of this random draw is that people can't pick
> and choose to substitute someone else for themselves. 
> Ideally, we would do a new random number generator for each
> additional selection rather than continuing down the list to
> completely eliminate those possibilities, but in the current
> model, I believe Tal is disqualified and will stay that way.
> 
> If Luigi still wants to remove himself, then the next selectee
> will be the one in the 13th position, not Tal in the
> disqualified 8th.