Re: deadlock problem

[RJ Atkinson <rja@extremenetworks.com>]

On Tuesday, May 13, 2003, at 10:22 America/Montreal, Brian E Carpenter 
wrote:
> But that is another matter. The IAB *has* a defined voting rule
> in its own charter,

I'll quote that section of RFC-2850, which is Section 3.5:

   3.5 Decision taking

   The IAB attempts to reach all decisions unanimously.  If unanimity
   cannot be achieved, the chair may conduct informal polls to determine
   consensus.  The IAB may make decisions and take action if at least
   seven full members concur and there are no more than two dissents.

   The IAB may reach decisions by face to face meeting, teleconference,
   Internet communication, or any combination of the above.

I'll note that this text also has a deadlock state whenever more than 2
dissent and at least 7 full members concur.  This condition has occurred
more than once during my time on the IAB with regard to confirming
nominees -- though it was never the process used for confirming 
nominees.

That deadlock might not be harmful -- and might even be desirable --
in the case where a purely architectural question is at hand.  Such
deadlock would actually be harmful in the special case of confirming
IESG nominees -- the question at hand.

> So your rules (A or others) simply create scope for ambiguity with
> those existing rules.

If it were out-of-scope for the IETF Nomcom process RFC to explain
how many votes are sufficient for approval/rejection of a nominee,
that is something that could and should have been raised *years and
years ago* by either ISoc BoT or IAB.

I do not believe that any of the 4 proposed corrections to the current
text creates new scope for ambiguity.  Please explain.

> 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 think that really eliminates the deadlock.  Further, it means
there isn't reliable consistency from year to year -- as the IETF
community expects (and has reason to expect).

> 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.

Thanks.  It is not a fundamental change in the actual process,
but rather a minor technical clarification to prevent a (not so
theoretical) deadlock state.

I'll note that
	(B) has an inverted bias to (A) with regards to how "abstain" votes
	impact the result
&& that
	(C) or (D) remove any result bias from the "abstain" vote.

I created 4 options to try to help focus the list conversation
on list -- and to make clear that multiple fixes exist and that
any of those would be acceptable to me.

> Nothing will inject common sense if it is absent.

Common sense isn't the issue.  A common understanding of the process
to follow and avoiding legislated deadlock states are the issues.

> It's pretty close to the status quo. You must have had
> a bad experience.

Painful to watch close-hand, at a minimum.

Summary:
	To go back to my original primary point, the problem that needs to
be fixed is the deadlock state in the current draft.  There are several
ways to do so.  This WG needs to pick a single way to fix the problem.

Ran's bottom line:
	I can live with anything that eliminates the deadlock state.

Ran Atkinson
rja@extremenetworks.com