But what is an 'obvious mistake in the result'?
All I can think of is that the Nomcon would make a choice that the confirming
body found controversial. While that might be because the ten momcon members
somehow managed to remain ignorant that a particular person was incompetent,
had a felony conviction or whatever, it seems much more likely that the
confirming body is going to object to candidates who are insufficiently
committed to the prevailing groupthink.
This is somewhat more of a problem on the IAB than the IESG. As I pointed out
at the plenary, the fact that the IETF transition plan for IPv6 is bogus has
been apparent to many of us for many years. This is the type of observation
that should be coming from the IAB. Instead the IAB is yet more inertia that
has to be overcome.
If you look at the IETF mailing list threads on IPv6 NAT beginning with the
decision to kill NAT-PT you will see that at the start of the conversation I
had virtually no support for my position that NAT represents an essential
component in the IPv6 transition. Continuing to hold that position was
certainly not the popular thing to do, but at this point there is a very clear
consensus that IPv4-6 transition has to be transparent for the end user.
The same thing happened on email authentication. It was certainly not a popular
view in the anti-spam community when it was first proposed. The authentication
faction was pretty isolated, we didn't get invited to speak at conferences in
the early days.
Telling people that everything is just splendid is going to make you so much
more popular than trying to get people to face the brutal facts.
A justification for the nomcon process would be if it actually increased the
chance that unpopular dissident views would be represented in the IETF
management. But the exact opposite is the case, every step in the process is
designed to minimize the risk of contrarian views. And the IAB selection
criteria in particular make the peculiar assertion that compatibility with the
group consensus is considered an asset rather than a liability.
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of Theodore Tso
Sent: Mon 17/03/2008 11:52 PM
To: Steven M. Bellovin
Cc: Christian Huitema; 'Fred Baker'; Dan Wing; 'IETF Discussion'
Subject: Re: Confirming vs. second-guessing
On Tue, Mar 18, 2008 at 02:08:15AM +0000, Steven M. Bellovin wrote:
Try this one, quite non-hypothetical: a candidate for the IESG is
contemplating switching jobs. His or her current employer does not yet
know this. It has a clear bearing on whether or not that person can do
the job of AD, but equally clearly should not be broadcast to the world.
A lot of whether you think information shared with NOMCOM should be
confidential depends on whether you frame the process from the point
of view of a governance issue, or from the point of view of personnel
I think most poeple would agree that if you consider Nomcom as being
more of a "performance review" or a "hiring/firing process", then like
most personnel issues, the information used to make these sorts of
decisions should be treated as confidential. Certainly if I give
feedback about my manager or vice president as part of some 360 review
process, I would feel *quite* betrayed if that information was shared
any further than it needed to be, lest that information get back to
the person in question --- or to a close friend of the person in
If you think of NOMCOM as being more of a governance question, then
especially if you are from the United States, and in particular from
those localities that have "Open Meeting" or "Open Door" laws that
mandate complete transparency in governance where *all* meetings
between any 2-3 goverment officials must be adequately noticed so the
public can attend and minutes taken which are publically posted, then
you'll probably also share the opinion that NOMCOM should run without
any confidentiality at all. (As an aside, I've noticed that this is
not true in all cultures, and there is variance on this depending on
where you're from. I've been on committees where we debated this
issue, and I recall some Europeans saying at this absolute insistance
on complete transparency was quite daft --- their words --- and not
the norm from their experience.)
The problem is that NOMCOM process can be viewed through either lens
equally well, and I suspect that's one of the reasons we don't have
consensus on this issue.
My personal bias, as a former NOMCOM chair, is to view NOMCOM as being
more of a personnel process, and thus I believe that most information
about the process should be kept confidential, *especially* if making
it public were might dissuade some talented individuals from throwing
their hat in the ring.
As for the related issue concerning the role of the confirming body, I
personally believe that the confirming body should act more as a
*sanity check* than anything else. That is, it should question any
obvious process violations that it noticed or had brought to its
attention (perhaps through the Laison) and if some choice has some
obvious problems that might harm the IETF if said selection should go
forward, the confirming body should ask questions. However, if there
are two obvious, viable candidates, and the choice of one or the other
is a 60/40 or a 55/45 question, I do **not** believe it is the place
of the confirming body to request so much information so they can
second-guess the NOMCOM and determine whether they made that 60/40 or
45/55 call correctly.
This is more than rubber-stamp, in that the confirming body should
call into question obvious mistakes in the result or process (or what
might be appear to obvious mistakes). But there is a far cry between
that and guaranteeing that the NOMCOM "made the correct decision". In
order to do the latter the confirming body would need a lot more
information and effective redo the work of the NOMCOM in order to
effectively "check their sums"; and I don't believe that is a healthy
or useful use of the confirming body's time.
However, I don't believe (although I would be delighted if I was
wrong) that we have consensus on this point, either...
IETF mailing list
IETF mailing list