"Michael" == Michael StJohns <mstjohns(_at_)comcast(_dot_)net> writes:
dread a NomCom might face is the potential that the IAB may
decide to exercise a line-item veto on nominated candidates
- either forcing the NomCom to effectively start over, or
giving the NomCom a clear indication that their effort to
come up with a balanced slate was a complete waste of time.
Michael> I'm still trying to figure out where this "requirement"
Michael> came from. It seems to pop up in each and every nomcom,
Michael> but is no where in RFC3777.
I think it comes from the IAB.
I was on the IESG and the IAB was asked to confirm some candidates
before others (I forget the reason).
The IAB declined because they wanted to evaluate the slate as a whole.
When I was on the nomcom I believe that we got the message from the IAB
that wee needed to consider the slate as a whole and from the ISOC BOT
that we needed to consider issues such as diversity slate-wide.
Michael> The confirming body does not have a reason or reasons for
Michael> why a candidate is rejected, it has a vote or result
Michael> rejecting that candidate. Individual members of the
Michael> confirming body have reasons, some or all of which they may
Michael> or may not care to state. The only thing the Nomcom should
Michael> infer is that the confirming body (or a sufficient portion
Michael> thereof) did not agree with the nomcom as to the
Michael> suitability of that specific candidate for that specific
Michael> position and it should then try again. To put it
Michael> succinctly, it's not the process it's the person - the
Michael> nomcom didn't do anything wrong, they just came to a
Michael> conclusion that the confirming body couldn't support and
Michael> the Nomcom should just move on to the next fully qualified
Michael> candidate for that position.
I was on a noncom involving a rejection of a candidate. We actually did
get a reason from the confirming body and it was quite helpful in us
knowing how to respond to the confirming body's concern.
I would imagine that as a matter of process the confirming body agreed
what reason we'd be given.
I do understand there may be cases where there is no clear reason.
However it happens to be false in a running code sense that the
confirming body never has a reason.