--On Friday, June 05, 2009 16:45 -0700 The IESG
<iesg-secretary@xxxxxxxx> wrote:
> The IESG has received a request from an individual submitter
> to consider the following document:
>
> - 'Nominating Committee Process: Open Disclosure of Willing
> Nominees ' <draft-dawkins-nomcom-openlist-04.txt> as a BCP
>
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the ietf@xxxxxxxx mailing lists by
> 2009-07-03.
>...
On balance, my personal conclusion is that the community
probably wants to do something like this. If it does, this is
close, but not ready for approval for at least three reasons:
(1) I believe that the issues in Sections 3 and 4 are
real, and that those sections correctly describe a
problem. But, especially against the background of
our apparently feeling a need to get the Nomcom started
earlier (and to be sure that it can) and concerns about
a shortage of plausible nominees for many positions, I
believe that we need to rethink the Nomcom model and the
way it works, rather than trying to apply minor patches.
Such patches would be harmless except that they divert
us from doing a real analysis on the issues and because
we have proven unable to make them without unintended
side-effects. Even this seemingly-innocuous patch has
opened up discussion about fundamental issues about the
limits Nomcom confidentiality that are outside its
specific scope.
(ii) We are still having discussions about, e.g.,
solicitations of support -- not about whether they are a
good idea, but about how strongly they should be
prohibited, especially in an environment in which names
are public. In some sense, we should not be having
that discussion now because it isn't in the scope of the
change proposed by this document. But we don't seem to
have consensus about whether the changes specified here
will have any consequences in terms of shifting things
toward election models, solicitations of support and
campaigning (positive or negative). And, unless we can
somehow understand that better, this proposal --with all
of the necessary opportunities for exceptions-- seems to
be too high-risk to apply as a patch.
(iii) We have had fairly extensive discussions about why
it might be destructive to publish some specific names
-- people who might be adversely affected by appearing
to "run against" other nominees (possibly especially
with incumbents), sensitive intra-company relationships,
and so on. I think we have reached agreement that the
Nomcom should be able to suppress names when they
conclude that is desirable --that they "may" publish
lists of names if they decide to do so. But the text of
the document actually doesn't make that clear. It
provides that a list can be published, that updated list
can be published if the Nomcom considers that desirable,
and that there should be no ringers. It does not
explicitly provide for publishing a list that omits some
willing candidates, no matter what the reason. That is
the sort of omission that leads us, often a few years
later when a situation actually arises, into long and
unpleasant arguments about what the procedures really
intend and require.
The document should not go forward unless the
community's intent in this area is absolutely clear. I
believe that intent is that the Nomcom should be able to
decide to not include all willing nominees for a
position in that list and that it should not be required
to avoid publishing a list entirely if there are one or
more names that should not be disclosed unless they are
selected. But, even if the intent is the opposite, the
document should be absolutely clear on the subject. At
present, it is not.
I do continue to question whether this is a good idea on
balance, for reasons that have been discussed many times before.
I don't even agree with the document that the IAB publication of
ISOC Trustee Nominees has been without negative side effects
(maybe not "apparent" ones, but the community has no way to know
who decided to not put forward a name because of the disclosure
issues -- a problem that may repeat itself with the RSE and ISE
selections). But, if this is what the community wants to do, we
should at least get it right.
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf