Re: Nomcom is responsible for IESG qualifications

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Michael" == Michael StJohns <mstjohns@xxxxxxxxxxx> 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.


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]