My theme here was that it is probably not humanly possible to absolutely
guarantee that no discretionary decision by the nomcom chair will ever
be required somewhere in the process of nomcom formation because it is
very hard to anticipate all possible real world events. The theme of
Section 5.2 of RFC 3797 is that this applies in the area of specifying
the source of future randomness. It is true that 5.2 probably harps too
much on using stocks as a bad idea. But problems have occurred with
them. It is easy to image things that could have happened this time,
such as a listed company merging or splitting, that would have required
a nomcom chair discretionary decision with regard to the random input.
However, the problem that occurred was not in applying the specification
of random input to the real world but a human error in the timing of
announcements.
Donald
-----Original Message-----
From: Ned Freed [mailto:ned(_dot_)freed(_at_)mrochek(_dot_)com]
Sent: Friday, September 01, 2006 6:08 PM
To: Eastlake III Donald-LDE008
Cc: IETF-Discussion
Subject: RE: Now there seems to be lack of communicaiton here...
...
(2) We do not redraw the entire Nomcom pool and _never_ do so after
anyone who has discretion has had an opportunity to see the initial
list of Nomcom members. If someone is selected (or
volunteers) and then determined to be ineligible, the people who have
already been selected by the mechanism specified stay selected.
Anything else just has a bad odor whether actual improprieties are
suspected or not.
@@@ It may be possible, with sufficient care, to make vanishingly
small the chance that a nomcom chair discretionary decision would be
needed for this aspect of nomcom selection. But I am not sure that, in
the real world, it is possible to do this for all aspects of nomcom
selection.
See Section 5.2 of RFC 3797.
Section 5.2 talks about potential issues with using stock prices or
volumes. I don't see how this connects with the need to remove the
ability for the nomcom chair to reset the process for no good reason.
...
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf