Just to clarify here there were two problems: 1) The list was not published on time 2) There was an unqualified person on the list. Neither flaw by itself was fatal. However the combination meant that there was no situation where the process was entirely deterministic as intended. Since the list was not published in time it was possible that the additional person had been added to the list after it was compiled, this meant that someone could suspect that the name had been added to the list after the random seed had been published in order to change the outcome. With 20 or so ineligible individuals it is not hard to see that this mechanism allows a considerable degree of control over the result. Simply removing the ineligible individual means that the compiler gets to choose between two outcomes. Rerunning the process means that the compiler gets to perform a redo if they wish. None of these outcomes is 100% satisfactory. 3979 does not anticipate the conjunction of the two failures. It probably wasn't thought about because it is not the administrative standard. The best way to fix the problem is to perform a thorough security analysis and identify each of the assets that the outcome depends upon and reduce these to the bare minimum. We cannot absolutely eliminate all possibility of fraud or error but it is certainly possible to arrive at a situation where the consequences of both are minimized. In particular the real failure of the original scheme is the way that small perturbations in the inputs cause a drastic change in the outcome. > -----Original Message----- > From: Dave Crocker [mailto:dhc2@xxxxxxxxxxxx] > Sent: Wednesday, September 06, 2006 1:09 PM > To: Ned Freed > Cc: ietf@xxxxxxxx > Subject: Re: Adjusting the Nomcom process > > Ned, > > Ned Freed wrote: > >> Interesting. What it showed me is that we cannot anticipate every > >> contingency. > > > > 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. > > > > Rather, the issue is simply that the nomcom chair elected not to > > follow the best practice guidelines we had established. > > Hmmmm. > > I have not seen Brian or others holding this view, although I > must say that my reading of 3797 matches yours. As to its > use, I suppose one one might quibble that 3797 is merely > Informational... > > In fact, 3797 has not seemed to get that much focus, from my > own sense of the ietf list discussion. To the extent that > there is universal belief that it covers the current problem, > then I do no understand why we have been having so much debate. > > In any event, what makes 3797 even more interesting is that > not only did the nomcom chair not follow it, but those he > consulted with seem not to have thought to follow it... > > I do not see any way to characterize any of this as involving > "ambiguity". That's why I am taking exception to that > characterization of the need. > > Perhaps a deeper sense of principles would not have prevented > such an error, but I am inclined to suspect that it might at > least have produced a less problematic error. > > > >> Hence what it showed me is that we need better statement of > >> principles and less effort to try to specify every problem and > >> solution that might ever occur. > > > > I have no problem with there being a better statement of > principles, > > and as Phillip was remarked, I agree that we've focused on > > confidentiality too much and auditability too little. But > this doesn't > > mean we don't need to drive a stake through this specific > problem (or > > rather, through an entire constellation of problems that > arise should > > the process be reset for no good reason). > > good point. > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf