Re: NomCom selection Fwd: Notification for draft-eastlake-rfc3797bis-00.txt

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

 



Sorry to have joined this conversation a bit late. (I was traveling Tuesday and had oral surgery Wednesday).

The current version of my draft is here:  https://datatracker.ietf.org/doc/html/draft-eastlake-rfc3797bis-02

Personally, I don't think the re-randomization is worth the complexity and effort but insisting that this is a problem that must be "fixed" is consistent with the way the IETF community (or at least the more vocal members of the IETF community) approach Nomcom process. Usually the IETF is a "do the right thing" kind of organization with reasonably flexible procedures. This is absolutely not the case with NomCom procedures. People insist on very precise processes enforced with absolute rigor.

If you are worried about the delay/stress caused by having to do one re-randomization, it will normally be substantially worse. In the selection of the 2022-2023 Nomcom, 3 extensions were required. The pool was huge with 267 members, the largest ever. In the initial selection, one of the 10 potential selectees was eliminated because confirmation of their willingness to serve could not be obtained in a timely fashion. In the 1st extended selection, the 11th potential selectee was eliminated because they declined to serve and the 12th was eliminated because there were already two selectees with the same sponsor. In the 2nd extended selection, the 13th potential selected also declined to serve. In the 3rd extended selection, the 14th potential selectee became the final voting member of the Nomcom when they confirmed their willingness to serve. Given this, a nomcom Chair would have to plan a schedule that would allow for up to 5 or 6 cycles of extension.

Doing these extensions is going to be pretty stressful with very tight deadlines on the order of a few days at most and those deadlines will have to be rigorously enforced. Nevertheless, I think it can be done. There is a sketch in my current draft of a way to do this using a "daily number" type state lottery drawing as the randomness source. (At least one person keeps recommending other sources that produce lots of what they claim is randomness but I don't see why I should have confidence in such sources let alone why the public would have any confidence in them, which is more important. While I don't claim government lotteries are perfect, at least most people will feel that they have an understanding of the risk involved.)

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@xxxxxxxxx


On Tue, Apr 25, 2023 at 5:30 PM Joel Halpern <jmh@xxxxxxxxxxxxxxx> wrote:
The problem is that we already have difficulty keeping to a schedule. 
If we have to have a sequence of

find random sources in the near future

announce random sources

allow protest of random sources

get random results

allow time for confirmation / objection to the random result

then we are adding a lot of time, potentially several iterations, to the
process.  Is the risk you are raising worth the cost and complexity? 
(And is it worth making the nomcom chair's job that much more
complicated?  We already have trouble finding qualified people willing
to do the job.)

Yours,

Joel

On 4/25/2023 5:21 PM, Michael StJohns wrote:
> On 4/25/2023 3:22 PM, Salz, Rich wrote:
>> I don't think re-randomize is what we should be doing.  Just go to
>> the next one on the initial list.
>
> The problem with that is gaming the system.  Say I'm selected, but the
> next on the list is someone from my organization that may have more
> time on their hands.  I can drop off without my organization losing a
> vote.  AIRC that was an actual problem for a previous nomcom.   An
> alternate scenario is that I'm an independent contractor with
> substantial portions of my income coming from X, and say that an X
> employee is next on the list.  I might be subject to pressure or
> remuneration to drop off.
>
> Fore knowledge of the outcome is power of sorts and subject to
> misuse.  Better to make sure at any point where a decision is made,
> those decisions are independent from later events.
>
> Later, Mike
>
>


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

  Powered by Linux