Hi - > From: "Henrik Levkowetz" <henrik@xxxxxxxxxxxxx> > To: "Eastlake III Donald-LDE008" <Donald.Eastlake@xxxxxxxxxxxx> > Cc: "IETF-Discussion" <ietf@xxxxxxxx> > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf