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.freed@xxxxxxxxxxx] 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf