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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/11/2020 5:50 AM, Yoav Nir wrote:


On 11 Jul 2020, at 1:58, Michael StJohns <mstjohns@xxxxxxxxxxx> 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.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux