Re: deadlock problem

["Joel M. Halpern" <joel@stevecrocker.com>]

If your concern is about the balance of power, then Ran's alternative B 
would meet your goal.  That stated that it takes 1/2 to reject, and the 
lack of rejection in the vote would constitute acceptance.

I am uncomfortable with the notion that a canddiate would be accepted who 
was not good enough to get 1/2 of the IAB to agree that he should / could / 
would do the job.

The current IAB voting procedures do have a state where the IAB can not 
make up its mind.  Assuming that we remove the current paragraph, the 
question is whether we need an extra impetus in  this document to ensure 
closure in the confirming body(ies)

Yours,
Joel M. Halpern

At 11:27 AM 5/13/2003 -0400, James M Galvin wrote:

> On Tue, 13 May 2003, Brian E Carpenter wrote:
>
>     > Based on that experience, I think that it would be a disaster to have
>     > the confirming bodies set their own rules.  Instead of having a
>     > straight-
>     > forward confirm/reject/abstain vote with a clearly defined outcome,
>     > letting each CB set their own rules has strong potential for (1)
>     > different procedures each year and (2) individuals trying to arrange
>     > the rules in a given year to favour particular nominees.  In short,
>     > letting each CB set their own rules would reduce consistency
>     > year-to-year
>     > and would increase the political quotient of the confirming activity.
>     > I view increasing the political quotient of anything in the IETF
>     > to be a bad result.
>
>     Yes, so maybe the NomCom doc should simply state that each confirming
>     body must apply its own standard voting rule, first to confirm the entire
>     slate, and if that fails to confirm individuals.
>
>     I don't agree with Jim that defining failure to confirm as equal to
>     rejection is a process change; that's simply been undefined in the
>     past. Ran is correct that it prevents a theoretical deadlock.
>
> Actually, it does not prevent a theoretical deadlock for two reasons.
>
> First, there is no fixed timer on when the vote needs to be completed.
> There's the general notion of being done prior to the First IETF, but
> there's no failsafe when that deadline is not met.
>
> Second, even if you assume or create a timer, the document simply states
> that the NOMCOM is to identify alternate candidates for rejected
> candidates.  Another existing ambiguity is whether or not the NOMCOM can
> re-submit the same candidate.  In the past they have, and if they do we
> still have deadlock.
>
> Even so, I won't press the point of whether it's a process change, per
> se, but I will re-iterate that it shifts the "balance of power," albeit
> imcompletely.
>
> A purpose of the NOMCOM is to represent the voice of the community.  I
> believe that ties or ambiguities should, in general, be broken or
> resolved in favor of the NOMCOM.  To suggest that the inaction or
> indecision of the confirming body is a fair result against the hard work
> of the NOMCOM is wrong in my opinion.
>
> Jim
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.elistx.com/subscribe>