Subject: Re: Re: Should the NomCom rules define CB voting behavior

From: Michael StJohns <[email-masked]>
Date: Tue, 01 Apr 2003 13:57:36 -0500 (GMT)

Unfortunately, this is a good example of why the Nomcom document SHOULD specify and control the "voting process" for confirmation.  This section (IAB charter) was cited during the IAB discussions but after discussion it was clear that the NOMCOM process was not considered when that section was written, so we ended up depending on what was in 2727.  Trust me, it was better that way, even though 2727 had the weird language about half accept or half reject.

I like to think of it this way.  The confirmation process is one that involves the members of the IAB or ISOC board, not necessarily the IAB or ISOC board themselves.  In the US an equivalent analogy would be the US House of Representatives which meets both as the House and as a Committee of the Whole.  There are different rules and procedures for each, but they both consist of nominally the same people, and are convened for different purposes.  So I don't necessarily think that the IAB process for doing confirmation has to be its normal process for doing things like writing documents, doing process reviews, or hearing appeals.

I also am more than adamantly opposed to any underspecification of the process which can lead to the PROCESS not completing.  For example, take the interaction of the DT's proposed language leaving the process for deciding how to confirm in the hands of the CB with the IAB's charter as mentioned by Brian.  Its possible for two IAB members to prevent the process from going forward. Period.  By that I don't mean that two IAB members can prevent a confirmation of a selectee, I mean that two members can prevent the IAB from making ANY decision for or against a selectee.  In the mid-term case, there's a timeout - if the CB doesn't act, the person is considered confirmed.  In the normal case, no time out and no way of forcing the issue.  And, without saying too much, this is not an abstract issue.

I'm not proposing the same set of timeouts for the normal process - I actually don't like them on the mid-term process, because I think a confirmation should be an affirmation, not a "not enough energy to object" type of thing.

So, set the objective standard - that at least of a majority of the confirming body has to agree to confirm - let the CBs set their own process within that standard, and make it clear that the standard for the Nomcom process does not apply to other CB activities, and that other CB standards don't apply to the Nomcom process.

-------Original Message-------
From: Brian E Carpenter <[email-masked]>
Sent: 04/01/03 11:22 AM
To: "Joel M. Halpern" <[email-masked]>
Subject: Re: Should the NomCom rules define CB voting behavior

> Joel,

The Nomcom document should not do this. BCP 39 is already quite clear:

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.

Regards
    Brian

"Joel M. Halpern" wrote:
> 
> It seems clear to me that the nomcom documents should not specify the
IAB
> decision process and better not specify the ISOC board decision process.
> 
> Yours,
> Joel M. Halpern
> 
> At 10:01 PM 3/31/2003 -0500, you wrote:
> 
> >Michael StJohns wrote:
> >
> > > At 05:05 PM 3/31/2003 -0500, Avri Doria wrote:
> > >
> > >> Re. The rules under which the CB decides to accept or not
> > >> accept a slate. I.e. should 2727bis require a majority.
> > >>
> > >> It is the recommendation of the DT that it is not in the NomCom's
> > >> purview to decide how the CB makes it decisions.  The
recommendation
> > >> is that 2727bis remove the requirement that at least 1/2 the CB
> > >> approve a slate.  NomCom rules are for the NomCom, not the CBs,
they
> > >> make their decisions by whatever process their charters or practice
> > >> dictate.
> > >
> > >
> > > Again, please don't leave this in the hands of the CB.  The process
at
> > > which the CB reaches a majority can safely be left there, but, if
this
> > > is not externally specified, its not a given that the CB will
establish
> > > rules to deal with the edge cases.
> > >
> > > Please specify at least the minimum required to let the CBs come to
a
> > > conclusion.
> >discussion?

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.elistx.com/subscribe>

---

From: Avri Doria <[email-masked]>
Date: Tue, 01 Apr 2003 14:43:30 -0500

Michael StJohns wrote:

> I also am more than adamantly opposed to any underspecification 
> of the process which can lead to the PROCESS not completing. 

There was an extensive discussion on this specific point early in
the process of this WG.  At that time, though the specific examples
may have differed, there was a WG rough consensus that certain
conditions could lead to a vacancy not being filled because the
CB and the NomCom could not reach a satisfactory closure, and that
that was acceptable, if not optimal.

I do not believe there has been new evidence or new issues brought
up to reopen this issue.  At that time it was argued that such an
inability would not be disastrous and that allowing the process to
continue to a natural progression was preferable to establishing
any rule to force closure.

> For example, take the interaction of the DT's proposed language 
> leaving the process for deciding how to confirm in the hands of 
> the CB with the IAB's charter as mentioned by Brian.  Its possible 
> for two IAB members to prevent the process from going forward. Period.  
> By that I don't mean that two IAB members can prevent a confirmation 
> of a selectee, I mean that two members can prevent the IAB from making 
> ANY decision for or against a selectee.  In the mid-term case, there's 
> a timeout - if the CB doesn't act, the person is considered confirmed.  
> In the normal case, no time out and no way of forcing the issue.  And, 
> without saying too much, this is not an abstract issue.

As I mentioned there was extensive discussion on this list earlier (these
should be available in the archives) on the fact that it was ok to leave
a  selection open if no agreement could be reached.

In terms of the IAB procedures, while I may agree that this could be
seen as a process problem, I do not see it as being within the NomCom
WG charter to resolve.

a.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 02 Apr 2003 08:53:11 +0200

--On tirsdag, april 01, 2003 13:57:36 -0500 Michael StJohns 
<[email-masked]> wrote:

> I also am more than adamantly opposed to any underspecification of the
> process which can lead to the PROCESS not completing.  For example, take
> the interaction of the DT's proposed language leaving the process for
> deciding how to confirm in the hands of the CB with the IAB's charter as
> mentioned by Brian.  Its possible for two IAB members to prevent the
> process from going forward. Period.  By that I don't mean that two IAB
> members can prevent a confirmation of a selectee, I mean that two members
> can prevent the IAB from making ANY decision for or against a selectee.
> In the mid-term case, there's a timeout - if the CB doesn't act, the
> person is considered confirmed.  In the normal case, no time out and no
> way of forcing the issue.  And, without saying too much, this is not an
> abstract issue.

Michael,

I don't believe your proposed amendment, or the current language in the 
document, fixes this problem.
Both cases speak to a required majority to confirm; they don't speak to 
anything about how the CB decides that it has decided.

If someone is seriously filibustering the CB's decision, there are lots of 
ways to do that under almost *any* set of rules.

The brutal mechanism that would fix this problem is specifying what happens 
at timeout - in this case, "deadlock = confirmation" - that a CB that did 
not return a rejection notice within the deadline is assumed to have 
confirmed the slate.

While I think of that as a mechanism of last resort, I think it's actually 
structurally better than having the nomcom specify rules for the confirming 
bodies' consensus processing.

(The question of whether the IAB should document its rules for deciding on 
a nomcom slate is a separate matter - I think it should)

                     Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Apr 2003 11:12:19 +0200

A little history about that clause in the IAB charter (which
I drafted). Some IAB members at the time objected to introducing
any kind of voting rule in the charter. As Chair, I felt fairly
strongly that we needed something, in case a tricky decision
needed to be taken, and that we needed something that would 
allow for strong consensus rather than a simple majority. So we
ended up requiring 7 "yes" (i.e. one more than a simple majority)
and the ability for 3 people (not 2) to block a decision.
In practice, in my experience, we never had to use this rule.

I agree that we need a Nomcom process that terminates, but
I would hate to see us abandoning the strong consensus
philosophy.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Apr 2003 14:47:55 +0200

fwiw I agree with Harald. I think a timeout on the confirmation process
(let's think in terms of 4 weeks) is entirely reasonable and would
prevent filibusters. It would also avoid constructing interlocks
between RFC 2727bis and the IAB Charter and ISOC By-laws.

> a nomcom slate is a separate matter - I think it should)

Do you want more detail than what is already in 2727bis and RFC 2850?
If so, why? And do you want the ISOC Board to do the same?

   Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 02 Apr 2003 15:31:12 +0200

--On onsdag, april 02, 2003 14:47:55 +0200 Brian E Carpenter 
<[email-masked]> wrote:

>> (The question of whether the IAB should document its rules for deciding
>> on a nomcom slate is a separate matter - I think it should)
>

the detail needed is probably on the order of:

- any member of the IAB who is on the slate will recuse him/herself, just
  as the IETF Chair does
- members who have been considered but are not nominated need not recuse
  themselves
- there should be something about whether or not the liaison to the nomcom
  should recuse him/herself - just so there's no doubt
- the IAB treats the response to nomcom as a single decision on a slate,
  not as a series of 1-person decisions (or the other way round; either
  way of deciding is internally consistent)
- a simple majority of the nonrecused members is sufficient to make a
  decision - ie the "3 may block" rule is relaxed because of the deadline

nothing controversial or non-obvious, once one spends a few cycles thinking 
about it. but as Mike said - better to think of it beforehand than in the
heat of the need to make a decision before the deadline.

and I think the IAB needs to be the one who decides it.
Yes, I think the ISOC board should do the same.

                   Harald

---

From: Michael StJohns <[email-masked]>
Date: Wed, 02 Apr 2003 08:46:48 -0500

At 08:53 AM 4/2/2003 +0200, Harald Tveit Alvestrand wrote:

>>process which can lead to the PROCESS not completing.
>Michael,
>

*wag hand*  In practice, if the only criteria is positive affirmation 
rather than the current IAB rules, one interpretation is that if a majority 
agree to confirmation then the candidate is confirmed.  Granted, it would 
be useful to set a timeout, but that's already in the document that the CB 
must complete its deliberations within a particular time.

>ways to do that under almost *any* set of rules.

Yes, but almost any set of rules has a mechanism for setting a time for a 
vote, or for forcing a vote.  The current IAB rules allow a permanent 
"discuss".

>The brutal mechanism that would fix this problem is specifying what 
>happens at timeout - in this case, "deadlock = confirmation" - that a CB 
>that did not return a rejection notice within the deadline is assumed to 
>have confirmed the slate.

Going back to other discussions, its probably a bad idea to have the 
default that the slate is confirmed. I really think that no one should be 
confirmed absent at least a majority of the CB deciding they should be 
confirmed.

>structurally better than having the nomcom specify rules for the 
>confirming bodies' consensus processing.
>

---

From: Michael StJohns <[email-masked]>
Date: Wed, 02 Apr 2003 09:31:37 -0500

>In practice, in my experience, we never had to use this rule.

 From the BCP:
    The IAB may make decisions and take action if at least
    seven full members concur and there are no more than two dissents.

Let's restate this by taking it from the other end and shaking it:

         The IAB may not make a decision if there are more than two 
dissents, and unless seven full members concur.

This has the same meaning as the BCP, but shows the problem clearer.  1) If 
too many people abstain, the IAB may not make a decision., 2) If three 
people dissent, the IAB may not make a decision, 3) If too many people have 
to recuse themselves it may be impossible to find seven concurrences.

Refusing to make a decision is different than deciding to say no.

Let's pretend for a moment that we fix the language so that it really does 
mean decide to say no, rather than refuse to decide.  There's still a 
problem with this type of criteria in that the result of a question depends 
upon how the question is formed.  Take for example a consideration of an 
appeal:  Q:  Shall we uphold the appeal?  Concur 7, dissent 3, not voting 
3.  Appeal is not upheld.  Q:  Shall we reject the appeal? Concur 3, 
Dissent 7, not voting 3.  Appeal is not rejected - i.e. its upheld.  Same 
set of people with the same set of issues and there's a different result.

A simple majority seems to have the  virtue of simplicity.  A simple 
majority of the qualified members seems to be a prudent change, at least 
for the Nomcom, but probably for other things.

>I would hate to see us abandoning the strong consensus

That's a much longer conversation than I have energy for right now.  In the 
abstract I agree with you, in the concrete, it feels too much like 
designing an OSI protocol (e.g. TP0, 2, 4) where every possible option or 
design choice tried to get stuck into the protocol. *sigh*