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

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Sep 2006 10:15:02 +0200

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Sep 2006 10:27:07 +0200

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
>   From [email-masked] Fri Sep 01 06:19:41 2006
Date: Fri, 01 Sep 2006 10:27:07 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: IETF-Discussion <[email-masked]>
Subject: 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-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.
> 
> 
>>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
>