Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
Assertion: The IETF still operates as if no other body exists. Fact: http://www.ietf.org/liaisonActivities.html Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
I originally said two...and would prefer that. What I am saying is that there should be a total of two or three instances as a NOMCOM candidate and that is a much different statement than figuring who is in office now and who is eligible...As to what it prevents-career Internet Standards jockey's. And since the purpose is to keep the IETF honest, I want the same term limits for any and all IETF positions, including the TRUST as well. By the way - has anyone seen a Business Plan for the TRUST and what it is supposed to do? I don't mean some fictional set of ideas - I mean the business plan. I want to see exactly what the Trust is responsible for and how its to be measured, Todd - Original Message - From: Bill Fenner [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED] Cc: IETF-Discussion Sent: Monday, September 04, 2006 7:04 PM Subject: Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here... On 9/4/06, todd glassey [EMAIL PROTECTED] wrote: Its time to talk about term limits for NOMCOM appointments. Two or maybe three terms at most are enough. Todd, Given that there are no standing IESG appointees that have served for three terms, what exactly would making such a rule change? Arkko, Jari 0.2 Callon, Ross 0.2 Carpenter, Brian0.7 Dusseault, Lisa 0.2 Eggert, Lars0.2 Fenner, Bill2.5 Hardie, Ted 1.7 Hartman, Sam0.8 Housley, Russ 1.7 Jennings, Cullen0.2 Kessens, David 1.3 Peterson, Jon 1.7 Romascanu, Dan 0.2 Townsley, Mark 0.7 Westerlund, Magnus 0.2 (This is AD and number of terms served, where numbers of terms served is counted by adding up the number of IETFs the AD is listed under at http://www.ietf.org/iesg_mem.html and dividing by 6) Bill [to be fair, 2 of the above positions didn't exist until their holders were appointed 0.2 terms ago] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
todd glassey wrote: And since the purpose is to keep the IETF honest, I want the same term limits for any and all IETF positions, including the TRUST as well. Including working group chairs and secretaries and directorate members? -andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
--On Tuesday, September 05, 2006 6:11 AM -0700 todd glassey [EMAIL PROTECTED] wrote: I originally said two...and would prefer that. What I am saying is that there should be a total of two or three instances as a NOMCOM candidate and that is a much different statement than figuring who is in office now and who is eligible...As to what it prevents-career Internet Standards jockey's. And since the purpose is to keep the IETF honest, I want the same term limits for any and all IETF positions, including the TRUST as well. By the way - has anyone seen a Business Plan for the TRUST and what it is supposed to do? I don't mean some fictional set of ideas - I mean the business plan. I want to see exactly what the Trust is responsible for and how its to be measured, Todd, Term limit ideas for IESG, IAB, and others, and even a suggestion that no one should be able to serve on consecutive Nomcoms, have been floated multiple times and have gone nowhere. I believe the latest attempt was as part of draft-klensin-nomcom-term-01.txt, which appears to be going nowhere as well. If you have a proposal here, I recommend that you make it in the form of an Internet Draft that is specific enough that people can actually comment on, or respond to, it.And, since proposals that have been fairly strongly motivated haven't even progressed to a WG review or IETF Last Call, I recommend that you justify your preferences in someone more detail than saying I want. In this area, there is clear evidence that no one cares about what you want or, for that matter, what I want. Just my opinion. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
I think the point has been missed here that there have been significant changes in the way that the IETF works. Six years ago the norm was for IESG and IAB members to be reappointed as a matter of course. Most NOMCONs changed one or two positions at most. Working Group chairs were with few exceptions appointed by the AD without the WG members even being aware that there is a vacancy. These practices have mostly changed and most people seem to agree that the changes are for the better. There are still problems to be addressed. In particular the IETF has yet to face the fact that major infrastructure changes such as IPv6 and DNSSEC require much closer attention to marketting and deployment than is currently the case. Also we still have the bizare situation where the IETF is a 'standards body' that almost never completes standards. There is an institutional failure to commit to production. The point of the first set of reforms was to enable the second set. We are all engineers and as engineers our preference for a management regime is likely to be an environment where there are no fixed deadlines, no accountability and endless scope for tinkering with details of the design. The IETF management procedures should hardly be a surprise therefore. The point of NOMCON was to maintain power in the hands of the establishment and to ensure that there was no effective means of accountability. The problem here is that we are now running an infrastructure that a billion people and about half of international commerce depends upon. The security of that infrastructure is unacceptable and throwing cryptography at it is not going to be the answer. The current IETF management procedures may meet the needs of some but they do not meet the needs of those people who have a different scope and a different vision of what the Internet should be, a vision and a scope that match what the Internet is today and will be in the future. -Original Message- From: Andrew Newton [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 05, 2006 10:03 AM To: todd glassey Cc: Bill Fenner; ietf@ietf.org Subject: Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here... todd glassey wrote: And since the purpose is to keep the IETF honest, I want the same term limits for any and all IETF positions, including the TRUST as well. Including working group chairs and secretaries and directorate members? -andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
todd glassey wrote: I originally said two...and would prefer that. What I am saying is that there should be a total of two or three instances as a NOMCOM candidate and that is a much different statement than figuring who is in office now and who is eligible...As to what it prevents-career Internet Standards jockey's. And since the purpose is to keep the IETF honest, I want the same term limits for any and all IETF positions, including the TRUST as well. I usually route around ietf political damage as much as possible, but the real life experience at least here in California is that this is a load of hooey. Term limits don't do any of these things, they just rearrange the deck chairs. There will always be Internet-Standards-Jockeys, it's just a question of whether the power they wield is transparent or not. Making them move to the shadows -- as power brokers always do when they can't be in power themselves -- changes the dynamic, but it doesn't do what you claim. The one thing that it *does* do is create clue scarcity when that wasn't a necessary outcome before. Which of course benefits the power brokers, not the process or constituency. But if you really want to prevent career Internet Standards Jockey's, why not go to the root of the problem: IETF participation in general. Why wouldn't it be a good idea to prevent people who've been participating for, oh say, 5 years to participate anymore? That would really clear out the dead wood. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
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:[EMAIL PROTECTED] 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
From: Hallam-Baker, Phillip [EMAIL PROTECTED] .. the IETF has yet to face the fact that major infrastructure changes such as IPv6 and DNSSEC require much closer attention to marketting and deployment than is currently the case. True. We are all engineers and as engineers our preference for a management regime is likely to be an environment where there are no fixed deadlines, no accountability and endless scope for tinkering with details of the design. The IETF management procedures should hardly be a surprise therefore. Interesting point. The point of NOMCON was to maintain power in the hands of the establishment and to ensure that there was no effective means of accountability. This is flat-out incorrect. The NomCom was created *precisely* to bring accountability to I* management positions, in the wake of the IAB's problematic actions at the time of the CLNP recommendation. Yes, the NomComm structure does retain control of I* management positions within the I* community, but what are the other options: give them over to national governments (as the ISO does), or the UN? Somehow I doubt that would improve the results. If what you're really saying is that what you don't like is that *you* don't have any influence over the results, I'm not sure that the rest of us would agree that that's a problem. The problem here is that we are now running an infrastructure that a billion people and about half of international commerce depends upon. Yes, that explains why IPv6 deployment has been so swift. The IETF isn't in charge of hardly anything. The vendors, ISP's and even the users (q.v. IPv6) all have a lot more influence - not to mention governments, and the legal systems of the various countries (e.g. look at wiretapping in the US, and the Great Firewall of China). The IETF has one (limited) role to play, which is to develop open standards (i.e. ones you don't have to sign a contract to read/use) in an open way (i.e. no closed rooms). There is some disagreement on how good a job it does on that (my take is that it's pretty good on both openness axes, but the technical quality sometimes is lacking), but that's all it really does. The security of that infrastructure is unacceptable and throwing cryptography at it is not going to be the answer. An interesting technical point (I agree it's not the whole answer, but it is part of the answer), but let's take it up once the useless poliics has died down. The current IETF management procedures may meet the needs of some but they do not meet the needs of those people who have a different scope and a different vision of what the Internet should be, a vision and a scope that match what the Internet is today and will be in the future. The rest of us apologize for being stupider, and of more limited vision, than you. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
John - the problem, is that management doesn't want either of us to gain any traction on reform or process with real oversight, and actually for all my screaming into the wind all I really want is a process that actually is fair and open. Again - I think the answer is a cafeteria style standardization process where the IETF nor IESG are responsible for the actual promotion of proposed standard to standard status ... Todd - Original Message - From: John C Klensin [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED] Cc: Bill Fenner [EMAIL PROTECTED]; ietf@ietf.org Sent: Tuesday, September 05, 2006 7:16 AM Subject: Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here... --On Tuesday, September 05, 2006 6:11 AM -0700 todd glassey [EMAIL PROTECTED] wrote: I originally said two...and would prefer that. What I am saying is that there should be a total of two or three instances as a NOMCOM candidate and that is a much different statement than figuring who is in office now and who is eligible...As to what it prevents-career Internet Standards jockey's. And since the purpose is to keep the IETF honest, I want the same term limits for any and all IETF positions, including the TRUST as well. By the way - has anyone seen a Business Plan for the TRUST and what it is supposed to do? I don't mean some fictional set of ideas - I mean the business plan. I want to see exactly what the Trust is responsible for and how its to be measured, Todd, Term limit ideas for IESG, IAB, and others, and even a suggestion that no one should be able to serve on consecutive Nomcoms, have been floated multiple times and have gone nowhere. I believe the latest attempt was as part of draft-klensin-nomcom-term-01.txt, which appears to be going nowhere as well. If you have a proposal here, I recommend that you make it in the form of an Internet Draft that is specific enough that people can actually comment on, or respond to, it.And, since proposals that have been fairly strongly motivated haven't even progressed to a WG review or IETF Last Call, I recommend that you justify your preferences in someone more detail than saying I want. In this area, there is clear evidence that no one cares about what you want or, for that matter, what I want. Just my opinion. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Eastlake III Donald-LDE008 wrote: 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. Also some input are sent to the nomcom chair for anonymous transmission to the rest of the nomcom. The chair needs to validate the authenticity of these comments and the to transmit them to the nomcom. There is an element of trust and discression in this process. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
--On Tuesday, September 05, 2006 9:20 AM -0700 todd glassey [EMAIL PROTECTED] wrote: John - the problem, is that management doesn't want either of us to gain any traction on reform or process with real oversight, and actually for all my screaming into the wind all I really want is a process that actually is fair and open. Again - I think the answer is a cafeteria style standardization process where the IETF nor IESG are responsible for the actual promotion of proposed standard to standard status ... Todd, I think you are describing no standardization process at all. Maybe it would be a specification-publishing process, but perhaps anyone could do that with a few web pages and an ability to shout people should pay attention to me and then see if anyone listens. Again, if you have a proposal that is specific enough to stand careful review and scrutiny, then write it up as a well-formed I-D and get it posted.At the moment, my assumption is that even your definition of fair and open differs from the general consensus of the IETF community _and_ that of the implementer/ user community. No amount of mailing list posting will reverse that assumption, only a proposal that is specific enough to really evaluate. Without such a proposal, you are doing little more than screaming I don't like the way it works, you are required to change it over and over again. That is not persuasive. Indeed, screaming may be the wrong metaphor wrt what you are doing into the wind. john p.s. If I felt that there were a management conspiracy against openness or fairness around here, I'd just quietly go somewhere else and try to encourage others --including vendors and implementers-- to follow. The IETF is really not that important; the development work, products, and the Internet are. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
... I also share your discomfort with the nomcom chair's decision to consult the IETF chair, although my discomfort falls short of wanting to see some formal rule against it happening. Well, let me observe that if there had been a formal rule, it would have been observed. And as a matter of fact, it wasn't Andrew who put me and the IAB Chair on copy - it was a person who noticed the anomaly. I happened to be aware that the ISOC President was on travel and Andrew turned out to be moving house, and at the same time the secretariat was experiencing sluggish mail queues (that problem is being addressed). So there was quite a combination of circumstances this time. Given this demonstration, I think some formal guidance that it is inappropriate for the nomcom chair to seek procedural advice from anyone who might be expected to be a candidate for selection or re-selection. But I have no idea how to write a formal rule that would work, even if it were desirable... and I'm not convinced that it would be desirable. I believe there is another, related, gap that has bothered me several times - there is nothing to indicate where the ISOC President should look for advice and consultancy when needed. So although it may take some debate, I think clarification in this area would be desirable. I can't speak for other people, but it seems to me that it's an obvious default for both the ISOC President and the Nomcom chair to turn to the I* chairs when in doubt - we have suggested nobody else except the previous Nomcom chair as a source of advice. If we don't want that to be the default, we need to provide an alternative. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
Title: RE: Now there seems to be lack of communicaiton here... Its time to talk about term limits for NOMCOM appointments. Two or maybe three terms at most areenough. If the IETF cannot bring in fresh management blood then it has become unnecessary and a vehicle through which only those initiatives approved by the sitting management ever get undertaken. Its time for some reform. Todd Glassey - Original Message - From: Hallam-Baker, Phillip To: Eastlake III Donald-LDE008 ; IETF-Discussion Sent: Saturday, September 02, 2006 7:24 PM Subject: RE: Now there seems to be lack of communication here... Actually the scheme I propose does not depend on pre-announcement of the list, only providing a proof of registration. I have not worked out exactly to avoid every attack but there is certainly no need to publish everyone's email address - although it is odd that you would mention that as the IETF is currently publishing my telephone number I gave when registering for a previous IETF. Certainly every selected member of NOMCON has to be reachable by email. All you require is a unique identifier. It could be the participant's name. If a person is registered twice and this is detected then you use the name that occurs first in some canonical ordering. The registration mechanism could be a Web form that you fill in that causes a receipt to be sent to the email address specified. That way a registrant has a proof that they registered and can use that to challenge the list. From: Eastlake III Donald-LDE008 [mailto:[EMAIL PROTECTED] Sent: Saturday, September 02, 2006 6:39 PMTo: IETF-DiscussionSubject: RE: Now there seems to be lack of communicaiton here... Depends what you mean by "it". The overall process may have broke in this case but the "it" referred to in the message you were responding to is the "cryptographic" part of theprocess. The one in RFC 3797 depends on pre-announcement of the orderedlist of volunteers. The one you suggested depends on pre-announcement of the email address of every volunteer. 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. Donald From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Saturday, September 02, 2006 10:00 AMTo: John C Klensin; Ned Freed; Eastlake III Donald-LDE008Cc: IETF-DiscussionSubject: RE: Now there seems to be lack of communicaiton here... If it ain't broke? How much more evidence of being broke do we need?The bug here is that the process is insufficiently robust under operator error.That is broke.The underlying problem here is the lack of auditability in the process.There is a simple fix here, eliminate the dependency on the list ordering and the system does not have such a critical dependence on the operator.Again nobody is claiming anything dishonest has happened here. The concern is that the accident could be repeated on purpose in the future to exclude undesirable candidates. Having spent part of last month watching this attempted in Alabama it is a real concern.When something is broke admit the fact. Prattling on about not fixing what aint broke only makes people angry.Sent from my GoodLink Wireless Handheld (www.good.com) ___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
On 9/4/06, todd glassey [EMAIL PROTECTED] wrote: Its time to talk about term limits for NOMCOM appointments. Two or maybe three terms at most are enough. Todd, Given that there are no standing IESG appointees that have served for three terms, what exactly would making such a rule change? Arkko, Jari 0.2 Callon, Ross 0.2 Carpenter, Brian0.7 Dusseault, Lisa 0.2 Eggert, Lars0.2 Fenner, Bill2.5 Hardie, Ted 1.7 Hartman, Sam0.8 Housley, Russ 1.7 Jennings, Cullen0.2 Kessens, David 1.3 Peterson, Jon 1.7 Romascanu, Dan 0.2 Townsley, Mark 0.7 Westerlund, Magnus 0.2 (This is AD and number of terms served, where numbers of terms served is counted by adding up the number of IETFs the AD is listed under at http://www.ietf.org/iesg_mem.html and dividing by 6) Bill [to be fair, 2 of the above positions didn't exist until their holders were appointed 0.2 terms ago] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
--On Friday, 01 September, 2006 15:07 -0700 Ned Freed [EMAIL PROTECTED] wrote: See below at @@@ -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Friday, September 01, 2006 11:45 AM To: Eastlake III Donald-LDE008; IETF-Discussion Subject: RE: Now there seems to be lack of communicaiton here... --On Thursday, 31 August, 2006 17:30 -0400 Eastlake III Donald-LDE008 [EMAIL PROTECTED] wrote: John, If the selection method is random, it makes no difference whatsoever how the list of nomcom volunteers is ordered. It only matters that the ... @@@ I'm not sure why you agree with me and then say the opposite. If it doesn't matter what the ordering of the nomcom volunteer pool is then it doesn't matter what the ordering of the nomcom volunteer pool is, and, in particular, it doesn't matter how random or biased it is. The RFC 3797 algorithm takes random inputs and uses them to make successive uniformly distributed non-repeating selections from a range of integers. The sole purpose of the published ordered volunteer pool list is to provide a pre-announced mapping from those integers to the people who volunteered. If it mattered what that mapping was, then you are not making uniformly distributed random selections. John, I have to agree with Donald here. Nothing anyone has said has indicated that there is a flaw in the algorithmic part of the selection process. If something ain't broke don't fix it. In my original note to Brian, I tried to ask a question involving a statistical nicety. It has to do with preserving the original randomness given a second draw from a rather small population (the number of volunteers). As you and Donald certainly know at least as well as I do, the key question about pseudo-random number generators and processes is whether they are good enough, not whether they produce randomness by all possible measures. I agree (but unfortunately did not say so explicitly) that the procedures defined in 3797 is more than adequate if followed exactly. I had and have some doubts about some of the variations 3797 permits if someone performs a partial reset (as distinct from a full reset, which would involve reopening the call for volunteers and maybe the Nomcom Chair appointment). However, I do not believe now, and have never believed, that quibbles about statistics and randomness are the issue here. I simply wanted to understand Brian's reasoning (and the reasoning of anyone else who recommended re-drawing the Nomcom composition after eliminating one name). I see two, related, issues at the core of the actual problem here: (1) Whatever the reason, essentially eliminating the time between when the volunteer pool was announced and the time the Nomcom membership list was determined took a series of checks out of the system, both with regard to eliminating individuals who were not eligible and with regard permitting people who volunteered and had been dropped to identify and question that decision (or find lost email, etc.).We will never know whether the numbers of the latter were large enough to have an impact on the selection model, and that lack of knowledge is a threat to the perceived integrity of the system. (2) Because the notion of a reset after the Nomcom membership list is selected permits someone, in principle, to examine the membership list and say no, I don't like that one, let's do it over, a reset is an extremely bad idea if there is any possible other alternative. To the extent to which a potential candidate in this round, or anyone with very strong opinions about a potential candidate, have an opportunity to examine the first-selected list and then provide substantive input into whether a reset should be done, we move beyond extremely bad into something worse. I assume that everything have been done with good faith here but, to paraphrase an off-list discussion, at least some of the community will always have a nagging fear that the reset was motivated by some members of the community believing that a second draw would yield a more favorable Nomcom. Indeed, not only is the algorithmic part of the selection process fine, the non-algorithmic parts were well thought out and various contingencies were covered, including the specific one where disqualified people found their way onto the final qualified candidate list. The problem is quite simply that the nomcom chair failed to follow these recommendations. yes It also appears we have dodged the bullet this time around. But this was mostly a matter of luck. We may not be so lucky the next time, and that means we need to act now to fix the problem that the nomcom chair has the dangerous and unnecessary ability to reset the selection process in cases where no reset should be allowed. (I have already described why there is real danger here - see my previous posting for specifics.) This absolutely must be attended to before the next nomcom.
RE: Now there seems to be lack of communicaiton here...
Title: RE: Now there seems to be lack of communicaiton here... If it ain't broke? How much more evidence of being broke do we need? The bug here is that the process is insufficiently robust under operator error. That is broke. The underlying problem here is the lack of auditability in the process. There is a simple fix here, eliminate the dependency on the list ordering and the system does not have such a critical dependence on the operator. Again nobody is claiming anything dishonest has happened here. The concern is that the accident could be repeated on purpose in the future to exclude undesirable candidates. Having spent part of last month watching this attempted in Alabama it is a real concern. When something is broke admit the fact. Prattling on about not fixing what aint broke only makes people angry. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 02, 2006 05:56 AM Pacific Standard Time To: Ned Freed; Eastlake III Donald-LDE008 Cc: IETF-Discussion Subject: RE: Now there seems to be lack of communicaiton here... --On Friday, 01 September, 2006 15:07 -0700 Ned Freed [EMAIL PROTECTED] wrote: See below at @@@ -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED]] Sent: Friday, September 01, 2006 11:45 AM To: Eastlake III Donald-LDE008; IETF-Discussion Subject: RE: Now there seems to be lack of communicaiton here... --On Thursday, 31 August, 2006 17:30 -0400 Eastlake III Donald-LDE008 [EMAIL PROTECTED] wrote: John, If the selection method is random, it makes no difference whatsoever how the list of nomcom volunteers is ordered. It only matters that the ... @@@ I'm not sure why you agree with me and then say the opposite. If it doesn't matter what the ordering of the nomcom volunteer pool is then it doesn't matter what the ordering of the nomcom volunteer pool is, and, in particular, it doesn't matter how random or biased it is. The RFC 3797 algorithm takes random inputs and uses them to make successive uniformly distributed non-repeating selections from a range of integers. The sole purpose of the published ordered volunteer pool list is to provide a pre-announced mapping from those integers to the people who volunteered. If it mattered what that mapping was, then you are not making uniformly distributed random selections. John, I have to agree with Donald here. Nothing anyone has said has indicated that there is a flaw in the algorithmic part of the selection process. If something ain't broke don't fix it. In my original note to Brian, I tried to ask a question involving a statistical nicety. It has to do with preserving the original randomness given a second draw from a rather small population (the number of volunteers). As you and Donald certainly know at least as well as I do, the key question about pseudo-random number generators and processes is whether they are good enough, not whether they produce randomness by all possible measures. I agree (but unfortunately did not say so explicitly) that the procedures defined in 3797 is more than adequate if followed exactly. I had and have some doubts about some of the variations 3797 permits if someone performs a partial reset (as distinct from a full reset, which would involve reopening the call for volunteers and maybe the Nomcom Chair appointment). However, I do not believe now, and have never believed, that quibbles about statistics and randomness are the issue here. I simply wanted to understand Brian's reasoning (and the reasoning of anyone else who recommended re-drawing the Nomcom composition after eliminating one name). I see two, related, issues at the core of the actual problem here: (1) Whatever the reason, essentially eliminating the time between when the volunteer pool was announced and the time the Nomcom membership list was determined took a series of checks out of the system, both with regard to eliminating individuals who were not eligible and with regard permitting people who volunteered and had been dropped to identify and question that decision (or find lost email, etc.). We will never know whether the numbers of the latter were large enough to have an impact on the selection model, and that lack of knowledge is a threat to the perceived integrity of the system. (2) Because the notion of a reset after the Nomcom membership list is selected permits someone, in principle, to examine the membership list and say no, I don't like that one, let's do it over, a reset is an extremely bad idea if there is any possible other alternative. To the extent to which a potential candidate in this round, or anyone with very strong opinions about a potential candidate, have an opportunity to examine the first-selected list and then provide substantive input into whether a reset should be done, we move beyond extremely bad into something worse. I assume that
Re: Now there seems to be lack of communicaiton here...
On Sat, Sep 02, 2006 at 06:59:36AM -0700, Hallam-Baker, Phillip wrote: The bug here is that the process is insufficiently robust under operator error. That is broke. I think we are in violent agreement that it should be fixed before the next Nomcom. There may be a difference of opinion of how exactly to fix the problem, but I don't think anyone has suggested that we should leave things the way that they are, at least for the next Nomcom. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
On 2 sep 2006, at 14.49, John C Klensin wrote: I assume that everything have been done with good faith here but, to paraphrase an off-list discussion, at least some of the community will always have a nagging fear that the reset was motivated by some members of the community believing that a second draw would yield a more favorable Nomcom. I think i agree that it is safe to say that is due to human error, though the consultation with someone who is on the list of those to be considered for renewal does compound the error and put it all at further risk. but i still think it is an error and not an intentional act to subvert the process. On 2 sep 2006, at 17.42, Theodore Tso wrote: On Sat, Sep 02, 2006 at 06:59:36AM -0700, Hallam-Baker, Phillip wrote: The bug here is that the process is insufficiently robust under operator error. That is broke. I think we are in violent agreement that it should be fixed before the next Nomcom. There may be a difference of opinion of how exactly to fix the problem, but I don't think anyone has suggested that we should leave things the way that they are, at least for the next Nomcom. i don't think the process is broken, but the implementation was. and i don't believe this is sufficient reason to reopen the nomcom process. i think the process is clear about what should happen once someone is committed to the 3797 process. what is broken is that the process was, perhaps, not well enough understood and, as is so often the case in the IETF and elsewhere, was followed loosely as opposed to strictly. i do wonder if the previous nomcom chair was consulted in making the decision to redraw - in fact perhaps previous chairs could be a useful resource for the new chair faced with such a dilemma as opposed to representatives of the bodies to be staffed. however, in the sprit of accepting broken implementations (i.e. conservative in what you send, liberal in what you receive) i suggest we wish Andrew luck and let him get on with it. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
Title: RE: Now there seems to be lack of communicaiton here... Depends what you mean by "it". The overall process may have broke in this case but the "it" referred to in the message you were responding to is the "cryptographic" part of theprocess. The one in RFC 3797 depends on pre-announcement of the orderedlist of volunteers. The one you suggested depends on pre-announcement of the email address of every volunteer. 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. Donald From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Saturday, September 02, 2006 10:00 AMTo: John C Klensin; Ned Freed; Eastlake III Donald-LDE008Cc: IETF-DiscussionSubject: RE: Now there seems to be lack of communicaiton here... If it ain't broke? How much more evidence of being broke do we need?The bug here is that the process is insufficiently robust under operator error.That is broke.The underlying problem here is the lack of auditability in the process.There is a simple fix here, eliminate the dependency on the list ordering and the system does not have such a critical dependence on the operator.Again nobody is claiming anything dishonest has happened here. The concern is that the accident could be repeated on purpose in the future to exclude undesirable candidates. Having spent part of last month watching this attempted in Alabama it is a real concern.When something is broke admit the fact. Prattling on about not fixing what aint broke only makes people angry.Sent from my GoodLink Wireless Handheld (www.good.com) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
Title: RE: Now there seems to be lack of communicaiton here... Actually the scheme I propose does not depend on pre-announcement of the list, only providing a proof of registration. I have not worked out exactly to avoid every attack but there is certainly no need to publish everyone's email address - although it is odd that you would mention that as the IETF is currently publishing my telephone number I gave when registering for a previous IETF. Certainly every selected member of NOMCON has to be reachable by email. All you require is a unique identifier. It could be the participant's name. If a person is registered twice and this is detected then you use the name that occurs first in some cannonical ordering. The registration mechanism could be a Web form that you fill in that causes a receipt to be sent to the email address specified. That way a registrant has a proof that they registered and can use that to challenge the list. From: Eastlake III Donald-LDE008 [mailto:[EMAIL PROTECTED] Sent: Saturday, September 02, 2006 6:39 PMTo: IETF-DiscussionSubject: RE: Now there seems to be lack of communicaiton here... Depends what you mean by "it". The overall process may have broke in this case but the "it" referred to in the message you were responding to is the "cryptographic" part of theprocess. The one in RFC 3797 depends on pre-announcement of the orderedlist of volunteers. The one you suggested depends on pre-announcement of the email address of every volunteer. 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. Donald From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Saturday, September 02, 2006 10:00 AMTo: John C Klensin; Ned Freed; Eastlake III Donald-LDE008Cc: IETF-DiscussionSubject: RE: Now there seems to be lack of communicaiton here... If it ain't broke? How much more evidence of being broke do we need?The bug here is that the process is insufficiently robust under operator error.That is broke.The underlying problem here is the lack of auditability in the process.There is a simple fix here, eliminate the dependency on the list ordering and the system does not have such a critical dependence on the operator.Again nobody is claiming anything dishonest has happened here. The concern is that the accident could be repeated on purpose in the future to exclude undesirable candidates. Having spent part of last month watching this attempted in Alabama it is a real concern.When something is broke admit the fact. Prattling on about not fixing what aint broke only makes people angry.Sent from my GoodLink Wireless Handheld (www.good.com) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Brian what in the world are you thinking? Given that the issue involved here is the integrity of the NOMCOM process, it deserves no more notification than a posting on the announce list? The ietf-announce list is where all our formal announcements go, and it reaches many more people than this list. Last time I checked there were 4261 addresses on ietf-announce and 2034 here. The announcements that led to at least one member of the community noticing the problem went to ietf-announce as well. As far as I can see, the checks and balances worked. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
(replying to multiple posts in one) Jeffrey Hutzelman wrote: ... Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good. I will refrain from expressing an opinion except to say that it's Andrew's decision as far as I'm concerned. Michael StJohns wrote: ... Unless I'm mistaken, I'm reading an overwhelming consensus NOT to reset from those posting on this list. I haven't kept count, but I think it's more evenly split (especially since Jeff's message quoted above). Eliot Lear wrote: Mike, To address Eliot's comment about the volunteer list - From Andrew's note that triggered all of this I see that he sent the list of the volunteers to the Secretariat. If we could have someone from the Secretariat provide a copy of that email independent of Andrew and verify it was submitted to them prior to the selection date that should resolve Eliot's issue. Eliot? Yes, that would have resolved my issue nicely. But I am equally satisfied with rerunning the selection algorithm. I believe there were some mail delivery glitches at the Secretariat on the day in question, so this might not have been completely straightforward. John C Klensin wrote: --On Thursday, 31 August, 2006 09:38 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Brian, I don't know about others, but I'd like to hear a little more about your reasoning (and Andrew's) about this. It seems to me that drawing a second sample would be unbiased if the decision to draw it were made before anyone knew the contents of the first sample. I was much more concerned about the failure to announce the volunteer list before the relevant market closing than about the presence of an ineligible name. I don't see how one can remove the theoretical presence of bias unless the list is announced in advance. I completely agree that an extra name in the list doesn't create bias. Pete Resnick wrote: On 8/31/06 at 9:38 AM +0200, Brian E Carpenter wrote: Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Brian, the fact that Andrew Cc'ed you on the issue was (IMO) not a good idea in the first place, He didn't. It was a person who noticed the anomaly who cc'ed me. but given that your position is one of those being selected, the fact that you expressed an opinion at all was phenomenally irresponsible. I disagree. My concern was to ensure that there is neither bias nor appearance of potential bias in the process. I believe it would have been irresponsible not to. Now, in addition to questions about Andrew's motivations for doing the reset (the theoretical Did he want a 'do-over' because he didn't like the outcome?), we also have to contend with whether *you* influenced the process deliberately because *you* didn't like the outcome. Unbelievably ill-advised on your part. Actually, I don't recall even looking at the list of selected volunteers. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
I haven't kept count, but I think it's more evenly split (especially since Jeff's message quoted above). Just another comment following up on my previous email. Allowing this list to influence the outcome is just as bad as allowing the NONCOM chair to decide. In the weekly posting summary there are usually less than 50 posters. It would not be hard for someone (or some small group) to put together 20 sock-puppets and influence the majority opinion here. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Donald, I don't think your argument covers the case where the presence of the ineligible person is noticed after the selection has been run, which is what happened in this case, and it is predicated on the list being published before the selection is run, which didn't happen in this case. Brian Eastlake III Donald-LDE008 wrote: Brian, The advice you gave is exactly the opposite of that in RFC 3797, the latest version of my non-binding guidelines for publicly verifiable random selection. Note in particular that Section 5.1 of that RFC says (with the all caps words in the original): 5.1. Uncertainty as to the Pool Every reasonable effort should be made to see that the published pool from which selection is made is of certain and eligible persons. However, especially with compressed schedules or perhaps someone whose claim that they volunteered and are eligible has not been resolved by the deadline, or a determination that someone is not eligible which occurs after the publication of the pool, it may be that there are still uncertainties. The best way to handle this is to maintain the announced schedule, INCLUDE in the published pool all those whose eligibility is uncertain and to keep the published pool list numbering IMMUTABLE after its publication. If someone in the pool is later selected by the algorithm and random input but it has been determined they are ineligible, they can be skipped and the algorithm run further to make an additional selection. Thus the uncertainty only effects one selection and in general no more than a maximum of U selections where there are U uncertain pool members. Other courses of action are far worse. Actual insertion or deletion of entries in the pool after its publication changes the length of the list and totally scrambles who is selected, possibly changing every selection. ... The presence of ineligible persons in the list is no reason whatsoever to reset. Donald -Original Message- From: Ned Freed [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 10:25 AM To: Brian E Carpenter Cc: [EMAIL PROTECTED]; IETF-Discussion; Michael StJohns Subject: Re: Now there seems to be lack of communicaiton here... ... The correct thing to do now is to reject the reest and stick with the original list. The only case where a reset should be allowed is if the process produced a bogus result. Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Well, I have to say I think you provided some extremely bad advice, and I sincerely hope that there isn't anyone on the first list that has an even slightly acrimonious public relationship with Andrew. We could be in very deep doo if there is. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good. (2) Text is added to the next version of the selection process to addresss this issue. I would suggest a strengthening of the existing language about leaving questionable candidates in the list and rejecting them in a later pass. In fact, it might be wiser to require the use of the original list of volunteers as given to the secretariat and _always_ rejecting ineligible candidates in a later pass. This would remove any need to insure that errors or disputes about eligibility be resolved before the random data becomes available. Jeff, I agree that this is the best course of action. I would also like to express my full support for Andrew's decisions. Due to unfortunate circumstances, he got into an unanticipated situation. He's being critized for the decision to re-run the selection; but given that we had several, not just one problem (timing and ineligible members) the other options would also have been problematic. Not an easy position to be in! --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Hello; On Sep 1, 2006, at 5:06 AM, Brian E Carpenter wrote: (replying to multiple posts in one) Jeffrey Hutzelman wrote: ... Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good. I will refrain from expressing an opinion except to say that it's Andrew's decision as far as I'm concerned. Michael StJohns wrote: ... Unless I'm mistaken, I'm reading an overwhelming consensus NOT to reset from those posting on this list. I haven't kept count, but I think it's more evenly split (especially since Jeff's message quoted above). Not being perturbed by this, I haven't felt the need to comment, but now I will : I think it's Andrew's decision and his decision making so far does not bother me. (To be clear, that's a WFM on the reset.) I suspect that others have also not felt the need to comment, so I don't feel that the overwhelming consensus claimed above exists in fact. Regards Marshall Eliot Lear wrote: Mike, To address Eliot's comment about the volunteer list - From Andrew's note that triggered all of this I see that he sent the list of the volunteers to the Secretariat. If we could have someone from the Secretariat provide a copy of that email independent of Andrew and verify it was submitted to them prior to the selection date that should resolve Eliot's issue. Eliot? Yes, that would have resolved my issue nicely. But I am equally satisfied with rerunning the selection algorithm. I believe there were some mail delivery glitches at the Secretariat on the day in question, so this might not have been completely straightforward. John C Klensin wrote: --On Thursday, 31 August, 2006 09:38 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Brian, I don't know about others, but I'd like to hear a little more about your reasoning (and Andrew's) about this. It seems to me that drawing a second sample would be unbiased if the decision to draw it were made before anyone knew the contents of the first sample. I was much more concerned about the failure to announce the volunteer list before the relevant market closing than about the presence of an ineligible name. I don't see how one can remove the theoretical presence of bias unless the list is announced in advance. I completely agree that an extra name in the list doesn't create bias. Pete Resnick wrote: On 8/31/06 at 9:38 AM +0200, Brian E Carpenter wrote: Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Brian, the fact that Andrew Cc'ed you on the issue was (IMO) not a good idea in the first place, He didn't. It was a person who noticed the anomaly who cc'ed me. but given that your position is one of those being selected, the fact that you expressed an opinion at all was phenomenally irresponsible. I disagree. My concern was to ensure that there is neither bias nor appearance of potential bias in the process. I believe it would have been irresponsible not to. Now, in addition to questions about Andrew's motivations for doing the reset (the theoretical Did he want a 'do-over' because he didn't like the outcome?), we also have to contend with whether *you* influenced the process deliberately because *you* didn't like the outcome. Unbelievably ill-advised on your part. Actually, I don't recall even looking at the list of selected volunteers. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
--On Thursday, 31 August, 2006 17:30 -0400 Eastlake III Donald-LDE008 [EMAIL PROTECTED] wrote: John, If the selection method is random, it makes no difference whatsoever how the list of nomcom volunteers is ordered. It only matters that the numbered list become fixed and be posted before the selection information is available. Alphabetic or the order they volunteered or any other order is perfectly fine. Agreed, except that an alphabetic sort is not, by any stretch of the imagination, random. Phillip's suggestion of using a well-established hash that is known to give good distributions would work; there are many other methods that would work. But a number of observable distribution issues make an alphabetic sort on names unacceptably random if one is then going to use the ordering for successive samplings/selections. I want to stress that, given this mess has occurred, I would find just about anything the Nomcom Chair decides to do acceptable although I do not approve of his consulting the IETF Chair (or IAB Chair) in the matter. But, if we are going to make sure this problem does not occur in the future, I think we should make the procedure as gaming-proof as possible. That, to me, implies two requirements going forward: (1) We get strong randomization of the selection process (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. In addition, I am extremely concerned by hints on this list that the Secretariat's checking procedures ruled people ineligible to volunteer who had, in fact, attended the correct number of meetings. That, it seems to me, is a much larger threat to the integrity of the Nomcom model and perceptions of trust in it than any issue that impacts a single volunteer or even, within broad limits, the randomization and Nomcom member selection processes. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
See below at @@@ -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Friday, September 01, 2006 11:45 AM To: Eastlake III Donald-LDE008; IETF-Discussion Subject: RE: Now there seems to be lack of communicaiton here... --On Thursday, 31 August, 2006 17:30 -0400 Eastlake III Donald-LDE008 [EMAIL PROTECTED] wrote: John, If the selection method is random, it makes no difference whatsoever how the list of nomcom volunteers is ordered. It only matters that the numbered list become fixed and be posted before the selection information is available. Alphabetic or the order they volunteered or any other order is perfectly fine. Agreed, except that an alphabetic sort is not, by any stretch of the imagination, random. Phillip's suggestion of using a well-established hash that is known to give good distributions would work; there are many other methods that would work. But a number of observable distribution issues make an alphabetic sort on names unacceptably random if one is then going to use the ordering for successive samplings/selections. @@@ I'm not sure why you agree with me and then say the opposite. If it doesn't matter what the ordering of the nomcom volunteer pool is then it doesn't matter what the ordering of the nomcom volunteer pool is, and, in particular, it doesn't matter how random or biased it is. The RFC 3797 algorithm takes random inputs and uses them to make successive uniformly distributed non-repeating selections from a range of integers. The sole purpose of the published ordered volunteer pool list is to provide a pre-announced mapping from those integers to the people who volunteered. If it mattered what that mapping was, then you are not making uniformly distributed random selections. @@@ Both RFC 3797 and Phil Hallam-Baker's suggestion use a well-established hash. (I happen to personally not like the details of Phil's specific suggestion because of questions related to email address canonicalization and because it would require publishing email addresses for all nomcom volunteers.) I want to stress that, given this mess has occurred, I would find just about anything the Nomcom Chair decides to do acceptable although I do not approve of his consulting the IETF Chair (or IAB Chair) in the matter. But, if we are going to make sure this problem does not occur in the future, I think we should make the procedure as gaming-proof as possible. That, to me, implies two requirements going forward: (1) We get strong randomization of the selection process @@@ We already have this. See RFC 3797. (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. In addition, I am extremely concerned by hints on this list that the Secretariat's checking procedures ruled people ineligible to volunteer who had, in fact, attended the correct number of meetings. That, it seems to me, is a much larger threat to the integrity of the Nomcom model and perceptions of trust in it than any issue that impacts a single volunteer or even, within broad limits, the randomization and Nomcom member selection processes. @@@ Well, you are welcome to be as concerned as you like, but we live in an imperfect world. As far as I know, there are usually a few disputes about the volunteer list, usually in connection with people whose eligibility the Secretariat doubts. Sometimes they are determined to be correct and sometimes the Secretariat is determined to be right. Sometimes the volunteer is confused about the eligibility requirements or about what their attendance actually was, or has variant versions of their name, or has changed their name, or ... But this sort of thing doesn't effect very many people on the volunteer list and is almost always resolved between the volunteer and the Secretariat before the list is published. john @@@ Thanks, @@@ Donald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
See below at @@@ -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Friday, September 01, 2006 11:45 AM To: Eastlake III Donald-LDE008; IETF-Discussion Subject: RE: Now there seems to be lack of communicaiton here... --On Thursday, 31 August, 2006 17:30 -0400 Eastlake III Donald-LDE008 [EMAIL PROTECTED] wrote: John, If the selection method is random, it makes no difference whatsoever how the list of nomcom volunteers is ordered. It only matters that the numbered list become fixed and be posted before the selection information is available. Alphabetic or the order they volunteered or any other order is perfectly fine. Agreed, except that an alphabetic sort is not, by any stretch of the imagination, random. Phillip's suggestion of using a well-established hash that is known to give good distributions would work; there are many other methods that would work. But a number of observable distribution issues make an alphabetic sort on names unacceptably random if one is then going to use the ordering for successive samplings/selections. @@@ I'm not sure why you agree with me and then say the opposite. If it doesn't matter what the ordering of the nomcom volunteer pool is then it doesn't matter what the ordering of the nomcom volunteer pool is, and, in particular, it doesn't matter how random or biased it is. The RFC 3797 algorithm takes random inputs and uses them to make successive uniformly distributed non-repeating selections from a range of integers. The sole purpose of the published ordered volunteer pool list is to provide a pre-announced mapping from those integers to the people who volunteered. If it mattered what that mapping was, then you are not making uniformly distributed random selections. John, I have to agree with Donald here. Nothing anyone has said has indicated that there is a flaw in the algorithmic part of the selection process. If something ain't broke don't fix it. Indeed, not only is the algorithmic part of the selection process fine, the non-algorithmic parts were well thought out and various contingencies were covered, including the specific one where disqualified people found their way onto the final qualified candidate list. The problem is quite simply that the nomcom chair failed to follow these recommendations. It also appears we have dodged the bullet this time around. But this was mostly a matter of luck. We may not be so lucky the next time, and that means we need to act now to fix the problem that the nomcom chair has the dangerous and unnecessary ability to reset the selection process in cases where no reset should be allowed. (I have already described why there is real danger here - see my previous posting for specifics.) This absolutely must be attended to before the next nomcom. Now, various people have argued that the nomcom chair was within the rules to reset the process when the error came to light. I agree with this assessment, but this is really beside the point. The point is the nomcom chair should NOT have the reset option available in this circumstance, and that our current process is BROKEN in allowing this level of discretion. @@@ Both RFC 3797 and Phil Hallam-Baker's suggestion use a well-established hash. (I happen to personally not like the details of Phil's specific suggestion because of questions related to email address canonicalization and because it would require publishing email addresses for all nomcom volunteers.) Agreed. I want to stress that, given this mess has occurred, I would find just about anything the Nomcom Chair decides to do acceptable although I do not approve of his consulting the IETF Chair (or IAB Chair) in the matter. I'm sorry, but I'm not so forgiving. The nomcom chair made a major blunder here, abetted by some exceptionally poor advice from the IETF chair. This blunder could have caused major damage to the organization. The combination of there being essentially no time before the second selection process and the fairly drastic nature of an ISOC appeal is the only - repeat ONLY - reason I for one didn't start the ball rolling. I've seen no indication that there's been any direct fallout from this, such as a lawsuit being filed. (Of course something along these lines could still happen.) But this does not mean that what has happened hasn't weakened the faith people have in the fairness of the process. I know for a fact that I'm much less sanguine about the process than I used to be, and I suspect I'm not alone in this. I also share your discomfort with the nomcom chair's decision to consult the IETF chair, although my discomfort falls short of wanting to see some formal rule against it happening. But, if we are going to make sure this problem does not occur in the future, I think we should make the procedure as gaming-proof as possible. That, to me, implies two requirements going forward: (1) We get strong randomization of the selection
Re: Now there seems to be lack of communicaiton here...
On Thursday, August 31, 2006 11:11:51 AM -0700 Dave Crocker [EMAIL PROTECTED] wrote: James Galvin wrote: But there is a part of the process that is not public: the actual selection of eligible volunteers. 1) The criteria are public. 2) The result is public, with the intention of time for review. I'm not sure how the internals of going from 1 to 2 could be made public and still function. Since the criteria are reasonably objective, I'm having trouble seeing how transparency on the decision process is meaningful. I agree. The important property here is not that any part of the process be observable, but that the results be independently verifiable. That is done by making all of the inputs(*) public before the process runs, and using a well-defined, fixed algorithm. (*) For this purpose, the random data itself is not an input, but the identification of the random source(s) and exactly how they are to be sampled is. At base, I suspect this demonstrates the problem with our being too rule-oriented, and not enough community oriented. It loses sight of the underpinnings of comfort and legitimacy, and that is community review and approval when a situation does -- or reasonably might -- entail the unknown or, at least, controversy. Really, as soon as the need or ability to make a decision as to whether to reset had been made, we had already lost. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
I further agree with Phillip (and Richard) that this is not an IAB or even a Nomcom chair decision I disagree. The chair of a committee should have some freedom to decide what to do in cases not covered by the RFC. The decision he made (rerun the algorithm with correct input data) is a reasonable one by any standard. Let's just accept his decision and go on with our work. There are, of course, other solutions, but I seriously doubt that a community discussion will ever lead to consensus on which one is best. So, let's not have this discussion (*) I disagree further with Phil that this can set a precedent for rerunning the algorithm in the case where a unacceptable to some member is selected in the NOMCOM. That is something completely different. Henk (*) This won't happen but thanks to procmail, I won't see it... -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- 1160438400 + 381600 = 116082. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Mike, As it happens the liaisons were both chosen some time ago, by definition with no knowledge of the chosen volunteers. We are not going to change the rules on the fly, are we? Brian Michael StJohns wrote: One of the things missing from this years list of volunteers is their association. That's one of the inputs into the selection algorithm as the number of voting members from a particular association is limited to two. I'd ask that the Nomcom chair include this in the list of volunteers. Also, I note that last year there were actually 4 members (2 voting and 2 others) from one particular organization. I'd suggest that this year the liasons NOT be selected from any organization already represented by a voting member. Later, Mike At 09:31 PM 8/30/2006, Richard Shockey wrote: This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. Second ...a complete explanation of why this go screwed up should have been posted to the community. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire process of the IETF and NomCom. This resulted in the list being sent to the secretariat later than I would have liked, and the message then got hung up in the secretariat's queue. The selection is still deterministic, because the list ordering algorithm used (alpha by first name) is deterministic. However, since the list was published late, the appearance is not ideal. Second: A sitting member of the IAB's name appeared on the candidate list. According to 3777, section 15, sitting IAB, IESG and ISOC members are not eligible to serve on the Nomcom. This was an oversight on my part. Ordering in the list does matter for the selection process. Although this person was not selected to serve, and the harm done is minimal, it is important that the IETF follow our own processes as closely as possible. For these reasons, and after consultation with members of the IAB, IESG and ISOC, I have decided that to remove any doubt from the proceedings we must re-run the selection algorithm with new seed information. This is unfair to the people who volunteered for NomCom and are the backbone of the process. These people rightfully believed that they were or were not selected, and everyone selected was preparing to serve. To the volunteers: Thank you for volunteering, for your patience and understanding. I apologize for any inconvenience this reset may cause. In order to close this issue quickly, the same stocks and procedure will be used as last time, but the trading date will be drawn from the September 1, 2006 Wall Street Journal which reports the the sales figures from the previous trading day - August 31, 2006. The list we will use is the same as before, but with the IAB member's name removed. The list will be sent in a separate mail. Thank you. Andrew Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org
Re: Now there seems to be lack of communicaiton here...
Richard Shockey wrote: This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. This message is on its way to the ietf-announce list; that takes time with several thousand subscribers. That is the appropriate list, not this one. Second ...a complete explanation of why this go screwed up should have been posted to the community. The message seems to give a complete explanation. Oversights happen. We are a volunteer community, and any of us can overlook something, any time. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. Actually the custodian of the process is, as I read RFC 3777, the ISOC President. There is a formal dispute procedure defined in RFC 3777, but Andrew took remedial action before anyone invoked that. Since remedial action has been taken, I don't see an issue at this time. Brian * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire process of the IETF and NomCom. This resulted in the list being sent to the secretariat later than I would have liked, and the message then got hung up in the secretariat's queue. The selection is still deterministic, because the list ordering algorithm used (alpha by first name) is deterministic. However, since the list was published late, the appearance is not ideal. Second: A sitting member of the IAB's name appeared on the candidate list. According to 3777, section 15, sitting IAB, IESG and ISOC members are not eligible to serve on the Nomcom. This was an oversight on my part. Ordering in the list does matter for the selection process. Although this person was not selected to serve, and the harm done is minimal, it is important that the IETF follow our own processes as closely as possible. For these reasons, and after consultation with members of the IAB, IESG and ISOC, I have decided that to remove any doubt from the proceedings we must re-run the selection algorithm with new seed information. This is unfair to the people who volunteered for NomCom and are the backbone of the process. These people rightfully believed that they were or were not selected, and everyone selected was preparing to serve. To the volunteers: Thank you for volunteering, for your patience and understanding. I apologize for any inconvenience this reset may cause. In order to close this issue quickly, the same stocks and procedure will be used as last time, but the trading date will be drawn from the September 1, 2006 Wall Street Journal which reports the the sales figures from the previous trading day - August 31, 2006. The list we will use is the same as before, but with the IAB member's name removed. The list will be sent in a separate mail. Thank you. Andrew Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Mike and Phill, Phill's assertion is wrong - the IAB and IESG has no control over this; such decisions are between the Nomcom Chair and the ISOC President. I don't see anything in RFC 3777 that sends disputes back to the community. In this case, nobody even got as far as invoking the dispute procedure before Andrew took action. Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Brian Michael StJohns wrote: I agree with Phillip - there is no harm here. If someone ineligible had happened to be selected, they would have been immediately disqualified and the next number on the list selected. That's why you actually ask for about 16 numbers to be output when you run the program which outputs the selection numbers. There is no reason for a reset. (However, see my comments on volunteer associations). I further agree with Phillip (and Richard) that this is not an IAB or even a Nomcom chair decision, but a community one and should not have been made in the back room. At 10:52 PM 8/30/2006, Hallam-Baker, Phillip wrote: The reset should not be permitted. The problem here is that the IAB and IESG could use this precedent to avoid appointment of certain individuals to the NOMCOM. The situation might appear to be that a member of the crazy gang got choosen and someone wants to block them. Given the tenuous nature of the NOMCON procedure itself and the abysmal level of accounability it achieves it is not acceptable to further dilute it. My personal view is that the NOMCON process itself is a charade that was intended to concentrate power in the hands of the establishment. The only reason why it can be claimed to work is that the process cannot be controlled by the administrators. Once someone can ask for a 'redo' that rationale is lost entirely. The original list should be used. If any member is ineligible and is elected then this should be treated as if they were elected and then immediately disqualified. Furthermore it is really unacceptable to present this as a fait acompli with a new selection date already set. -Original Message- From: Richard Shockey [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 9:31 PM To: 'IETF-Discussion' Subject: Now there seems to be lack of communicaiton here... This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. Second ...a complete explanation of why this go screwed up should have been posted to the community. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire process of the IETF and NomCom. This resulted in the list being sent to the secretariat later than I would have liked, and the message then got hung up in the secretariat's queue. The selection is still deterministic, because the list ordering algorithm used (alpha by first name) is deterministic. However, since the list was published late, the appearance is not ideal. Second: A sitting member of the IAB's name appeared on the candidate list. According to 3777, section 15, sitting IAB, IESG and ISOC members are not eligible to serve on the Nomcom. This was an oversight on my part. Ordering in the list does matter for the selection process. Although this person was not selected to serve, and the harm done is minimal, it is important that the IETF follow our own
Re: Now there seems to be lack of communicaiton here...
Michael StJohns wrote: I agree with Phillip - there is no harm here. If someone ineligible had happened to be selected, they would have been immediately disqualified and the next number on the list selected. That's why you actually ask for about 16 numbers to be output when you run the program which outputs the selection numbers. There is no reason for a reset. (However, see my comments on volunteer associations). Mike, it's not often, but you and I disagree on this one. There were two problems. Don't forget that the list of volunteers was announced along with the selection process. I fully accept Andrew Lange's explanation that a message got hung in the queue. Never-the-less, selection of our leadership should not be taken lightly. When the foul-up was discovered, the chair followed the procedure that was documented. Please let's recognize that Mr. Lange has erred on the side of transparency. I applaud his choice. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Title: Re: Now there seems to be lack of communicaiton here... Brian Ok if you were not being asked in your official capacity then why not ask me? I have some expertise in security protocols. Allowing the reset nullifies the process entirely. Phill Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 31, 2006 12:39 AM Pacific Standard Time To: Michael StJohns Cc: Hallam-Baker, Phillip; [EMAIL PROTECTED]; IETF-Discussion Subject: Re: Now there seems to be lack of communicaiton here... Mike and Phill, Phill's assertion is wrong - the IAB and IESG has no control over this; such decisions are between the Nomcom Chair and the ISOC President. I don't see anything in RFC 3777 that sends disputes back to the community. In this case, nobody even got as far as invoking the dispute procedure before Andrew took action. Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Brian Michael StJohns wrote: I agree with Phillip - there is no harm here. If someone ineligible had happened to be selected, they would have been immediately disqualified and the next number on the list selected. That's why you actually ask for about 16 numbers to be output when you run the program which outputs the selection numbers. There is no reason for a reset. (However, see my comments on volunteer associations). I further agree with Phillip (and Richard) that this is not an IAB or even a Nomcom chair decision, but a community one and should not have been made in the back room. At 10:52 PM 8/30/2006, Hallam-Baker, Phillip wrote: The reset should not be permitted. The problem here is that the IAB and IESG could use this precedent to avoid appointment of certain individuals to the NOMCOM. The situation might appear to be that a member of the crazy gang got choosen and someone wants to block them. Given the tenuous nature of the NOMCON procedure itself and the abysmal level of accounability it achieves it is not acceptable to further dilute it. My personal view is that the NOMCON process itself is a charade that was intended to concentrate power in the hands of the establishment. The only reason why it can be claimed to work is that the process cannot be controlled by the administrators. Once someone can ask for a 'redo' that rationale is lost entirely. The original list should be used. If any member is ineligible and is elected then this should be treated as if they were elected and then immediately disqualified. Furthermore it is really unacceptable to present this as a fait acompli with a new selection date already set. -Original Message- From: Richard Shockey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 30, 2006 9:31 PM To: 'IETF-Discussion' Subject: Now there seems to be lack of communicaiton here... This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. Second ...a complete explanation of why this go screwed up should have been posted to the community. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire process of the IETF and NomCom. This resulted in the list being sent to the secretariat later than I would have liked, and the message then
Re: Now there seems to be lack of communicaiton here...
Title: Re: Now there seems to be lack of communicaiton here... Furthermore the absence of a complaint makes things worse not better. The nomcon process is meant to eliminate the ability of the establishment to control the process. ISOC is not above suspicion either. Like every other part of this keretsu the governance procedures are only superficially open. Elections work, this process does not. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 31, 2006 12:39 AM Pacific Standard Time To: Michael StJohns Cc: Hallam-Baker, Phillip; [EMAIL PROTECTED]; IETF-Discussion Subject: Re: Now there seems to be lack of communicaiton here... Mike and Phill, Phill's assertion is wrong - the IAB and IESG has no control over this; such decisions are between the Nomcom Chair and the ISOC President. I don't see anything in RFC 3777 that sends disputes back to the community. In this case, nobody even got as far as invoking the dispute procedure before Andrew took action. Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Brian Michael StJohns wrote: I agree with Phillip - there is no harm here. If someone ineligible had happened to be selected, they would have been immediately disqualified and the next number on the list selected. That's why you actually ask for about 16 numbers to be output when you run the program which outputs the selection numbers. There is no reason for a reset. (However, see my comments on volunteer associations). I further agree with Phillip (and Richard) that this is not an IAB or even a Nomcom chair decision, but a community one and should not have been made in the back room. At 10:52 PM 8/30/2006, Hallam-Baker, Phillip wrote: The reset should not be permitted. The problem here is that the IAB and IESG could use this precedent to avoid appointment of certain individuals to the NOMCOM. The situation might appear to be that a member of the crazy gang got choosen and someone wants to block them. Given the tenuous nature of the NOMCON procedure itself and the abysmal level of accounability it achieves it is not acceptable to further dilute it. My personal view is that the NOMCON process itself is a charade that was intended to concentrate power in the hands of the establishment. The only reason why it can be claimed to work is that the process cannot be controlled by the administrators. Once someone can ask for a 'redo' that rationale is lost entirely. The original list should be used. If any member is ineligible and is elected then this should be treated as if they were elected and then immediately disqualified. Furthermore it is really unacceptable to present this as a fait acompli with a new selection date already set. -Original Message- From: Richard Shockey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 30, 2006 9:31 PM To: 'IETF-Discussion' Subject: Now there seems to be lack of communicaiton here... This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. Second ...a complete explanation of why this go screwed up should have been posted to the community. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire
RE: Now there seems to be lack of communicaiton here...
I further agree with Phillip (and Richard) that this is not an IAB or even a Nomcom chair decision I disagree. The chair of a committee should have some freedom to decide what to do in cases not covered by the RFC. The decision he made (rerun the algorithm with correct input data) is a reasonable one by any standard. Let's just accept his decision and go on with our work. I second that! /L-E ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
-Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 3:29 AM To: [EMAIL PROTECTED] Cc: 'IETF-Discussion' Subject: Re: Now there seems to be lack of communicaiton here... Richard Shockey wrote: This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. This message is on its way to the ietf-announce list; that takes time with several thousand subscribers. That is the appropriate list, not this one. Brian what in the world are you thinking? Given that the issue involved here is the integrity of the NOMCOM process, it deserves no more notification than a posting on the announce list? Second ...a complete explanation of why this go screwed up should have been posted to the community. The message seems to give a complete explanation. Oversights happen. We are a volunteer community, and any of us can overlook something, any time. 'Seems' is a very mild word here. I do not believe there is any malice involved here only a severe lack of communication and consultation on an issue that essentially disqualifies the entire elector slate. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. Actually the custodian of the process is, as I read RFC 3777, the ISOC President. There is a formal dispute procedure defined in RFC 3777, but Andrew took remedial action before anyone invoked that. Since remedial action has been taken, I don't see an issue at this time. Well I do. The suggestion that the selection process be respun is IMHO very very serious and the incorrect solution here. Why respin the entire list when it would have been just as easy to select the next elector on the list? IMHO options here should have been made clear before the decision was ultimately made. I don't dispute the NOMCOM's right to make the decision only that on a matter of such gravity input come from the community at large. This entire event has been very badly handled Brian. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
Title: RE: Now there seems to be lack of communicaiton here... The entire process is predicated on their being no freedom of decision. The lack of any exception planning is due to the central conceit that no exceptions are possible. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Lars-Erik Jonsson (LU/EAB) [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 31, 2006 06:53 AM Pacific Standard Time To: Henk Uijterwaal; Michael StJohns; Hallam-Baker, Phillip; [EMAIL PROTECTED]; IETF-Discussion Subject: RE: Now there seems to be lack of communicaiton here... I further agree with Phillip (and Richard) that this is not an IAB or even a Nomcom chair decision I disagree. The chair of a committee should have some freedom to decide what to do in cases not covered by the RFC. The decision he made (rerun the algorithm with correct input data) is a reasonable one by any standard. Let's just accept his decision and go on with our work. I second that! /L-E ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Mike and Phill, Phill's assertion is wrong - the IAB and IESG has no control over this; such decisions are between the Nomcom Chair and the ISOC President. Unfortunately this makes things much worse, not better. Who's to say that Andrew didn't intentionally leave the IAB member on the list because doing so gave him two bites at the selection apple? He then rolled the dice, for whatever reason didn't like the outcome, called foul and reset the process. The odds are pretty good that whatever thing he didn't like won't be repeated on the second list. Of course I'm not saying that's what happened. Rather, I'm saying that I see no way to be sure that _isn't_ what happened. The goal of this process is not just to make it hard to game the system, but also for everyone to be completely confident the system has not been gamed. Allowing the same person that creates the list the authority to later reject that list and start over based on an imperfection that didn't lead to a bogus selection makes it impossible to have the necessary confidence in the process. The correct thing to do now is to reject the reest and stick with the original list. The only case where a reset should be allowed is if the process produced a bogus result. Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Well, I have to say I think you provided some extremely bad advice, and I sincerely hope that there isn't anyone on the first list that has an even slightly acrimonious public relationship with Andrew. We could be in very deep doo if there is. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
At 9:31 PM -0400 8/30/06, Richard Shockey wrote: Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. I think Richard is referring to this in Andrew's message: For these reasons, and after consultation with members of the IAB, IESG and ISOC, I have decided that to remove any doubt from the proceedings we must re-run the selection algorithm with new seed information. Speaking with my IESG hat on, the IESG as a whole was not consulted. The first I heard of this was late last night, post-decision, and I understand that the same is true of at least David, Lars, and Cullen. There was no discussion of this by the IESG prior to this decision having been taken. Whoever Andrew consulted may serve on the IESG, but the IESG was not brought in to discuss this and it had no role in making this decision. Speaking with my personal hat on, I am glad that the IESG was not consulted. Having the IESG have much influence on a decision like could be worrying in other contexts. I am sorry, however, that Andrew did not put the problem and his proposed course of action to the community for a comment period, so that the whole IETF community would know and could discuss that the issue had come up and what the resolution would be. Since this is the first time (to my knowledge, anyway) this has happened, I assume the next NomCom chair to have to face this will know that some folks prefer this type of decision to have a Last Call period. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
At 04:39 AM 8/31/2006, Eliot Lear wrote: Michael StJohns wrote: I agree with Phillip - there is no harm here. If someone ineligible had happened to be selected, they would have been immediately disqualified and the next number on the list selected. That's why you actually ask for about 16 numbers to be output when you run the program which outputs the selection numbers. There is no reason for a reset. (However, see my comments on volunteer associations). Mike, it's not often, but you and I disagree on this one. There were two problems. Don't forget that the list of volunteers was announced along with the selection process. And it's actually supposed to be announced 1 week prior to such process. Given the delay in getting the volunteer list vetted, he should have announced a delay in the selection PRIOR to the day of selection. He didn't. One of the reasons for announcing such list is to prevent issues similar to this. I fully accept Andrew Lange's explanation that a message got hung in the queue. Never-the-less, selection of our leadership should not be taken lightly. When the foul-up was discovered, the chair followed the procedure that was documented. What procedure and where is it documented? Please let's recognize that Mr. Lange has erred on the side of transparency. I applaud his choice. While I don't believe that Mr Lange is trying to game the system, nonetheless, it's inappropriate for him to void the result of the selection process for any reason other than the most egregious. E.g. because some volunteer wasn't included on the list of volunteers and should have been. The whole selection process is based on removing the possibility of outside interference and I'd say that voiding the selection is a pretty large outside interference. I can't read 3777 in any way that would allow this. Let me review the bidding. Andrew proposes to remove the ineligible volunteer and rerun the process. If the ineligible volunteer HAD been selected previously, the right answer would be to strike his name from the selectee list and use the 11th output of the random number dealer to select the replacement which is the process used if you get more than 2 people with the same affilitiation. Given that the ineligible volunteer was not selected, there's no reason to even do that. The random dealer is just that - random. The presence or absence of extraneous volunteers on the list does not change the probability of the selection of any given volunteer. Given that there is no reason to rerun the selection that I can see. I still want to see the affiliations of both the volunteers and the liasons as is required by 3777. Mike Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Hey Brian - what say - I am no longer the top poster eh? Todd - Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: Michael StJohns [EMAIL PROTECTED] Cc: 'IETF-Discussion' ietf@ietf.org; [EMAIL PROTECTED] Sent: Thursday, August 31, 2006 12:24 AM Subject: Re: Now there seems to be lack of communicaiton here... Mike, As it happens the liaisons were both chosen some time ago, by definition with no knowledge of the chosen volunteers. We are not going to change the rules on the fly, are we? Brian Michael StJohns wrote: One of the things missing from this years list of volunteers is their association. That's one of the inputs into the selection algorithm as the number of voting members from a particular association is limited to two. I'd ask that the Nomcom chair include this in the list of volunteers. Also, I note that last year there were actually 4 members (2 voting and 2 others) from one particular organization. I'd suggest that this year the liasons NOT be selected from any organization already represented by a voting member. Later, Mike At 09:31 PM 8/30/2006, Richard Shockey wrote: This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. Second ...a complete explanation of why this go screwed up should have been posted to the community. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire process of the IETF and NomCom. This resulted in the list being sent to the secretariat later than I would have liked, and the message then got hung up in the secretariat's queue. The selection is still deterministic, because the list ordering algorithm used (alpha by first name) is deterministic. However, since the list was published late, the appearance is not ideal. Second: A sitting member of the IAB's name appeared on the candidate list. According to 3777, section 15, sitting IAB, IESG and ISOC members are not eligible to serve on the Nomcom. This was an oversight on my part. Ordering in the list does matter for the selection process. Although this person was not selected to serve, and the harm done is minimal, it is important that the IETF follow our own processes as closely as possible. For these reasons, and after consultation with members of the IAB, IESG and ISOC, I have decided that to remove any doubt from the proceedings we must re-run the selection algorithm with new seed information. This is unfair to the people who volunteered for NomCom and are the backbone of the process. These people rightfully believed that they were or were not selected, and everyone selected was preparing to serve. To the volunteers: Thank you for volunteering, for your patience and understanding. I apologize for any inconvenience this reset may cause. In order to close this issue quickly, the same stocks and procedure will be used as last time, but the trading date will be drawn from the September 1, 2006 Wall Street Journal which reports the the sales figures from the previous trading day - August 31, 2006. The list we will use is the same as before, but with the IAB member's name removed. The list will be sent in a separate mail. Thank you. Andrew Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org
RE: Now there seems to be lack of communicaiton here...
Brian, The advice you gave is exactly the opposite of that in RFC 3797, the latest version of my non-binding guidelines for publicly verifiable random selection. Note in particular that Section 5.1 of that RFC says (with the all caps words in the original): 5.1. Uncertainty as to the Pool Every reasonable effort should be made to see that the published pool from which selection is made is of certain and eligible persons. However, especially with compressed schedules or perhaps someone whose claim that they volunteered and are eligible has not been resolved by the deadline, or a determination that someone is not eligible which occurs after the publication of the pool, it may be that there are still uncertainties. The best way to handle this is to maintain the announced schedule, INCLUDE in the published pool all those whose eligibility is uncertain and to keep the published pool list numbering IMMUTABLE after its publication. If someone in the pool is later selected by the algorithm and random input but it has been determined they are ineligible, they can be skipped and the algorithm run further to make an additional selection. Thus the uncertainty only effects one selection and in general no more than a maximum of U selections where there are U uncertain pool members. Other courses of action are far worse. Actual insertion or deletion of entries in the pool after its publication changes the length of the list and totally scrambles who is selected, possibly changing every selection. ... The presence of ineligible persons in the list is no reason whatsoever to reset. Donald -Original Message- From: Ned Freed [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 10:25 AM To: Brian E Carpenter Cc: [EMAIL PROTECTED]; IETF-Discussion; Michael StJohns Subject: Re: Now there seems to be lack of communicaiton here... ... The correct thing to do now is to reject the reest and stick with the original list. The only case where a reset should be allowed is if the process produced a bogus result. Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Well, I have to say I think you provided some extremely bad advice, and I sincerely hope that there isn't anyone on the first list that has an even slightly acrimonious public relationship with Andrew. We could be in very deep doo if there is. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
On Thursday, August 31, 2006 06:43:53 AM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: Furthermore the absence of a complaint makes things worse not better. Phill, I can assure you from personal knowledge that at least one complaint _was_ made. As Brian noted, Andrew took action to correct the issue before the formal dispute resolution process was invoked. And before you ask, no, I will not tell you who made the complaint, but I will say that I was not consulted on the issue of how to fix the problem, and that I don't believe the complaintant I know about was consulted either. Given the nature of the complaint (that a volunteer was ineligible), I believe there were two reasonable courses of action. One is to remove the name from the list before running the random process, and the other is to run the process with the name, but discard any selection of that name. If the error had been discovered before the random data became available, the first choice would have been the obvious one. However, it was not, and the situation is complicated by the fact that the list of volunteers did not become available in time for anyone to challenge eligibility prior to the random data becoming available. Even before the error in the list was discovered, I considered complaining about the timing issue and suggesting the remedy of running the process with new random data that would not become available before people had a chance to object (in other words, the same remedy that Andrew ended up applying). If you or anyone else feels that there is a problem, the correct course of action as described by RFC 3777 is to bring the issue to the nomcom chair and then, if the situation is not resolved to your satisfaction, take it to the ISOC President as a formal dispute. Nowhere does RFC 3777 suggest that a suitable remedy is to complain on a public mailing list that you were not personally consulted. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
I think this has already been said in this thread, but just to be very clear on one point: Andrew's message does read as if the IAB IESG were somehow consulted. They were not. Brian I were on the cc list of one complaint; we certainly agreed the situation needed addressing. No doubt that motivated Andrew's text. I will note, however, that the ultimate decision of whether, and certainly the choice of *how*, was up to Lynn and/or Andrew by a means of their own devising. Leslie. Richard Shockey wrote: This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. Second ...a complete explanation of why this go screwed up should have been posted to the community. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire process of the IETF and NomCom. This resulted in the list being sent to the secretariat later than I would have liked, and the message then got hung up in the secretariat's queue. The selection is still deterministic, because the list ordering algorithm used (alpha by first name) is deterministic. However, since the list was published late, the appearance is not ideal. Second: A sitting member of the IAB's name appeared on the candidate list. According to 3777, section 15, sitting IAB, IESG and ISOC members are not eligible to serve on the Nomcom. This was an oversight on my part. Ordering in the list does matter for the selection process. Although this person was not selected to serve, and the harm done is minimal, it is important that the IETF follow our own processes as closely as possible. For these reasons, and after consultation with members of the IAB, IESG and ISOC, I have decided that to remove any doubt from the proceedings we must re-run the selection algorithm with new seed information. This is unfair to the people who volunteered for NomCom and are the backbone of the process. These people rightfully believed that they were or were not selected, and everyone selected was preparing to serve. To the volunteers: Thank you for volunteering, for your patience and understanding. I apologize for any inconvenience this reset may cause. In order to close this issue quickly, the same stocks and procedure will be used as last time, but the trading date will be drawn from the September 1, 2006 Wall Street Journal which reports the the sales figures from the previous trading day - August 31, 2006. The list we will use is the same as before, but with the IAB member's name removed. The list will be sent in a separate mail. Thank you. Andrew Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Ned Freed wrote: The goal of this process is not just to make it hard to game the system, but also for everyone to be completely confident the system has not been gamed. Allowing the same person that creates the list the authority to later reject that list and start over based on an imperfection that didn't lead to a bogus selection makes it impossible to have the necessary confidence in the process. This strikes me as a key point about managing problems with this process (or maybe *any* IETF process.) A robust process has little or no dependence on the vagaries of one or a few people. The issue is not with the people but with the structure of the control mechanism. The correct thing to do now is to reject the reest and stick with the original list. The only case where a reset should be allowed is if the process produced a bogus result. It is entirely reasonable for there to have been concern that the pool of candidates for nomcom was polluted. However the presence of concern is not enough. Is there any empirical (statistical) basis for asserting that the presence of one ineligible member of the pool renders the entire selection process invalid? I suspect not. The pool was not small. So the sampling impact was not likely to be large. Small impact warrants small reaction. One, intuitive demonstration that the error did not have a systemic effect to the selection process was that the ineligible member of the pool was not chosen. Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Well, I have to say I think you provided some extremely bad advice, Again, the underlying problem with the effort to fix the problem was that that effort was made too fragile by involving too few people, for handling such an exceptional situation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
Granted 3777 does not require the consultation of the community on disputes involving the NOMCOM but given the highly unusual nature of the problem at hand and the tendency of the IETF toward anal retentive behavior in matters of process it seems reasonable to suggest that a wider set of views should have been solicited. I'm in complete agreement with Ned Freed here. Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Well, I have to say I think you provided some extremely bad advice, and I sincerely hope that there isn't anyone on the first list that has an even slightly acrimonious public relationship with Andrew. We could be in very deep doo if there is. And with Dave Crocker, Again, the underlying problem with the effort to fix the problem was that that effort was made too fragile by involving too few people, for handling such an exceptional situation. However I'm willing to suggest that the damage has been done and we should respect Andrew Lange's decision. I may disagree with the process by which Andrew made his decision but in the final analysis a decision had to be made and he did it. If the error had been discovered before the random data became available, the first choice would have been the obvious one. However, it was not, and the situation is complicated by the fact that the list of volunteers did not become available in time for anyone to challenge eligibility prior to the random data becoming available. Even before the error in the list was discovered, I considered complaining about the timing issue and suggesting the remedy of running the process with new random data that would not become available before people had a chance to object (in other words, the same remedy that Andrew ended up applying). If you or anyone else feels that there is a problem, the correct course of action as described by RFC 3777 is to bring the issue to the nomcom chair and then, if the situation is not resolved to your satisfaction, take it to the ISOC President as a formal dispute. Nowhere does RFC 3777 suggest that a suitable remedy is to complain on a public mailing list that you were not personally consulted. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
-- On Wednesday, August 30, 2006 9:31 PM -0400 Richard Shockey [EMAIL PROTECTED] wrote regarding Now there seems to be lack of communicaiton here... -- First .. the instant there was a problem the IETF community should have been notified in full on this list. Perhaps, in this particular case, but in general the NOMCOM operates under the veil of confidentiality. Historically that veil has covered most everything about the NOMCOM (in spite of the leakage), and I would not expect that to change any time soon. Personally I am not particularly fond of this aspect of our NOMCOM. I think the veil of confidentiality should be much more constrained but that has not been the community consensus over the years. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. Section 4 Nominating Committee Selection, Item 16 states: It must be possible to repeat the selection method, either through iteration or by restarting in such a way as to remain fair and unbiased. This is necessary to replace selected volunteers should they become unavailable after selection. The fact that Andrew chose to restart the process is within the rules. Also, since there is no enumeration of what become unavailable means, it would have been within the rules to simply iterate the selection process if an oversight or anomaly or even a challenge had been determined after the selection. Consulting with the IAB and IESG is not called out as an option in the document but neither is consulting with the IETF community. In fact, (speaking as Editor of the document) the rules lean towards the Chair simply conducting the selection process to the best of his or her ability, while keeping the community informed. No consultation necessary except where explicitly stated. The primary reason for this is that there is a schedule to keep. Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Hi, on 2006-08-31 17:33 Eastlake III Donald-LDE008 said the following: Brian, The advice you gave is exactly the opposite of that in RFC 3797, the latest version of my non-binding guidelines for publicly verifiable random selection. Note in particular that Section 5.1 of that RFC says (with the all caps words in the original): 5.1. Uncertainty as to the Pool Every reasonable effort should be made to see that the published pool from which selection is made is of certain and eligible persons. However, especially with compressed schedules or perhaps someone whose claim that they volunteered and are eligible has not been resolved by the deadline, or a determination that someone is not eligible which occurs after the publication of the pool, it may be that there are still uncertainties. The best way to handle this is to maintain the announced schedule, INCLUDE in the published pool all those whose eligibility is uncertain and to keep the published pool list numbering IMMUTABLE after its publication. If someone in the pool is later selected by the algorithm and random input but it has been determined they are ineligible, they can be skipped and the algorithm run further to make an additional selection. Thus the uncertainty only effects one selection and in general no more than a maximum of U selections where there are U uncertain pool members. Other courses of action are far worse. Actual insertion or deletion of entries in the pool after its publication changes the length of the list and totally scrambles who is selected, possibly changing every selection. ... The presence of ineligible persons in the list is no reason whatsoever to reset. I think this is well reasoned by Donald. Permitting a reset opens the door on the possibility for a NomCom chair to include ineligible persons, and subsequently, if he doesn't like the result, declare a reset and re-do the selection. We avoid this by keeping to the original numbered and published pool of people, permitting one single run of the random number generation mechanism, and then use that to select members from the original numbered published pool (rejecting ineligible choices) until the desired number of eligible NomCom members have been chosen. (And to be clear, I don't mean that there is *any* foul play in the current situation, just that we don't want a process which opens the door on that possibility.) Regards, Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
James I also agree with Donald's logic - So then what happens when the selection process is restarted and the ramdomizer is used again - say the second time it selects six of the same candidates and the rest are different out of a pool of 20 or 30 probably. How is that fair to those selected in the original pick who now loses their potential seat to the process. Todd Glassey - Original Message - From: James Galvin [EMAIL PROTECTED] To: 'IETF-Discussion' ietf@ietf.org Sent: Thursday, August 31, 2006 6:41 AM Subject: Re: Now there seems to be lack of communicaiton here... -- On Wednesday, August 30, 2006 9:31 PM -0400 Richard Shockey [EMAIL PROTECTED] wrote regarding Now there seems to be lack of communicaiton here... -- First .. the instant there was a problem the IETF community should have been notified in full on this list. Perhaps, in this particular case, but in general the NOMCOM operates under the veil of confidentiality. Historically that veil has covered most everything about the NOMCOM (in spite of the leakage), and I would not expect that to change any time soon. Personally I am not particularly fond of this aspect of our NOMCOM. I think the veil of confidentiality should be much more constrained but that has not been the community consensus over the years. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. Section 4 Nominating Committee Selection, Item 16 states: It must be possible to repeat the selection method, either through iteration or by restarting in such a way as to remain fair and unbiased. This is necessary to replace selected volunteers should they become unavailable after selection. The fact that Andrew chose to restart the process is within the rules. Also, since there is no enumeration of what become unavailable means, it would have been within the rules to simply iterate the selection process if an oversight or anomaly or even a challenge had been determined after the selection. Consulting with the IAB and IESG is not called out as an option in the document but neither is consulting with the IETF community. In fact, (speaking as Editor of the document) the rules lean towards the Chair simply conducting the selection process to the best of his or her ability, while keeping the community informed. No consultation necessary except where explicitly stated. The primary reason for this is that there is a schedule to keep. Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
James Galvin wrote: First .. the instant there was a problem the IETF community should have been notified in full on this list. Perhaps, in this particular case, but in general the NOMCOM operates under the veil of confidentiality. Specifically, the process of selecting the nomcom does *not*. Historically that veil has covered most everything about the NOMCOM (in spite of the leakage), and I would not expect that to change any time soon. The process of selecting the nomcom has been fully public for a very long time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
-- On Thursday, August 31, 2006 10:46 AM -0700 Dave Crocker [EMAIL PROTECTED] wrote regarding Re: Now there seems to be lack of communicaiton here... -- James Galvin wrote: First .. the instant there was a problem the IETF community should have been notified in full on this list. Perhaps, in this particular case, but in general the NOMCOM operates under the veil of confidentiality. Specifically, the process of selecting the nomcom does *not*. Historically that veil has covered most everything about the NOMCOM (in spite of the leakage), and I would not expect that to change any time soon. The process of selecting the nomcom has been fully public for a very long time. Most of the random selection process has been public for a long time, because of the requirement for it to be verifiable by third parties. This just means that enough of it is public to ensure it can be verified. But there is a part of the process that is not public: the actual selection of eligible volunteers. I have not been party to any discussions of this issue outside this list, but as I understand it the issue(s) that surfaced was(were) related to that part of the process. Personally, I think that restarting the process was overkill, but then it depends on how you judge fair and unbiased, which is the principal requirement in RFC3777. We are dependent on the Chair to do the right thing. The document says that in so many words. So, as editor of the document, I just want to point out that I believe that what transpired was allowed under the rules. If we, as a community, don't like what transpired, then we need to change the rules. Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
James Galvin wrote: But there is a part of the process that is not public: the actual selection of eligible volunteers. 1) The criteria are public. 2) The result is public, with the intention of time for review. I'm not sure how the internals of going from 1 to 2 could be made public and still function. Since the criteria are reasonably objective, I'm having trouble seeing how transparency on the decision process is meaningful. So, as editor of the document, I just want to point out that I believe that what transpired was allowed under the rules. If we, as a community, don't like what transpired, then we need to change the rules. At base, I suspect this demonstrates the problem with our being too rule-oriented, and not enough community oriented. It loses sight of the underpinnings of comfort and legitimacy, and that is community review and approval when a situation does -- or reasonably might -- entail the unknown or, at least, controversy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
First I should say that being chair of Nomcom when an innocent mistake like this happens must be a nightmare with every possible action being subject to criticism. Andrew therefore has a completely thankless task in resolving this, and I will support what ever he decides to do. I cannot see how the presence of the an ineligible candidate that was not selected biased* the results, and I think that the result should have stood - indeed RFC3777 seems to say that it should stand. I am however concerned that the re-run decision, and now the decision about whether we continue with the re-run or not, opens the door to human intervention in a way that the RFC was supposed to design out. Given where we are, perhaps the way forward is to throw a two sided dice - using our usual method. If the answer is 0 we continue with the previous - valid selection - if the answer is 1 we rerun the selection. That way no human can determine the outcome of this ongoing selection process. - Stewart * Yes - it changed the result - but the important thing is that it will not have biased it because of the random nature of the selection from the pool. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
-- On Thursday, August 31, 2006 10:40 AM -0700 todd glassey [EMAIL PROTECTED] wrote regarding Re: Now there seems to be lack of communicaiton here... -- James I also agree with Donald's logic - So then what happens when the selection process is restarted and the ramdomizer is used again - say the second time it selects six of the same candidates and the rest are different out of a pool of 20 or 30 probably. How is that fair to those selected in the original pick who now loses their potential seat to the process. I'll only say that RFC3777 defines what it means by fair and unbiased, and I believe that what transpired was within that definition. Specifically, a process is fair if any eligible volunteer is equally likely to be selected. Even a restart is allowed by the rules. Now, was a restart the best choice given the issue at hand? Personally I think there were other good choices that would have served the purpose. Even so, it is the Chair's job to make that decision and he obviously saw the situation differently. Do I want to change the rules to prevent a restart in the future? Not just yet, but I'm following the discussion and perhaps I'll change my mind. Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
A restart that selected other candidates would not be unbiased. Todd Glassey - Original Message - From: James Galvin [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED] Cc: 'IETF-Discussion' ietf@ietf.org Sent: Thursday, August 31, 2006 11:13 AM Subject: Re: Now there seems to be lack of communicaiton here... -- On Thursday, August 31, 2006 10:40 AM -0700 todd glassey [EMAIL PROTECTED] wrote regarding Re: Now there seems to be lack of communicaiton here... -- James I also agree with Donald's logic - So then what happens when the selection process is restarted and the ramdomizer is used again - say the second time it selects six of the same candidates and the rest are different out of a pool of 20 or 30 probably. How is that fair to those selected in the original pick who now loses their potential seat to the process. I'll only say that RFC3777 defines what it means by fair and unbiased, and I believe that what transpired was within that definition. Specifically, a process is fair if any eligible volunteer is equally likely to be selected. Even a restart is allowed by the rules. Now, was a restart the best choice given the issue at hand? Personally I think there were other good choices that would have served the purpose. Even so, it is the Chair's job to make that decision and he obviously saw the situation differently. Do I want to change the rules to prevent a restart in the future? Not just yet, but I'm following the discussion and perhaps I'll change my mind. Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Don, I'll reiterate what I said earlier, since it seems to be missed by many people. The presence of an IAB member on the list, while an issue, is not my overwhelming concern. My overwhelming concern is the fact that the volunteer list came out at the same time as the results. That could allow for funny business, by the NOMCOM chair choosing the algorithm by which people are ordered. I am by no means claiming that was done here, and I fully accept Andrew Lange's explanation, but I believe transparency demands redress in this circumstance, and the the best redress I could envision is rerunning the algorithm. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Hi - From: Henrik Levkowetz [EMAIL PROTECTED] To: Eastlake III Donald-LDE008 [EMAIL PROTECTED] Cc: IETF-Discussion ietf@ietf.org Sent: Thursday, August 31, 2006 10:20 AM Subject: Re: Now there seems to be lack of communicaiton here... Hi, on 2006-08-31 17:33 Eastlake III Donald-LDE008 said the following: Brian, The advice you gave is exactly the opposite of that in RFC 3797, the latest version of my non-binding guidelines for publicly verifiable random selection. Note in particular that Section 5.1 of that RFC says (with the all caps words in the original): 5.1. Uncertainty as to the Pool Every reasonable effort should be made to see that the published pool from which selection is made is of certain and eligible persons. However, especially with compressed schedules or perhaps someone whose claim that they volunteered and are eligible has not been resolved by the deadline, or a determination that someone is not eligible which occurs after the publication of the pool, it may be that there are still uncertainties. The best way to handle this is to maintain the announced schedule, INCLUDE in the published pool all those whose eligibility is uncertain and to keep the published pool list numbering IMMUTABLE after its publication. If someone in the pool is later selected by the algorithm and random input but it has been determined they are ineligible, they can be skipped and the algorithm run further to make an additional selection. Thus the uncertainty only effects one selection and in general no more than a maximum of U selections where there are U uncertain pool members. Other courses of action are far worse. Actual insertion or deletion of entries in the pool after its publication changes the length of the list and totally scrambles who is selected, possibly changing every selection. ... The presence of ineligible persons in the list is no reason whatsoever to reset. I think this is well reasoned by Donald. Permitting a reset opens the door on the possibility for a NomCom chair to include ineligible persons, and subsequently, if he doesn't like the result, declare a reset and re-do the selection. We avoid this by keeping to the original numbered and published pool of people, permitting one single run of the random number generation mechanism, and then use that to select members from the original numbered published pool (rejecting ineligible choices) until the desired number of eligible NomCom members have been chosen. (And to be clear, I don't mean that there is *any* foul play in the current situation, just that we don't want a process which opens the door on that possibility.) ... Though I hate to add to this tea-pot tempest, I also agree with Donald's reasoning that a reset is not justified in this case. Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
My two cents: If I were to go to Las Vegas and roll the dice at a crap table, then ask to roll again because there was a clap of thunder which made my arm twitch just as I released the dice during the first roll, I assure you that they would not allow me to do so. They would not be persuaded by an argument that the second roll would have the exact same set of probabilities of outcomes as the first, or indeed as any other roll. And their decision would have nothing to do with the actual result of the first roll (i.e. it would not matter if I won or lost money, on that roll). Here we have a similar situation. We have a randomized process which at worst, was affected by a name on the list that should not have been there. While the presence of that name did affect the outcome, like the clap of thunder, it did not do so in any predictable way, and so the random (unbiased) nature of that outcome is preserved. Resetting and re-running the process is not an appropriate response. Doing so inserts human intervention (read, bias) into an otherwise unbiased process. So also, by the way, would a let's decide what to do based on a coin flip solution. That would be rather like me trying to convince the casino to do a coin flip to see if I should be allowed to roll the dice again. Any solution, other than accepting the results as they originally were generated, will be biased. In my opinion we should not rerun the process. Rerunning the process is the exact wrong thing to do. The decision to do so was no doubt made in good faith, and with the best of intentions, but it is clearly incorrect. -Matt -Original Message- From: James Galvin [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 2:13 PM To: todd glassey Cc: 'IETF-Discussion' Subject: Re: Now there seems to be lack of communicaiton here... -- On Thursday, August 31, 2006 10:40 AM -0700 todd glassey [EMAIL PROTECTED] wrote regarding Re: Now there seems to be lack of communicaiton here... -- James I also agree with Donald's logic - So then what happens when the selection process is restarted and the ramdomizer is used again - say the second time it selects six of the same candidates and the rest are different out of a pool of 20 or 30 probably. How is that fair to those selected in the original pick who now loses their potential seat to the process. I'll only say that RFC3777 defines what it means by fair and unbiased, and I believe that what transpired was within that definition. Specifically, a process is fair if any eligible volunteer is equally likely to be selected. Even a restart is allowed by the rules. Now, was a restart the best choice given the issue at hand? Personally I think there were other good choices that would have served the purpose. Even so, it is the Chair's job to make that decision and he obviously saw the situation differently. Do I want to change the rules to prevent a restart in the future? Not just yet, but I'm following the discussion and perhaps I'll change my mind. Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
If the main problem is that the Secretariat can't do its vetting job in time, for whatever reason, to allow the volunteer list to be publicly posted for a reasonable before selection takes place, there seem to be approximately three things you could do: A. Leave as much as you can of the selection algorithm in place but change the date of selection to later to give the Secretariat more time and/or give time for public posting before selection. B. Run the selection as scheduled and put out the volunteer list and selection at the same time. C. Do B but then run yet another selection. Seems to me clear that A is superior and C is inferior and if I revise RFC 3797 I'll put in something about this case. Donald -Original Message- From: Eliot Lear [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 2:24 PM To: Eastlake III Donald-LDE008 Cc: IETF-Discussion Subject: Re: Now there seems to be lack of communicaiton here... Don, I'll reiterate what I said earlier, since it seems to be missed by many people. The presence of an IAB member on the list, while an issue, is not my overwhelming concern. My overwhelming concern is the fact that the volunteer list came out at the same time as the results. That could allow for funny business, by the NOMCOM chair choosing the algorithm by which people are ordered. I am by no means claiming that was done here, and I fully accept Andrew Lange's explanation, but I believe transparency demands redress in this circumstance, and the the best redress I could envision is rerunning the algorithm. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
To address Eliot's comment about the volunteer list - From Andrew's note that triggered all of this I see that he sent the list of the volunteers to the Secretariat. If we could have someone from the Secretariat provide a copy of that email independent of Andrew and verify it was submitted to them prior to the selection date that should resolve Eliot's issue. Eliot? At 02:23 PM 8/31/2006, Eliot Lear wrote: Don, My overwhelming concern is the fact that the volunteer list came out at the same time as the results. That could allow for funny business, by the NOMCOM chair choosing the algorithm by which people are ordered. The list was ordered in the same manner as previous years I believe? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
Yup. More specifically, A has to happen before close of trading on the day you're getting your random numbers from. Unless I'm mistaken, I'm reading an overwhelming consensus NOT to reset from those posting on this list. Given that close of trading for Andrew's reset is today we're about to get ourselves in very big trouble. Andrew - I'd like to ask that you reverse yourself, or at least delay your second selection until at least next week. I know you need to get the Nomcom up and running, but you need to consider the community feeling on this without being trapped into a misstep by a too-early deadline. At 03:01 PM 8/31/2006, Eastlake III Donald-LDE008 wrote: If the main problem is that the Secretariat can't do its vetting job in time, for whatever reason, to allow the volunteer list to be publicly posted for a reasonable before selection takes place, there seem to be approximately three things you could do: A. Leave as much as you can of the selection algorithm in place but change the date of selection to later to give the Secretariat more time and/or give time for public posting before selection. B. Run the selection as scheduled and put out the volunteer list and selection at the same time. C. Do B but then run yet another selection. Seems to me clear that A is superior and C is inferior and if I revise RFC 3797 I'll put in something about this case. Donald -Original Message- From: Eliot Lear [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 2:24 PM To: Eastlake III Donald-LDE008 Cc: IETF-Discussion Subject: Re: Now there seems to be lack of communicaiton here... Don, I'll reiterate what I said earlier, since it seems to be missed by many people. The presence of an IAB member on the list, while an issue, is not my overwhelming concern. My overwhelming concern is the fact that the volunteer list came out at the same time as the results. That could allow for funny business, by the NOMCOM chair choosing the algorithm by which people are ordered. I am by no means claiming that was done here, and I fully accept Andrew Lange's explanation, but I believe transparency demands redress in this circumstance, and the the best redress I could envision is rerunning the algorithm. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Mike, To address Eliot's comment about the volunteer list - From Andrew's note that triggered all of this I see that he sent the list of the volunteers to the Secretariat. If we could have someone from the Secretariat provide a copy of that email independent of Andrew and verify it was submitted to them prior to the selection date that should resolve Eliot's issue. Eliot? Yes, that would have resolved my issue nicely. But I am equally satisfied with rerunning the selection algorithm. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
--On Thursday, 31 August, 2006 09:38 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Brian, I don't know about others, but I'd like to hear a little more about your reasoning (and Andrew's) about this. It seems to me that drawing a second sample would be unbiased if the decision to draw it were made before anyone knew the contents of the first sample. But, as soon as someone looks at the first sample and then has discretion as to whether to say never mind and draw another one, there is bias in the statistical sense. That bias may or may not be harmful, or have the appearance of being harmful, but it definitely removes the rigid randomization of a method that doesn't allow any latitude or individual choice in the selection of a candidate pool. To illustrate this, suppose that one initially drew two membership pools from the list of volunteers. Now examine the following cases: (i) Someone looks at the contents of both pools, decides which one is preferred, and picks that one. (ii) Someone decides to look at one of the two pools and then decide whether to accept it or to select the other pool. (iii) The second pool is drawn after some or all the members of the first pool are withdrawn from the initial volunteer list, with the mechanism for selecting those who are withdrawn being exogenous to the process and presumably deterministic. There are rather complex, and quite intriguing, models in statistical decision theory for examining each of these types of cases. But none of them involve unbiased with regard to the randomness of the selection process. john p.s. I deliberately haven't looked at the volunteer lists to determine who the relevant IAB member was, making the comment I'm about to make unbiased by that knowledge. But I believe that an IAB member who is sufficiently unfamiliar with our procedures to have volunteered to the nomcom should be seriously considering stepping down (which would not make him or her nomcom-eligible, of course). I also believe that this micro-debacle suggests that future revisions of the nomcom selection document should be explicit about two cases: (1) Sorting the nomcom volunteer pool into alphabetical order and then assigning numbers that will, in turn, be used in the determination of who gets selected is not appropriate. The sequencing of the volunteer pool should probably use a randomization process that is demonstrably independent of the randomization process that selects nomcom members from that list. (2) Just as the rules that link the date of resignation from a nomcom-selected position with rules about filling the resigned position (e.g., with regard to duration of terms) need clarification in some way that can be reviewed by the community via Last Call, we probably need absolute clarity about the relationship between the date of resignation and eligibility to serve on a Nomcom, initiate recalls, etc. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
On Thursday, August 31, 2006 09:26:11 AM -0700 Dave Crocker [EMAIL PROTECTED] wrote: Ned Freed wrote: The goal of this process is not just to make it hard to game the system, but also for everyone to be completely confident the system has not been gamed. Allowing the same person that creates the list the authority to later reject that list and start over based on an imperfection that didn't lead to a bogus selection makes it impossible to have the necessary confidence in the process. This strikes me as a key point about managing problems with this process (or maybe *any* IETF process.) A robust process has little or no dependence on the vagaries of one or a few people. The issue is not with the people but with the structure of the control mechanism. I agree with Ned here that an important design feature of this process is that it is easy to verify that the process was carried out correctly and that its results were not tampered with. I also agree with Dave that any failing in the present instance is in the process which allowed a situation to develop in which the results could be tampered with, and not with Andrew Lange's handling of that situation. I don't think anyone believes there was foul play here, but the problem is that a situation arose in which someone had to decide how to proceed, and that decision had predictable results. Worse, it is trivially easy for a future nomcom chair to recreate that situation, and it may be possible even for some other person to do so. I've reviewed the specification for this process, including the random selection algorithm, several times over the past few years. I've always believed the selection process was reasonably well-designed to meet its goals, and I certainly didn't predict the present situation. However, now that it's been raised, it seems reasonable to fix it _for the future_. Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good. (2) Text is added to the next version of the selection process to addresss this issue. I would suggest a strengthening of the existing language about leaving questionable candidates in the list and rejecting them in a later pass. In fact, it might be wiser to require the use of the original list of volunteers as given to the secretariat and _always_ rejecting ineligible candidates in a later pass. This would remove any need to insure that errors or disputes about eligibility be resolved before the random data becomes available. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
John, If the selection method is random, it makes no difference whatsoever how the list of nomcom volunteers is ordered. It only matters that the numbered list become fixed and be posted before the selection information is available. Alphabetic or the order they volunteered or any other order is perfectly fine. Donald -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 4:54 PM To: Brian E Carpenter Cc: IETF-Discussion Subject: Re: Now there seems to be lack of communicaiton here... ... (1) Sorting the nomcom volunteer pool into alphabetical order and then assigning numbers that will, in turn, be used in the determination of who gets selected is not appropriate. The sequencing of the volunteer pool should probably use a randomization process that is demonstrably independent of the randomization process that selects nomcom members from that list. ... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
My concerns are pretty much the same as John's here except that I care less about the outcome of this round than the precedent that would be set. The statement 'this is not a precedent' does not make it any less of a precedent. If you have a problem in a normal election process then a re-vote is usually the right course of action. That is not the case for this particular process. The process depends entirely on there being no degree of freedom on the part of the RO. I would like to see a process that specifies the exception process, and no recourse to the chair does not count. In particular the process only works if there is a period between the publication of the list and the random selection. -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 4:54 PM To: Brian E Carpenter Cc: IETF-Discussion Subject: Re: Now there seems to be lack of communicaiton here... --On Thursday, 31 August, 2006 09:38 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Brian, I don't know about others, but I'd like to hear a little more about your reasoning (and Andrew's) about this. It seems to me that drawing a second sample would be unbiased if the decision to draw it were made before anyone knew the contents of the first sample. But, as soon as someone looks at the first sample and then has discretion as to whether to say never mind and draw another one, there is bias in the statistical sense. That bias may or may not be harmful, or have the appearance of being harmful, but it definitely removes the rigid randomization of a method that doesn't allow any latitude or individual choice in the selection of a candidate pool. To illustrate this, suppose that one initially drew two membership pools from the list of volunteers. Now examine the following cases: (i) Someone looks at the contents of both pools, decides which one is preferred, and picks that one. (ii) Someone decides to look at one of the two pools and then decide whether to accept it or to select the other pool. (iii) The second pool is drawn after some or all the members of the first pool are withdrawn from the initial volunteer list, with the mechanism for selecting those who are withdrawn being exogenous to the process and presumably deterministic. There are rather complex, and quite intriguing, models in statistical decision theory for examining each of these types of cases. But none of them involve unbiased with regard to the randomness of the selection process. john p.s. I deliberately haven't looked at the volunteer lists to determine who the relevant IAB member was, making the comment I'm about to make unbiased by that knowledge. But I believe that an IAB member who is sufficiently unfamiliar with our procedures to have volunteered to the nomcom should be seriously considering stepping down (which would not make him or her nomcom-eligible, of course). I also believe that this micro-debacle suggests that future revisions of the nomcom selection document should be explicit about two cases: (1) Sorting the nomcom volunteer pool into alphabetical order and then assigning numbers that will, in turn, be used in the determination of who gets selected is not appropriate. The sequencing of the volunteer pool should probably use a randomization process that is demonstrably independent of the randomization process that selects nomcom members from that list. (2) Just as the rules that link the date of resignation from a nomcom-selected position with rules about filling the resigned position (e.g., with regard to duration of terms) need clarification in some way that can be reviewed by the community via Last Call, we probably need absolute clarity about the relationship between the date of resignation and eligibility to serve on a Nomcom, initiate recalls, etc. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
On 8/31/06 at 9:38 AM +0200, Brian E Carpenter wrote: Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Brian, the fact that Andrew Cc'ed you on the issue was (IMO) not a good idea in the first place, but given that your position is one of those being selected, the fact that you expressed an opinion at all was phenomenally irresponsible. Now, in addition to questions about Andrew's motivations for doing the reset (the theoretical Did he want a 'do-over' because he didn't like the outcome?), we also have to contend with whether *you* influenced the process deliberately because *you* didn't like the outcome. Unbelievably ill-advised on your part. I will refrain from giving my opinion on what Andrew should do at this point. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Elliot - What about those that may not be in the selection pool this time around - how fair would that be to them? Todd Glassey - Original Message - From: Eliot Lear [EMAIL PROTECTED] To: Michael StJohns [EMAIL PROTECTED] Cc: IETF-Discussion ietf@ietf.org Sent: Thursday, August 31, 2006 1:22 PM Subject: Re: Now there seems to be lack of communicaiton here... Mike, To address Eliot's comment about the volunteer list - From Andrew's note that triggered all of this I see that he sent the list of the volunteers to the Secretariat. If we could have someone from the Secretariat provide a copy of that email independent of Andrew and verify it was submitted to them prior to the selection date that should resolve Eliot's issue. Eliot? Yes, that would have resolved my issue nicely. But I am equally satisfied with rerunning the selection algorithm. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
The problem is demonstrative of the real issues with the IETF's processes and that they are designed by people who particularly don't plan for contingency - its a true testament to the Arrogance of the Technical Mind in screaming loudly all the way to the Gallows that it mailed the check. The point is not one of finding workarounds its one of designing the contingencies into the process so that it remains fair and open and DOES NOT leave way or cause for arbitrary actions by any of the administration. Clearly the processes and 3777 need to be amended to deal with this process-occurrence so that it doesn't happen again. And bluntly I don't think there is any cause or precedent for the Chair to overturn process put in place by the WG's unless you folks want to get into arguments about the Chair acting as a Dictator... Todd - Original Message - From: Eastlake III Donald-LDE008 [EMAIL PROTECTED] To: Eliot Lear [EMAIL PROTECTED] Cc: IETF-Discussion ietf@ietf.org Sent: Thursday, August 31, 2006 12:01 PM Subject: RE: Now there seems to be lack of communicaiton here... If the main problem is that the Secretariat can't do its vetting job in time, for whatever reason, to allow the volunteer list to be publicly posted for a reasonable before selection takes place, there seem to be approximately three things you could do: TSG: NO - ANYTHING THAT THE SECRETARIATE WAS TO DO WOULD REQUIRE A FORMAL AMENDMENT TO THE 3777 OR OTHER DOCUMENTS TEXT AND ITS APPROVAL THROUGH THE IESG ETC. - THE FAILINGS OF ONE DOCUMENT'S PROCESS FOR THE CURRENT ISSUES DO NOT SET ASIDE THE LARGER ISSUES OF PROCESS. A. Leave as much as you can of the selection algorithm in place but change the date of selection to later to give the Secretariat more time and/or give time for public posting before selection. B. Run the selection as scheduled and put out the volunteer list and selection at the same time. C. Do B but then run yet another selection. Seems to me clear that A is superior and C is inferior and if I revise RFC 3797 I'll put in something about this case. Donald -Original Message- From: Eliot Lear [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 2:24 PM To: Eastlake III Donald-LDE008 Cc: IETF-Discussion Subject: Re: Now there seems to be lack of communicaiton here... Don, I'll reiterate what I said earlier, since it seems to be missed by many people. The presence of an IAB member on the list, while an issue, is not my overwhelming concern. My overwhelming concern is the fact that the volunteer list came out at the same time as the results. That could allow for funny business, by the NOMCOM chair choosing the algorithm by which people are ordered. I am by no means claiming that was done here, and I fully accept Andrew Lange's explanation, but I believe transparency demands redress in this circumstance, and the the best redress I could envision is rerunning the algorithm. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Phillip congrats - re-votes are dependant on a fully defined election process with oversight and proper what-if contingencies that are pre-planned and not fixed in an ad-hoc manner. - Original Message - From: Hallam-Baker, Phillip [EMAIL PROTECTED] To: John C Klensin [EMAIL PROTECTED]; Brian E Carpenter [EMAIL PROTECTED] Cc: IETF-Discussion Sent: Thursday, August 31, 2006 2:59 PM Subject: RE: Now there seems to be lack of communicaiton here... My concerns are pretty much the same as John's here except that I care less about the outcome of this round than the precedent that would be set. The statement 'this is not a precedent' does not make it any less of a precedent. If you have a problem in a normal election process then a re-vote is usually the right course of action. That is not the case for this particular process. The process depends entirely on there being no degree of freedom on the part of the RO. I would like to see a process that specifies the exception process, and no recourse to the chair does not count. In particular the process only works if there is a period between the publication of the list and the random selection. -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 4:54 PM To: Brian E Carpenter Cc: IETF-Discussion Subject: Re: Now there seems to be lack of communicaiton here... --On Thursday, 31 August, 2006 09:38 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Brian, I don't know about others, but I'd like to hear a little more about your reasoning (and Andrew's) about this. It seems to me that drawing a second sample would be unbiased if the decision to draw it were made before anyone knew the contents of the first sample. But, as soon as someone looks at the first sample and then has discretion as to whether to say never mind and draw another one, there is bias in the statistical sense. That bias may or may not be harmful, or have the appearance of being harmful, but it definitely removes the rigid randomization of a method that doesn't allow any latitude or individual choice in the selection of a candidate pool. To illustrate this, suppose that one initially drew two membership pools from the list of volunteers. Now examine the following cases: (i) Someone looks at the contents of both pools, decides which one is preferred, and picks that one. (ii) Someone decides to look at one of the two pools and then decide whether to accept it or to select the other pool. (iii) The second pool is drawn after some or all the members of the first pool are withdrawn from the initial volunteer list, with the mechanism for selecting those who are withdrawn being exogenous to the process and presumably deterministic. There are rather complex, and quite intriguing, models in statistical decision theory for examining each of these types of cases. But none of them involve unbiased with regard to the randomness of the selection process. john p.s. I deliberately haven't looked at the volunteer lists to determine who the relevant IAB member was, making the comment I'm about to make unbiased by that knowledge. But I believe that an IAB member who is sufficiently unfamiliar with our procedures to have volunteered to the nomcom should be seriously considering stepping down (which would not make him or her nomcom-eligible, of course). I also believe that this micro-debacle suggests that future revisions of the nomcom selection document should be explicit about two cases: (1) Sorting the nomcom volunteer pool into alphabetical order and then assigning numbers that will, in turn, be used in the determination of who gets selected is not appropriate. The sequencing of the volunteer pool should probably use a randomization process that is demonstrably independent of the randomization process that selects nomcom members from that list. (2) Just as the rules that link the date of resignation from a nomcom-selected position with rules about filling the resigned position (e.g., with regard to duration of terms) need clarification in some way that can be reviewed by the community via Last Call, we probably need absolute clarity about the relationship between the date of resignation and eligibility to serve on a Nomcom, initiate recalls, etc. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
At 20:38 31/08/2006, Cimbala, Matthew wrote: In my opinion we should not rerun the process.Rerunning the process is the exact wrong thing to do.The decision to do so was no doubt made in good faith, and with the best of intentions, but it is clearly incorrect. +1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
On Thu, Aug 31, 2006 at 05:55:25PM -0400, Jeffrey Hutzelman wrote: Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good. (2) Text is added to the next version of the selection process to addresss this issue. I would suggest a strengthening of the existing language about leaving questionable candidates in the list and rejecting them in a later pass. In fact, it might be wiser to require the use of the original list of volunteers as given to the secretariat and _always_ rejecting ineligible candidates in a later pass. This would remove any need to insure that errors or disputes about eligibility be resolved before the random data becomes available. I think Jeff proposal makes a lot of sense and is probably the best way to move forward given the current circumstances. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
I agree that this seems to be the best course available. Yours, Joel M. Halpern At 09:08 PM 8/31/2006, Theodore Tso wrote: On Thu, Aug 31, 2006 at 05:55:25PM -0400, Jeffrey Hutzelman wrote: Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good. (2) Text is added to the next version of the selection process to addresss this issue. I would suggest a strengthening of the existing language about leaving questionable candidates in the list and rejecting them in a later pass. In fact, it might be wiser to require the use of the original list of volunteers as given to the secretariat and _always_ rejecting ineligible candidates in a later pass. This would remove any need to insure that errors or disputes about eligibility be resolved before the random data becomes available. I think Jeff proposal makes a lot of sense and is probably the best way to move forward given the current circumstances. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
(1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. we have not heard from Andrew since this discussion began - maybe he is off the net - lets not make any assumptions on what he has decided to do until he tells us my preference is to take note of the text in RFC 3797 pointed to by Donald and keep the already selected nomcom but it would not be the end of the world if Andrew decides to respin the selection in any case, this event does indicate that fixing RFC 3777 to follow the guidance in RFC 3797 is needed Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
I agree as well. Again, having started this charming little discussion thread, any other course of action at this late stage would cause more problems than it would solve. R. Shockey -Original Message- From: Joel M. Halpern [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 9:40 PM To: IETF-Discussion Subject: Re: Now there seems to be lack of communicaiton here... I agree that this seems to be the best course available. Yours, Joel M. Halpern At 09:08 PM 8/31/2006, Theodore Tso wrote: On Thu, Aug 31, 2006 at 05:55:25PM -0400, Jeffrey Hutzelman wrote: Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good. (2) Text is added to the next version of the selection process to addresss this issue. I would suggest a strengthening of the existing language about leaving questionable candidates in the list and rejecting them in a later pass. In fact, it might be wiser to require the use of the original list of volunteers as given to the secretariat and always rejecting ineligible candidates in a later pass. This would remove any need to insure that errors or disputes about eligibility beresolved before the random data becomes available. I think Jeff proposal makes a lot of sense and is probably the best way to move forward given the current circumstances. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available ... (2) Text is added to the next version of the selection process to addresss No one has expressed a concern that there was an attempt, here, to game the process, or that re-doing selection will actually produce a problematic nomcom membership. So either retaining the original list or re-doing the selections results in an acceptable set of nomcom members. The wastefulness and disruption of unnecessarily re-doing selection is unfortunate, but hardly fatal. Creating better text for the future is certainly a good idea. And, yes, this is a long-winded version of: +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
PS - I do think its fully in Andrew's remit to make this decisison and I do not think it would be good for the IETF for anyone to appeal his decision Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
As someone who was actually selected in the previous round and started this little thread, I support this position. I've reviewed the specification for this process, including the random selection algorithm, several times over the past few years. I've always believed the selection process was reasonably well-designed to meet its goals, and I certainly didn't predict the present situation. However, now that it's been raised, it seems reasonable to fix it _for the future_. Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good. (2) Text is added to the next version of the selection process to addresss this issue. I would suggest a strengthening of the existing language about leaving questionable candidates in the list and rejecting them in a later pass. In fact, it might be wiser to require the use of the original list of volunteers as given to the secretariat and _always_ rejecting ineligible candidates in a later pass. This would remove any need to insure that errors or disputes about eligibility be resolved before the random data becomes available. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Now there seems to be lack of communicaiton here...
One of the things missing from this years list of volunteers is their association. That's one of the inputs into the selection algorithm as the number of voting members from a particular association is limited to two. I'd ask that the Nomcom chair include this in the list of volunteers. Also, I note that last year there were actually 4 members (2 voting and 2 others) from one particular organization. I'd suggest that this year the liasons NOT be selected from any organization already represented by a voting member. Later, Mike At 09:31 PM 8/30/2006, Richard Shockey wrote: This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. Second ...a complete explanation of why this go screwed up should have been posted to the community. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire process of the IETF and NomCom. This resulted in the list being sent to the secretariat later than I would have liked, and the message then got hung up in the secretariat's queue. The selection is still deterministic, because the list ordering algorithm used (alpha by first name) is deterministic. However, since the list was published late, the appearance is not ideal. Second: A sitting member of the IAB's name appeared on the candidate list. According to 3777, section 15, sitting IAB, IESG and ISOC members are not eligible to serve on the Nomcom. This was an oversight on my part. Ordering in the list does matter for the selection process. Although this person was not selected to serve, and the harm done is minimal, it is important that the IETF follow our own processes as closely as possible. For these reasons, and after consultation with members of the IAB, IESG and ISOC, I have decided that to remove any doubt from the proceedings we must re-run the selection algorithm with new seed information. This is unfair to the people who volunteered for NomCom and are the backbone of the process. These people rightfully believed that they were or were not selected, and everyone selected was preparing to serve. To the volunteers: Thank you for volunteering, for your patience and understanding. I apologize for any inconvenience this reset may cause. In order to close this issue quickly, the same stocks and procedure will be used as last time, but the trading date will be drawn from the September 1, 2006 Wall Street Journal which reports the the sales figures from the previous trading day - August 31, 2006. The list we will use is the same as before, but with the IAB member's name removed. The list will be sent in a separate mail. Thank you. Andrew Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
The reset should not be permitted. The problem here is that the IAB and IESG could use this precedent to avoid appointment of certain individuals to the NOMCOM. The situation might appear to be that a member of the crazy gang got choosen and someone wants to block them. Given the tenuous nature of the NOMCON procedure itself and the abysmal level of accounability it achieves it is not acceptable to further dilute it. My personal view is that the NOMCON process itself is a charade that was intended to concentrate power in the hands of the establishment. The only reason why it can be claimed to work is that the process cannot be controlled by the administrators. Once someone can ask for a 'redo' that rationale is lost entirely. The original list should be used. If any member is ineligible and is elected then this should be treated as if they were elected and then immediately disqualified. Furthermore it is really unacceptable to present this as a fait acompli with a new selection date already set. -Original Message- From: Richard Shockey [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 9:31 PM To: 'IETF-Discussion' Subject: Now there seems to be lack of communicaiton here... This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. Second ...a complete explanation of why this go screwed up should have been posted to the community. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire process of the IETF and NomCom. This resulted in the list being sent to the secretariat later than I would have liked, and the message then got hung up in the secretariat's queue. The selection is still deterministic, because the list ordering algorithm used (alpha by first name) is deterministic. However, since the list was published late, the appearance is not ideal. Second: A sitting member of the IAB's name appeared on the candidate list. According to 3777, section 15, sitting IAB, IESG and ISOC members are not eligible to serve on the Nomcom. This was an oversight on my part. Ordering in the list does matter for the selection process. Although this person was not selected to serve, and the harm done is minimal, it is important that the IETF follow our own processes as closely as possible. For these reasons, and after consultation with members of the IAB, IESG and ISOC, I have decided that to remove any doubt from the proceedings we must re-run the selection algorithm with new seed information. This is unfair to the people who volunteered for NomCom and are the backbone of the process. These people rightfully believed that they were or were not selected, and everyone selected was preparing to serve. To the volunteers: Thank you for volunteering, for your patience and understanding. I apologize for any inconvenience this reset may cause. In order to close this issue quickly, the same stocks and procedure will be used as last time, but the trading date will be drawn from the September 1, 2006 Wall Street Journal which reports the the sales figures from the previous trading day - August 31, 2006. The list we will use is the same as before, but with the IAB member's name removed. The list will be sent in a separate mail. Thank you. Andrew Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA
RE: Now there seems to be lack of communicaiton here...
I agree with Phillip - there is no harm here. If someone ineligible had happened to be selected, they would have been immediately disqualified and the next number on the list selected. That's why you actually ask for about 16 numbers to be output when you run the program which outputs the selection numbers. There is no reason for a reset. (However, see my comments on volunteer associations). I further agree with Phillip (and Richard) that this is not an IAB or even a Nomcom chair decision, but a community one and should not have been made in the back room. At 10:52 PM 8/30/2006, Hallam-Baker, Phillip wrote: The reset should not be permitted. The problem here is that the IAB and IESG could use this precedent to avoid appointment of certain individuals to the NOMCOM. The situation might appear to be that a member of the crazy gang got choosen and someone wants to block them. Given the tenuous nature of the NOMCON procedure itself and the abysmal level of accounability it achieves it is not acceptable to further dilute it. My personal view is that the NOMCON process itself is a charade that was intended to concentrate power in the hands of the establishment. The only reason why it can be claimed to work is that the process cannot be controlled by the administrators. Once someone can ask for a 'redo' that rationale is lost entirely. The original list should be used. If any member is ineligible and is elected then this should be treated as if they were elected and then immediately disqualified. Furthermore it is really unacceptable to present this as a fait acompli with a new selection date already set. -Original Message- From: Richard Shockey [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 9:31 PM To: 'IETF-Discussion' Subject: Now there seems to be lack of communicaiton here... This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. Second ...a complete explanation of why this go screwed up should have been posted to the community. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire process of the IETF and NomCom. This resulted in the list being sent to the secretariat later than I would have liked, and the message then got hung up in the secretariat's queue. The selection is still deterministic, because the list ordering algorithm used (alpha by first name) is deterministic. However, since the list was published late, the appearance is not ideal. Second: A sitting member of the IAB's name appeared on the candidate list. According to 3777, section 15, sitting IAB, IESG and ISOC members are not eligible to serve on the Nomcom. This was an oversight on my part. Ordering in the list does matter for the selection process. Although this person was not selected to serve, and the harm done is minimal, it is important that the IETF follow our own processes as closely as possible. For these reasons, and after consultation with members of the IAB, IESG and ISOC, I have decided that to remove any doubt from the proceedings we must re-run the selection algorithm with new seed information. This is unfair to the people who volunteered for NomCom and are the backbone of the process. These people rightfully believed that they were or were not selected, and everyone selected was preparing to serve. To the volunteers: Thank you for volunteering, for your patience and understanding. I apologize for any
