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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Apr 2003 12:23:40 +0200

I agree. The text in draft-ietf-nomcom-rfc2727bis-03.txt is
fine the way it is. The DT has no input from WG discussion to
justify a change.

   Brian

Scott Bradner wrote:
> 
> I disagree with the DT -
> I think it is in the IETF's scope to say that the CB has to have majority
> support and say what that majority is of (those voiting or those
> able to vote - I'd rather the latter)
> 
> specfically, I think it is in the IETF's scope to say how serious the
> CB needs to be - implying that if one person says "yes" and no one
> else says anything a set of nominees gets OKed (or not OKed) is
> not serious enough in my book
> 
> Scott

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Apr 2003 14:04:59 -0500

I understand the distinction you are drawing, but in fact I do not think it 
applies.
I believe that the IAB and the ISOC BoT are indeed acting in their roles as 
IAB and ISOC BoT when they undertake the activity of reviewing and 
approving the nominating committee recomendation.  (At least, that is how I 
read the procedures, and how I recall the intent.) I do not believe that 
they are acting in some other capacity (as a committee of the 
whole).  Hence, the bodies should act according to their own rules.  If 
those rules permit a deadlock on critical issues, then the body may need to 
revisit its own rules.  But the IETF Nominating Committee procedures 
working group, and the RFC from that, should not be deciding those 
procedures.

Yours,
Joel M. Halpern

At 01:57 PM 4/1/2003 -0500, Michael StJohns wrote:
>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>
> >