>>>>> "Michael" == Michael StJohns <mstjo...@comcast.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.