There were, as far as I can see, exactly two "right" things the nomcom chair could have done: (1) Amend the randomness input specification by moving it out a few days. As long as this is done in advance of the old date which is being changed, so the decision to move out the date can not be based on the results using the old date, this is completely safe. It would probably have been the best thing to do. (2) Publish the unvetted list (or only partially vetted list) before the randomness input date even while there was still eligibility disputes over who was qualified. As long as everyone who is qualified or about whom there is still an unsettle dispute is included, this is safe as extra ineligible names in the list don't cause a problem. They are just skipped and the algorithm run further if they come up in selection. The evidence of past experience (12 years worth) is that disputes about eligibility based on IETF meeting attendance can be settled with the Secretariat within one week. The announced schedule gave a deadline for volunteering and implied that the vetted list would be published immediately after that deadline giving the Secretariat approximately zero time to vet the list and settle disputes. I think more transparency in the nomcom selection is good so, if the process involves a stage of removing ineligibles from the list, to produce a cleaner list, then the raw list should be posted and about a week later the vetted list (and probably a week after that should be the time of the last random input so the algorithm can be run). As above, it is no problem if an ineligible person slips through on the "vetted" list as long as this is detected before the actual selected nomcom voting membership is announced. Donald -----Original Message----- From: Eliot Lear [mailto:lear@xxxxxxxxx] Sent: Thursday, September 07, 2006 1:42 AM To: Ned Freed Cc: IETF Discussion Subject: Re: Adjusting the Nomcom process Ned Freed wrote: >> Ned, >> >>> Dave, I'm sorry, but it didn't show that at all. The specific >>> problem that arose here WAS anticipated and analyzed and the correct >>> thing to do in this case WAS determined and documented. See RFC 3797 >>> section 5.1 for specifics. >>> > > >> I don't know how many ways I can say this, but 5.1 is irrelevant to >> the problem I was concerned about, which is having the pool come out >> at the same time as the results. That allows for mischief in many >> ways (not that I'm accusing anyone of that). Under the circumstances >> I *still* believe that the chair did the correct thing, and that his >> doing so has ensured the integrity of the process. >> > > First of all, as others have suggested, the problem with the proximity > of the list and result publication can be addressed trivially by > having the secretariat provide the list they received for vetting > purposes as well as the result they handed back. What we had here was a foul-up between the secretariat and the chair, largely based on timing and technical problems. There is no need for the secretariat to post its input list (although I have no objections to that). And as I wrote, in *this* case, which is what I am talking about, given the problem, the chair did the right thing. The rule which states that the chair will wait at least a week, is *almost* sufficient. If the secretariat posts the list, it should also post the date the algorithm should be run, and it should be responsible for seeing that the message is properly distributed - which is really what happened here. And even so, *other* problems can arise, and so I agree with Dave that attempting to address every contingency is going to yield to the qualifications for chair being an Internet lawyer, and nobody should want that. Save the lawyers for the real elections :-( As to whether the chair gamed the system in the way you described, it's easy enough to determine: ask the secretariat if a message got stuck in the queue. If it did, then he didn't. If it didn't then perhaps he did. Of course who is to say the secretariat didn't collude? Well, at some point we have to draw a line and simply believe they didn't. Besides having the list visibly posted in advance is sufficient to tackle this particular case. Eliot _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf