Re: Now there seems to be lack of communicaiton here...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:ned.freed at mrochek.com]
Sent: Thursday, August 31, 2006 10:25 AM
To: Brian E Carpenter
Cc: richard at shockey.us; IETF-Discussion; Michael StJohns
Subject: Re: Now there seems to be lack of communicaiton here...
...
The correct thing to do now is to renter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP
id k818R9LI010649 for <ietf at ietf.org>; Fri, 1 Sep 2006 10:27:09 +0200
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP
id k818R9YG010642; Fri, 1 Sep 2006 10:27:09 +0200
Received: from zurich.ibm.com ([9.4.210.83])
by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA165460;
Fri, 1 Sep 2006 10:27:06 +0200
Message-ID: <44F7EEDB.8080907 at zurich.ibm.com>
Date: Fri, 01 Sep 2006 10:27:07 +0200
From: Brian E Carpenter <brc at zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Eastlake III Donald-LDE008 <Donald.Eastlake at motorola.com>
References: <3870C46029D1F945B1472F170D2D979001543776 at de01exm64.ds.mot.com>
In-Reply-To: <3870C46029D1F945B1472F170D2D979001543776 at de01exm64.ds.mot.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: IETF-Discussion <ietf at ietf.org>
Subject: Re: Now there seems to be lack of communicaiton here...
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org
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:ned.freed at mrochek.com]
Sent: Thursday, August 31, 2006 10:25 AM
To: Brian E Carpenter
Cc: richard at shockey.us; 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
eject 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
