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(_at_)cisco(_dot_)com]
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf