Re: proposal for random selection process for nominations
"James R. (Chuck) Davin" <davin@bellcore.com> Wed, 02 December 1992 17:28 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12157; 2 Dec 92 12:28 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12148; 2 Dec 92 12:28 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16672; 2 Dec 92 12:29 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12143; 2 Dec 92 12:28 EST
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16640; 2 Dec 92 12:29 EST
Received: from phila.bellcore.com by thumper.bellcore.com (4.1/4.7) id <AA00580> for poised@CNRI.Reston.VA.US; Wed, 2 Dec 92 12:29:22 EST
Received: from localhost.bellcore.com by phila.bellcore.com (4.1/4.7) id <AA08308> for poised@CNRI.Reston.VA.US; Wed, 2 Dec 92 12:29:42 EST
Message-Id: <9212021729.AA08308@phila.bellcore.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "James R. (Chuck) Davin" <davin@bellcore.com>
To: Craig Partridge <craig@aland.bbn.com>
Cc: "James R. (Chuck) Davin" <davin@bellcore.com>, poised@CNRI.Reston.VA.US
Subject: Re: proposal for random selection process for nominations
In-Reply-To: Your message of Tue, 01 Dec 92 07:55:44 -0800. <9212011555.AA00136@aland.bbn.com>
Date: Wed, 02 Dec 1992 12:29:38 -0500
X-Orig-Sender: davin@phila.bellcore.com
Craig, I interpret your insights about the "sampling errors" that could put too many IESG/IAB types on the committee as implying that we need some sort of explicit mechanism for precluding that case. Publically pulling names out of a hat works for me. It is not clear that doing the hat exercise in an open, public meeting means necessarily that we all have to show up just to see that it's done properly. I guess I don't have a substantive beef with your proposal, but it seemed to me that the introduction of an algorithm for pseudo-random number generation was an unwanted optimization. Your general scheme works equally well if the ombudman simply puts a list of numbers into a sealed envelope BEFORE the new pool of volunteers is solicited, and the envelope is only opened AFTER the selection pool is established. The integrity and opacity of the envelope are the important thing. The process by which the numbers in the envelope are generated is secondary. The C code you posted could give us a way of abbreviating a list of numbers, but I'm not sure how much benefit we really get by etching a particular, single abbreviation convention into our procedural culture. One can make a similar statement about the sealed "envelope" into which the numbers are placed. Using PEM is attractive, but an ordinary sealed paper envelope works just fine too. These sorts of implementation choices should be left to the implementor -- in this case, the ombudsman. Chuck
- proposal for random selection process for nominat… Craig Partridge
- Re: proposal for random selection process for nom… James R. (Chuck) Davin
- re: proposal for random selection process for nom… Craig Partridge
- re: proposal for random selection process for nom… Frank Kastenholz
- Re: proposal for random selection process for nom… James R. (Chuck) Davin