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(_at_)dcrocker(_dot_)net]
Sent: Wednesday, September 06, 2006 1:09 PM
To: Ned Freed
Cc: ietf(_at_)ietf(_dot_)org
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(_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