Subject: RE: Now there seems to be lack of communicaiton here...

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 30 Aug 2006 19:52:23 -0700

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-masked]] 
> 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 [email-masked] 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-masked]>
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Michael StJohns <[email-masked]>
Date: Thu, 31 Aug 2006 01:36:10 -0400

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 problem here is that the IAB and IESG could use this precedent 
>to avoid appointment of certain individuals to the NOMCOM.
>
>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.
>
>
>

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 31 Aug 2006 09:16:39 +0200

>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 Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

1160438400 + 381600 = 1160820000.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Aug 2006 09:38:52 +0200

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).
> 
>> The problem here is that the IAB and IESG could use this precedent to 
>> avoid appointment of certain individuals to the NOMCOM.
>>
>> cannot be controlled by the administrators. Once someone can ask for a 
>> 'redo' that rationale is lost entirely.
>>
>>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 Aug 2006 10:39:41 +0200

Michael StJohns wrote:
> 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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 31 Aug 2006 15:52:47 +0200

> 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

---

From: Ned Freed <[email-masked]>
Date: Thu, 31 Aug 2006 07:24:38 -0700 (PDT)

> 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.

> 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

---

From: Michael StJohns <[email-masked]>
Date: Thu, 31 Aug 2006 10:55:34 -0400

At 04:39 AM 8/31/2006, Eliot Lear wrote:
>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
>documented.

What procedure and where is it documented?

>Please let's recognize that Mr. Lange has erred on the side

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

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 31 Aug 2006 11:33:37 -0400

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-masked]] 
Sent: Thursday, August 31, 2006 10:25 AM
To: Brian E Carpenter
Cc: [email-masked]; 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.

> 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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 Aug 2006 09:26:11 -0700

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.

>  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

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 31 Aug 2006 19:20:36 +0200

Hi,

> The presence of ineligible persons in the list is no reason whatsoever

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 Aug 2006 20:23:59 +0200

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

rhaps I'll 
> change my mind.
> Jim

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 Aug 2006 20:23:59 +0200

Don,

Eliot

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 31 Aug 2006 11:37:31 -0700

Hi -

> From: "Henrik Levkowetz" <[email-masked]>
> To: "Eastlake III Donald-LDE008" <[email-masked]>
> Cc: "IETF-Discussion" <[email-masked]>
> Sent: Thursday, August 31, 2006 10:20 AM
...

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

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 31 Aug 2006 15:01:19 -0400

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-masked]] 
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,

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Thu, 31 Aug 2006 16:04:07 -0400

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
>which people are ordered.

The list was ordered in the same manner as previous years I believe?

---

From: Michael StJohns <[email-masked]>
Date: Thu, 31 Aug 2006 16:12:30 -0400

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.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 Aug 2006 22:22:35 +0200

Mike,
> 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

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Aug 2006 16:53:45 -0400

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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 31 Aug 2006 17:55:25 -0400

On Thursday, August 31, 2006 09:26:11 AM -0700 Dave Crocker 
<[email-masked]> wrote:

> 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

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 31 Aug 2006 17:30:10 -0400

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-masked]] 
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.

...

---

From: Pete Resnick <[email-masked]>
Date: Thu, 31 Aug 2006 17:54:37 -0500

On 8/31/06 at 9:38 AM +0200, Brian E Carpenter wrote:

>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

---

From: "todd glassey" <[email-masked]>
Date: Thu, 31 Aug 2006 14:04:49 -0700

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-masked]>
To: "Eliot Lear" <[email-masked]>
Cc: "IETF-Discussion" <[email-masked]>
Sent: Thursday, August 31, 2006 12:01 PM
Subject: RE: Now there seems to be lack of communicaiton here...

TSG: NO - ANYTHING THAT THE SECRETARIATE WAS TO DO WOULD REQUIRE A From [email-masked] Thu Aug 31 19:09:48 2006
From: "todd glassey" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>,
	"Eliot Lear" <[email-masked]>
Date: Thu, 31 Aug 2006 14:04:49 -0700
Cc: IETF-Discussion <[email-masked]>
Subject: 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-masked]>
To: "Eliot Lear" <[email-masked]>
Cc: "IETF-Discussion" <[email-masked]>
Sent: Thursday, August 31, 2006 12:01 PM
Subject: RE: Now there seems to be lack of communicaiton here...

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.

Donald

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
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,

Eliot

---

From: "todd glassey" <[email-masked]>
Date: Thu, 31 Aug 2006 16:05:21 -0700

X-MailFORMAL

Donald

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
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,

Eliot

---

From: "todd glassey" <[email-masked]>
Date: Thu, 31 Aug 2006 16:05:21 -0700

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-masked]>
To: "Michael StJohns" <[email-masked]>
Cc: "IETF-Discussion" <[email-masked]>
Sent: Thursday, August 31, 2006 1:22 PM
Subject: Re: Now there seems to be lack of communicaiton here...

man-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Elliot -
What about those that may not be in the selection pool this time around -
how fair would that be to them?

Todd Glassey

---

From: Theodore Tso <[email-masked]>
Date: Thu, 31 Aug 2006 21:08:14 -0400

>    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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 31 Aug 2006 21:40:19 -0400

I agree that this seems to be the best course available.

Yours,
Joel M. Halpern

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 31 Aug 2006 21:51:07 -0400

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

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Thursday, August 31, 2006 9:40 PM
> To: IETF-Discussion
> > > (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.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 31 Aug 2006 21:51:07 -0400

R. Shockey

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 Aug 2006 19:03:53 -0700

...
> (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

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 31 Aug 2006 19:11:42 -0400

As someone who was actually selected in the previous round and started this
little thread, I support this position.