Re: DISCUSSION: rejecting candidates

[Mark Allman <mallman@grc.nasa.gov>]

(At the risk of repeating something I said in an earlier note...)

> So why don't we just put in a paragraph stating explictly "The
> rejection of a candidate by a confirming body isn't cataclysmic
> but is a normal part of the procedss."?
>
> [...]
>
> The concept is not that the cofirmations bodies should be able to
> leisurely take their pick of a variety of candidates. The nomcom
> is not supposed to just be winnowing things down with the
> confirmatory body making the final choice. As the representatives
> of the IETF Community, the nomcom, with the advice and assistance
> of the liaisons, is supposed to make the choice, subject to a
> final sanity check by the confirming bodies.

I agree with the second paragraph above.  I do not agree with the
text proposed in the first paragraph.  That is, I think these two
things are contradictory.  I believe the nomcom SHOULD get to choose
IESG and IAB members, provided that they do due diligence and follow
a very inclusive process.  If that is not the case, the confirming
bodies MUST pushback and reject whoever is put forth.  But, if the
nomcom can convince the confirming body that the process was
sufficiently clean then the nominee should not be rejected because
the confirming body disagrees with the choice.  The choice should
not be a negotiation between the nomcom and the confirming body.  If
the confirming body simply has a different interpretation/opinion on
the possible candidates such that they would have made a different
choice, that should not matter.  

Also, we have liasons to the nomcom.  These folks should be sounding
early warnings if there are big process problems such that the
confirming bodies may have to engage the "reject" button.  The
nomcom should them take action to prevent that from happening.

So, it seems to me that pushing the big red "reject" button should
be difficult.  And, the confirming body should have to provide a
solid argument as to why they are doing it.  And, this argument MUST
revolve around *process* problems.

allman


--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/