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

[Michael StJohns <[e-mail]>]

On 7/11/2020 5:50 AM, Yoav Nir wrote:
>
>
>> On 11 Jul 2020, at 1:58, Michael StJohns <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> If Luigi declines to take the position, "the chair must repeat the 
>> random selection process" or work with 9 members.   In general, 
>> that's meant continuing down the list, not going back and picking up 
>> someone who was already not selected.
>
> As others noted, that if for the period after the seating of the nomcom.
>>
>>
>>> I believe she has made such a determination, and has acted within 
>>> the mandate of RFC 7437.
>>
>> Luigi indicating he works for Huawei restructures the list and 
>> eliminates Tal.  Luigi indicating he won't serve triggers 5.7.  These 
>> are two separate events.
>>
>> This is not ambiguous.
>>
>>
> I disagree.
>
> You cannot un-emit data. Once the NomCom chair has send the message 
> with the list of NomCom members, they are the presumptive NomCom and 
> all changes and challenges must be based on that list. What you are 
> suggesting is to turn back the clock to re-run the process as if that 
> message had never been sent.


Hi Yoav -

Let me try and explain why I think you're making claims that don't meet 
the reasonableness test by using the example from 5.1 of RFC3797.

Let's pretend for a moment, that Luigi, upon seeing the presumptive list 
and his selection suddenly remembers that instead of attending 3 of 5 
meetings, he'd registered for one of those meetings, but was unable to 
attend.  He didn't end up cancelling, so a record keeping error had him 
as eligible.   He reports his ineligibility, he's skipped over (per 
second para of 5.1), and the next person on the list is selected.   It 
doesn't matter that the Nomcom chair had announced that he was selected, 
once he's ineligible, the list gets corrected based on the input data 
(of the ordered list, the input seeds, and the fact of Luigi's 
ineligibility, and the various organizational associations).

That's not running the clock backwards, that's reinterpreting the result 
of the selection (and the down-selection of too many from a single 
company) in the face of updated input data.

In this case, the chair ran the process and provided a presumptive 
list.  Luigi took a look at it, realized he was listed with an incorrect 
organization and the chair made a discretionary call based on Luigi's 
request and provided a new presumptive list based on that request rather 
than providing a new presumptive list based solely on the data at 
hand.   Again, the presumptive list changed by reinterpreting the 
selection data.  That's not running the clock backwards (nor was the 
first example).   And specifically, Luigi was not disqualified from 
serving, so he doesn't get skipped over in the order.

Given the data of the ordered list, the updated organizational 
associations, and the input seeds, the new presumptive list had to have 
Luigi on it and Tal off of it.   If Luigi *then* decides not to serve, a 
new selection has to be made - either continuing down the list or 
re-running the random selection for the new member. If the latter, Tal 
may be part of the selection pool again, if the former, he's a ball 
that's already been selected and discarded.

There was no need, and in fact it was an error, for the chair to 
exercise discretion at this point and that's the basis of the challenge.

Second example:  The chair transposes two numbers in the random seed 
input, leading to a presumptive list.   During the challenge period, a 
sharp eyed IETF type notes the error and challenges. The chair does not 
have discretion to keep the presumptive list and must publish a new list 
based on the actual data.  And again, the new presumptive list would 
replace the old presumptive list as valid.

Later, Mike


ps - Note that RFC3797 is *one* way to do the selection, not *the* way.  
It's an informative reference for 8713 for that reason.  It was 
published about the same time as 3777 which is when the "not more than 
two" condition was added and at least for that reason probably didn't 
provide specific examples along the lines we're experiencing.  The RFC 
does apply here because this is the method that the chair announced.

pps - someone was complaining about the use of the term "disqualified" 
with respect to the greater that 2 eliminated volunteers - I'm just 
using the term the chair used in her message.  Feel free to substitute 
"volunteers eliminated as exceeding the limit of 2 from an organization" 
for "disqualified" where context indicates that.