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