See below at @@@
-----Original Message-----
From: John C Klensin [mailto:john-ietf(_at_)jck(_dot_)com]
Sent: Friday, September 01, 2006 11:45 AM
To: Eastlake III Donald-LDE008; IETF-Discussion
Subject: RE: Now there seems to be lack of communicaiton here...
--On Thursday, 31 August, 2006 17:30 -0400 Eastlake III
Donald-LDE008 <Donald(_dot_)Eastlake(_at_)motorola(_dot_)com> wrote:
John,
If the selection method is random, it makes no difference whatsoever
how the list of nomcom volunteers is ordered. It only matters that the
numbered list become fixed and be posted before the selection
information is available. Alphabetic or the order they volunteered or
any other order is perfectly fine.
Agreed, except that an alphabetic sort is not, by any stretch of the
imagination, random. Phillip's suggestion of using a well-established
hash that is known to give good distributions would work; there are many
other methods that would work. But a number of observable distribution
issues make an alphabetic sort on names unacceptably random if one is
then going to use the ordering for successive samplings/selections.
@@@ I'm not sure why you agree with me and then say the opposite. If it
doesn't matter what the ordering of the nomcom volunteer pool is then it
doesn't matter what the ordering of the nomcom volunteer pool is, and,
in particular, it doesn't matter how random or "biased" it is. The RFC
3797 algorithm takes random inputs and uses them to make successive
uniformly distributed non-repeating selections from a range of integers.
The sole purpose of the published ordered volunteer pool list is to
provide a pre-announced mapping from those integers to the people who
volunteered. If it mattered what that mapping was, then you are not
making uniformly distributed random selections.
John, I have to agree with Donald here. Nothing anyone has said has indicated
that there is a flaw in the algorithmic part of the selection process. If
something ain't broke don't fix it.
Indeed, not only is the algorithmic part of the selection process fine, the
non-algorithmic parts were well thought out and various contingencies were
covered, including the specific one where disqualified people found their way
onto the final qualified candidate list. The problem is quite simply that the
nomcom chair failed to follow these recommendations.
It also appears we have dodged the bullet this time around. But this was mostly
a matter of luck. We may not be so lucky the next time, and that means we need
to act now to fix the problem that the nomcom chair has the dangerous and
unnecessary ability to reset the selection process in cases where no reset
should be allowed. (I have already described why there is real danger here -
see my previous posting for specifics.) This absolutely must be attended to
before the next nomcom.
Now, various people have argued that the nomcom chair was within the rules to
reset the process when the error came to light. I agree with this assessment,
but this is really beside the point. The point is the nomcom chair should NOT
have the reset option available in this circumstance, and that our current
process is BROKEN in allowing this level of discretion.
@@@ Both RFC 3797 and Phil Hallam-Baker's suggestion use a
well-established hash. (I happen to personally not like the details of
Phil's specific suggestion because of questions related to email address
canonicalization and because it would require publishing email addresses
for all nomcom volunteers.)
Agreed.
I want to stress that, given this mess has occurred, I would find just
about anything the Nomcom Chair decides to do acceptable although I do
not approve of his consulting the IETF Chair (or IAB Chair) in the
matter.
I'm sorry, but I'm not so forgiving. The nomcom chair made a major blunder
here, abetted by some exceptionally poor advice from the IETF chair. This
blunder could have caused major damage to the organization. The combination of
there being essentially no time before the second selection process and the
fairly drastic nature of an ISOC appeal is the only - repeat ONLY - reason I
for one didn't start the ball rolling.
I've seen no indication that there's been any direct fallout from this, such as
a lawsuit being filed. (Of course something along these lines could still
happen.) But this does not mean that what has happened hasn't weakened the
faith people have in the fairness of the process. I know for a fact that I'm
much less sanguine about the process than I used to be, and I suspect I'm not
alone in this.
I also share your discomfort with the nomcom chair's decision to
consult the IETF chair, although my discomfort falls short of wanting to
see some formal rule against it happening.
But, if we are going to make sure this problem does not occur
in the future, I think we should make the procedure as gaming-proof as
possible. That, to me, implies two requirements going forward:
(1) We get strong randomization of the selection process
@@@ We already have this. See RFC 3797.
Yep. Again, if it ain't broke...
(2) We do not redraw the entire Nomcom pool and _never_ do so after
anyone who has discretion has had an opportunity to see the initial list
of Nomcom members. If someone is selected (or
volunteers) and then determined to be ineligible, the people who have
already been selected by the mechanism specified stay selected.
Anything else just has a bad odor whether actual improprieties are
suspected or not.
@@@ It may be possible, with sufficient care, to make vanishingly small
the chance that a nomcom chair discretionary decision would be needed
for this aspect of nomcom selection. But I am not sure that, in the real
world, it is possible to do this for all aspects of nomcom selection.
See Section 5.2 of RFC 3797.
Section 5.2 talks about potential issues with using stock prices or
volumes. I don't see how this connects with the need to remove the
ability for the nomcom chair to reset the process for no good reason.
In addition, I am extremely concerned by hints on this list that the
Secretariat's checking procedures ruled people ineligible to volunteer
who had, in fact, attended the correct number of meetings. That, it
seems to me, is a much larger threat to the integrity of the Nomcom
model and perceptions of trust in it than any issue that impacts a
single volunteer or even, within broad limits, the randomization and
Nomcom member selection processes.
@@@ Well, you are welcome to be as concerned as you like, but we live in
an imperfect world. As far as I know, there are usually a few disputes
about the volunteer list, usually in connection with people whose
eligibility the Secretariat doubts. Sometimes they are determined to be
correct and sometimes the Secretariat is determined to be right.
Sometimes the volunteer is confused about the eligibility requirements
or about what their attendance actually was, or has variant versions of
their name, or has changed their name, or ... But this sort of thing
doesn't effect very many people on the volunteer list and is almost
always resolved between the volunteer and the Secretariat before the
list is published.
Nevertheless, I believe John is correct in saying that even if we eliminate the
unnecessary and dangerous discretionary powers the nomcom chair has currently,
there's still an issue when the list we use is subsequently found not to
contain people it should. However, there doesn't appear to be a good way to
address this problem should it arise. If someone has a novel suggestion for how
to deal with this I'd love to hear it, but absent such a suggestion I'm at a
loss as to how to deal with this one other than to say "yes, it's a potential
issue, hopefully it won't happen".
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf