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



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 at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf





="1851492088:sNHT31081932"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
k7VI9aST017190; Thu, 31 Aug 2006 11:09:36 -0700
Received: from [128.107.163.38] (dhcp-128-107-163-38.cisco.com
[128.107.163.38])
by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7VI9a6W009742;
Thu, 31 Aug 2006 11:09:36 -0700 (PDT)
Message-ID: <44F725E0.3010503 at cisco.com>
Date: Thu, 31 Aug 2006 19:09:36 +0100
From: Stewart Bryant <stbryant at cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: todd glassey <tglassey at earthlink.net>
References: <001d01c6cc9d$33919af0$23f0a544 at cis.neustar.com> <6B82C39E6F93D94AD124F661 at [10.0.0.6]>
<00fb01c6cd24$8dc60740$010aa8c0 at home.glassey.com>
In-Reply-To: <00fb01c6cd24$8dc60740$010aa8c0 at home.glassey.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=1169; t=1157047776; x=1157911776;
c=relaxed/simple; s=sjdkim5002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=stbryant at cisco.com;
z=From:Stewart=20Bryant=20<stbryant at cisco.com>
|Subject:Re=3A=20Now=20there=20seems=20to=20be=20lack=20of=20communicaiton=20here
...; X=v=3Dcisco.com=3B=20h=3DJj/TYGUTjQHqRMmg5BTRjTAuCKA=3D;
b=MFT1BuNIlokJy1ztxUuI9C8+0GY3aQe2sDubpiY0uzTk5wKZbz9Bst30xgq5pYm43eyu7NUI
w2qfkqlhuJi2jcn6VzCYWccrLEgF7V4m10yQXwpyYvJJHD+yxLJrqpQ8;
Authentication-Results: sj-dkim-5.cisco.com; header.From=stbryant at cisco.com;
dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: 'IETF-Discussion' <ietf at ietf.org>, James Galvin <galvin+ietf at elistx.com>
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


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