Subject: RE: deadlock problem

From: Christian Huitema <[email-masked]>
Date: Tue, 13 May 2003 11:58:00 -0700

> 	ISOC BoT have for *years* been following an RFC-specified
> confirmation
> process that does not appear to be in its bylaws.  

The bylaws specify voting procedures in general. The formal adoption of
the ISOC Board's role in the nomination process is a resolution of the
Board of Trustees: 

	Resolution 98-03 Selection of IAB and IESG members.

	RESOLVED, that the Board accepts the process for 
	selection of IAB and IESG members, as documented in 
	RFC 2282, and accepts the role of the Board described 
	in this process.

This resolution amends the previous state, references to the "poised"
documents adopted in 1992 and 1993. Presumably, when the new RFC is
published, the board will review it. In fact, if an RFC specifies an
ISOC action, the ISOC board will be part of the last call.

> 	At best, your claim is late in the day -- years late.  If IAB or
> ISOC really had heartache over this (and I can say that the IAB had 
> *no* anxiety
> about it during my 4 years on the IAB and I heard zero individual
> complaints
> about it), that REALLY should have been raised years ago (e.g. at any
> of the
> IAB Chair transitions or when the first RFC on Nomcom procedures was
> published).

Well, I have witnessed "some" anxiety, as in last minute phone
conferences to make sure that the slate was voted on in time.

> 	And I'll note that if you adhere to the position you outline
above
> (i.e. that how a confirming body decides stuff is their concern only),
> then this WG should delete the current text and ought not be
discussing
> "the way we manage indecision".

My point is that the RFC should not mention specific voting rules, e.g.
simple majority rather than consensus or whatever else the confirmation
body sees as appropriate.

> 	As to how to do indecision, I think that boils down to (A) or
(C)
> versus (B) or (D).  I can live with any of those 4.

All of A, B, C and D have the drawback that they specify a voting rule.
I would rather go for a choice between (E) and (F):

(Proposal E)
For a given nominee to be confirmed, an explicit confirmation by the
confirming body is required. Nominees that are not confirmed under this
rule are considered to be rejected.

xor (Proposal F)
For a given nominee to be rejected, an explicit rejection by the
confirming body is required. Nominees that are not confirmed under this
rule are considered to be confirmed.

How the confirming bodies arrive to explicit confirmation or implicit
rejection is their own cooking.

-- Christian Huitema

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 13 May 2003 15:41:28 -0400

On Tuesday, May 13, 2003, at 14:58 America/Montreal, Christian Huitema 
> conferences to make sure that the slate was voted on in time.

my bad -- unclear antecedent in my note.

"this" in my note quoted above meant "Confirmation process being 
specified
in an RFC" rather than "this" meaning "confirmation process being 
completed
on time".

I suspect that "confirmation process being completed on time" is a
frequent anxiety -- at least of individuals on the confirming bodies
and sometimes of the confirming body as a whole.

> body sees as appropriate.

My point is different:

The existing text in the online I-D has always mentioned specific
voting rules (e.g. 50%) -- yet no one seemed to have a problem with
that existing text until I raised the question very very recently.

It seems very curious that some folks are now worried that some
specific voting rules are mentioned in the RFC, yet folks were not 
worried
about specific voting rules being in the RFC before the last day
or two, even though the text has been there all along.

Probably best if we set both of those points (yours and mine) aside,
and focus on how to move forward to eliminate deadlock as a problem
in confirmation.

> rejection is their own cooking.

(E) and (F) are OK with me, only if the confirming bodies have internal
processes which preclude the confirming body wedging in some deadlock.
It might be the case that your wording is trying to preclude such
wedging -- not clear whether that is your intent nor whether the
wording achieves that goal.

Maybe you could at least clarify your intent ?
Maybe there is an opportunity to wordsmith it (perhaps using
the existing deadlock state in IAB decision process as a
test case) to achieve the no-deadlock property ?

Thanks,

Ran