Publicly Verifiable Nominations Committee (NomCom) Random Selection
draft-eastlake-rfc2777bis-selection-04

Version -04 has changed the counter based prefix and suffix to be 16 bits rather than 8, so there's nothing magic about the 256th entry in the pool any more.

[Ballot comment]
>    executed. The algorithm can be run to select, in an ordered fashion,
>    a larger number than are actually necessary so that if any of those
>    selected need to be passed over or replaced for any reason, an
>    ordered set of additional alternate selections will be available.

I would prefer to see the above tweaked to not mention that a larger
pool can be selected. This document should stick to how to select from
the pool, not to suggest extensions to the nomcom algorithm.
Specifically, I do not believe it is appropriate to choose a larger
pool than the ten, because doing so would allow folk to see who the
replacement selections would be prior to there being an opening. This
may influence decisions as to whether someone should disqualify
themselves, etc. It would be better not to go there and have
replacements chosen by a new random selection AFTER the vacancy
appears.

Can the sentence just be dropped?

>    The random sources must not include anything that any reasonable
>    person would believe to be under the control or influence of the IETF
>    or its components, such as IETF meeting attendance statistics,
>    numbers of documents issued, or the like.

Actually, the requirement is not that the IETF can't influence, but
that it can't influence in a _negative_ way, i.e., a way that biases
the final results towards a particular outcome. The document later
has text that indicates this is the real issue, i.e.:

  It is important that the last source of randomness, chronologically,
  produce a substantial amount of the entropy needed.  If most of the
  randomness has come from the earlier of the specified sources, and
  someone has even limited influence on the final source, they might do
  an exhaustive analysis and exert such influence so as to bias the
  selection in the direction they wanted.  Thus it is best for the last
  source to be an especially strong and unbiased source of a large
  amount of randomness such as a government run lottery.

[Ballot discuss]
The algorithm for dealing with more that 255 nominees seems wrong -- it will produce duplicates for 0 and 256, 1 and 257, etc.  Why not just use 16-bit numbers?

The text on dealing with alphanumeric inputs doesn't seem to handle internationalization issues particularly well.  I recommend changing that paragraph to bar such inputs.

From the nomcom chair, in regard to version 03:

The document now resolves the concerns originally brought up during the  Nomcom WG review of the doc.

Nomcom WG chair has asked for revisions from author to remove language that seems to impinge on the way nomcom selection procedures are defined - this is the province of, and properly documented in, 2727bis. Changed state back to "waiting for AD go-ahead".

From the nomcom WG chair, Nov 7:

A while back there was a discussion on
http://www.ietf.org/internet-drafts/draft-eastlake-rfc2777bis-selection-01.txt
on this list

The following is my interpretation of what was said
(the actual email can be found in the archives for August 02
http://lists.elistx.com/archives/ietf-nomcom/200208/.)

1. While the document might be ok as an individual submission,
it does contain process information that might be more
appropriate, if approved, in the base nomcom document.

- since the document was Informational before there
is no reason to change that status

- the procedure for picking alternates should be removed
and put into the base document.

2. a contradictory position, each stated by one person, on
whether the practice should be optional or not:

- the procedure described is rather mechanistic and
should remain optional

- the procedure is reproducible and its results are
verifiable and thus it should be formalized as practice.

3. Since the document contains code, the code should be
verified ( I believe it is).

---

So, from the very small conversation, I suggest the following
draft WG position on the draft.

1. The draft should be changed to remove the discussion on
picking alternates (section 5.2).

2. A statement of the code having been verified should be made.

3. The draft should then be considered for Informational status
as an individual contribution.


The other issues of

- whether this procedure should be required
is discussed in the base draft 4.17 of
http://www.ietf.org/internet-drafts/draft-ietf-nomcom-rfc2727bis-02.txt
where the use of RFC2777 is presented as an option.
While not requiring this process, the text
reads as requiring a mechanistic process.

At the moment, there is not sufficient call for changing that
text.  Also, to make this procedure a requirement would
involve making 2777bis a normative document as opposed to it
being an informational document.  This is not, as I  understand
it, the recommendation of the WG at this time.  I am not even
sure that it is what was meant by making it a formalized
practice.

- choosing alternates is covered in 4.18 of the current base draft.


Please respond to this list before 21 Nov if you have any
comments on this WG position on the draft.

State Changes to AD Evaluation                                    from Requested                                        by hta