Hi -
From: "Henrik Levkowetz" <henrik(_at_)levkowetz(_dot_)com>
To: "Eastlake III Donald-LDE008"
<Donald(_dot_)Eastlake(_at_)motorola(_dot_)com>
Cc: "IETF-Discussion" <ietf(_at_)ietf(_dot_)org>
Sent: Thursday, August 31, 2006 10:20 AM
Subject: Re: Now there seems to be lack of communicaiton here...
Hi,
on 2006-08-31 17:33 Eastlake III Donald-LDE008 said the following:
Brian,
The advice you gave is exactly the opposite of that in RFC 3797, the
latest version of my non-binding guidelines for publicly verifiable
random selection. Note in particular that Section 5.1 of that RFC says
(with the all caps words in the original):
5.1. Uncertainty as to the Pool
Every reasonable effort should be made to see that the published pool
from which selection is made is of certain and eligible persons.
However, especially with compressed schedules or perhaps someone
whose claim that they volunteered and are eligible has not been
resolved by the deadline, or a determination that someone is not
eligible which occurs after the publication of the pool, it may be
that there are still uncertainties.
The best way to handle this is to maintain the announced schedule,
INCLUDE in the published pool all those whose eligibility is
uncertain and to keep the published pool list numbering IMMUTABLE
after its publication. If someone in the pool is later selected by
the algorithm and random input but it has been determined they are
ineligible, they can be skipped and the algorithm run further to make
an additional selection. Thus the uncertainty only effects one
selection and in general no more than a maximum of U selections where
there are U uncertain pool members.
Other courses of action are far worse. Actual insertion or deletion
of entries in the pool after its publication changes the length of
the list and totally scrambles who is selected, possibly changing
every selection. ...
The presence of ineligible persons in the list is no reason whatsoever
to reset.
I think this is well reasoned by Donald. Permitting a reset opens the
door on the possibility for a NomCom chair to include ineligible persons,
and subsequently, if he doesn't like the result, declare a reset and re-do
the selection.
We avoid this by keeping to the original numbered and published pool of
people, permitting one single run of the random number generation
mechanism, and then use that to select members from the original numbered
published pool (rejecting ineligible choices) until the desired number
of eligible NomCom members have been chosen.
(And to be clear, I don't mean that there is *any* foul play in the
current situation, just that we don't want a process which opens the
door on that possibility.)
...
Though I hate to add to this tea-pot tempest, I also agree with
Donald's reasoning that a reset is not justified in this case.
Randy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf