![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Ned Freed wrote:The goal of this process is not just to make it hard to game the system, but also for everyone to be completely confident the system has not been gamed. Allowing the same person that creates the list the authority to later reject that list and start over based on an imperfection that didn't lead to a bogus selection makes it impossible to have the necessary confidence in the process.
This strikes me as a key point about managing problems with this process (or maybe *any* IETF process.) A robust process has little or no dependence on the vagaries of one or a few people. The issue is not with the people but with the structure of the control mechanism.
Therefore, I propose the following:
(1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good.
(2) Text is added to the next version of the selection process to addresss this issue. I would suggest a strengthening of the existing language about leaving questionable candidates in the list and rejecting them in a later pass. In fact, it might be wiser to require the use of the original list of volunteers as given to the secretariat and _always_ rejecting ineligible candidates in a later pass. This would remove any need to insure that errors or disputes about eligibility be resolved before the random data becomes available.
-- Jeff
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.