From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 02:55:00 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00004N2768@eListX.com> (original mail from harald@alvestrand.no); Tue, 01 Apr 2003 02:49:19 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00001N2666@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 02:49:18 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00001N2563@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 02:49:17 -0500 (EST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCN00LAVN25J1@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 02:49:17 -0500 (EST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id D407B622BB; Tue, 01 Apr 2003 09:48:10 +0200 (CEST) Date: Tue, 01 Apr 2003 09:48:10 +0200 From: Harald Tveit Alvestrand Subject: Re: Should a CB approve a slate or individuals? In-reply-to: <5.1.0.14.2.20030401125736.017a14b0@kahuna.telstra.net> To: Geoff Huston , Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <79040000.1049183290@askvoll.hjemme.alvestrand.no> MIME-version: 1.0 X-Mailer: Mulberry/2.2.1 (Linux/x86) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <5.1.0.14.2.20030401125736.017a14b0@kahuna.telstra.net> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On tirsdag, april 01, 2003 13:02:29 +1000 Geoff Huston wrote: > I am of the view that the most effective process is one of individual > confirmation or rejection , rather than confirmation or rejection of the > entire slate of names. > > The task here is to pick the best qualified individuals for each open > position, and the focus should be on the attributes of the individual to > the requirements of the open position. Treating this as a slate tends to > make the entire confirmation process tougher. There have been cases in the past where it's been quite obvious that two people should not serve on the IESG together. Mostly because of fundamental disagreements about how to run a single area ("incompatibe co-ADs"), but there could be other versions of this problem. If A and B were both considered "good people" by Nomcom, and A was advanced, but rejected, it would be logical for Nomcom to consider putting B into another slot for which he was better qualified than the original proposal, since the consideration that blocked him from being considered has gone away. Similarly, if A was advanced, and accepted, but another candidate was rejected, and B was the only reasonable alternative, the Nomcom would logically have to consider withdrawing A from the slate. Locking the process to "individuals only" would then produce a suboptimal result. That's not what we expect to be the common case, but I'd like to have the possibility open. Harald From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 02:55:06 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00004N6KBF@eListX.com> (original mail from harald@alvestrand.no); Tue, 01 Apr 2003 02:51:56 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00001N6KBD@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 02:51:56 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00001N6JBC@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 02:51:55 -0500 (EST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCN00LC2N6IN5@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 02:51:55 -0500 (EST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 892A0622BB; Tue, 01 Apr 2003 09:50:51 +0200 (CEST) Date: Tue, 01 Apr 2003 09:50:51 +0200 From: Harald Tveit Alvestrand Subject: Re: Should NomCom rules define who has CB voting rights In-reply-to: <200304010317.h313H6gs003101@newdev.harvard.edu> To: Scott Bradner , avri@acm.org, ietf-nomcom@lists.elistx.com Message-id: <79710000.1049183451@askvoll.hjemme.alvestrand.no> MIME-version: 1.0 X-Mailer: Mulberry/2.2.1 (Linux/x86) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200304010317.h313H6gs003101@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On mandag, mars 31, 2003 22:17:06 -0500 Scott Bradner wrote: > I agree with Mike - the IETF chair should not vote on the IESG > slate (and should not "vote" in any IAB process) > > Scott this is in conflict with the IAB charter. RFC 2850: 1. IAB Membership The Internet Architecture Board (IAB) shall consist of thirteen full members, composed of the chair of the Internet Engineering Task Force (IETF), and of twelve sitting members. The IETF chair, who is also the chair of the Internet Engineering Steering Group (IESG), may participate in all official IAB actions except the approval of IESG members and appeals against IESG decisions. Ex-officio and liaison members of the IAB may also attend IAB meetings but shall not participate in determination of official actions. please let's not reopen this debate here. From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 02:55:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00004N9UD9@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 01 Apr 2003 02:53:54 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00001N9UD7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 02:53:54 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00001N9TD6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 02:53:53 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCN00LBWN9SJ1@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 02:53:53 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h317qf33053748; Tue, 01 Apr 2003 09:52:42 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h317qh0Z275004; Tue, 01 Apr 2003 09:52:43 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23588 from ; Tue, 01 Apr 2003 09:52:42 +0200 Date: Tue, 01 Apr 2003 09:51:35 +0200 From: Brian E Carpenter Subject: Re: Notes from one member of the IAB on the current draft To: Michael StJohns Cc: ietf-nomcom@lists.elistx.com, iab@ietf.org Message-id: <3E894507.F6BAEA10@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <7309347.1048615982203.JavaMail.nobody@wamui04.slb.atl.earthlink.net> <5.1.0.14.2.20030331093500.05d65680@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Mike, I am OK with your comments. One remark at the very end... Michael StJohns wrote: > > At 10:04 PM 3/28/2003 +0100, Brian E Carpenter wrote: > > > I took a few days off from this thread to pay attention to my day job... > > > > Michael StJohns wrote: > > > > > > > > This implies that the candidates already confirmed by the confirming > > > body could be withdrawn. I think that's a *really > > > > really really* bad idea and unfair to the confirmed candidates. > > > > > > Well, all this process remains under the seal of confidentiality, so > > > the confirmed candidates would never know. > > Sorry to go back to this, but should have commented before. Its actually important to your current submission. > > "... confirmed candidates would never know." Except in the case that the IAB is considering an IESG where a current IAB member > has been submitted. The IAB member is disqualified from participating in their own confirmation, but not in others. Current > practice generally has the confirmation or rejection of the IAB IESG candidate first, and then bringing in that IAB member to > consider the rest of the candidates and positions. There are other reasons related to process deadlock why this is a bad idea > which we can get in to if necessary. > > > But I agree, it would be very > > > bizarre to withdraw a nomination at this stage, although I can imagine > > > an AD nominee being renominated to a different Area or even to IETF Chair, > > > after the confirming body rejected a nominee. > > As can I, but I stress that its not the Nomcom's choice to summarily reverse a previous confirmation. See my previous > comments on how to equitably handle this issue. It shouldn't take more than a day for the Nomcom to ASK the confirmee if > they're willing to be moved once they've been confirmed. > > > So we need a sentence > > > that enables NomCom to react flexibly to a rejection, without endorsing > > > egregious actions. > > > > > > During the course of the consultation, the nominating committee may > > > adjust the slate of candidates in response to the confirming body's > > > partial confirmation, by replacing the nominees who were not already > > > confirmed, and in the case of the IESG, possibly by changing the > > > positions > > > to which already confirmed candidates are appointed. > > > > > > Brian > > > > > > This is actually already in the text in other places - in fact in the > > > paragraph following the one referenced. And I repeat - it is not and should > > > not be a consultive communication - the confirming body should be free to > > > deliberate without undue influence from the Nomcom. The confirming body > > > should be free to seek information, it should not be soliciting opinion from the > > > Nomcom past that implied by the submission of the particular candidate. > > > > OK, you are bothered by the word "consult" in a way that I'm not. I would > > certainly agree to a more neutral word such as "communicate". In the cases > > where I've been involved, the communication has in fact been interrogatory > > (i.e. the confirming body asks the NomCom "Did you consider issue X when > > choosing nominee Y?" or "Did you seek an opinion about nominee Y from > > source Z?"). > > And those are questions of fact, not of opinion. Also, I'm not looking for neutral, I'm looking for accurate. "Communicate" > is at least non-egregious, and probably accurate enough for this. > > > Now let me try to be constructive. How would you find this as a > > replacement for section 3, paragraph 7 sub paragraph 3 paragraph > > beginning "If some or none..." ? > > > > If not all the candidates submitted to a confirming body are > > rapidly > > Where did "rapidly" come from? Remove. Once the slate is handed to the confirming body, the Nomcom is out of the loop until > the confirming body responds. As stated, implies that the Nomcom gets to start prodding the confirming body. The prodding if > any should probably come from the IESG Secretary? > > Also, the type of communication we're talking about more appropriately happens BEFORE the confirming body actually makes a > decision. > > > confirmed, the confirming body > > > continues to communicate > > "may communicate" - continues to communicate implies that it was already having a dialog, and also that such communication is > mandatory on the part of the confirming body. The confirming body may believe, with good justification, that it has all > necessary information it needs. > > > with the nominating committee both to understand the committee's > > rationale for the slate > > See below. > > > and, if appropriate, to explain the reason > > why all the candidates were not confirmed. > > So replace this with > > "During the course of its deliberations, the confirming body may communicate with the nominating committee to understand > the committee's rationale for the slate, and the rationale for any specific nominee. If the confirming body chooses not > to confirm one or more candidates, it is appropriate and helpful, but not mandatory, for the confirming body to provide > a brief explanation to the nominating committee of the reasoning behind the failure to confirm to assist the nominating > committee in its selection of an alternate." > > > The confirming body may ask the nominating committee for additional > information about a nominee, or about the nominating committee's procedure, > to assist them in their deliberations. However, the confirming body > and the nominating committee must refrain from mutual communication > about availability, qualification or characteristics of other possible > candidates for the position. > > Yup. > > > Then extend the following paragraph to become: > > > The confirming body may reject individual candidates, in > > which case the nominating committee must select alternate > > candidates for the rejected candidates, > > Yup. > > > and in the case of > > the IESG, may possibly change the positions to which already > > confirmed candidates are appointed. > > NO. For all the reasons I've stated before. There is no reason the Nomcom can't ASK a selectee if they'll give up their > position, but they don't get to do it unilaterally. Also, as stated implies that the nomcom can take any confirmee and stick > them in any slot without further reference to the confirming body. I agree, it shouldn't be unilateral, in the case where a nominee has already been informed. But the language mustn't be too rigid, either, because it's entirely possible that a nominee has already told the Nomcom that s/he would accept either of a couple of positions. Try and in the case of the IESG, may optionally propose a change in the positions to which already confirmed nominees are appointed, with the consent of those nominees and the approving body. > > > Brian > > Obviously, if any of this makes it in its going to require at least one editing pass to make sure it all works together. > > Later, Mike From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 04:15:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00204QKQPR@eListX.com> (original mail from gih@telstra.net); Tue, 01 Apr 2003 04:05:14 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00201QKOPP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 04:05:13 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00201QKOPO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 04:05:12 -0500 (EST) Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCN00LIDQKMN5@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 04:05:12 -0500 (EST) Received: from gih505.telstra.net (dhcp104.potaroo.net [203.10.60.104]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h31942MM063884 for ; Tue, 01 Apr 2003 19:04:06 +1000 (EST envelope-from gih@telstra.net) Date: Tue, 01 Apr 2003 18:55:31 +1000 From: Geoff Huston Subject: Re: Should a CB approve a slate or individuals? In-reply-to: <79040000.1049183290@askvoll.hjemme.alvestrand.no> X-Sender: gih@kahuna.telstra.net To: ietf-nomcom@lists.elistx.com Message-id: <5.1.0.14.2.20030401184808.016cad80@kahuna.telstra.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.1.0.14.2.20030401125736.017a14b0@kahuna.telstra.net> <5.1.0.14.2.20030401125736.017a14b0@kahuna.telstra.net> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: At 09:48 AM 4/1/2003 +0200, Harald Tveit Alvestrand wrote: Locking the process to "individuals only" would then produce a suboptimal result. >That's not what we expect to be the common case, but I'd like to have the >possibility open. I feel that this approach is a new vector in the nomcom process, and one that I'm not entirely happy with. I'm not entirely happy with the concept of the IESG or the IAB being a clump of orthodoxy, where the individual members are chosen according to their level of adherence to a common theme or membership of a particular clique or school of networking thought. I'm not sure any of us see benefit in such an direction for the IETF. I would like to think that the IESG and IAB folk have been nominated by their peers because they are regarded as being qualified _as individuals_ to do the task, and I would be much more comfortable if the confirming bodies had the ability to see the nominations as a set of individual nominations and reviewed then as a collection of individuals, rather than a 'take it or reject it' package. Geoff From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 05:05:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00404TAKK6@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 01 Apr 2003 05:03:56 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00401TAJK4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:03:55 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00401TAJK3@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:03:55 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCN00LQ5TAIJ1@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 05:03:54 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h31A2k33110424; Tue, 01 Apr 2003 12:02:48 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h31A2m0Z271300; Tue, 01 Apr 2003 12:02:48 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53796 from ; Tue, 01 Apr 2003 12:02:47 +0200 Date: Tue, 01 Apr 2003 12:01:40 +0200 From: Brian E Carpenter Subject: Re: Should a CB approve a slate or individuals? To: Avri Doria Cc: ietf-nomcom@lists.elistx.com Message-id: <3E896384.6A1260B2@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <3E88FED1.8020107@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I fully support Mike. This would be a major change in the formal rules and the practice followed for the last ten years. I have seen no discussion that would motivate or justify such a change. The rule should stay as it is The confirming bodies review their respective slate ...[and] consent to some, all, or none of the candidates. MSJ has proposed some other changes to this key sentence, but this part shouldn't change. Contrary to Avri, I find nothing ambiguous in RFC 2727 - it clearly implies a complete slate. Brian Avri Doria wrote: > > Michael StJohns wrote: > > > At 05:05 PM 3/31/2003 -0500, Avri Doria wrote: > > > >> Re: the question of reviewing a slate as whole or as individual > >> candidates. > >> > >> While more often the case in selecting the IAB then IESG, though > >> it does occur in the IESG as well, a slate is often picked for its > >> balance of talents. The recommendation of the DT is that a slate > >> is sent to the CB as a whole and must be accepted as a whole. In > >> rejecting a slate, the CB is certainly encouraged to indicate what > >> parts of the slate it finds unacceptable, but the NomCom can > >> reconsider the entire slate and resubmit a slate with different > >> candidates, even if some of the replaced candidates were acceptable > >> to the CB during its prior review. It is in keeping with this > >> recommendation for the NomCom to submit a slate to the CB that does > >> not fill all open roles. In this case, the presented slate counts > >> as a unit and its approval is not affected by any later submissions. > >> To reiterate, a slate can only be accepted in its entirety, but t > >> here is no rule stating that a slate must fill every vacancy - a > >> slate is defined as being a single list of names and positions > >> presented to the CB for approval. > >> It is considered approved and unchangeable once the CB notifies the > >> NomCom that it has been accepted. > > > > > > > > No. Just no. Its unfair and unreasonable to expect the CB to be able > > to balance individuals against a complete slate. The slate represents > > no more than 1/2 of the sitting members of the body being appointed, the > > change of one or two individuals based on a rejection should not be > > considered to cause that much perturbation. In any event, any imbalance > > can be fixed in the following year. > > > > Confirmations are discussed and decided upon based on the qualifications > > of an individual, not on the ability of the slate as a whole to succeed > > or fail. If I were managing the confirmation process for the IAB > > (fortunately, that's Leslie's job), I wouldn't know how to frame the > > question of whether to accept or reject a slate based on whether one or > > more individuals were bad enough to prevent us from accepting the rest. > > It may be possible to frame this for a single rejection, but you start > > getting interesting combinatorial problems when you start thinking about > > more than one unacceptable person. > > > > Please, leave this as a confirmation of individuals. If an individual > > fails of confirmation, it shouldn't be that traumatic to suggest an > > alternative, even if the balance among the whole slate isn't exactly > > what the Nomcom hoped it would be. Think of it this way: if changing 1 > > or 2 fully qualified candidates (out of 12 or 18 total members) causes > > so much perturbation, there's a lot more wrong than the Nomcom can > > actually fix. > > > > The suggestion that partial slates could go forward also fails. It > > needlessly extends the process without actually adding to the quality of > > the result. > > > > I am curious to hear some discussion of the list on this issue. > So far I think there have been only a few voices. While I need > to review the list again, I think I have heard one voice for > voting as a slate and one against. > > As for RFC2727, I think it was ambiguous on the notion of a slate > of candidates versus single candidates. > > a. From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 05:15:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00404THRS7@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 01 Apr 2003 05:08:15 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00401THQS5@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:08:14 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00401THQS4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:08:14 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCN00LOXTHPN5@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 05:08:14 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h31A7133057568; Tue, 01 Apr 2003 12:07:05 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h31A6o0Z264294; Tue, 01 Apr 2003 12:06:51 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA36266 from ; Tue, 01 Apr 2003 12:06:49 +0200 Date: Tue, 01 Apr 2003 12:05:42 +0200 From: Brian E Carpenter Subject: Re: Should a CB approve a slate or individuals? To: Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <3E896476.6583BC39@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <3E88FED1.8020107@acm.org> <3E896384.6A1260B2@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Just to be clear, since I now realise that what Avri wrote was itself ambiguous. The Nomcom should present a complete slate. The confirming body should be able to reject individuals within that slate. That's what RFC 2727 and draft-ietf-nomcom-rfc2727bis-03.txt both say, in different words. This should not be changed. Brian Brian E Carpenter wrote: > > I fully support Mike. This would be a major change in the > formal rules and the practice followed for the last ten years. > I have seen no discussion that would motivate or justify > such a change. The rule should stay as it is > > The confirming bodies review their respective slate ...[and] > consent to some, all, or none of the candidates. > > MSJ has proposed some other changes to this key sentence, but > this part shouldn't change. > > Contrary to Avri, I find nothing ambiguous in RFC 2727 - it clearly > implies a complete slate. > > Brian > > Avri Doria wrote: > > > > Michael StJohns wrote: > > > > > At 05:05 PM 3/31/2003 -0500, Avri Doria wrote: > > > > > >> Re: the question of reviewing a slate as whole or as individual > > >> candidates. > > >> > > >> While more often the case in selecting the IAB then IESG, though > > >> it does occur in the IESG as well, a slate is often picked for its > > >> balance of talents. The recommendation of the DT is that a slate > > >> is sent to the CB as a whole and must be accepted as a whole. In > > >> rejecting a slate, the CB is certainly encouraged to indicate what > > >> parts of the slate it finds unacceptable, but the NomCom can > > >> reconsider the entire slate and resubmit a slate with different > > >> candidates, even if some of the replaced candidates were acceptable > > >> to the CB during its prior review. It is in keeping with this > > >> recommendation for the NomCom to submit a slate to the CB that does > > >> not fill all open roles. In this case, the presented slate counts > > >> as a unit and its approval is not affected by any later submissions. > > >> To reiterate, a slate can only be accepted in its entirety, but t > > >> here is no rule stating that a slate must fill every vacancy - a > > >> slate is defined as being a single list of names and positions > > >> presented to the CB for approval. > > >> It is considered approved and unchangeable once the CB notifies the > > >> NomCom that it has been accepted. > > > > > > > > > > > > No. Just no. Its unfair and unreasonable to expect the CB to be able > > > to balance individuals against a complete slate. The slate represents > > > no more than 1/2 of the sitting members of the body being appointed, the > > > change of one or two individuals based on a rejection should not be > > > considered to cause that much perturbation. In any event, any imbalance > > > can be fixed in the following year. > > > > > > Confirmations are discussed and decided upon based on the qualifications > > > of an individual, not on the ability of the slate as a whole to succeed > > > or fail. If I were managing the confirmation process for the IAB > > > (fortunately, that's Leslie's job), I wouldn't know how to frame the > > > question of whether to accept or reject a slate based on whether one or > > > more individuals were bad enough to prevent us from accepting the rest. > > > It may be possible to frame this for a single rejection, but you start > > > getting interesting combinatorial problems when you start thinking about > > > more than one unacceptable person. > > > > > > Please, leave this as a confirmation of individuals. If an individual > > > fails of confirmation, it shouldn't be that traumatic to suggest an > > > alternative, even if the balance among the whole slate isn't exactly > > > what the Nomcom hoped it would be. Think of it this way: if changing 1 > > > or 2 fully qualified candidates (out of 12 or 18 total members) causes > > > so much perturbation, there's a lot more wrong than the Nomcom can > > > actually fix. > > > > > > The suggestion that partial slates could go forward also fails. It > > > needlessly extends the process without actually adding to the quality of > > > the result. > > > > > > > I am curious to hear some discussion of the list on this issue. > > So far I think there have been only a few voices. While I need > > to review the list again, I think I have heard one voice for > > voting as a slate and one against. > > > > As for RFC2727, I think it was ambiguous on the notion of a slate > > of candidates versus single candidates. > > > > a. From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 05:15:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00404TLQUT@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 01 Apr 2003 05:10:39 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00401TLQUR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:10:38 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00401TLQUQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:10:38 -0500 (EST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCN00LPATLPN5@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 05:10:37 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h31A9Tdk062408; Tue, 01 Apr 2003 12:09:29 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h31A9T0Z156062; Tue, 01 Apr 2003 12:09:31 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA06924 from ; Tue, 01 Apr 2003 12:09:27 +0200 Date: Tue, 01 Apr 2003 12:08:20 +0200 From: Brian E Carpenter Subject: Re: Should NomCom rules define who has CB voting rights To: Avri Doria Cc: ietf-nomcom@lists.elistx.com Message-id: <3E896514.8BD2B43F@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <3E8900CF.7060406@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Avri Doria wrote: > > Michael StJohns wrote: > > > At 05:05 PM 3/31/2003 -0500, Avri Doria wrote: > > >> --- > >> Re: Is the IETF chair a sitting member of the IAB > >> > >> The DT recommends that it is not in the NomCom's purview to > >> decide whether IETF chair is a sitting member of IAB or not. > >> This decision is part of the IAB charter and should be determined > >> there. > > > > > > Sorry, wrong. Its clear its not in the Nomcom's purview, but it > > certainly is in this document's purview to indicate this. The IETF > > chair does not vote and should not vote on the composition of the IESG. > > > >> It is recommended, however, the advice go into the oral tradition > >> indicating that past history indicates a practice of the IETF chair > >> recusing him/herself from IAB confirming votes of the IESG. What we actually need is a normative reference to BCP 39 (RFC 2850, the IAB Charter) where this is stated explicitly. It's not a good idea to duplicate normative material, and this is moer than "oral tradition." Brian From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 05:15:11 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00404TOLXD@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 01 Apr 2003 05:12:21 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00401TOLXB@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:12:21 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00401TOKXA@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:12:20 -0500 (EST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCN0040VTOJLK@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 05:12:20 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h31AB4EO038242; Tue, 01 Apr 2003 12:11:04 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h31AB50Z170888; Tue, 01 Apr 2003 12:11:06 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52262 from ; Tue, 01 Apr 2003 12:11:03 +0200 Date: Tue, 01 Apr 2003 12:09:56 +0200 From: Brian E Carpenter Subject: Re: Should NomCom rules define who has CB voting rights To: Scott Bradner Cc: avri@acm.org, ietf-nomcom@lists.elistx.com Message-id: <3E896574.299CB16A@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <200304010317.h313H6gs003101@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Scott Bradner wrote: > > I agree with Mike - the IETF chair should not vote on the IESG > slate (and should not "vote" in any IAB process) The parenthesis is not correct. BCP 39 gives the IETF Chair full membership of the IAB, except for this issue and appeals against the IESG. Brian From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 05:25:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00504U408A@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 01 Apr 2003 05:21:37 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00501U4088@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:21:36 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00501U3Z87@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:21:35 -0500 (EST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCN00LQBU3ZN5@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 05:21:35 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h31AKNdk086436; Tue, 01 Apr 2003 12:20:26 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h31AKK0Z287718; Tue, 01 Apr 2003 12:20:21 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32106 from ; Tue, 01 Apr 2003 12:20:19 +0200 Date: Tue, 01 Apr 2003 12:19:12 +0200 From: Brian E Carpenter Subject: Re: Should someone be prohibited from serving in 2 roles? To: Avri Doria Cc: ietf-nomcom@lists.elistx.com Message-id: <3E8967A0.9E54A6AB@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <3E88FD90.7020003@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I agree with Mike, there was no discussion on the list which leads to a change from draft-ietf-nomcom-rfc2727bis-03.txt. One more comment in-line... Avri Doria wrote: > > Michael StJohns wrote: > > > At 05:05 PM 3/31/2003 -0500, Avri Doria wrote: > --- > >> > >> Re: Discretion of the IAB or IESG over whether a midterm > >> vacancies must be filled. > >> > >> 2727bis allegedly removed discretion for whether a mid-term > >> vacancy should be filled by the NomCom. > >> > >> Note: In rereading the document, I am not sure this is > >> the case. We certainly removed the discretion of > >> which NomCom picks if a position is to be filled. > >> Since a NomCom only fills position on instruction > >> from the ExDir and since the I* notifies the ExDir > >> of which positions to fill and since midterm vacancies > >> are filled under all standing rules other then those > >> having to do with which NomCom does the choosing, it > >> is not clear to me that we actually ever made the > >> change we think we made. > >> > >> The recommendation of the DT is that the discretion should remain > >> with the body that looses a member. This means that the language for > >> mid term vacancies should be clarified to indicate this. > >> Essentially, from the NomCom point of view, a vacancy exists only > >> when the ExDir informs it of a vacancy. The resignation per se > >> does not constitute such notification. > >> > >> ---- > >> > >> Re: Poaching rules > >> > >> It has been the practice of NomCom to not only choose candidates > >> from members of the other sitting body, but to nominate replacements > >> for that person at the same time. > >> > >> For several reasons, the DT believes this is inappropriate: > >> > >> - As a vacancy does not exist until a resignation occurs, there > >> is no vacancy until the candidate is confirmed. > >> - Further, it can be argued that since there is no rule against > >> serving on both bodies at the same time (though there is advice > >> against this practice), the position is not vacant until the > >> confirmed candidates resigns the prior position. > >> - As stated in the document and in the recommendation above, a > >> vacancy does not exist until the ExDir notifies the NomCom that > >> it does exist. > >> > >> There is, however, interest in keeping the process efficient. > >> the DT therefore decided to recommend a 2 stage process: > >> > >> 1. The candidate is confirmed and is advised to immediately > >> resign from the prior post. This resignation does not need to > >> be made public immediately, nor does it need to take effect > >> until a later time. The NomCom is notified of the pending > >> resignation by the ExDir. > >> 2. The NomCom then nominates a candidate for the 'to be vacant' > >> post. Since the NomCom can predict this vacancy, it can be > >> ready with a candidate. I think this is unnecessary complexity for a very narrowly conceived pseudo-legal reason, and a total waste of everybody's time. Let's just not go there. Leave the draft as it is. Brian > >> > >> An aside: We also do not have any rule against someone > >> holding 2 AD spots. I think this rule will also > >> cover the case of someone being nominated for a > >> different AD spot then they currently hold. As > >> to what happens if someone wishes to hold > >> both spots - that is not in the NomCom purview. > >> > >> ---- > >> > >> Re: Question of whether someone can be a member of both the IAB and > >> the IESG (or hold 2 AD spots) > >> > >> This was discussed earlier in this WG process and the consensus > >> was that while this is inadvisable, it should not be prohibited > >> by rule. Advise was therefore inserted in the advice section. > > > > > > > > The above three items interact poorly. Because a) there's no rule > > prohibiting being on both IAB and IESG, then b) there's no requirement > > that a person appointed to the IESG resign from the IAB, then c) the > > Nomcom shouldn't a priori nominate an IAB replacement. This actually > > happened this time around and caused more than a little consternation > > and confusion. Either being a member on both is prohibited - in which > > case the Nomcom can act to do the replacement as part of the > > confirmation process; or its not prohibited, which suggest its a very > > separate action from the normal replacement process. Pick one - PLEASE > > don't leave this to chance and good will. For example, what happens if > > IAB member A is nominated and confirmed for a position on the IESG, but > > refuses to resign from the IAB???? > > Then he or she would end up serving on both. > this was discussed at length and I believe that > the consensus was that while this is not to be > recommended, it should not be prohibited and > thus is advised against, but not prohibited. > > > > > Please simplify this by explicitly prohibiting dual membership - there > > is no real reason not to. > > I think there was an assumption that there was not an > absolute reason for forbidding it and therefore there > was no consensus for forbidding it. There was consensus > for recommending against it. > > a. From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 05:35:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00504UBRG1@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 01 Apr 2003 05:26:15 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00501UBRFZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:26:15 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCN00501UBQFY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 05:26:14 -0500 (EST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCN0050SUBP9B@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 05:26:14 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h31AOsEO013712; Tue, 01 Apr 2003 12:24:58 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h31AOt0Z261556; Tue, 01 Apr 2003 12:24:56 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47900 from ; Tue, 01 Apr 2003 12:24:48 +0200 Date: Tue, 01 Apr 2003 12:23:40 +0200 From: Brian E Carpenter Subject: Re: Should the NomCom rules define CB voting behavior To: Scott Bradner Cc: avri@acm.org, ietf-nomcom@lists.elistx.com Message-id: <3E8968AC.E713CA41@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <200304010321.h313Lq0s003117@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: 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 ietf-nomcom-errors@lists.elistx.com Tue Apr 1 10:35:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00F04868X5@eListX.com> (original mail from randy@psg.com); Tue, 01 Apr 2003 10:25:20 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00F01867WY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 10:25:20 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00F01867WV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 10:25:19 -0500 (EST) Received: from psg.com (psg.com [147.28.0.62]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO00AD886648@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 10:25:19 -0500 (EST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 190NcW-0006iK-00; Tue, 01 Apr 2003 07:24:16 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 190NcW-0000rn-00; Tue, 01 Apr 2003 07:24:16 -0800 Date: Tue, 01 Apr 2003 07:24:15 -0800 From: Randy Bush Subject: Re: Should a CB approve a slate or individuals? To: Geoff Huston Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <5.1.0.14.2.20030401125736.017a14b0@kahuna.telstra.net> <5.1.0.14.2.20030401184808.016cad80@kahuna.telstra.net> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > I would like to think that the IESG and IAB folk have been > nominated by their peers because they are regarded as being > qualified _as individuals_ to do the task, and I would be much > more comfortable if the confirming bodies had the ability to see > the nominations as a set of individual nominations and reviewed > then as a collection of individuals, rather than a 'take it or > reject it' package. this completely ignores the common business practice of the culture of a "management team" which works well *together*. there is a very good reason that this is often the *first* criterion which VCs use when making decisions about funding. randy From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 10:35:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00G048E54X@eListX.com> (original mail from mstjohns@mindspring.com) ; Tue, 01 Apr 2003 10:30:05 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00G018E44V@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 10:30:05 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00G018E44U@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 10:30:04 -0500 (EST) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO00F1C8E3J8@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 10:30:04 -0500 (EST) Received: by sentry.gw.tislabs.com; id KAA25151; Tue, 01 Apr 2003 10:29:56 -0500 (EST) Received: from dyn083.gw.tislabs.com(10.33.10.83) by sentry.gw.tislabs.com via smap (V5.5) id xma025140; Tue, 01 Apr 2003 10:29:43 -0500 Date: Tue, 01 Apr 2003 10:28:34 -0500 From: Michael StJohns Subject: Re: Notes from one member of the IAB on the current draft In-reply-to: <3E894507.F6BAEA10@hursley.ibm.com> X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: Brian E Carpenter Cc: ietf-nomcom@lists.elistx.com, iab@ietf.org Message-id: <5.1.0.14.2.20030401101934.05dbcb18@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <7309347.1048615982203.JavaMail.nobody@wamui04.slb.atl.earthlink.net> <5.1.0.14.2.20030331093500.05d65680@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: At 09:51 AM 4/1/2003 +0200, Brian E Carpenter wrote: >Mike, > >I am OK with your comments. One remark at the very end... > > > > and in the case of > > > the IESG, may possibly change the positions to which already > > > confirmed candidates are appointed. > > > > NO. For all the reasons I've stated before. There is no reason the > Nomcom can't ASK a selectee if they'll give up their > > position, but they don't get to do it unilaterally. Also, as stated > implies that the nomcom can take any confirmee and stick > > them in any slot without further reference to the confirming body. > >I agree, it shouldn't be unilateral, in the case where a nominee has >already been informed. But the language mustn't be too rigid, either, >because it's entirely possible that a nominee has already told the >Nomcom that s/he would accept either of a couple of positions. Try > > and in the case of > the IESG, may optionally propose a change in the positions to > which already confirmed nominees are appointed, with the > consent of those nominees and the approving body. Hi Brian - The reason I've been so adamant about the above is that its really the argument between whether confirmation is by person or by slate. If the Nomcom has the ability to shuffle already confirmed folks without asking permission of anyone (the CB or the person confirmed) then the process is effectively confirmation by slate. N.B.: If the confirming body rejected a single candidate but approved everyone else, the Nomcom could, under the language I've seen, withdraw the entire slate and submit a whole new group of folks for confirmation. The language you suggest does fix this - and I like the idea that the confirming body, in addition to the confirmed nominee (regardless of whether they've been notified) have to approve this. Thanks - Mike From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 10:55:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00H049DIAI@eListX.com> (original mail from joel@stevecrocker.com) ; Tue, 01 Apr 2003 10:51:18 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00H019DIAG@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 10:51:18 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00H019DIAF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 10:51:18 -0500 (EST) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO00AHV9DH48@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 10:51:17 -0500 (EST) Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4450324 for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 10:50:15 -0500 Date: Tue, 01 Apr 2003 10:49:33 -0500 From: "Joel M. Halpern" Subject: Re: Should the NomCom rules define CB voting behavior In-reply-to: <3E8900F9.1070102@acm.org> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com To: ietf-nomcom@lists.elistx.com Message-id: <5.1.0.14.0.20030401104843.018a8818@mail.stevecrocker.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: 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: From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 11:05:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00H049UNRA@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 01 Apr 2003 11:01:35 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00H019UMR8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 11:01:34 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00H019UMR7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 11:01:34 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO00H0L9ULML@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 11:01:34 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h31G0433106072; Tue, 01 Apr 2003 18:00:05 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h31G030Z247668; Tue, 01 Apr 2003 18:00:04 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23614 from ; Tue, 01 Apr 2003 17:59:59 +0200 Date: Tue, 01 Apr 2003 17:58:52 +0200 From: Brian E Carpenter Subject: Re: Should a CB approve a slate or individuals? To: Harald Tveit Alvestrand Cc: Geoff Huston , Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <3E89B73C.CBD4C73@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <5.1.0.14.2.20030401125736.017a14b0@kahuna.telstra.net> <79040000.1049183290@askvoll.hjemme.alvestrand.no> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: below... Harald Tveit Alvestrand wrote: > > --On tirsdag, april 01, 2003 13:02:29 +1000 Geoff Huston > wrote: > > > I am of the view that the most effective process is one of individual > > confirmation or rejection , rather than confirmation or rejection of the > > entire slate of names. > > > > The task here is to pick the best qualified individuals for each open > > position, and the focus should be on the attributes of the individual to > > the requirements of the open position. Treating this as a slate tends to > > make the entire confirmation process tougher. > > There have been cases in the past where it's been quite obvious that two > people should not serve on the IESG together. Mostly because of fundamental > disagreements about how to run a single area ("incompatibe co-ADs"), but > there could be other versions of this problem. > > If A and B were both considered "good people" by Nomcom, and A was > advanced, but rejected, it would be logical for Nomcom to consider putting > B into another slot for which he was better qualified than the original > proposal, since the consideration that blocked him from being considered > has gone away. > > Similarly, if A was advanced, and accepted, but another candidate was > rejected, and B was the only reasonable alternative, the Nomcom would > logically have to consider withdrawing A from the slate. > > Locking the process to "individuals only" would then produce a suboptimal > result. > > That's not what we expect to be the common case, but I'd like to have the > possibility open. > Since this part of RFC 2727 isn't broken, why are we trying to fix it? Brian From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 11:15:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00I04AGYF4@eListX.com> (original mail from PRoberts@MEGISTO.com); Tue, 01 Apr 2003 11:14:58 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00I01AGXF2@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 11:14:57 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00I01AGXF1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 11:14:57 -0500 (EST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO00I0GAGX62@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 11:14:57 -0500 (EST) Received: by megisto-sql1 with Internet Mail Service (5.5.2653.19) id ; Tue, 01 Apr 2003 11:07:58 -0500 Content-return: allowed Date: Tue, 01 Apr 2003 11:07:58 -0500 From: Phil Roberts Subject: RE: Should a CB approve a slate or individuals? To: 'Brian E Carpenter' , Harald Tveit Alvestrand Cc: Geoff Huston , Avri Doria , ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On a close rereading of the text the last sentence of the first paragraph below seems operative, so I agree with Brian, this part of 2727bis-03 doesn't need to be modified. If some or none of the candidates submitted to a confirming body are confirmed, the confirming body continues to consult with the nominating committee both to explain the reason why all the candidates were not confirmed and to understand the nominating committee's rationale for the slate. During the course of the consultation the nominating committee may re-examine the slate of candidates and may change it in any way. The confirming body may reject individual candidates, in which case the nominating committee must select alternate candidates for the rejected candidates. > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, April 01, 2003 10:59 AM > To: Harald Tveit Alvestrand > Cc: Geoff Huston; Avri Doria; ietf-nomcom@lists.elistx.com > Subject: Re: Should a CB approve a slate or individuals? > > > below... > > Harald Tveit Alvestrand wrote: > > > > --On tirsdag, april 01, 2003 13:02:29 +1000 Geoff Huston > > > > wrote: > > > > > I am of the view that the most effective process is one of > > > individual confirmation or rejection , rather than > confirmation or > > > rejection of the entire slate of names. > > > > > > The task here is to pick the best qualified individuals for each > > > open position, and the focus should be on the attributes of the > > > individual to the requirements of the open position. > Treating this > > > as a slate tends to make the entire confirmation process tougher. > > > > There have been cases in the past where it's been quite > obvious that > > two people should not serve on the IESG together. Mostly because of > > fundamental disagreements about how to run a single area > ("incompatibe > > co-ADs"), but there could be other versions of this problem. > > > > If A and B were both considered "good people" by Nomcom, and A was > > advanced, but rejected, it would be logical for Nomcom to consider > > putting B into another slot for which he was better > qualified than the > > original proposal, since the consideration that blocked him > from being > > considered has gone away. > > > > Similarly, if A was advanced, and accepted, but another > candidate was > > rejected, and B was the only reasonable alternative, the > Nomcom would > > logically have to consider withdrawing A from the slate. > > > > Locking the process to "individuals only" would then produce a > > suboptimal result. > > > > That's not what we expect to be the common case, but I'd > like to have > > the possibility open. > > > > Since this part of RFC 2727 isn't broken, why are we trying to fix it? > > Brian > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: > From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 11:35:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00I04AXSYN@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 01 Apr 2003 11:25:04 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00I01AXRY3@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 11:25:03 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00I01AXQXS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 11:25:02 -0500 (EST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO00I1MAXO62@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 11:25:01 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h31GNmdk039482; Tue, 01 Apr 2003 18:23:51 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h31GNj0Z222466; Tue, 01 Apr 2003 18:23:46 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23760 from ; Tue, 01 Apr 2003 18:23:32 +0200 Date: Tue, 01 Apr 2003 18:22:25 +0200 From: Brian E Carpenter Subject: Re: Should the NomCom rules define CB voting behavior To: "Joel M. Halpern" Cc: ietf-nomcom@lists.elistx.com Message-id: <3E89BCC1.C3E97D2E@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <5.1.0.14.0.20030401104843.018a8818@mail.stevecrocker.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: 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? From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 12:05:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00K04CKVKP@eListX.com> (original mail from mstjohns@mindspring.com) ; Tue, 01 Apr 2003 12:00:31 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00K01CKRKI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 12:00:31 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00K01CKQKH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 12:00:26 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO00I7OCKM61@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 12:00:22 -0500 (EST) Received: from [192.168.167.42] (helo=wamui04.slb.atl.earthlink.net) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 190P6M-0001yo-00; Tue, 01 Apr 2003 11:59:10 -0500 Received: from [192.168.167.57] by EarthlinkWAM via HTTP; Tue Apr 01 11:59:10 EST 2003 Date: Tue, 01 Apr 2003 11:58:59 -0500 (GMT) From: Michael StJohns Subject: Re: RE: Should a CB approve a slate or individuals? To: Phil Roberts , 'Brian E Carpenter' , Harald Tveit Alvestrand Cc: Geoff Huston , Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <5538769.1049216350922.JavaMail.nobody@wamui04.slb.atl.earthlink.net> MIME-version: 1.0 X-Mailer: Earthlink Web Access Mail version 3.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I'm not certain, but I think Brian was referring to RFC2727 while you were referring to the ID. Personally, I think that paragraph in the ID is broken. -------Original Message------- From: Phil Roberts Sent: 04/01/03 11:07 AM To: 'Brian E Carpenter' , Harald Tveit Alvestrand Subject: RE: Should a CB approve a slate or individuals? > > On a close rereading of the text the last sentence of the first paragraph below seems operative, so I agree with Brian, this part of 2727bis-03 doesn't need to be modified. If some or none of the candidates submitted to a confirming body are confirmed, the confirming body continues to consult with the nominating committee both to explain the reason why all the candidates were not confirmed and to understand the nominating committee's rationale for the slate. During the course of the consultation the nominating committee may re-examine the slate of candidates and may change it in any way. The confirming body may reject individual candidates, in which case the nominating committee must select alternate candidates for the rejected candidates. > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, April 01, 2003 10:59 AM > To: Harald Tveit Alvestrand > Cc: Geoff Huston; Avri Doria; ietf-nomcom@lists.elistx.com > Subject: Re: Should a CB approve a slate or individuals? > > > below... > > Harald Tveit Alvestrand wrote: > > > > --On tirsdag, april 01, 2003 13:02:29 +1000 Geoff Huston > > > > wrote: > > > > > I am of the view that the most effective process is one of > > > individual confirmation or rejection , rather than > confirmation or > > > rejection of the entire slate of names. > > > > > > The task here is to pick the best qualified individuals for each > > > open position, and the focus should be on the attributes of the > > > individual to the requirements of the open position. > Treating this > > > as a slate tends to make the entire confirmation process tougher. > > > > There have been cases in the past where it's been quite > obvious that > > two people should not serve on the IESG together. Mostly because of > > fundamental disagreements about how to run a single area > ("incompatibe > > co-ADs"), but there could be other versions of this problem. > > > > If A and B were both considered "good people" by Nomcom, and A was > > advanced, but rejected, it would be logical for Nomcom to consider > > putting B into another slot for which he was better > qualified than the > > original proposal, since the consideration that blocked him > from being > > considered has gone away. > > > > Similarly, if A was advanced, and accepted, but another > candidate was > > rejected, and B was the only reasonable alternative, the > Nomcom would > > logically have to consider withdrawing A from the slate. > > > > Locking the process to "individuals only" would then produce a > > suboptimal result. > > > > That's not what we expect to be the common case, but I'd > like to have > > the possibility open. > > > > Since this part of RFC 2727 isn't broken, why are we trying to fix it? > > Brian > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: > From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 14:05:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00304I2O9U@eListX.com> (original mail from mstjohns@mindspring.com) ; Tue, 01 Apr 2003 13:59:12 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00301I2O9S@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 13:59:12 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00301I2O9R@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 13:59:12 -0500 (EST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO00184I2N1D@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 13:59:11 -0500 (EST) Received: from [192.168.167.42] (helo=wamui04.slb.atl.earthlink.net) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 190QxB-0004dx-00; Tue, 01 Apr 2003 13:57:49 -0500 Received: from [192.168.167.62] by EarthlinkWAM via HTTP; Tue Apr 01 13:57:50 EST 2003 Date: Tue, 01 Apr 2003 13:57:36 -0500 (GMT) From: Michael StJohns Subject: Re: Re: Should the NomCom rules define CB voting behavior To: Brian E Carpenter , "Joel M. Halpern" Cc: ietf-nomcom@lists.elistx.com Message-id: <2319593.1049223470228.JavaMail.nobody@wamui04.slb.atl.earthlink.net> MIME-version: 1.0 X-Mailer: Earthlink Web Access Mail version 3.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: 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 Sent: 04/01/03 11:22 AM To: "Joel M. Halpern" 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: > From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 14:15:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00304IFHNR@eListX.com> (original mail from joel@stevecrocker.com) ; Tue, 01 Apr 2003 14:06:54 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00301IFHNP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 14:06:53 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00301IFHNO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 14:06:53 -0500 (EST) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO00174IFGTE@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 14:06:52 -0500 (EST) Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4450944 for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 14:05:49 -0500 Date: Tue, 01 Apr 2003 14:04:59 -0500 From: "Joel M. Halpern" Subject: Re: Re: Should the NomCom rules define CB voting behavior In-reply-to: <2319593.1049223470228.JavaMail.nobody@wamui04.slb.atl.eart hlink.net> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com To: ietf-nomcom@lists.elistx.com Message-id: <5.1.0.14.0.20030401140024.01892538@mail.stevecrocker.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: 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 >Sent: 04/01/03 11:22 AM >To: "Joel M. Halpern" >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: > > From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 14:55:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00504K9IC4@eListX.com> (original mail from avri@acm.org); Tue, 01 Apr 2003 14:46:30 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00501K9IC2@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 14:46:30 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00501K9HC1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 14:46:29 -0500 (EST) Received: from lakecm2mtao01.coxmail.com (lakecm2mtao01.coxmail.com [68.99.120.68]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO001GOK9HTE@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 14:46:29 -0500 (EST) Received: from acm.org ([68.15.42.104]) by lakecm2mtao01.coxmail.com (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030401194526.JQPB25617.lakecm2mtao01.coxmail.com@acm.org> for ; Tue, 01 Apr 2003 14:45:26 -0500 Date: Tue, 01 Apr 2003 14:43:30 -0500 From: Avri Doria Subject: Re: Should the NomCom rules define CB voting behavior To: ietf-nomcom@lists.elistx.com Message-id: <3E89EBE2.9070809@acm.org> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 References: <2319593.1049223470228.JavaMail.nobody@wamui04.slb.atl.earthlink.net> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: 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 ietf-nomcom-errors@lists.elistx.com Tue Apr 1 16:55:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00B04PW3F6@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Tue, 01 Apr 2003 16:48:03 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00B01PW3F4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 16:48:03 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00B01PW2F2@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 16:48:02 -0500 (EST) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO006M6PW19S@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 16:48:02 -0500 (EST) Date: Tue, 01 Apr 2003 16:47:18 -0500 (Eastern Standard Time) From: James M Galvin Subject: Re: Should someone be prohibited from serving in 2 roles? In-reply-to: <5.1.0.14.2.20030331222115.05db8de8@pop.mindspring.com> To: Michael StJohns Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <5.1.0.14.2.20030331222115.05db8de8@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Speaking as editor of the document: On Mon, 31 Mar 2003, Michael StJohns wrote: At 09:46 PM 3/31/2003 -0500, Avri Doria wrote: >Michael StJohns wrote: >Either being a member on both is prohibited - in which > > case the Nomcom can act to do the replacement as part of the > > confirmation process; or its not prohibited, which suggest its a very > > separate action from the normal replacement process. Pick one - PLEASE > > don't leave this to chance and good will. Just to be clear about my instructions, there has never been working group consensus to prohibit a person from serving on both the IAB and the IESG (the IETF Chair is a special case). Thus, I have not been directed to make any change with respect to this issue. > > For example, what happens if > > IAB member A is nominated and confirmed for a position on the IESG, but > > refuses to resign from the IAB???? This is actually two different threads which have some interaction. The first thread is the interaction between the question of whether or not someone should serve on both boards with the question of when the Nomcom should act to replace someone who's on one board who is then confirmed on the other. You are exactly correct and the proposed text is -- in my opinion -- more of a clarification than a change. Specifically, the recommendation from the design team is to address the issue of "poaching an individual from one body for another" by calling it out and ensuring it is processed according the rules as currently specified in the rest of the document. What this means is that a vacancy does not exist until it is "announced". For this reason there needs to be a two step process. The NOMCOM proposes a slate that includes the person being poached. After that slate is fully confirmed -- through ordinary process -- then the poached person gets to decide if they are going to resign or not (see note above about serving on two bodies). Presumably all those involved actually know about the resignation in advance, just as a practical matter. However it is not required. Assuming the poached person resigns, then the NOMCOM addresses the issue of a slate for the new vacancy. Since presumably all the relevant parties knew about the resignation in advance, the NOMCOM can prepare in advance to deal with this vacancy. Note, too, that the clarification will not require all this to be public. The resignation can be confidential and set to take effect at some time in the future. It will be become public when the slates are announced. This is the wiggle room that will be allowed in the timing of the process. Jim From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 17:15:06 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00C04QU1JO@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Tue, 01 Apr 2003 17:08:26 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00C01QU1JM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 17:08:25 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00C01QU1JL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 17:08:25 -0500 (EST) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO00B2VQU0ZK@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 17:08:24 -0500 (EST) Date: Tue, 01 Apr 2003 17:07:41 -0500 (Eastern Standard Time) From: James M Galvin Subject: Re: Should a CB approve a slate or individuals? In-reply-to: <3E88FED1.8020107@acm.org> To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <3E88FED1.8020107@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Speaking as editor of the document: Let me try some a different description of this issue that should either clear up any confusion or make it clear there is an issue. The instructions I have are as follows: The principles to be documented are: * The NOMCOM can change any part of the slate at any time up to the time the entire slate is approved. * The confirming body can reject any single candidate or more than one candidate, including the entire slate. The second bullet above has always been clear and unambiguous in the document. I regard the first item as a clarification based on my understanding of the intent of the rules overall but, regardless, it is fair to say the document has always been ambiguous on this point. On the whole, it is the NOMCOM's job to present a slate that best embodies all of the requirements it believes the community wants. One of those qualities surely includes "the ability to work as a team." With that in mind, if the confirming body rejects a particular individual, it seems like a reasonable interpretation of the rules to permit the NOMCOM to completely or partially change its original slate. All I have been instructed to do is to make that point clear. No other changes will occur. However, there are some logical consequence from documenting the principles as stated. Specifically, the NOMCOM can submit a partial slate to the confirming body. In addition, as a confirming body receives each partial slate, one of the criteria it may use to evaluate the current partial slate is how it "teams" with the prior slate. Although the confirming body may *not* change its mind about a prior partial slate, it can reject the new partial slate. This issue would be resolved during the communication between the NOMCOM and the confirming body when the new partial slate is rejected, according to the ordinary process. Jim On Mon, 31 Mar 2003, Avri Doria wrote: Date: Mon, 31 Mar 2003 21:52:01 -0500 From: Avri Doria To: ietf-nomcom@lists.elistx.com Subject: Should a CB approve a slate or individuals? Michael StJohns wrote: > At 05:05 PM 3/31/2003 -0500, Avri Doria wrote: > >> Re: the question of reviewing a slate as whole or as individual >> candidates. >> >> While more often the case in selecting the IAB then IESG, though >> it does occur in the IESG as well, a slate is often picked for its >> balance of talents. The recommendation of the DT is that a slate >> is sent to the CB as a whole and must be accepted as a whole. In >> rejecting a slate, the CB is certainly encouraged to indicate what >> parts of the slate it finds unacceptable, but the NomCom can >> reconsider the entire slate and resubmit a slate with different >> candidates, even if some of the replaced candidates were acceptable >> to the CB during its prior review. It is in keeping with this >> recommendation for the NomCom to submit a slate to the CB that does >> not fill all open roles. In this case, the presented slate counts >> as a unit and its approval is not affected by any later submissions. >> To reiterate, a slate can only be accepted in its entirety, but t >> here is no rule stating that a slate must fill every vacancy - a >> slate is defined as being a single list of names and positions >> presented to the CB for approval. >> It is considered approved and unchangeable once the CB notifies the >> NomCom that it has been accepted. > > > > No. Just no. Its unfair and unreasonable to expect the CB to be able > to balance individuals against a complete slate. The slate represents > no more than 1/2 of the sitting members of the body being appointed, the > change of one or two individuals based on a rejection should not be > considered to cause that much perturbation. In any event, any imbalance > can be fixed in the following year. > > Confirmations are discussed and decided upon based on the qualifications > of an individual, not on the ability of the slate as a whole to succeed > or fail. If I were managing the confirmation process for the IAB > (fortunately, that's Leslie's job), I wouldn't know how to frame the > question of whether to accept or reject a slate based on whether one or > more individuals were bad enough to prevent us from accepting the rest. > It may be possible to frame this for a single rejection, but you start > getting interesting combinatorial problems when you start thinking about > more than one unacceptable person. > > Please, leave this as a confirmation of individuals. If an individual > fails of confirmation, it shouldn't be that traumatic to suggest an > alternative, even if the balance among the whole slate isn't exactly > what the Nomcom hoped it would be. Think of it this way: if changing 1 > or 2 fully qualified candidates (out of 12 or 18 total members) causes > so much perturbation, there's a lot more wrong than the Nomcom can > actually fix. > > The suggestion that partial slates could go forward also fails. It > needlessly extends the process without actually adding to the quality of > the result. > I am curious to hear some discussion of the list on this issue. So far I think there have been only a few voices. While I need to review the list again, I think I have heard one voice for voting as a slate and one against. As for RFC2727, I think it was ambiguous on the notion of a slate of candidates versus single candidates. a. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: From ietf-nomcom-errors@lists.elistx.com Tue Apr 1 17:15:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00C02QXBN8@eListX.com> (original mail from ietf-nomcom+moderator@lists.elistx.com); Tue, 01 Apr 2003 17:10:23 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00C01QXAN7@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 17:10:23 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00C01QXAN6@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com) ; Tue, 01 Apr 2003 17:10:22 -0500 (EST) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00C04QX9N3@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 17:10:21 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00C01QX9N1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 17:10:21 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCO00C01QX9MZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 01 Apr 2003 17:10:21 -0500 (EST) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCO00B1UQX8K7@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 01 Apr 2003 17:10:20 -0500 (EST) Date: Tue, 01 Apr 2003 17:09:37 -0500 (Eastern Standard Time) From: James M Galvin Subject: Re: Should NomCom rules define who has CB voting rights In-reply-to: <3E896514.8BD2B43F@hursley.ibm.com> To: Brian E Carpenter Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <3E8900CF.7060406@acm.org> <3E896514.8BD2B43F@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Speaking as editor of the document: On Tue, 1 Apr 2003, Brian E Carpenter wrote: > >> It is recommended, however, the advice go into the oral tradition > >> indicating that past history indicates a practice of the IETF chair > >> recusing him/herself from IAB confirming votes of the IESG. What we actually need is a normative reference to BCP 39 (RFC 2850, the IAB Charter) where this is stated explicitly. It's not a good idea to duplicate normative material, and this is moer than "oral tradition." I will do this. Jim From ietf-nomcom-errors@lists.elistx.com Wed Apr 2 01:55:06 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00604F6FZQ@eListX.com> (original mail from harald@alvestrand.no); Wed, 02 Apr 2003 01:54:15 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00601F6EZO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 01:54:14 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00601F6EZN@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 01:54:14 -0500 (EST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCP00MKBF6DDD@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 02 Apr 2003 01:54:14 -0500 (EST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 42C726223F; Wed, 02 Apr 2003 08:53:11 +0200 (CEST) Date: Wed, 02 Apr 2003 08:53:11 +0200 From: Harald Tveit Alvestrand Subject: Re: Re: Should the NomCom rules define CB voting behavior In-reply-to: <2319593.1049223470228.JavaMail.nobody@wamui04.slb.atl.earthlink.net> To: Michael StJohns , Brian E Carpenter , "Joel M. Halpern" Cc: ietf-nomcom@lists.elistx.com Message-id: <183740000.1049266391@askvoll.hjemme.alvestrand.no> MIME-version: 1.0 X-Mailer: Mulberry/2.2.1 (Linux/x86) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <2319593.1049223470228.JavaMail.nobody@wamui04.slb.atl.earthlink.net> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On tirsdag, april 01, 2003 13:57:36 -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. 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 ietf-nomcom-errors@lists.elistx.com Wed Apr 2 03:55:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00B04KO2KH@eListX.com> (original mail from brian@hursley.ibm.com) ; Wed, 02 Apr 2003 03:52:50 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00B01KO2K9@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 03:52:50 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00B01KO1K7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 03:52:49 -0500 (EST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCP008M7KO072@eListX.com>; Wed, 02 Apr 2003 03:52:49 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.8) with ESMTP id h328pini010834; Wed, 02 Apr 2003 10:51:44 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h328pivv257496; Wed, 02 Apr 2003 10:51:44 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40026 from ; Wed, 02 Apr 2003 10:51:42 +0200 Date: Wed, 02 Apr 2003 10:50:34 +0200 From: Brian E Carpenter Subject: Re: Should a CB approve a slate or individuals? To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <3E8AA45A.F53304F@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <3E88FED1.8020107@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Jim, I think the 2 person consensus I reached with Mike StJ is that your first bullet is incomplete, because it implies a unilateral decision by Nomcom to change a nomination that may already have been confirmed. Thus I supplied some text that states explicitly that both the confirming body and the nominee have to agree to any musical chairs. Brian James M Galvin wrote: > > Speaking as editor of the document: > > Let me try some a different description of this issue that should either > clear up any confusion or make it clear there is an issue. > > The instructions I have are as follows: > > The principles to be documented are: > > * The NOMCOM can change any part of the slate at any time up to the > time the entire slate is approved. > > * The confirming body can reject any single candidate or more than one > candidate, including the entire slate. > > The second bullet above has always been clear and unambiguous in the > document. I regard the first item as a clarification based on my > understanding of the intent of the rules overall but, regardless, it is > fair to say the document has always been ambiguous on this point. > > On the whole, it is the NOMCOM's job to present a slate that best > embodies all of the requirements it believes the community wants. One > of those qualities surely includes "the ability to work as a team." > > With that in mind, if the confirming body rejects a particular > individual, it seems like a reasonable interpretation of the rules to > permit the NOMCOM to completely or partially change its original slate. > All I have been instructed to do is to make that point clear. No other > changes will occur. > > However, there are some logical consequence from documenting the > principles as stated. Specifically, the NOMCOM can submit a partial > slate to the confirming body. In addition, as a confirming body > receives each partial slate, one of the criteria it may use to evaluate > the current partial slate is how it "teams" with the prior slate. > Although the confirming body may *not* change its mind about a prior > partial slate, it can reject the new partial slate. > > This issue would be resolved during the communication between the NOMCOM > and the confirming body when the new partial slate is rejected, > according to the ordinary process. > > Jim > > On Mon, 31 Mar 2003, Avri Doria wrote: > > Date: Mon, 31 Mar 2003 21:52:01 -0500 > From: Avri Doria > To: ietf-nomcom@lists.elistx.com > Subject: Should a CB approve a slate or individuals? > > Michael StJohns wrote: > > > At 05:05 PM 3/31/2003 -0500, Avri Doria wrote: > > > >> Re: the question of reviewing a slate as whole or as individual > >> candidates. > >> > >> While more often the case in selecting the IAB then IESG, though > >> it does occur in the IESG as well, a slate is often picked for its > >> balance of talents. The recommendation of the DT is that a slate > >> is sent to the CB as a whole and must be accepted as a whole. In > >> rejecting a slate, the CB is certainly encouraged to indicate what > >> parts of the slate it finds unacceptable, but the NomCom can > >> reconsider the entire slate and resubmit a slate with different > >> candidates, even if some of the replaced candidates were acceptable > >> to the CB during its prior review. It is in keeping with this > >> recommendation for the NomCom to submit a slate to the CB that does > >> not fill all open roles. In this case, the presented slate counts > >> as a unit and its approval is not affected by any later submissions. > >> To reiterate, a slate can only be accepted in its entirety, but t > >> here is no rule stating that a slate must fill every vacancy - a > >> slate is defined as being a single list of names and positions > >> presented to the CB for approval. > >> It is considered approved and unchangeable once the CB notifies the > >> NomCom that it has been accepted. > > > > > > > > No. Just no. Its unfair and unreasonable to expect the CB to be able > > to balance individuals against a complete slate. The slate represents > > no more than 1/2 of the sitting members of the body being appointed, the > > change of one or two individuals based on a rejection should not be > > considered to cause that much perturbation. In any event, any imbalance > > can be fixed in the following year. > > > > Confirmations are discussed and decided upon based on the qualifications > > of an individual, not on the ability of the slate as a whole to succeed > > or fail. If I were managing the confirmation process for the IAB > > (fortunately, that's Leslie's job), I wouldn't know how to frame the > > question of whether to accept or reject a slate based on whether one or > > more individuals were bad enough to prevent us from accepting the rest. > > It may be possible to frame this for a single rejection, but you start > > getting interesting combinatorial problems when you start thinking about > > more than one unacceptable person. > > > > Please, leave this as a confirmation of individuals. If an individual > > fails of confirmation, it shouldn't be that traumatic to suggest an > > alternative, even if the balance among the whole slate isn't exactly > > what the Nomcom hoped it would be. Think of it this way: if changing 1 > > or 2 fully qualified candidates (out of 12 or 18 total members) causes > > so much perturbation, there's a lot more wrong than the Nomcom can > > actually fix. > > > > The suggestion that partial slates could go forward also fails. It > > needlessly extends the process without actually adding to the quality of > > the result. > > > > I am curious to hear some discussion of the list on this issue. > So far I think there have been only a few voices. While I need > to review the list again, I think I have heard one voice for > voting as a slate and one against. > > As for RFC2727, I think it was ambiguous on the notion of a slate > of candidates versus single candidates. > > a. > From ietf-nomcom-errors@lists.elistx.com Wed Apr 2 04:15:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00C04LOB81@eListX.com> (original mail from brian@hursley.ibm.com) ; Wed, 02 Apr 2003 04:14:35 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00C01LOA7Z@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 04:14:35 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00C01LOA7Y@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 04:14:34 -0500 (EST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCP008OJLO972@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 02 Apr 2003 04:14:34 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.8) with ESMTP id h329DR5c024632; Wed, 02 Apr 2003 11:13:28 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h329DRvv279798; Wed, 02 Apr 2003 11:13:27 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA56340 from ; Wed, 02 Apr 2003 11:13:26 +0200 Date: Wed, 02 Apr 2003 11:12:19 +0200 From: Brian E Carpenter Subject: Re: Should the NomCom rules define CB voting behavior To: Avri Doria Cc: ietf-nomcom@lists.elistx.com Message-id: <3E8AA973.7013459@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <2319593.1049223470228.JavaMail.nobody@wamui04.slb.atl.earthlink.net> <3E89EBE2.9070809@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: 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 Avri Doria wrote: > > 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 ietf-nomcom-errors@lists.elistx.com Wed Apr 2 07:55:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00I04VNNNR@eListX.com> (original mail from brian@hursley.ibm.com) ; Wed, 02 Apr 2003 07:50:11 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00I01VNNNP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 07:50:11 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00I01VNMNO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 07:50:10 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCP00CE3VNLQT@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 02 Apr 2003 07:50:10 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h32Cn4IX028786 for ; Wed, 02 Apr 2003 14:49:05 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h32Cn3vv211524 for ; Wed, 02 Apr 2003 14:49:04 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27070 from ; Wed, 02 Apr 2003 14:49:02 +0200 Date: Wed, 02 Apr 2003 14:47:55 +0200 From: Brian E Carpenter Subject: Re: Should the NomCom rules define CB voting behavior To: ietf-nomcom@lists.elistx.com Message-id: <3E8ADBFB.E9908100@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <2319593.1049223470228.JavaMail.nobody@wamui04.slb.atl.earthlink.net> <183740000.1049266391@askvoll.hjemme.alvestrand.no> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: 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. However, a question about Harald's parenthesis: > (The question of whether the IAB should document its rules for deciding on > 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 Harald Tveit Alvestrand wrote: > > --On tirsdag, april 01, 2003 13:57:36 -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. 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 > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: From ietf-nomcom-errors@lists.elistx.com Wed Apr 2 08:35:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00K04XLTUM@eListX.com> (original mail from harald@alvestrand.no); Wed, 02 Apr 2003 08:32:17 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00K01XLTUI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 08:32:17 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00K01XLTUH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 08:32:17 -0500 (EST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCP00J27XLSSW@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 02 Apr 2003 08:32:16 -0500 (EST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 672886238C; Wed, 02 Apr 2003 15:31:12 +0200 (CEST) Date: Wed, 02 Apr 2003 15:31:12 +0200 From: Harald Tveit Alvestrand Subject: Re: Should the NomCom rules define CB voting behavior In-reply-to: <3E8ADBFB.E9908100@hursley.ibm.com> To: Brian E Carpenter , ietf-nomcom@lists.elistx.com Message-id: <213530000.1049290272@askvoll.hjemme.alvestrand.no> MIME-version: 1.0 X-Mailer: Mulberry/2.2.1 (Linux/x86) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <2319593.1049223470228.JavaMail.nobody@wamui04.slb.atl.earthlink.net> <183740000.1049266391@askvoll.hjemme.alvestrand.no> <3E8ADBFB.E9908100@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On onsdag, april 02, 2003 14:47:55 +0200 Brian E Carpenter wrote: > 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. > > However, a question about Harald's parenthesis: > >> (The question of whether the IAB should document its rules for deciding >> on 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? 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 ietf-nomcom-errors@lists.elistx.com Wed Apr 2 08:55:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00M04YD0HK@eListX.com> (original mail from mstjohns@mindspring.com) ; Wed, 02 Apr 2003 08:48:37 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00M01YD0HI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 08:48:36 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCP00M01YD0HH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 08:48:36 -0500 (EST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCP00J3QYCZSW@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 02 Apr 2003 08:48:35 -0500 (EST) Received: from pcp802197pcs.nrockv01.md.comcast.net ([68.48.86.43] helo=STJOHNS-LAPTOP.mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:DES-CBC3-SHA:168) (Exim 3.33 #1) id 190ia2-0005Qa-00; Wed, 02 Apr 2003 05:47:06 -0800 Date: Wed, 02 Apr 2003 08:46:48 -0500 From: Michael StJohns Subject: Re: Re: Should the NomCom rules define CB voting behavior In-reply-to: <183740000.1049266391@askvoll.hjemme.alvestrand.no> X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: Harald Tveit Alvestrand , Brian E Carpenter , "Joel M. Halpern" Cc: ietf-nomcom@lists.elistx.com Message-id: <5.1.0.14.2.20030402082509.05f0a990@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d394985ce1c38e2ec252a02bf6d3f5d7e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <2319593.1049223470228.JavaMail.nobody@wamui04.slb.atl.earthlink.net> <2319593.1049223470228.JavaMail.nobody@wamui04.slb.atl.earthlink.net> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: At 08:53 AM 4/2/2003 +0200, Harald Tveit Alvestrand wrote: >--On tirsdag, april 01, 2003 13:57:36 -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. >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. *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. >If someone is seriously filibustering the CB's decision, there are lots of >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. >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 ietf-nomcom-errors@lists.elistx.com Wed Apr 2 09:35:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCQ003040F23G@eListX.com> (original mail from mstjohns@mindspring.com) ; Wed, 02 Apr 2003 09:33:02 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCQ003010EZ34@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 09:33:01 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCQ003010EZ33@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 02 Apr 2003 09:32:59 -0500 (EST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCQ00JA70EZSR@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 02 Apr 2003 09:32:59 -0500 (EST) Received: from pcp802197pcs.nrockv01.md.comcast.net ([68.48.86.43] helo=STJOHNS-LAPTOP.mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:DES-CBC3-SHA:168) (Exim 3.33 #1) id 190jHM-0006Xl-00; Wed, 02 Apr 2003 06:31:52 -0800 Date: Wed, 02 Apr 2003 09:31:37 -0500 From: Michael StJohns Subject: Re: Should the NomCom rules define CB voting behavior In-reply-to: <3E8AA973.7013459@hursley.ibm.com> X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: Brian E Carpenter , Avri Doria Cc: ietf-nomcom@lists.elistx.com Message-id: <5.1.0.14.2.20030402084705.05f09d60@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: multipart/alternative; boundary="Boundary_(ID_FBCWf7H5sa9xcUQpT/jpeA)" X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d394f976803cb09ce2d79fce26d38215c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <2319593.1049223470228.JavaMail.nobody@wamui04.slb.atl.earthlink.net> <3E89EBE2.9070809@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --Boundary_(ID_FBCWf7H5sa9xcUQpT/jpeA) Content-type: text/plain; format=flowed; charset=us-ascii At 11:12 AM 4/2/2003 +0200, Brian E Carpenter wrote: >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. 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 agree that we need a Nomcom process that terminates, but >I would hate to see us abandoning the strong consensus >philosophy. 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* > Brian > >Avri Doria wrote: > > > > 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. > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: --Boundary_(ID_FBCWf7H5sa9xcUQpT/jpeA) Content-type: text/html; charset=us-ascii At 11:12 AM 4/2/2003 +0200, Brian E Carpenter wrote:
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.

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 agree that we need a Nomcom process that terminates, but
I would hate to see us abandoning the strong consensus
philosophy.

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*


   Brian

Avri Doria wrote:
>
> 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.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.elistx.com/subscribe>
--Boundary_(ID_FBCWf7H5sa9xcUQpT/jpeA)-- From ietf-nomcom-errors@lists.elistx.com Thu Apr 3 06:55:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCR00204NN7ZS@eListX.com> (original mail from narten@us.ibm.com); Thu, 03 Apr 2003 06:52:19 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCR00201NN6ZQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 03 Apr 2003 06:52:18 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCR00201NN6ZO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 03 Apr 2003 06:52:18 -0500 (EST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCR00EDTNN32I@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 03 Apr 2003 06:52:18 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h33Bnli2104574 for ; Thu, 03 Apr 2003 06:49:48 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-244-106.mts.ibm.com [9.65.244.106]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h33Bp9qS091486 for ; Thu, 03 Apr 2003 04:51:09 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h33Bo4b17865 for ; Thu, 03 Apr 2003 06:50:04 -0500 Date: Thu, 03 Apr 2003 06:50:04 -0500 From: Thomas Narten Subject: Re: Should a CB approve a slate or individuals? In-reply-to: <"Message from sob"@harvard.edu> "of Mon, 31 Mar 2003 22:10:57 EST." <200304010310.h313Avrq003062@newdev.harvard.edu> To: ietf-nomcom@lists.elistx.com Message-id: <200304031150.h33Bo4b17865@cichlid.adsl.duke.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: As one who argued for having the CB confirm the slate as a whole (or reject it as whole), here is my thinking. The intent was not to move from confirmation of "individuals" model to "a slate" model, but rather to give the nomcom the _possibility_ of reconsidering a slate if one of its selections is rejected. In practice, I expect the nomcom in most cases to just resubmit the individuals for which there is no issue and find others for the ones the CB had an issue with. Right now, however, it seems like the CB could reject one choice and confirm the others, when in fact, confirmation of the others (in conjunction with a rejection) is not what the nomcom thinks is the best overall choice. One can argue that this situation is a bit of a corner case and can be avoided by having the nomcom and CB having a dialog prior to the CB rendering an official decision, but I worry that this won't happen in practice. In my experience, the dialog between the nomcom and CB is rather formal and narrow. Thus, making the formal confirmation/rejection be on the slate as a whole ensures that the nomcom has the _option_ of reshuffling the slate. Nothing more. Thomas From ietf-nomcom-errors@lists.elistx.com Fri Apr 4 08:05:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCT00204LBC0L@eListX.com> (original mail from brian@hursley.ibm.com) ; Fri, 04 Apr 2003 07:57:12 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCT00201LBC0J@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 04 Apr 2003 07:57:12 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HCT00201LBB0I@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 04 Apr 2003 07:57:11 -0500 (EST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCT00M54LBA8H@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 04 Apr 2003 07:57:11 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h34Cu3Um014212 for ; Fri, 04 Apr 2003 14:56:04 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h34Cu1g9269588 for ; Fri, 04 Apr 2003 14:56:02 +0200 Received: from dhcp222-24.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA57750 from ; Fri, 04 Apr 2003 14:55:59 +0200 Date: Fri, 04 Apr 2003 14:56:45 +0200 From: Brian E Carpenter Subject: Re: Should a CB approve a slate or individuals? To: ietf-nomcom@lists.elistx.com Message-id: <3E8D810D.7D264DD0@hursley.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <200304031150.h33Bo4b17865@cichlid.adsl.duke.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Thomas Narten wrote: ... > In my experience, the dialog > between the nomcom and CB is rather formal and narrow. A side comment (hence I've deleted the rest of Thomas' message). This is absolutely true, and it's a direct consequence of respect for the strict confidentiality of the NomCom's deliberations. I don't think the CB should have a high-bandwidth debate with the NomCom, for reasons that Mike StJ has already given. Brian