Eastlake III Donald-LDE008 wrote: > the "it" referred to in the message you were responding to > is the "cryptographic" part of the process. The one in RFC > 3797 depends on pre-announcement of the ordered list of > volunteers. Just for fun I've added RFC 3797 to an MD5 test suite, works like a charme, <http://purl.net/xyzzy/src/md5.cmd> (REXX) Reading RFC 3797 again, I have "float" wrong, I'll fix that. Maybe a hypothetical 3797bis should get an example covering also "float". With a sanity check if there is enough entropy. Decimal digits * 3 could be an approximation, the first digit for traded stocks is not completely random. The public source for these input numbers should be given as one or more URLs. > Neither is any more robust than the other against a failure > to make all the information necessary for public verification > available in advance, including the specification of the > source of future randomness. The "bug" (if any) is related to 3777, not to 3797: If the IETF secretariat is unable to determine the eligible population in time the NomCom Chair is in trouble, (s)he must get a final result (modulo appeals) two months before the 3rd IETF meeting. Maybe a public list maintained by the secretariat and updated after each IETF meeting (within two weeks) would help, just the names and up to five numbers like 66 65 64 63 62. Folks can then see if they are eligible, and they can discuss errors as soon as they see them (with the secretariat, and appeals to ISOC, because IAB and IESG shouldn't interfere in such cases). RFC 3777 4.15 is not 100% clear. Obviously IAB or IESG members cannot be NomCom members at the same time. But what if they volunteer because they know that the random numbers are drawn after they have resigned from their IAB or IESG seat ? And if they manage to "forget" to resign they're not eligible, ready. Under an "assume good faith" doctrine anything in this "tea-pot tempest" (quoting Randy) makes sense, an IAB member volunteers because the rules promise that this is a guarantee to get no other job, several screw-ups between the secretariat and some volunteers, an announcement sent too late caused by another hiccup, an RO asking for advice how to fix it, and using the (intuitively) most conservative approach "reset". But RFC 3797 defines that "most conservative" would be "draw next number" - which doesn't cover the case "announcement sent after input random numbers are already determined". Publishing the complete list two days after the random input numbers are drawn is a hopeless case. With "secret volunteers" the result could be manipulated, with a reset an "undesirable" result could be vetoed. Whatever the RO does, (s)he loses. :-( If you want to harden the algorithm you could use N, N-1, N-2, etc. as prefix + suffix for the MD5 input, instead of 0, 1, 2, etc. Won't help if the list is published too late, with two consenting "secret volunteers" Zacharias and Abel it would be possible to silently remove Zacharias from the end of the list, and add Abel at the begin. Phil's proposal also doesn't help in this case, it's hopeless. This situation must not happen. Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf