From ietf-nomcom-errors@lists.elistx.com Thu May 8 01:35:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEJ00204ZBJIE@eListX.com> (original mail from avri@acm.org); Thu, 08 May 2003 01:30:55 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEJ00201ZBJIC@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 01:30:55 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEJ00201ZBIIB@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 01:30:54 -0400 (EDT) Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEJ000BFZBHDB@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 08 May 2003 01:30:54 -0400 (EDT) Received: from acm.org (IDENT:V8wc6L+AEcmd1iuFusW5tMHpcS4rYVOd@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h485URw20550 for ; Thu, 08 May 2003 01:30:27 -0400 Date: Thu, 08 May 2003 14:30:21 +0900 From: Avri Doria Subject: Recommendations for closing open issues. To: ietf-nomcom@lists.elistx.com Message-id: <3EB9EB6D.2070802@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 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On 1 April, a list of topics and recommendation from the design team was sent to this list for review and discussion. If I have counted correctly there have been 38 comments by 10 people with 2 people accounting for 60% of the traffic. I have tried to capture the rough consensus points in this list. there has also been and extensive and sometime lively discussion in the design team on these issues. On several issues, there was a fairly even split on the opinions. In those cases, where there was a preexisting practice, a lack of consensus to change the practice was taken as an indication that the practice should remain as document in RFC2727. The following reflects actions to be taken in the document. A new draft should be out shortly for WG review. ------- Issue 1 ------- 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. This would have been a process change from previous practice. There was no consensus for such a change. 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. ------- Issue 2 ------- Re: Poaching rules It has been the practice of NomCom to not only choose candidates from mid-term sitting members of the other sitting body, but to nominate replacements for that person at the same time. The policy will be clarified based on the the fact that a vacancy does not exist until a resignation occurs and the ExDir notifies the NomCom that the vacancy does exist. There is, however, interest in keeping the process efficient. Therefore the following 2 stage process will be documented: 1. Once the candidate is confirmed he/she 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. ------- Issue 3 ------- Re: Question of whether someone can be a member of both the IAB and the IESG 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 stating that it was inadvisable and that is had never been done. While there have been some strong opinions voiced in the recent discussion that this should be prohibited by an explicit rule, there still does not seem to be a consensus for elevating it to a rule. It therefore remains as advice. ------- Issue 4 ------- Re. Question of whether the confirming body, CB, is limited to reviewing only for process irregularities or can do a full review of candidates. The WG consensus appears to be in favor of a CB requirement for due diligence in its review of candidates. The document should reflect this. ------- Issue 5 ------- Re: the question of reviewing a slate as whole or as individual candidates. In the past it was accepted that once the CB approved a candidate that candidate could not then be withdrawn by the Nomcom. The language of RFC2727 does not include the notion of a slate being submitted, but rather a list of individuals who are each judged and confirmed on their own separate merits. The latest version of 2727bis added the notion of a slate which has a coherence beyond simply being a list of individuals. New text made explicit the possibility of Nomcom revisiting the slate once submitted, including candidates who had already been confirmed, until such time as the entire slate had been approved. This change did not appear to receive WG consensus. The lack of consensus warrants returning the process to the language of RFC2727 that deals with lists of individual candidates and which does not give the Nomcom the ability to withdraw candidates once they are approved by the CB. ------- Issue 6 ------- Re. The rules under which the CB decides to accept or not accept a candidate should be strengthened from the RFC2727 rule: that at least one-half of the sitting members agree with the decision. There was also a counter proposal that the rule should changed to leave the full discretion up to CB, i.e. the rule for one-half of sitting members be removed. While there were some strong opinions that a stronger dictate on the CB decision procedure was warranted, and some strong opinions that the CB should pick using a process of its own choosing without any predefined rules, there was no consensus for changing the language of RFC 2727. ------- Issue 7 ------- Re: Is the IETF chair a sitting member of the IAB? The role of the IETF chair with regard to the IAB is defined in the IAB charter. 2727bis should refer to this language. There was no consensus for making any change to the IETF chair's role in 2727bis. -------- Issue 8 -------- Re: Issue of succession rules for IETF Chair The WG was asked to include rules describing the process of succession for the IETF chair. There did not appear to be a consensus for adding such language to the text of the nomcom document. Rather, there was recommendation to IESG chair that the IESG charter should fix this. Otherwise this falls under normal midterm vacancy rules. As with any other vacancy upon request of the IESG the ExDir informs the Nomcom of the vacancy and the IESG deals with the vacancy in its own fashion. There was no consensus for making a change to cover this in 2727bis. -------------------------------------------------------------- I await the WG's comments. a. From ietf-nomcom-errors@lists.elistx.com Thu May 8 07:25:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEK00H04FJ6QA@eListX.com> (original mail from brian@hursley.ibm.com) ; Thu, 08 May 2003 07:21:06 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEK00H01FJ5Q8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 07:21:06 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEK00H01FJ5Q7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 07:21:05 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEK008OGFJ40E@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 08 May 2003 07:21:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Dhh8-0000YT-00; Thu, 08 May 2003 10:28:06 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19DhaW-0000KQ-00; Thu, 08 May 2003 10:21:16 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA66768; Thu, 08 May 2003 10:21:12 +0100 Date: Thu, 08 May 2003 11:21:44 +0200 From: Brian E Carpenter Subject: Re: Recommendations for closing open issues. To: Avri Doria Cc: ietf-nomcom@lists.elistx.com Message-id: <3EBA21A8.C13618D8@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: <3EB9EB6D.2070802@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: ... > ------- > Issue 2 > ------- > Re: Poaching rules > > It has been the practice of NomCom to not only choose candidates > from mid-term sitting members of the other sitting body, but to > nominate replacements for that person at the same time. > > The policy will be clarified based on the the fact > that a vacancy does not exist until a resignation occurs and > the ExDir notifies the NomCom that the vacancy does exist. > > There is, however, interest in keeping the process efficient. > Therefore the following 2 stage process will be documented: > > 1. Once the candidate is confirmed he/she 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 really feel this is overkill. There have been several instances in which the Nomcom wanted to move someone from the IAB to the IESG in midterm, and since in practice the IESG slate is approved first, this has worked smoothly without any need for a formal resignation and notification. The proposed change just introduces pointless procedure. Rule 1 in Section 5 allows the NomCom to exercise common sense, so I think that there is no need to write anything down. Regards Brian From ietf-nomcom-errors@lists.elistx.com Thu May 8 14:35:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEK00K04ZCOVG@eListX.com> (original mail from jwkckid1@ix.netcom.com) ; Thu, 08 May 2003 14:29:12 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEK00K01ZCNVE@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 14:29:12 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEK00K01ZCNVD@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 14:29:11 -0400 (EDT) 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 <0HEK00HBNZCMOV@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 08 May 2003 14:29:11 -0400 (EDT) Received: from dialup-67.30.21.162.dial1.dallas1.level3.net ([67.30.21.162] helo=ix.netcom.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 19Dq8J-00051n-00; Thu, 08 May 2003 14:28:44 -0400 Date: Thu, 08 May 2003 13:26:57 -0700 From: Jeff Williams Subject: Re: Recommendations for closing open issues. To: Brian E Carpenter Cc: Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <3EBABD91.FF3F1269@ix.netcom.com> Organization: INEGroup Spokesman MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <3EB9EB6D.2070802@acm.org> <3EBA21A8.C13618D8@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Brian and all, Respectfully Brian, I disagree with you here. It is very important that a simple but documented procedure be in place to accomplish this. Hence "Something" needs to be written down as often times common sense is not practiced... Brian E Carpenter wrote: > ... > > ------- > > Issue 2 > > ------- > > Re: Poaching rules > > > > It has been the practice of NomCom to not only choose candidates > > from mid-term sitting members of the other sitting body, but to > > nominate replacements for that person at the same time. > > > > The policy will be clarified based on the the fact > > that a vacancy does not exist until a resignation occurs and > > the ExDir notifies the NomCom that the vacancy does exist. > > > > There is, however, interest in keeping the process efficient. > > Therefore the following 2 stage process will be documented: > > > > 1. Once the candidate is confirmed he/she 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 really feel this is overkill. There have been several instances > in which the Nomcom wanted to move someone from the IAB to the IESG > in midterm, and since in practice the IESG slate is approved first, > this has worked smoothly without any need for a formal resignation and > notification. The proposed change just introduces pointless procedure. > > Rule 1 in Section 5 allows the NomCom to exercise common sense, so I > think that there is no need to write anything down. > > Regards > Brian > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From ietf-nomcom-errors@lists.elistx.com Thu May 8 16:05:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL003043DF1C@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Thu, 08 May 2003 15:56:03 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL003013DF1A@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 15:56:03 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL003013DE18@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 15:56:02 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEL0012W3DDX7@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 08 May 2003 15:56:02 -0400 (EDT) Date: Thu, 08 May 2003 15:55:47 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Recommendations for closing open issues. In-reply-to: <3EBA21A8.C13618D8@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: <3EB9EB6D.2070802@acm.org> <3EBA21A8.C13618D8@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thu, 8 May 2003, Brian E Carpenter wrote: > It has been the practice of NomCom to not only choose candidates > from mid-term sitting members of the other sitting body, but to > nominate replacements for that person at the same time. > > The policy will be clarified based on the the fact > that a vacancy does not exist until a resignation occurs and > the ExDir notifies the NomCom that the vacancy does exist. I really feel this is overkill. It is, in part, but experience has told us that it is important to document this edge condition. It reinforces: 1. the rule that the NOMCOM is told what positions to fill. 2. The non-rule that serving on more than one body is not prohibited. Revising this document is mostly about clarifications, which arguably could be mostly overkill. Jim From ietf-nomcom-errors@lists.elistx.com Thu May 8 16:15:16 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL004044779W@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Thu, 08 May 2003 16:13:55 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL004014779U@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 16:13:55 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL004014769T@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 16:13:54 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEL00174475X7@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 08 May 2003 16:13:54 -0400 (EDT) Date: Thu, 08 May 2003 16:13:39 -0400 (Eastern Daylight Time) From: James M Galvin Subject: confirming body voting rules (was: Re: Recommendations for closing open issues.) In-reply-to: <3EB9EB6D.2070802@acm.org> To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <3EB9EB6D.2070802@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Speaking personally (not as Editor of the document) I have a different view of the consensus on this point. As pointed out, there were some significant advocates in favor of specific rules for the voting rules of the confirming bodies. I agree there was no consensus on creating such specific rules. From that discussion came the counter-proposal for the NOMCOM document to not say anthing about the voting rules of the confirming body. It is my opinion there was consensus on this point because some of those who favored specific rules preferred no rules if they could not get the specific rules first suggested. The reason for this was they agreed that the voting rules for a confirming body are more properly stated in the respective "charters" for those bodies. Thus, the rule in 2727bis should change to say that a confirming body makes a decision about confirmation according to its ordinary process for making decisions. If I'm wrong and you agree with the consensus as stated below, then there is nothing for you to do. If you believe I'm right and do not agree with the consensus stated below then you should send a note to the mailing list stating as such. Jim On Thu, 8 May 2003, Avri Doria wrote: ------- Issue 6 ------- Re. The rules under which the CB decides to accept or not accept a candidate should be strengthened from the RFC2727 rule: that at least one-half of the sitting members agree with the decision. There was also a counter proposal that the rule should changed to leave the full discretion up to CB, i.e. the rule for one-half of sitting members be removed. While there were some strong opinions that a stronger dictate on the CB decision procedure was warranted, and some strong opinions that the CB should pick using a process of its own choosing without any predefined rules, there was no consensus for changing the language of RFC 2727. From ietf-nomcom-errors@lists.elistx.com Thu May 8 16:35:15 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL0050450ZG0@eListX.com> (original mail from mstjohns@mindspring.com) ; Thu, 08 May 2003 16:31:47 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL0050150ZFY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 16:31:47 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL0050150YFX@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 16:31:46 -0400 (EDT) Received: from shell-ng.nominum.com (shell-ng.nominum.com [81.200.64.181]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEL0050S50X1J@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 08 May 2003 16:31:46 -0400 (EDT) Received: from STJOHNS-LAPTOP2.mindspring.com (dhcp-23.corp.nominum.com [128.177.196.23]) by shell-ng.nominum.com (Postfix) with ESMTP id 97AF756870; Thu, 08 May 2003 13:31:19 -0700 (PDT) Date: Thu, 08 May 2003 16:31:18 -0400 From: Michael StJohns Subject: Re: Recommendations for closing open issues. In-reply-to: <3EB9EB6D.2070802@acm.org> X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <5.2.1.1.2.20030508144345.00b7dfd8@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; format=flowed; charset=us-ascii List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Hi Avri - comments in line. Restricted to the mechanical deterministic issues rather than whether one approach or the other is better. At 01:30 5/8/2003, Avri Doria wrote: >On 1 April, a list of topics and recommendation from the >design team was sent to this list for review and discussion. > >If I have counted correctly there have been 38 comments by 10 >people with 2 people accounting for 60% of the traffic. I >have tried to capture the rough consensus points in this list. >there has also been and extensive and sometime lively discussion >in the design team on these issues. > >On several issues, there was a fairly even split on the >opinions. In those cases, where there was a preexisting >practice, a lack of consensus to change the practice >was taken as an indication that the practice should remain >as document in RFC2727. > >The following reflects actions to be taken in the document. > >A new draft should be out shortly for WG review. > > > >------- >Issue 1 >------- > >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. This would have been >a process change from previous practice. There was no consensus >for such a change. > >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. > > >------- >Issue 2 >------- >Re: Poaching rules > >It has been the practice of NomCom to not only choose candidates >from mid-term sitting members of the other sitting body, but to >nominate replacements for that person at the same time. > >The policy will be clarified based on the the fact >that a vacancy does not exist until a resignation occurs and >the ExDir notifies the NomCom that the vacancy does exist. > >There is, however, interest in keeping the process efficient. >Therefore the following 2 stage process will be documented: > >1. Once the candidate is confirmed he/she 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. > Resolution Issue 1 conflicts with this resolution of issue 2. This language implies the poached candidate is required to resign (which conflicts with the statements in issue 1). If Issue 1 stands as stated, then the poached canidate CANNOT be advised to resign, the nomcom CANNOT predict the vacancy and SHOULD NOT take any action to fill it. Either change 1 so that the poached candidate is REQUIRED to resign, or change 2 so that it acknowledges the nomcom cannot a priori propose a candidate to fill a poached position for a mid-term poaching. >------- >Issue 3 >------- > >Re: Question of whether someone can be a member of both the IAB and >the IESG > >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 stating >that it was inadvisable and that is had never been done. > >While there have been some strong opinions voiced in the recent >discussion that this should be prohibited by an explicit rule, >there still does not seem to be a consensus for elevating it to >a rule. It therefore remains as advice. And 3 conflicts with 2. Let's just make 2 go away and instead make sure the Nomcom knows it has to wait to be asked, it can't assume the position will become vacant. >------- >Issue 4 >------- > >Re. Question of whether the confirming body, CB, is limited >to reviewing only for process irregularities or can do a full >review of candidates. > >The WG consensus appears to be in favor of a CB requirement >for due diligence in its review of candidates. >The document should reflect this. > >------- >Issue 5 >------- > >Re: the question of reviewing a slate as whole or as individual >candidates. > >In the past it was accepted that once the CB approved a candidate >that candidate could not then be withdrawn by the Nomcom. >The language of RFC2727 does not include the notion of a slate >being submitted, but rather a list of individuals who are each judged >and confirmed on their own separate merits. > >The latest version of 2727bis added the notion of a slate which >has a coherence beyond simply being a list of individuals. New >text made explicit the possibility of Nomcom revisiting the slate >once submitted, including candidates who had already been confirmed, >until such time as the entire slate had been approved. > >This change did not appear to receive WG consensus. The lack of >consensus warrants returning the process to the language of >RFC2727 that deals with lists of individual candidates and which >does not give the Nomcom the ability to withdraw candidates once >they are approved by the CB. > >------- >Issue 6 >------- > >Re. The rules under which the CB decides to accept or not >accept a candidate should be strengthened from the RFC2727 >rule: > that at least one-half of the sitting > members agree with the decision. Mechanically, this rule has two non-terminating states. The state where 1/2 agree to confirm and 1/2 agree not to confirm; and the state where less than 1/2 agree on anything (e.g. 1/3 agree to confirm, 1/3 agree not to confirm and 1/3 decide to abstain. At a minimum this language should be change from "agree with the decision" to "agree to confirm". Ideally "sitting members" should be changed to "qualified members" to cover the situation where one or more sitting members must disqualify themselves due to conflicts (e.g. Ted Hardie IAB member being considered for an IESG position - Ted doesn't get a vote). >There was also a counter proposal that the rule should changed >to leave the full discretion up to CB, i.e. the rule for one-half >of sitting members be removed. > >While there were some strong opinions that a stronger dictate >on the CB decision procedure was warranted, and some strong opinions >that the CB should pick using a process of its own choosing without >any predefined rules, there was no consensus for changing the language >of RFC 2727. > >------- >Issue 7 >------- > >Re: Is the IETF chair a sitting member of the IAB? > >The role of the IETF chair with regard to the IAB is >defined in the IAB charter. 2727bis should refer to this >language. > >There was no consensus for making any change to the IETF chair's >role in 2727bis. > >-------- >Issue 8 >-------- > >Re: Issue of succession rules for IETF Chair > >The WG was asked to include rules describing the process >of succession for the IETF chair. > >There did not appear to be a consensus for adding such >language to the text of the nomcom document. Rather, there was >recommendation to IESG chair that the IESG charter should fix >this. > >Otherwise this falls under normal midterm vacancy rules. As >with any other vacancy upon request of the IESG the ExDir >informs the Nomcom of the vacancy and the IESG deals with the >vacancy in its own fashion. > >There was no consensus for making a change to cover this in >2727bis. > >-------------------------------------------------------------- > > >I await the WG's comments. > > >a. > > > > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Thu May 8 17:05:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL007046E9B1@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Thu, 08 May 2003 17:01:21 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL007016E8AV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 17:01:20 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL007016E7AR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 17:01:19 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEL001AL6E6X7@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 08 May 2003 17:01:19 -0400 (EDT) Date: Thu, 08 May 2003 17:01:04 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Recommendations for closing open issues. In-reply-to: <5.2.1.1.2.20030508144345.00b7dfd8@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.2.1.1.2.20030508144345.00b7dfd8@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Speaking as Editor: With respect to your comments on Issues 1, 2, and 3, specifically how they conflict, please do review the actual text when it becomes available. The conflicts should not be present. Jim On Thu, 8 May 2003, Michael StJohns wrote: >------- >Issue 1 >------- > >Re: Discretion of the IAB or IESG over whether a midterm >vacancies must be filled. > >------- >Issue 2 >------- >Re: Poaching rules > Resolution Issue 1 conflicts with this resolution of issue 2. >------- >Issue 3 >------- > >Re: Question of whether someone can be a member of both the IAB and >the IESG And 3 conflicts with 2. From ietf-nomcom-errors@lists.elistx.com Thu May 8 18:35:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL00C04AGT02@eListX.com> (original mail from gih@telstra.net); Thu, 08 May 2003 18:29:17 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL00C01AGS00@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 18:29:16 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL00B01AGSZZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 08 May 2003 18:29:16 -0400 (EDT) Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEL0055MAGQ38@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 08 May 2003 18:29:15 -0400 (EDT) Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h48MSVMO034573; Fri, 09 May 2003 08:28:41 +1000 (EST envelope-from gih@telstra.net) Date: Fri, 09 May 2003 08:01:50 +1000 From: Geoff Huston Subject: Re: Recommendations for closing open issues. In-reply-to: <5.2.1.1.2.20030508144345.00b7dfd8@pop.mindspring.com> X-Sender: gih@localhost To: Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <5.1.0.14.2.20030509075356.00b349c0@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <3EB9EB6D.2070802@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I like to raise a point of clarification regarding the reference to the role of the "ExDir" in this summary..... >>------- >>Issue 1 >>------- >> >>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. This would have been >>a process change from previous practice. There was no consensus >>for such a change. >> >>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. As a point of clarification, there are in fact 2 Executive Directors - one for the IESG and 1 for the IAB. It appears to me that it is appropriate that the advice to the Nomcom regarding IAB vacancies originates from the IAB Executive Director.l >>------- >>Issue 2 >>------- >>Re: Poaching rules >> >>It has been the practice of NomCom to not only choose candidates >>from mid-term sitting members of the other sitting body, but to >>nominate replacements for that person at the same time. >> >>The policy will be clarified based on the the fact >>that a vacancy does not exist until a resignation occurs and >>the ExDir notifies the NomCom that the vacancy does exist. In the same vein, this refers to the Exec Dir of the body to whom the resignation is passed. >>There is, however, interest in keeping the process efficient. >>Therefore the following 2 stage process will be documented: >> >>1. Once the candidate is confirmed he/she 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. as above. >>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. From ietf-nomcom-errors@lists.elistx.com Fri May 9 02:15:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL00C04VMH2G@eListX.com> (original mail from harald@alvestrand.no); Fri, 09 May 2003 02:06:17 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL00C01VMG2E@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 09 May 2003 02:06:16 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEL00C01VMF2D@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 09 May 2003 02:06:15 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEL007FUVMEPD@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 09 May 2003 02:06:15 -0400 (EDT) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id EF5B2623CD; Fri, 09 May 2003 08:05:49 +0200 (CEST) Date: Fri, 09 May 2003 08:05:50 +0200 From: Harald Tveit Alvestrand Subject: Re: Recommendations for closing open issues. In-reply-to: <5.1.0.14.2.20030509075356.00b349c0@localhost> To: Geoff Huston , ietf-nomcom@lists.elistx.com Message-id: <28990000.1052460350@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: <3EB9EB6D.2070802@acm.org> <5.1.0.14.2.20030509075356.00b349c0@localhost> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On fredag, mai 09, 2003 08:01:50 +1000 Geoff Huston wrote: >>> 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. > > > As a point of clarification, there are in fact 2 Executive Directors - one > for the IESG and 1 for the IAB. It appears to me that it is appropriate > that the advice to the Nomcom regarding IAB vacancies originates > from the IAB Executive Director.l IESG doesn't have an ExDir; the IETF has one. RFC 2727 says: a. The IETF Executive Director advises the nominating committee of the IESG and IAB positions to be reviewed. so this would be a change.... From ietf-nomcom-errors@lists.elistx.com Fri May 9 03:55:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEM00H040I91L@eListX.com> (original mail from brian@hursley.ibm.com) ; Fri, 09 May 2003 03:51:45 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEM00H010I81D@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 09 May 2003 03:51:44 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEM00H010I71A@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 09 May 2003 03:51:43 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEM00F3F0I5XV@eListX.com>; Fri, 09 May 2003 03:51:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E2ey-0007wm-00; Fri, 09 May 2003 08:51:16 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E2ey-0007wa-00; Fri, 09 May 2003 08:51:16 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA81986; Fri, 09 May 2003 08:51:15 +0100 Date: Fri, 09 May 2003 09:51:47 +0200 From: Brian E Carpenter Subject: Re: confirming body voting rules (was: Re: Recommendations for closingopen issues.) To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <3EBB5E13.1709BAA3@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: <3EB9EB6D.2070802@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: The reason I don't object to Avri's proposal is that a simple majority is never going to be in conflict with any reasonable voting rule in the confirming bodies, and it doesn't prevent them having a more stringent rule. I wouldn't object to Jim's proposal either, but it just isn't a big deal imho. Brian James M Galvin wrote: > > Speaking personally (not as Editor of the document) I have a different > view of the consensus on this point. > > As pointed out, there were some significant advocates in favor of > specific rules for the voting rules of the confirming bodies. I agree > there was no consensus on creating such specific rules. > > >From that discussion came the counter-proposal for the NOMCOM document > to not say anthing about the voting rules of the confirming body. It is > my opinion there was consensus on this point because some of those who > favored specific rules preferred no rules if they could not get the > specific rules first suggested. The reason for this was they agreed > that the voting rules for a confirming body are more properly stated in > the respective "charters" for those bodies. Thus, the rule in 2727bis > should change to say that a confirming body makes a decision about > confirmation according to its ordinary process for making decisions. > > If I'm wrong and you agree with the consensus as stated below, then > there is nothing for you to do. > > If you believe I'm right and do not agree with the consensus stated > below then you should send a note to the mailing list stating as such. > > Jim > > On Thu, 8 May 2003, Avri Doria wrote: > > ------- > Issue 6 > ------- > > Re. The rules under which the CB decides to accept or not > accept a candidate should be strengthened from the RFC2727 > rule: > that at least one-half of the sitting > members agree with the decision. > > There was also a counter proposal that the rule should changed > to leave the full discretion up to CB, i.e. the rule for one-half > of sitting members be removed. > > While there were some strong opinions that a stronger dictate > on the CB decision procedure was warranted, and some strong opinions > that the CB should pick using a process of its own choosing without > any predefined rules, there was no consensus for changing the language > of RFC 2727. > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From ietf-nomcom-errors@lists.elistx.com Fri May 9 04:25:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEM00I041O3PL@eListX.com> (original mail from brian@hursley.ibm.com) ; Fri, 09 May 2003 04:16:51 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEM00I011O1PD@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 09 May 2003 04:16:50 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEM00I011O0PB@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 09 May 2003 04:16:48 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEM00F991O0YW@eListX.com>; Fri, 09 May 2003 04:16:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E33H-0000le-00; Fri, 09 May 2003 09:16:23 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E33H-0000lZ-00; Fri, 09 May 2003 09:16:23 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA20562; Fri, 09 May 2003 09:16:21 +0100 Date: Fri, 09 May 2003 10:16:54 +0200 From: Brian E Carpenter Subject: Re: Recommendations for closing open issues. To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <3EBB63F6.FAAA0523@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: <3EB9EB6D.2070802@acm.org> <3EBA21A8.C13618D8@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Jim, James M Galvin wrote: > > On Thu, 8 May 2003, Brian E Carpenter wrote: > > > It has been the practice of NomCom to not only choose candidates > > from mid-term sitting members of the other sitting body, but to > > nominate replacements for that person at the same time. > > > > The policy will be clarified based on the the fact > > that a vacancy does not exist until a resignation occurs and > > the ExDir notifies the NomCom that the vacancy does exist. > > I really feel this is overkill. > > It is, in part, but experience has told us that it is important to > document this edge condition. What experience? When was there ever a problem in this area? I've served in both the confirming bodies and I have never seen a case where there was any confusion or doubt about this. > It reinforces: > > 1. the rule that the NOMCOM is told what positions to fill. > > 2. The non-rule that serving on more than one body is not prohibited. > > Revising this document is mostly about clarifications, which arguably > could be mostly overkill. If it adds redundant bureaucratic process, it is a *harmful* clarificattion. I've said my piece on this, so I will try to shut up . Brian From ietf-nomcom-errors@lists.elistx.com Fri May 9 09:25:10 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEM00804FPTRR@eListX.com> (original mail from gih@telstra.net); Fri, 09 May 2003 09:20:17 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEM00801FPSRP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 09 May 2003 09:20:16 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEM00801FPSRO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 09 May 2003 09:20:16 -0400 (EDT) Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEM00665FPQEZ@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 09 May 2003 09:20:15 -0400 (EDT) Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h49DJcMK041960; Fri, 09 May 2003 23:19:42 +1000 (EST envelope-from gih@telstra.net) Date: Fri, 09 May 2003 23:17:42 +1000 From: Geoff Huston Subject: Re: Recommendations for closing open issues. In-reply-to: <28990000.1052460350@askvoll.hjemme.alvestrand.no> X-Sender: gih@localhost To: Harald Tveit Alvestrand , ietf-nomcom@lists.elistx.com Message-id: <5.1.0.14.2.20030509231511.01a16b90@localhost> 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.20030509075356.00b349c0@localhost> <3EB9EB6D.2070802@acm.org> <5.1.0.14.2.20030509075356.00b349c0@localhost> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: At 08:05 AM 5/9/2003 +0200, Harald Tveit Alvestrand wrote: >--On fredag, mai 09, 2003 08:01:50 +1000 Geoff Huston wrote: > >>>>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. >> >> >>As a point of clarification, there are in fact 2 Executive Directors - one >>for the IESG and 1 for the IAB. It appears to me that it is appropriate >>that the advice to the Nomcom regarding IAB vacancies originates >>from the IAB Executive Director.l > >IESG doesn't have an ExDir; the IETF has one. Thank you for the clarification. Nevertheless, the IAB still has an Executive Director and its _not_ the same individual as the IETF Executive Director, which was the point of my posting. From ietf-nomcom-errors@lists.elistx.com Mon May 12 07:35:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HER00G04UH76X@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Mon, 12 May 2003 07:27:07 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HER00G01UH26R@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 07:27:06 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HER00G01UH26Q@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 07:27:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HER008HTUH13J@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 07:27:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08485; Mon, 12 May 2003 07:23:32 -0400 (EDT) Date: Mon, 12 May 2003 07:23:32 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-nomcom-rfc2727bis-04.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-nomcom@lists.elistx.com Reply-to: Internet-Drafts@ietf.org Message-id: <200305121123.HAA08485@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_8jF6DaO4BDcer9+5QuJrAA)" List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --Boundary_(ID_8jF6DaO4BDcer9+5QuJrAA) Content-type: TEXT/PLAIN A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operation of the IESG/IAB Nominating and Recall Committees Working Group of the IETF. Title : IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees Author(s) : J. Galvin Filename : draft-ietf-nomcom-rfc2727bis-04.txt Pages : 41 Date : 2003-5-9 The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self-consistent, organized compilation of the process as it was known at the time of publication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nomcom-rfc2727bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nomcom-rfc2727bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nomcom-rfc2727bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_8jF6DaO4BDcer9+5QuJrAA) Content-type: multipart/alternative; boundary="Boundary_(ID_sWGDpcwhtXHfuJ3TpgcjqQ)" --Boundary_(ID_sWGDpcwhtXHfuJ3TpgcjqQ) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server Content-Type: text/plain Content-ID: <2003-5-9123939.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nomcom-rfc2727bis-04.txt --Boundary_(ID_sWGDpcwhtXHfuJ3TpgcjqQ) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-nomcom-rfc2727bis-04.txt Content-Type: text/plain Content-ID: <2003-5-9123939.I-D@ietf.org> --Boundary_(ID_sWGDpcwhtXHfuJ3TpgcjqQ)-- --Boundary_(ID_8jF6DaO4BDcer9+5QuJrAA)-- From ietf-nomcom-errors@lists.elistx.com Mon May 12 10:55:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES000043XQ9I@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Mon, 12 May 2003 10:51:26 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES000013XM9C@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 10:51:25 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES000013XL9B@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 10:51:21 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HES00I6M3XK61@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 10:51:21 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17158; Mon, 12 May 2003 10:47:51 -0400 (EDT) Date: Mon, 12 May 2003 10:47:51 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-nomcom-rfc2727bis-04.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-nomcom@lists.elistx.com Reply-to: Internet-Drafts@ietf.org Message-id: <200305121447.KAA17158@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_OsHAsz6/uKeC4IfNCYznyw)" List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --Boundary_(ID_OsHAsz6/uKeC4IfNCYznyw) Content-type: TEXT/PLAIN A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operation of the IESG/IAB Nominating and Recall Committees Working Group of the IETF. Title : IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees Author(s) : J. Galvin Filename : draft-ietf-nomcom-rfc2727bis-04.txt Pages : 41 Date : 2003-5-9 The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self-consistent, organized compilation of the process as it was known at the time of publication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nomcom-rfc2727bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nomcom-rfc2727bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nomcom-rfc2727bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_OsHAsz6/uKeC4IfNCYznyw) Content-type: multipart/alternative; boundary="Boundary_(ID_I76cP+EHukKRkdJUsCp3SA)" --Boundary_(ID_I76cP+EHukKRkdJUsCp3SA) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server Content-Type: text/plain Content-ID: <2003-5-9123939.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nomcom-rfc2727bis-04.txt --Boundary_(ID_I76cP+EHukKRkdJUsCp3SA) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-nomcom-rfc2727bis-04.txt Content-Type: text/plain Content-ID: <2003-5-9123939.I-D@ietf.org> --Boundary_(ID_I76cP+EHukKRkdJUsCp3SA)-- --Boundary_(ID_OsHAsz6/uKeC4IfNCYznyw)-- From ietf-nomcom-errors@lists.elistx.com Mon May 12 15:35:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00C02GLR59@eListX.com> (original mail from ietf-nomcom+moderator@lists.elistx.com); Mon, 12 May 2003 15:25:03 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00B01FXOEL@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 15:10:36 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00B01FXNEE@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com) ; Mon, 12 May 2003 15:10:35 -0400 (EDT) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00B04FXNE9@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 15:10:35 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00B01FXME7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 15:10:34 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00B01FXLE6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 15:10:33 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HES00IKDFXKHF@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 15:10:33 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 0A06067104 for ; Mon, 12 May 2003 15:35:23 -0400 (EDT) Date: Mon, 12 May 2003 15:10:05 -0400 From: RJ Atkinson Subject: deadlock problem To: ietf-nomcom@lists.elistx.com Message-id: <5738622A-84AD-11D7-B619-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=2.7 required=7.5 tests=DOUBLE_CAPSWORD,MSG_ID_ADDED_BY_MTA_2 version=2.31 X-Spam-Level: ** List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On page 10 of draft-ietf-nomcom-rfc2727bis-04.txt in the paragraph with sub-heading "4.", there is a process problem. The Nomcom WG needs to revise this text in order to avoid retaining an existing deadlock state in the confirmation process. My concern is NOT hypothetical -- it describes a situation which actually arose during my 4 years on the IAB. Facts: - Some IAB members have abstained from some or all votes to confirm IESG nominees from the Nomcom. - The current text description requires at least half of the IAB to agree either on confirmation or rejection of each IESG nominee. - Some instances of the IAB have been unable to get at least half of the IAB onto either of those positions -- in part because of abstensions by one or more sitting IAB members. - This means that the IAB was unable to meet the process rule currently specified. Observation: I see 4 fairly obvious ways to prevent a deadlock state. More fixes might also exist. The current process text should be changed such that no deadlock states can exist. Personally, having been down this road 4 times, I prefer fix (A) below -- on grounds that if a candidate is so controversial that at least 50% of the confirming body is not actively supportive of a given candidate then that candidate is clearly not the best choice for the Internet community. However, ANY fix that removes the possibility of deadlock in the confirming body is acceptable to me. Each proposal deletes the existing sentence: At least one-half of the sitting members of the confirming bodies must agree to either confirm or reject each individual nominee. and instead substitutes the new text: (Proposal A) For a given nominee to be confirmed, at least one-half of the sitting members of the confirming bodies must agree to confirm that nominee. Nominees that are not confirmed under this rule are considered to be rejected. xor (Proposal B) For a given nominee to be rejected, at least one-half of the sitting members of the confirming bodies must agree to reject that nominee. Nominees that are not rejected under this rule are considered to be confirmed. xor (Proposal C) For a given nominee to be confirmed, at least one-half of the sitting members who do not abstain from voting on a particular nominee must agree to confirm that nominee. Nominees that are not confirmed under this rule are considered to be rejected. xor (Proposal D) For a given nominee to be rejected, at least one-half of the sitting members who do not abstain from voting on a particular nominee must agree to reject that nominee. Nominees that are not rejected under this rule are considered to be confirmed. Yours, Ran Atkinson rja@extremenetworks.com Sitting IAB member from Spring 1999 to Spring 2003. From ietf-nomcom-errors@lists.elistx.com Mon May 12 15:35:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00C04GWUGR@eListX.com> (original mail from sob@newdev.harvard.edu) ; Mon, 12 May 2003 15:31:42 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00C01GWTGP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 15:31:42 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00C01GWTGO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 15:31:41 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HES00IL3GWSH8@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 15:31:41 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h4CJV1H3015994; Mon, 12 May 2003 15:31:01 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4CJV0Hg015993; Mon, 12 May 2003 15:31:00 -0400 (EDT) Date: Mon, 12 May 2003 15:31:00 -0400 (EDT) From: Scott Bradner Subject: Re: deadlock problem In-reply-to: <5738622A-84AD-11D7-B619-00039357A82A@extremenetworks.com> To: ietf-nomcom@lists.elistx.com, rja@extremenetworks.com Message-id: <200305121931.h4CJV0Hg015993@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I like A (Proposal A) For a given nominee to be confirmed, at least one-half of the sitting members of the confirming bodies must agree to confirm that nominee. Nominees that are not confirmed under this rule are considered to be rejected. Scott From ietf-nomcom-errors@lists.elistx.com Mon May 12 15:45:11 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00D04HEY26@eListX.com> (original mail from harald@alvestrand.no); Mon, 12 May 2003 15:42:34 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00D01HEY24@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 15:42:34 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00D01HEX23@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 15:42:33 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HES00ILXHEWGH@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 15:42:33 -0400 (EDT) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64FE862574 for ; Mon, 12 May 2003 21:42:04 +0200 (CEST) Date: Mon, 12 May 2003 21:42:04 +0200 From: Harald Tveit Alvestrand Subject: Re: deadlock problem In-reply-to: <5738622A-84AD-11D7-B619-00039357A82A@extremenetworks.com> To: ietf-nomcom@lists.elistx.com Message-id: <271670000.1052768524@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: <5738622A-84AD-11D7-B619-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On mandag, mai 12, 2003 15:10:05 -0400 RJ Atkinson wrote: > On page 10 of draft-ietf-nomcom-rfc2727bis-04.txt in the paragraph > with sub-heading "4.", there is a process problem. > > The Nomcom WG needs to revise this text in order to avoid retaining an > existing deadlock state in the confirmation process. My concern is NOT > hypothetical -- it describes a situation which actually arose during > my 4 years on the IAB. Speaking only for myself.... I still hold to the position that it's inappropriate for this body to dictate voting rules in other bodies - that there's no reason to require the IAB and the ISOC Board to have consistent rules, even. If the community does not agree with me, any choice would do, and I agree with Ran that we should fix the language. Harald From ietf-nomcom-errors@lists.elistx.com Mon May 12 16:45:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F03JUHMB@eListX.com> (original mail from ietf-nomcom+moderator@lists.elistx.com); Mon, 12 May 2003 16:35:06 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JMYG3@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:30:34 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JMYG2@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com) ; Mon, 12 May 2003 16:30:34 -0400 (EDT) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F04JMXFZ@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:30:33 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JMXFX@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:30:33 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JMWFW@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:30:32 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HES00F1JJMV2A@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 16:30:32 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 746AE67104; Mon, 12 May 2003 16:55:22 -0400 (EDT) Date: Mon, 12 May 2003 16:30:04 -0400 From: RJ Atkinson Subject: Re: deadlock problem In-reply-to: <3EC003A7.A63288A3@bell-labs.com> To: faynberg@bell-labs.com Cc: ietf-nomcom@lists.elistx.com Message-id: <83735A9D-84B8-11D7-B619-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-1.8 required=7.5 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.31 X-Spam-Level: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Igor, Of course, I have no objection to fixing the grammar (or spelling, if I made an error there :-). Does this mean you concur with Scott (and me) that the WG should adopt Proposal A ? Ran On Monday, May 12, 2003, at 16:27 America/Montreal, Igor Faynberg wrote: > I propose a nit in-line (because there is only one confirming body in > each > specific case) > > Igor > > Scott Bradner wrote: >> >> I like A >> >> (Proposal A) >> For a given nominee to be confirmed, at least one-half of the >> sitting members of the confirming > >> bodies > > Change to "body" > >> must agree to confirm that nominee. >> Nominees that are not confirmed under this rule are considered >> to be >> rejected. >> >> Scott >> >> ---------------------------------------------------------------- >> To subscribe or unsubscribe from this elist use the subscription >> manager: From ietf-nomcom-errors@lists.elistx.com Mon May 12 16:55:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F02KB3Z7@eListX.com> (original mail from ietf-nomcom+moderator@lists.elistx.com); Mon, 12 May 2003 16:45:03 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JIHDZ@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:27:53 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JIHDY@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com) ; Mon, 12 May 2003 16:27:53 -0400 (EDT) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F04JIGDV@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:27:52 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JIGDT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:27:52 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JIFDS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:27:51 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HES00E3HJIFP2@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 16:27:51 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CKRJ809578; Mon, 12 May 2003 16:27:20 -0400 (EDT) Received: from bell-labs.com by homail.ho.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h4CKRI604654; Mon, 12 May 2003 16:27:18 -0400 (EDT) Date: Mon, 12 May 2003 16:27:19 -0400 From: Igor Faynberg Subject: Re: deadlock problem To: Scott Bradner Cc: ietf-nomcom@lists.elistx.com, rja@extremenetworks.com Reply-to: faynberg@bell-labs.com Message-id: <3EC003A7.A63288A3@bell-labs.com> Organization: Lucent Technologies MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,el References: <200305121931.h4CJV0Hg015993@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I propose a nit in-line (because there is only one confirming body in each specific case) Igor Scott Bradner wrote: > > I like A > > (Proposal A) > For a given nominee to be confirmed, at least one-half of the sitting members of the confirming > bodies Change to "body" > must agree to confirm that nominee. > Nominees that are not confirmed under this rule are considered to be > rejected. > > Scott > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: From ietf-nomcom-errors@lists.elistx.com Mon May 12 16:55:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F08KB4Z7@eListX.com> (original mail from ietf-nomcom+moderator@lists.elistx.com); Mon, 12 May 2003 16:45:04 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JT3KE@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:34:15 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JT3KD@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com) ; Mon, 12 May 2003 16:34:15 -0400 (EDT) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F04JT2KA@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:34:14 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JT1K8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:34:14 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00F01JT1K7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 16:34:13 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HES00E4KJT0P2@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 16:34:13 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4CKXh813771; Mon, 12 May 2003 16:33:43 -0400 (EDT) Received: from bell-labs.com by homail.ho.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h4CKXg607480; Mon, 12 May 2003 16:33:42 -0400 (EDT) Date: Mon, 12 May 2003 16:33:42 -0400 From: Igor Faynberg Subject: Re: deadlock problem To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Reply-to: faynberg@bell-labs.com Message-id: <3EC00526.571F5268@bell-labs.com> Organization: Lucent Technologies MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,el References: <83735A9D-84B8-11D7-B619-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Ran, Absolutely, I concur with you and Scott. Igor RJ Atkinson wrote: > > Igor, > > Of course, I have no objection to fixing the grammar (or spelling, > if I made an error there :-). > > Does this mean you concur with Scott (and me) that the WG > should adopt Proposal A ? > > Ran > > On Monday, May 12, 2003, at 16:27 America/Montreal, Igor Faynberg wrote: > > I propose a nit in-line (because there is only one confirming body in > > each > > specific case) > > > > Igor > > > > Scott Bradner wrote: > >> > >> I like A > >> > >> (Proposal A) > >> For a given nominee to be confirmed, at least one-half of the > >> sitting members of the confirming > > > >> bodies > > > > Change to "body" > > > >> must agree to confirm that nominee. > >> Nominees that are not confirmed under this rule are considered > >> to be > >> rejected. > >> > >> Scott > >> > >> ---------------------------------------------------------------- > >> To subscribe or unsubscribe from this elist use the subscription > >> manager: From ietf-nomcom-errors@lists.elistx.com Mon May 12 18:55:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00K04PX9HT@eListX.com> (original mail from avri@acm.org); Mon, 12 May 2003 18:46:21 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00K01PX8HR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 18:46:20 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00K01PX8HP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 18:46:20 -0400 (EDT) Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HES00J2VPX7X5@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 18:46:19 -0400 (EDT) Received: from acm.org (IDENT:tl8+BMczeq0ja0uXelNg49bTWmVugERh@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h4CMjm309262 for ; Mon, 12 May 2003 18:45:48 -0400 Date: Tue, 13 May 2003 07:45:46 +0900 From: Avri Doria Subject: Re: deadlock problem To: ietf-nomcom@lists.elistx.com Message-id: <3EC0241A.9060207@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 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <200305121931.h4CJV0Hg015993@newdev.harvard.edu> <3EC003A7.A63288A3@bell-labs.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: From the chair: The last time this issue was discussed I felt there was no consensus and therefore things were left as written in RFC2727. To achieve consensus this time around, I ask that a lot of people on this list please speak up on the issue and see if we can't mostly convince ourselves that one option is really the right option. You have been given lots of options from: - doing nothing and leaving it as written in RFC2727 and 2727bis, - to making one of the changes {A-D} Mike suggests, - to removing the clause altogether and leaving it up to the CB to determine it own processes as Harald suggests. Since I would like to take this doc to WG last call as soon as possible, please respond in the next couple of days. It would be really nice to hear from a large cross-section of the list participants instead of the same few who always step-up and contribute. I plan to try and determine the state of consensus by the end of the week. Thanks a. From ietf-nomcom-errors@lists.elistx.com Mon May 12 18:55:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00K04Q7UQY@eListX.com> (original mail from joel@stevecrocker.com) ; Mon, 12 May 2003 18:52:42 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00K01Q7TQW@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 18:52:41 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00K01Q7TQV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 18:52:41 -0400 (EDT) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HES00FMRQ7S2A@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 18:52:40 -0400 (EDT) Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4592716 for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 18:52:12 -0400 Date: Mon, 12 May 2003 18:51:30 -0400 From: "Joel M. Halpern" Subject: Re: deadlock problem In-reply-to: <3EC0241A.9060207@acm.org> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com To: ietf-nomcom@lists.elistx.com Message-id: <5.1.0.14.0.20030512184959.029fb9e0@mail.stevecrocker.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <200305121931.h4CJV0Hg015993@newdev.harvard.edu> <3EC003A7.A63288A3@bell-labs.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I believe that the best alternative would be to remove the clause altogether, as per Harald's suggestion. Failing that, I could probably live with any of the choices give by Mike, but would lean towards choice A (1/2 the CB must support the candidate) slightly. Yours, Joel M. Halpern At 07:45 AM 5/13/2003 +0900, Avri Doria wrote: > From the chair: > >The last time this issue was discussed I felt there >was no consensus and therefore things were left as written >in RFC2727. > >To achieve consensus this time around, I ask that a lot of >people on this list please speak up on the issue and see if we >can't mostly convince ourselves that one option is really the >right option. > >You have been given lots of options from: >- doing nothing and leaving it as written in RFC2727 and 2727bis, >- to making one of the changes {A-D} Mike suggests, >- to removing the clause altogether and leaving it up to > the CB to determine it own processes as Harald suggests. > > >Since I would like to take this doc to WG last call as soon >as possible, please respond in the next couple of days. It >would be really nice to hear from a large cross-section of >the list participants instead of the same few who always >step-up and contribute. I plan to try and determine the >state of consensus by the end of the week. > > >Thanks > >a. > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Mon May 12 20:15:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00004TMO8C@eListX.com> (original mail from avri@acm.org); Mon, 12 May 2003 20:06:24 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00001TMN8A@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 20:06:23 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HES00001TMN89@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 12 May 2003 20:06:23 -0400 (EDT) Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HES00JEMTMLX5@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 12 May 2003 20:06:22 -0400 (EDT) Received: from acm.org (IDENT:KmKhF3U9KEiR8LKoxH00mPBUBHfEgknE@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h4D05o316405 for ; Mon, 12 May 2003 20:05:51 -0400 Date: Tue, 13 May 2003 09:05:48 +0900 From: Avri Doria Subject: Re: deadlock problem - correction To: ietf-nomcom@lists.elistx.com Message-id: <3EC036DC.2010901@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 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <200305121931.h4CJV0Hg015993@newdev.harvard.edu> <3EC003A7.A63288A3@bell-labs.com> <3EC0241A.9060207@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Correction below Avri Doria wrote: > From the chair: > > The last time this issue was discussed I felt there > was no consensus and therefore things were left as written > in RFC2727. > > To achieve consensus this time around, I ask that a lot of > people on this list please speak up on the issue and see if we > can't mostly convince ourselves that one option is really the > right option. > > You have been given lots of options from: > - doing nothing and leaving it as written in RFC2727 and 2727bis, > - to making one of the changes {A-D} Mike suggests, > - to removing the clause altogether and leaving it up to > the CB to determine it own processes as Harald suggests. > > > Since I would like to take this doc to WG last call as soon > as possible, please respond in the next couple of days. It > would be really nice to hear from a large cross-section of > the list participants instead of the same few who always Not instead of, but in addition to. I don't know what I was thinking. Meant to say ... instead of only the same few ... Apologies to the few!!! > step-up and contribute. I plan to try and determine the > state of consensus by the end of the week. > > > Thanks > > a. > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: > From ietf-nomcom-errors@lists.elistx.com Tue May 13 00:15:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00704511SB@eListX.com> (original mail from mstjohns@mindspring.com) ; Tue, 13 May 2003 00:12:37 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00701511S9@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 00:12:37 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00701510S8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 00:12:36 -0400 (EDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HET003PK50Z8O@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 00:12:36 -0400 (EDT) Received: from pcp802197pcs.nrockv01.md.comcast.net ([68.48.86.43] helo=STJOHNS-LAPTOP2.mindspring.com) by heron.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 19FR94-00079Y-00; Mon, 12 May 2003 21:12:06 -0700 Date: Tue, 13 May 2003 00:11:54 -0400 From: Michael StJohns Subject: Re: deadlock problem In-reply-to: <3EC0241A.9060207@acm.org> X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <5.2.1.1.2.20030513001111.02247d08@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4dc76ffcc6cdb48f5cdf5a091f6eff8e11350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <200305121931.h4CJV0Hg015993@newdev.harvard.edu> <3EC003A7.A63288A3@bell-labs.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Repeat after me... Ran is not Mike... Ran is not Mike... :-) Referenced email was Ran's.... Mike At 18:45 5/12/2003, Avri Doria wrote: > From the chair: > >The last time this issue was discussed I felt there >was no consensus and therefore things were left as written >in RFC2727. > >To achieve consensus this time around, I ask that a lot of >people on this list please speak up on the issue and see if we >can't mostly convince ourselves that one option is really the >right option. > >You have been given lots of options from: >- doing nothing and leaving it as written in RFC2727 and 2727bis, >- to making one of the changes {A-D} Mike suggests, >- to removing the clause altogether and leaving it up to > the CB to determine it own processes as Harald suggests. > > >Since I would like to take this doc to WG last call as soon >as possible, please respond in the next couple of days. It >would be really nice to hear from a large cross-section of >the list participants instead of the same few who always >step-up and contribute. I plan to try and determine the >state of consensus by the end of the week. > > >Thanks > >a. > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Tue May 13 00:45:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET0080462ZUB@eListX.com> (original mail from jwkckid1@ix.netcom.com) ; Tue, 13 May 2003 00:35:23 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET0080162YU9@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 00:35:22 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET0080162XU6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 00:35:21 -0400 (EDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HET0086362W5F@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 00:35:20 -0400 (EDT) Received: from dialup-67.29.252.162.dial1.dallas1.level3.net ([67.29.252.162] helo=ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 19FRV3-000382-00; Tue, 13 May 2003 00:34:50 -0400 Date: Mon, 12 May 2003 23:32:53 -0700 From: Jeff Williams Subject: Re: deadlock problem To: Michael StJohns Cc: Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <3EC09194.9D56B361@ix.netcom.com> Organization: INEGroup Spokesman MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <200305121931.h4CJV0Hg015993@newdev.harvard.edu> <3EC003A7.A63288A3@bell-labs.com> <5.2.1.1.2.20030513001111.02247d08@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Michael and all, Well thank you for this enlightening revelation Michael! >;) But it seems that you are prone to some sort of obsessive compulsive disorder... Work on it will ya! >:/ Michael StJohns wrote: > Repeat after me... Ran is not Mike... Ran is not Mike... :-) Referenced > email was Ran's.... > > Mike > > At 18:45 5/12/2003, Avri Doria wrote: > > From the chair: > > > >The last time this issue was discussed I felt there > >was no consensus and therefore things were left as written > >in RFC2727. > > > >To achieve consensus this time around, I ask that a lot of > >people on this list please speak up on the issue and see if we > >can't mostly convince ourselves that one option is really the > >right option. > > > >You have been given lots of options from: > >- doing nothing and leaving it as written in RFC2727 and 2727bis, > >- to making one of the changes {A-D} Mike suggests, > >- to removing the clause altogether and leaving it up to > > the CB to determine it own processes as Harald suggests. > > > > > >Since I would like to take this doc to WG last call as soon > >as possible, please respond in the next couple of days. It > >would be really nice to hear from a large cross-section of > >the list participants instead of the same few who always > >step-up and contribute. I plan to try and determine the > >state of consensus by the end of the week. > > > > > >Thanks > > > >a. > > > > > >---------------------------------------------------------------- > >To subscribe or unsubscribe from this elist use the subscription > >manager: > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From ietf-nomcom-errors@lists.elistx.com Tue May 13 01:35:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00A048MFQS@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 13 May 2003 01:30:15 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00A018MEQQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 01:30:14 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00A018MDQP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 01:30:13 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HET008K78MC5F@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 01:30:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19FSMA-0004Wn-00; Tue, 13 May 2003 06:29:42 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19FSMA-0004Wi-00; Tue, 13 May 2003 06:29:42 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id GAA146914; Tue, 13 May 2003 06:29:39 +0100 Date: Tue, 13 May 2003 07:30:00 +0200 From: Brian E Carpenter Subject: Re: deadlock problem To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: <3EC082D8.D5FE3608@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: <5738622A-84AD-11D7-B619-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I would prefer to remove the rule completely and leave the CBs to set their own rules. If we don't remove the rule, I would support (A) which is effectively the status quo. Brian RJ Atkinson wrote: > > On page 10 of draft-ietf-nomcom-rfc2727bis-04.txt in the paragraph > with sub-heading "4.", there is a process problem. > > The Nomcom WG needs to revise this text in order to avoid retaining an > existing deadlock state in the confirmation process. My concern is NOT > hypothetical -- it describes a situation which actually arose during > my 4 years on the IAB. > > Facts: > - Some IAB members have abstained from some or all votes > to confirm IESG nominees from the Nomcom. > - The current text description requires at least half > of the IAB to agree either on confirmation or rejection > of each IESG nominee. > - Some instances of the IAB have been unable to get at least > half of the IAB onto either of those positions -- in part > because of abstensions by one or more sitting IAB members. > - This means that the IAB was unable to meet the process rule > currently specified. > > Observation: > I see 4 fairly obvious ways to prevent a deadlock state. More > fixes might also exist. The current process text should be changed such > that no deadlock states can exist. > > Personally, having been down this road 4 times, I prefer fix (A) > below -- on grounds that if a candidate is so controversial that at > least 50% > of the confirming body is not actively supportive of a given candidate > then that candidate is clearly not the best choice for the Internet > community. However, ANY fix that removes the possibility of deadlock > in the confirming body is acceptable to me. > > Each proposal deletes the existing sentence: > At least one-half of the sitting members of the confirming bodies > must agree to either confirm or reject each individual nominee. > > and instead substitutes the new text: > > (Proposal A) > For a given nominee to be confirmed, at least one-half of the sitting > members of the confirming bodies must agree to confirm that > nominee. > Nominees that are not confirmed under this rule are considered to > be > rejected. > > xor (Proposal B) > For a given nominee to be rejected, at least one-half of the sitting > members of the confirming bodies must agree to reject that > nominee. > Nominees that are not rejected under this rule are considered to > be > confirmed. > > xor (Proposal C) > For a given nominee to be confirmed, at least one-half of the sitting > members who do not abstain from voting on a particular nominee must > agree to confirm that nominee. Nominees that are not confirmed under > this rule are considered to be rejected. > > xor (Proposal D) > For a given nominee to be rejected, at least one-half of the sitting > members who do not abstain from voting on a particular nominee must > agree to reject that nominee. Nominees that are not rejected under > this rule are considered to be confirmed. > > Yours, > > Ran Atkinson > rja@extremenetworks.com > > Sitting IAB member from Spring 1999 to Spring 2003. > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From ietf-nomcom-errors@lists.elistx.com Tue May 13 04:55:24 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00G04I1BFN@eListX.com> (original mail from bwijnen@lucent.com); Tue, 13 May 2003 04:53:35 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00G01I1AFL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 04:53:34 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00G01I1AFK@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 04:53:34 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HET00F1OI19SP@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 04:53:33 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4D8r4B23389 for ; Tue, 13 May 2003 04:53:04 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10CCF4>; Tue, 13 May 2003 10:53:03 +0200 Content-return: allowed Date: Tue, 13 May 2003 10:53:03 +0200 From: "Wijnen, Bert (Bert)" Subject: RE: deadlock problem To: Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <7D5D48D2CAA3D84C813F5B154F43B155018B92C8@nl0006exch001u.nl.lucent.com> 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: I'd say: remove the clause all-together. 2nd choice would be option A (as proposed by Ran). Thanks, Bert > -----Original Message----- > From: Avri Doria [mailto:avri@acm.org] > Sent: dinsdag 13 mei 2003 0:46 > To: ietf-nomcom@lists.elistx.com > Subject: Re: deadlock problem > > > From the chair: > > The last time this issue was discussed I felt there > was no consensus and therefore things were left as written > in RFC2727. > > To achieve consensus this time around, I ask that a lot of > people on this list please speak up on the issue and see if we > can't mostly convince ourselves that one option is really the > right option. > > You have been given lots of options from: > - doing nothing and leaving it as written in RFC2727 and 2727bis, > - to making one of the changes {A-D} Mike suggests, > - to removing the clause altogether and leaving it up to > the CB to determine it own processes as Harald suggests. > > > Since I would like to take this doc to WG last call as soon > as possible, please respond in the next couple of days. It > would be really nice to hear from a large cross-section of > the list participants instead of the same few who always > step-up and contribute. I plan to try and determine the > state of consensus by the end of the week. > > > Thanks > > a. > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: > From ietf-nomcom-errors@lists.elistx.com Tue May 13 09:45:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00304VCZA3@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Tue, 13 May 2003 09:41:23 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00301VCYA1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 09:41:23 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00301VCYA0@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 09:41:22 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HET00N76VCX01@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 09:41:22 -0400 (EDT) Date: Tue, 13 May 2003 09:41:06 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: deadlock problem In-reply-to: <5738622A-84AD-11D7-B619-00039357A82A@extremenetworks.com> To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <5738622A-84AD-11D7-B619-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Speaking for myself, the NOMCOM document should not say anything about the voting rules of a confirming body. However, if that's not possible I only agree with the first sentence of Ran's Proposal A because the second sentence is a fundamental process change and I object to it. In its entirety, Ran's Proposal A is: (Proposal A) For a given nominee to be confirmed, at least one-half of the sitting members of the confirming bodies must agree to confirm that nominee. Nominees that are not confirmed under this rule are considered to be rejected. The first sentence is fine insofar as it removes the ambiguity without removing the "positive" intent of the original statement. However, the second sentence presents a rule that has not been discussed during this revision. Further, it gives control to the confirming body because now if they don't like a candidate all they have to do is not vote (thus not take responsibility for their decision). This document is largely ambiguous when it comes to a tie, and I would argue this is by design. Over the years we have resolved some conflicts and ties, but generally we resolve them in favor of the NOMCOM, not the confirming body. For example, in the case of a mid-term vacancy the failure of confirming body to actually confirm a candidate results in automatic confirmation, not rejection. The second sentence resolves the conflict (or indecision) in favor of the confirming body and I think this is wrong. Jim From ietf-nomcom-errors@lists.elistx.com Tue May 13 10:15:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00402WGH88@eListX.com> (original mail from ietf-nomcom+moderator@lists.elistx.com); Tue, 13 May 2003 10:05:05 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00201URUQ1@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 09:28:42 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00201URTQ0@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com) ; Tue, 13 May 2003 09:28:41 -0400 (EDT) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00204URTPX@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 09:28:41 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00201URSPV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 09:28:40 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00201URRPU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 09:28:39 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HET00N53URR2K@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 09:28:39 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id BEC6F67105; Tue, 13 May 2003 09:53:33 -0400 (EDT) Date: Tue, 13 May 2003 09:28:06 -0400 From: RJ Atkinson Subject: Re: deadlock problem In-reply-to: <3EC082D8.D5FE3608@hursley.ibm.com> To: Brian E Carpenter Cc: ietf-nomcom@lists.elistx.com, Ran Atkinson Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-1.8 required=7.5 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.31 X-Spam-Level: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tuesday, May 13, 2003, at 01:30 America/Montreal, Brian E Carpenter wrote: > I would prefer to remove the rule completely and leave the > CBs to set their own rules. During my time on IAB, (at least once) a lack of pre-planning (e.g. with respect to handling 'abstain' votes) by the collective IAB (i.e. what happened is really no one's fault) created serious issues in convergence on one or more IESG nominees. Based on that experience, I think that it would be a disaster to have the confirming bodies set their own rules. Instead of having a straight- forward confirm/reject/abstain vote with a clearly defined outcome, letting each CB set their own rules has strong potential for (1) different procedures each year and (2) individuals trying to arrange the rules in a given year to favour particular nominees. In short, letting each CB set their own rules would reduce consistency year-to-year and would increase the political quotient of the confirming activity. I view increasing the political quotient of anything in the IETF to be a bad result. By contrast, having a small number of simple, clearly defined, rules would tend to reduce the political quotient and help ensure consistency in the procedures from one year to the next. > If we don't remove the rule, I would support (A) which is > effectively the status quo. I wish it were the status quo. Thanks for that support. Ran From ietf-nomcom-errors@lists.elistx.com Tue May 13 11:05:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00604Z0XNW@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 13 May 2003 11:00:33 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00601Z0WNU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:00:33 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HET00601Z0WNT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:00:32 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HET00NCYZ0R01@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 11:00:32 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4DExt9X057116; Tue, 13 May 2003 10:59:56 -0400 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4DExlK8266490; Tue, 13 May 2003 16:59:54 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23686 from ; Tue, 13 May 2003 16:59:42 +0200 Date: Tue, 13 May 2003 16:22:35 +0200 From: Brian E Carpenter Subject: Re: deadlock problem To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: <3EC0FFAB.A4F86E07@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: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: RJ Atkinson wrote: > > On Tuesday, May 13, 2003, at 01:30 America/Montreal, Brian E Carpenter > wrote: > > I would prefer to remove the rule completely and leave the > > CBs to set their own rules. > > During my time on IAB, (at least once) a lack of pre-planning (e.g. with > respect to handling 'abstain' votes) by the collective IAB (i.e. what > happened is really no one's fault) created serious issues in convergence > on one or more IESG nominees. But that is another matter. The IAB *has* a defined voting rule in its own charter, and the ISOC Board has voting rules in the by-laws. So your rules (A or others) simply create scope for ambiguity with those existing rules. > > Based on that experience, I think that it would be a disaster to have > the confirming bodies set their own rules. Instead of having a > straight- > forward confirm/reject/abstain vote with a clearly defined outcome, > letting each CB set their own rules has strong potential for (1) > different procedures each year and (2) individuals trying to arrange > the rules in a given year to favour particular nominees. In short, > letting each CB set their own rules would reduce consistency > year-to-year > and would increase the political quotient of the confirming activity. > I view increasing the political quotient of anything in the IETF > to be a bad result. Yes, so maybe the NomCom doc should simply state that each confirming body must apply its own standard voting rule, first to confirm the entire slate, and if that fails to confirm individuals. I don't agree with Jim that defining failure to confirm as equal to rejection is a process change; that's simply been undefined in the past. Ran is correct that it prevents a theoretical deadlock. > > By contrast, having a small number of simple, clearly defined, rules > would tend to reduce the political quotient and help ensure consistency > in the procedures from one year to the next. Nothing will inject common sense if it is absent. > > > If we don't remove the rule, I would support (A) which is > > effectively the status quo. > > I wish it were the status quo. Thanks for that support. It's pretty close to the status quo. You must have had a bad experience. Brian From ietf-nomcom-errors@lists.elistx.com Tue May 13 11:35:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU0080209X34@eListX.com> (original mail from ietf-nomcom+moderator@lists.elistx.com); Tue, 13 May 2003 11:27:33 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU0080109X33@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:27:33 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU0080109W32@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com) ; Tue, 13 May 2003 11:27:32 -0400 (EDT) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU0080409W2Z@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:27:32 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU0080109V2X@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:27:31 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU0080109U2V@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:27:30 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00NCU09T4J@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 11:27:30 -0400 (EDT) Date: Tue, 13 May 2003 11:27:13 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: deadlock problem In-reply-to: <3EC0FFAB.A4F86E07@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: <3EC0FFAB.A4F86E07@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tue, 13 May 2003, Brian E Carpenter wrote: > Based on that experience, I think that it would be a disaster to have > the confirming bodies set their own rules. Instead of having a > straight- > forward confirm/reject/abstain vote with a clearly defined outcome, > letting each CB set their own rules has strong potential for (1) > different procedures each year and (2) individuals trying to arrange > the rules in a given year to favour particular nominees. In short, > letting each CB set their own rules would reduce consistency > year-to-year > and would increase the political quotient of the confirming activity. > I view increasing the political quotient of anything in the IETF > to be a bad result. Yes, so maybe the NomCom doc should simply state that each confirming body must apply its own standard voting rule, first to confirm the entire slate, and if that fails to confirm individuals. I don't agree with Jim that defining failure to confirm as equal to rejection is a process change; that's simply been undefined in the past. Ran is correct that it prevents a theoretical deadlock. Actually, it does not prevent a theoretical deadlock for two reasons. First, there is no fixed timer on when the vote needs to be completed. There's the general notion of being done prior to the First IETF, but there's no failsafe when that deadline is not met. Second, even if you assume or create a timer, the document simply states that the NOMCOM is to identify alternate candidates for rejected candidates. Another existing ambiguity is whether or not the NOMCOM can re-submit the same candidate. In the past they have, and if they do we still have deadlock. Even so, I won't press the point of whether it's a process change, per se, but I will re-iterate that it shifts the "balance of power," albeit imcompletely. A purpose of the NOMCOM is to represent the voice of the community. I believe that ties or ambiguities should, in general, be broken or resolved in favor of the NOMCOM. To suggest that the inaction or indecision of the confirming body is a fair result against the hard work of the NOMCOM is wrong in my opinion. Jim From ietf-nomcom-errors@lists.elistx.com Tue May 13 11:35:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU008040LQBT@eListX.com> (original mail from joel@stevecrocker.com) ; Tue, 13 May 2003 11:34:38 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU008010LPBR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:34:37 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU008010LPBQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:34:37 -0400 (EDT) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00NET0LO1N@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 11:34:36 -0400 (EDT) Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4601197; Tue, 13 May 2003 11:34:07 -0400 Date: Tue, 13 May 2003 11:33:23 -0400 From: "Joel M. Halpern" Subject: Re: deadlock problem In-reply-to: X-Sender: joel@stevecrocker.com@mail.stevecrocker.com To: ietf-nomcom@lists.elistx.com Cc: RJ Atkinson Message-id: <5.1.0.14.0.20030513113010.028ba188@mail.stevecrocker.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <3EC0FFAB.A4F86E07@hursley.ibm.com> <3EC0FFAB.A4F86E07@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: If your concern is about the balance of power, then Ran's alternative B would meet your goal. That stated that it takes 1/2 to reject, and the lack of rejection in the vote would constitute acceptance. I am uncomfortable with the notion that a canddiate would be accepted who was not good enough to get 1/2 of the IAB to agree that he should / could / would do the job. The current IAB voting procedures do have a state where the IAB can not make up its mind. Assuming that we remove the current paragraph, the question is whether we need an extra impetus in this document to ensure closure in the confirming body(ies) Yours, Joel M. Halpern At 11:27 AM 5/13/2003 -0400, James M Galvin wrote: >On Tue, 13 May 2003, Brian E Carpenter wrote: > > > Based on that experience, I think that it would be a disaster to have > > the confirming bodies set their own rules. Instead of having a > > straight- > > forward confirm/reject/abstain vote with a clearly defined outcome, > > letting each CB set their own rules has strong potential for (1) > > different procedures each year and (2) individuals trying to arrange > > the rules in a given year to favour particular nominees. In short, > > letting each CB set their own rules would reduce consistency > > year-to-year > > and would increase the political quotient of the confirming activity. > > I view increasing the political quotient of anything in the IETF > > to be a bad result. > > Yes, so maybe the NomCom doc should simply state that each confirming > body must apply its own standard voting rule, first to confirm the entire > slate, and if that fails to confirm individuals. > > I don't agree with Jim that defining failure to confirm as equal to > rejection is a process change; that's simply been undefined in the > past. Ran is correct that it prevents a theoretical deadlock. > >Actually, it does not prevent a theoretical deadlock for two reasons. > >First, there is no fixed timer on when the vote needs to be completed. >There's the general notion of being done prior to the First IETF, but >there's no failsafe when that deadline is not met. > >Second, even if you assume or create a timer, the document simply states >that the NOMCOM is to identify alternate candidates for rejected >candidates. Another existing ambiguity is whether or not the NOMCOM can >re-submit the same candidate. In the past they have, and if they do we >still have deadlock. > >Even so, I won't press the point of whether it's a process change, per >se, but I will re-iterate that it shifts the "balance of power," albeit >imcompletely. > >A purpose of the NOMCOM is to represent the voice of the community. I >believe that ties or ambiguities should, in general, be broken or >resolved in favor of the NOMCOM. To suggest that the inaction or >indecision of the confirming body is a fair result against the hard work >of the NOMCOM is wrong in my opinion. > >Jim > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Tue May 13 11:45:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU008040TNNV@eListX.com> (original mail from sob@newdev.harvard.edu) ; Tue, 13 May 2003 11:39:23 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU008010TNNT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:39:23 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU008010TMNS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:39:22 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00NHF0TL1L@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 11:39:22 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h4DFcrH3024554 for ; Tue, 13 May 2003 11:38:53 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4DFcruW024553 for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 11:38:53 -0400 (EDT) Date: Tue, 13 May 2003 11:38:53 -0400 (EDT) From: Scott Bradner Subject: Re: Re: deadlock problem To: ietf-nomcom@lists.elistx.com Message-id: <200305131538.h4DFcruW024553@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Joel sez: > I am uncomfortable with the notion that a canddiate would be accepted who > was not good enough to get 1/2 of the IAB to agree that he should / could / > would do the job. if memory serves, this was why that there is anything in the document about what the confirming needs to do Scott From ietf-nomcom-errors@lists.elistx.com Tue May 13 11:55:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU0090419Q9E@eListX.com> (original mail from mstjohns@mindspring.com) ; Tue, 13 May 2003 11:49:02 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU0090119O9A@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:49:01 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU0090119N99@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:48:59 -0400 (EDT) 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 <0HEU00NEL19D2K@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 11:48:59 -0400 (EDT) Received: from pcp802197pcs.nrockv01.md.comcast.net ([68.48.86.43] helo=STJOHNS-LAPTOP2.mindspring.com) by stork.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 19Fc0p-0007i8-00; Tue, 13 May 2003 08:48:19 -0700 Date: Tue, 13 May 2003 11:48:06 -0400 From: Michael StJohns Subject: Re: deadlock problem In-reply-to: <3EC0FFAB.A4F86E07@hursley.ibm.com> X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: Brian E Carpenter , RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: <5.2.1.1.2.20030513112819.02247080@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: multipart/alternative; boundary="Boundary_(ID_YJ30brrTSh0yW1t6R5X3Aw)" X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4db431cf47f7b1de400eea82ce62d02886350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --Boundary_(ID_YJ30brrTSh0yW1t6R5X3Aw) Content-type: text/plain; format=flowed; charset=us-ascii At 10:22 5/13/2003, Brian E Carpenter wrote: >But that is another matter. The IAB *has* a defined voting rule >in its own charter, and the ISOC Board has voting rules in the by-laws. >So your rules (A or others) simply create scope for ambiguity with >those existing rules. Speaking plainly. The IAB does NOT have a voting rule, it has a consensus fuzzy feeling sort of thing. >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. In the context of the confirmation, if there are two dissents (e.g. we don't want to decide yet), the IAB can take NO action. E.g. it can neither confirm, nor reject. The rule as written in the IAB charter is an interesting statement of desire, but pretty useless when applied to situations where the IAB must absolutely come to some decision. Another example - appeals. An "action" on an appeal may be framed either as a decision to uphold or reject. Depending on how its framed, the "decision" could go either way with the same set of votes. The IAB charter is not and should not be the controlling document here. It neither explicitly considers the case of confirmation, nor does it provide enough rigor for the IAB to actually come to a result in all possible situations. It would be appropriate and useful for the NOMCOM document to provide specific guidance, but allow the confirming bodies to override the guidance if they issue written procedures. "Absent any written procedures by the confirming bodies which explicitly mention and consider the confirmation process, the confirming bodies shall require an affirmative vote by the majority of the qualified members of that confirming body to confirm any given candidate. A member MUST disqualify themselves from voting on any question of their tenure in office or confirmation." In any event, if the nomcom document doesn't say anything about this, I'll be proposing an IAB charter mod for this. I think its the wrong answer, but I'm too tired to fight any more. So... Brian, do you expect the IAB charter to be a normative reference for the NOMCOM document? The ISOC charter? *sigh* --Boundary_(ID_YJ30brrTSh0yW1t6R5X3Aw) Content-type: text/html; charset=us-ascii At 10:22 5/13/2003, Brian E Carpenter wrote:

But that is another matter. The IAB *has* a defined voting rule
in its own charter, and the ISOC Board has voting rules in the by-laws.
So your rules (A or others) simply create scope for ambiguity with
those existing rules.


Speaking plainly.  The IAB does NOT have a voting rule, it has a consensus fuzzy feeling sort of thing.  


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.


In the context of the confirmation, if there are two dissents (e.g. we don't want to decide yet), the IAB can take NO action.  E.g. it can neither confirm, nor reject. 

The rule as written in the IAB charter is an interesting statement of desire, but pretty useless when applied to situations where the IAB must absolutely come to some decision. 

Another example - appeals.  An "action" on an appeal may be framed either as a decision to uphold or reject.  Depending on how its framed, the "decision" could go either way with the same set of votes.

The IAB charter is not and should not be the controlling document here.  It neither explicitly considers the case of confirmation, nor does it provide enough rigor for the IAB to actually come to a result in all possible situations.  It would be appropriate and useful for the NOMCOM document to provide specific guidance, but allow the confirming bodies to override the guidance if they issue written procedures.  "Absent any written procedures by the confirming bodies which explicitly mention and consider the confirmation process, the confirming bodies shall require an affirmative vote by the majority of the qualified members of that confirming body to confirm any given candidate.  A member MUST disqualify themselves from voting on any question of their tenure in office or confirmation."


In any event, if the nomcom document doesn't say anything about this, I'll be proposing an IAB charter mod for this.  I think its the wrong answer, but I'm too tired to fight any more.

So... Brian, do you expect the IAB charter to be a normative reference for the NOMCOM document?  The ISOC charter?

*sigh*
--Boundary_(ID_YJ30brrTSh0yW1t6R5X3Aw)-- From ietf-nomcom-errors@lists.elistx.com Tue May 13 12:05:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU009031JTJ4@eListX.com> (original mail from ietf-nomcom+moderator@lists.elistx.com); Tue, 13 May 2003 11:55:05 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU008010YSRM@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:42:28 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU008010YRRL@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com) ; Tue, 13 May 2003 11:42:27 -0400 (EDT) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU008040YRRI@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:42:27 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU008010YQRG@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:42:26 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU008010YPRF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:42:26 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00NHR0YO1L@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 11:42:25 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 25CEF67103; Tue, 13 May 2003 12:07:22 -0400 (EDT) Date: Tue, 13 May 2003 11:41:52 -0400 From: RJ Atkinson Subject: Re: deadlock problem In-reply-to: <3EC0FFAB.A4F86E07@hursley.ibm.com> To: Brian E Carpenter Cc: ietf-nomcom@lists.elistx.com Message-id: <6B0958E6-8559-11D7-B680-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-1.8 required=7.5 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.31 X-Spam-Level: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tuesday, May 13, 2003, at 10:22 America/Montreal, Brian E Carpenter wrote: > But that is another matter. The IAB *has* a defined voting rule > in its own charter, I'll quote that section of RFC-2850, which is Section 3.5: 3.5 Decision taking The IAB attempts to reach all decisions unanimously. If unanimity cannot be achieved, the chair may conduct informal polls to determine consensus. The IAB may make decisions and take action if at least seven full members concur and there are no more than two dissents. The IAB may reach decisions by face to face meeting, teleconference, Internet communication, or any combination of the above. I'll note that this text also has a deadlock state whenever more than 2 dissent and at least 7 full members concur. This condition has occurred more than once during my time on the IAB with regard to confirming nominees -- though it was never the process used for confirming nominees. That deadlock might not be harmful -- and might even be desirable -- in the case where a purely architectural question is at hand. Such deadlock would actually be harmful in the special case of confirming IESG nominees -- the question at hand. > So your rules (A or others) simply create scope for ambiguity with > those existing rules. If it were out-of-scope for the IETF Nomcom process RFC to explain how many votes are sufficient for approval/rejection of a nominee, that is something that could and should have been raised *years and years ago* by either ISoc BoT or IAB. I do not believe that any of the 4 proposed corrections to the current text creates new scope for ambiguity. Please explain. > Yes, so maybe the NomCom doc should simply state that each confirming > body must apply its own standard voting rule, first to confirm the > entire > slate, and if that fails to confirm individuals. I don't think that really eliminates the deadlock. Further, it means there isn't reliable consistency from year to year -- as the IETF community expects (and has reason to expect). > I don't agree with Jim that defining failure to confirm as equal to > rejection is a process change; that's simply been undefined in the > past. Ran is correct that it prevents a theoretical deadlock. Thanks. It is not a fundamental change in the actual process, but rather a minor technical clarification to prevent a (not so theoretical) deadlock state. I'll note that (B) has an inverted bias to (A) with regards to how "abstain" votes impact the result && that (C) or (D) remove any result bias from the "abstain" vote. I created 4 options to try to help focus the list conversation on list -- and to make clear that multiple fixes exist and that any of those would be acceptable to me. > Nothing will inject common sense if it is absent. Common sense isn't the issue. A common understanding of the process to follow and avoiding legislated deadlock states are the issues. > It's pretty close to the status quo. You must have had > a bad experience. Painful to watch close-hand, at a minimum. Summary: To go back to my original primary point, the problem that needs to be fixed is the deadlock state in the current draft. There are several ways to do so. This WG needs to pick a single way to fix the problem. Ran's bottom line: I can live with anything that eliminates the deadlock state. Ran Atkinson rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Tue May 13 12:15:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00A0220I9W@eListX.com> (original mail from ietf-nomcom+moderator@lists.elistx.com); Tue, 13 May 2003 12:05:06 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU009011IAGO@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:54:10 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU009011IAGN@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com) ; Tue, 13 May 2003 11:54:10 -0400 (EDT) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU009041I9GK@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:54:09 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU009011I9GG@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:54:09 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU009011I8GE@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 11:54:08 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00NFK1I74J@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 11:54:08 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 40CB267103; Tue, 13 May 2003 12:19:06 -0400 (EDT) Date: Tue, 13 May 2003 11:53:37 -0400 From: RJ Atkinson Subject: Re: deadlock problem In-reply-to: <5.1.0.14.0.20030513113010.028ba188@mail.stevecrocker.com> To: "Joel M. Halpern" Cc: ietf-nomcom@lists.elistx.com Message-id: <0F875468-855B-11D7-B680-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tuesday, May 13, 2003, at 11:33 America/Montreal, Joel M. Halpern wrote: > The current IAB voting procedures do have a state where the IAB can > not make up its mind. Yes. And this is not necessarily a problem with regards to an architectural or technical question. It really is a problem with respect to the narrow question of confirming IESG nominees. > Assuming that we remove the current paragraph, the question is whether > we need an extra impetus in this document to ensure closure in the > confirming body(ies) Before this WG went down the path of just deleting the current broken paragraph, it would be important (IMHO) for this group to have specific assurance from the IAB collective or the IAB Chair that a prompt effort would be undertaken to eliminate the current deadlock state --with respect *only* to confirming IESG nominations-- (i.e. IAB could deadlock on everything else if they desired, just no deadlock on a confirmation of an IESG person). In practice, the resulting change to the IAB charter would likely be similar to one of (A) through (D), even if not identical to any of them. However, potentially, the chosen IAB resolution would represent a major change (e.g. if the IAB decided that a 3/4 majority of IAB members were needed to confirm a given IESG candidate). I think it is more practical and simpler for this WG to specify some deadlock-free specific process than to delete the text entirely and have things blowing in the wind. IMHO, Ran rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Tue May 13 12:15:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00A04215E1@eListX.com> (original mail from rja@extremenetworks.com) ; Tue, 13 May 2003 12:05:29 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00A01214DT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 12:05:28 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00A01213DR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 12:05:27 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00NGK2122K@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 12:05:27 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 6FF4867103; Tue, 13 May 2003 12:30:25 -0400 (EDT) Date: Tue, 13 May 2003 12:04:57 -0400 From: RJ Atkinson Subject: Re: deadlock problem In-reply-to: <5.2.1.1.2.20030513112819.02247080@pop.mindspring.com> To: Michael StJohns Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tuesday, May 13, 2003, at 11:48 America/Montreal, Michael StJohns= =20 wrote: > It would be appropriate and useful for the NOMCOM document to provi= de=20 > specific guidance, but allow the confirming bodies to override the= =20 > guidance if they issue written procedures.=A0 > "Absent any written procedures by the confirming bodies which=20 > explicitly mention and consider the confirmation process, the=20 > confirming bodies shall require an affirmative vote by the majority= of=20 > the qualified members of that confirming body to confirm any given= =20 > candidate.=A0 A member MUST disqualify themselves from voting on an= y=20 > question of their tenure in office or confirmation." This seems like a reasonable compromise. For the would-be lawyers= =20 among us, it lets the confirming body explicitly create rules which would take precedence (if that body so desires), yet for the practical among us = it provides a good workable process. I would further state that the confirming body's process (if created) ought to be required to be free of any deadlock state -- since we kno= w experimentally that deadlocks are real rather than theoretical issues= . > So... Brian, do you expect the IAB charter to be a normative refere= nce=20 > for the NOMCOM document?=A0 The ISOC charter? Certainly I would expect them to be normative references iff the=20 decision is to delete the current paragraph -- on grounds that the actually define part of the Nomcom procedures. Is the ISOC Charter published in an RFC anyplace where it would be widely accessible ? If not, then maybe that also should be undertake= n, particularly given the new role of the IAB in putting folks on the IS= OC BoT. Ran rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Tue May 13 12:25:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00B042WZ8G@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 13 May 2003 12:24:35 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00B012WY89@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 12:24:34 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00B012WX87@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 12:24:33 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00NI12WR4J@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 12:24:33 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4DGNwWn085492; Tue, 13 May 2003 12:23:58 -0400 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4DGNtK8293256; Tue, 13 May 2003 18:23:56 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA64650 from ; Tue, 13 May 2003 18:23:51 +0200 Date: Tue, 13 May 2003 18:24:20 +0200 From: Brian E Carpenter Subject: Re: deadlock problem To: Michael StJohns Cc: ietf-nomcom@lists.elistx.com Message-id: <3EC11C34.79E45F20@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.2.1.1.2.20030513112819.02247080@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Michael StJohns wrote: ... > In the context of the confirmation, if there are two dissents (e.g. we don't want to decide yet), the IAB can take NO action. > E.g. it can neither confirm, nor reject. > > The rule as written in the IAB charter is an interesting statement of desire, but pretty useless when applied to situations > where the IAB must absolutely come to some decision. True, unless the IAB chooses to exercise common sense. ... > > So... Brian, do you expect the IAB charter to be a normative reference for the NOMCOM document? The ISOC charter? No. I think we should simply avoid the potential for inconsistency by *not* defining IAB or ISOC voting rules in two different places. That doesn't imply a normative reference. But I've said that often enough now. Ultimately it doesn't matter, because if common sense can't be relied to resolve potential deadlocks, then no amount of document tweaking will help us. Therefore, I won't object to the A) version at last call. Brian From ietf-nomcom-errors@lists.elistx.com Tue May 13 12:35:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00B04314GN@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 13 May 2003 12:27:04 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00B01313GL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 12:27:03 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00B01312GK@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 12:27:02 -0400 (EDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00MIZ30XZZ@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 12:27:02 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4DGQPsZ171160; Tue, 13 May 2003 12:26:26 -0400 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4DGQNK8188548; Tue, 13 May 2003 18:26:24 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA50784 from ; Tue, 13 May 2003 18:26:18 +0200 Date: Tue, 13 May 2003 18:26:46 +0200 From: Brian E Carpenter Subject: ISOC by-laws [Re: deadlock problem] To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: <3EC11CC6.CE557938@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: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: RJ Atkinson wrote: ... > Is the ISOC Charter published in an RFC anyplace where it would be > widely accessible ? http://www.isoc.org/isoc/general/trustees/bylaws.shtml Brian From ietf-nomcom-errors@lists.elistx.com Tue May 13 12:55:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00C0445NGS@eListX.com> (original mail from sob@newdev.harvard.edu) ; Tue, 13 May 2003 12:51:23 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00C0145MGQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 12:51:22 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00C0145LGP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 12:51:21 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00NMP45G01@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 12:51:21 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h4DGojH3024941; Tue, 13 May 2003 12:50:45 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4DGoixU024940; Tue, 13 May 2003 12:50:44 -0400 (EDT) Date: Tue, 13 May 2003 12:50:44 -0400 (EDT) From: Scott Bradner Subject: Re: ISOC by-laws [Re: deadlock problem] In-reply-to: <3EC11CC6.CE557938@hursley.ibm.com> To: brian@hursley.ibm.com, rja@extremenetworks.com Cc: ietf-nomcom@lists.elistx.com Message-id: <200305131650.h4DGoixU024940@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: RJ Atkinson wrote: ... > Is the ISOC Charter published in an RFC anyplace where it would be > widely accessible ? RFC 2134 & 2135 From ietf-nomcom-errors@lists.elistx.com Tue May 13 13:05:11 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00D044PK4N@eListX.com> (original mail from rja@extremenetworks.com) ; Tue, 13 May 2003 13:03:21 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00D014PK4L@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 13:03:20 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00D014PJ4K@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 13:03:19 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00NO54PI01@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 13:03:19 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id A114C67103; Tue, 13 May 2003 13:28:17 -0400 (EDT) Date: Tue, 13 May 2003 13:02:49 -0400 From: RJ Atkinson Subject: Re: deadlock problem In-reply-to: <3EC11C34.79E45F20@hursley.ibm.com> To: Brian E Carpenter Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tuesday, May 13, 2003, at 12:24 America/Montreal, Brian E Carpenter wrote: > True, unless the IAB chooses to exercise common sense. Brian, Lack of common sense has never been evident on the IAB, AFAIK. Despite that, deadlock HAS been evident. One might legitimately abstain for common sense reasons. Individuals might legitimately have different views on a given candidate for common sense reasons. The intersection of that has lead to deadlock under the current process rule (and would lead to deadlock on the relevant section of the IAB Charter's decision process, as several folks have outlined to this list). Repeating that common sense will avoid deadlock doesn't make that statement true nor even make the two pieces of that claim related to each other. > No. I think we should simply avoid the potential for inconsistency by > *not* defining IAB or ISOC voting rules in two different places. They are unrelated kinds of voting rules, so no inconsistency exists right now -- nor would any of the proposed edits create an inconsistency. > Therefore, I won't object to the A) version at last call. Thanks. Ran Atkinson rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Tue May 13 13:45:15 2003 Return-Path: Return-path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00E046MZTJ@eListX.com> (original mail from huitema@windows.microsoft.com); Tue, 13 May 2003 13:44:59 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00E016MYTH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 13:44:58 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00E016MYTG@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 13:44:58 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00MOC6MWZZ@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 13:44:57 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Tue, 13 May 2003 10:44:26 -0700 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 May 2003 10:44:26 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 13 May 2003 10:44:26 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 May 2003 10:44:25 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 13 May 2003 10:44:24 -0700 Date: Tue, 13 May 2003 10:44:05 -0700 From: Christian Huitema Subject: RE: deadlock problem To: RJ Atkinson , Brian E Carpenter Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: deadlock problem thread-index: AcMZccDD9cfCOg5SQlilxW0krepqwwABHZPw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 13 May 2003 17:44:24.0822 (UTC) FILETIME=[4B18B960:01C31977] > =09Despite that, deadlock HAS been evident. One might legitimately > > No. I think we should simply avoid the potential for inconsistenc= y by > > *not* defining IAB or ISOC voting rules in two different places. >=20 > They are unrelated kinds of voting rules, so no inconsistency exist= s > right now -- nor would any of the proposed edits create an > inconsistency. Ran, ISOC voting rules are defined by its by-laws. You just cannot define them somewhere else. Even if you had some text in an RFC, that text would only have an effect on the ISOC process if it was incorporated = as a modification to the by-laws. This is a fairly heavy weight process, and I don't believe it is necessary. You raise an important point, which is the possibility of a deadlock. Inaction or indecision by a confirming body may result in a slate or = a candidate not being approved or rejected in time. It is fair to recognize that whatever the voting rules of a confirming body, there = are three possible results: explicit confirmation, explicit rejection, or indecision. The discussion should center on the way we manage indecision, i.e. is it an implicit confirmation or an implicit rejection? I can see arguments both ways. -- Christian Huitema From ietf-nomcom-errors@lists.elistx.com Tue May 13 14:35:14 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00G048M7UW@eListX.com> (original mail from rja@extremenetworks.com) ; Tue, 13 May 2003 14:27:43 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00G018M6UU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 14:27:42 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00G018M6UT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 14:27:42 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00F568M5EG@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 14:27:41 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id E383267103; Tue, 13 May 2003 14:34:16 -0400 (EDT) Date: Tue, 13 May 2003 14:08:48 -0400 From: RJ Atkinson Subject: Re: deadlock problem In-reply-to: To: Christian Huitema Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tuesday, May 13, 2003, at 13:44 America/Montreal, Christian Huitema wrote: > ISOC voting rules are defined by its by-laws. You just cannot define > them somewhere else. Even if you had some text in an RFC, that text > would only have an effect on the ISOC process if it was incorporated as > a modification to the by-laws. This is a fairly heavy weight process, > and I don't believe it is necessary. Christian, ISOC BoT have for *years* been following an RFC-specified confirmation process that does not appear to be in its bylaws. IAB have for *years* followed an RFC-specified confirmation process contrary to that specified in the IAB Charter. While IAB Chair during my time on the IAB, Brian did not raise any question that IAB should follow that process. I haven't heard any complaint about this from any ISOC BoT in any of the past years. In fact, until I pointed out, within the last day or so, that the process in the current I-D to update that RFC contained deadlock, this WG was on a clear path to retain the broken RFC language and continuing to apply it to both ISOC and IAB confirmation processes. At best, your claim is late in the day -- years late. If IAB or ISOC really had heartache over this (and I can say that the IAB had *no* anxiety about it during my 4 years on the IAB and I heard zero individual complaints about it), that REALLY should have been raised years ago (e.g. at any of the IAB Chair transitions or when the first RFC on Nomcom procedures was published). > You raise an important point, which is the possibility of a deadlock. > Inaction or indecision by a confirming body may result in a slate or a > candidate not being approved or rejected in time. It is fair to > recognize that whatever the voting rules of a confirming body, there > are > three possible results: explicit confirmation, explicit rejection, or > indecision. The discussion should center on the way we manage > indecision, i.e. is it an implicit confirmation or an implicit > rejection? I'm truly focused *primarily* on eliminating the deadlock that the current text legislates. And I'll note that if you adhere to the position you outline above (i.e. that how a confirming body decides stuff is their concern only), then this WG should delete the current text and ought not be discussing "the way we manage indecision". As to how to do indecision, I think that boils down to (A) or (C) versus (B) or (D). I can live with any of those 4. Yours, Ran rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Tue May 13 14:45:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00H049DYHS@eListX.com> (original mail from rja@extremenetworks.com) ; Tue, 13 May 2003 14:44:22 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00H019DYHQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 14:44:22 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00H019DXHP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 14:44:21 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00F5Z9DWEH@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 14:44:21 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id A7E366710B for ; Tue, 13 May 2003 14:37:53 -0400 (EDT) Date: Tue, 13 May 2003 14:12:25 -0400 From: RJ Atkinson Subject: Question 1 about deadlock issue To: ietf-nomcom@lists.elistx.com Message-id: <731CB764-856E-11D7-B680-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Does anyone here believe that the current confirmation text should be retained as-is ? Please speak up on-list if you believe in retaining the current confirmation process text as-is. I'd be interested to understand the rationale for retaining it if anyone wants to retain it. Silence will be interpreted as agreement that the current text at issue either (1) should be edited in some manner xor (2) deleted entirely. My goal here is to try to validate that there is broad belief that the current text should not remain as-is in the final RFC, ignoring for the moment the question of what change the WG prefers to undertake. Thanks, Ran rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Tue May 13 15:05:40 2003 Return-Path: Return-path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00I04A37EH@eListX.com> (original mail from huitema@windows.microsoft.com); Tue, 13 May 2003 14:59:31 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00I01A36EF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 14:59:30 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00I01A36ED@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 14:59:30 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00F8OA35EH@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 14:59:29 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Tue, 13 May 2003 11:59:00 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 May 2003 11:59:00 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0) ; Tue, 13 May 2003 11:58:59 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 May 2003 11:58:59 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 13 May 2003 11:58:53 -0700 Date: Tue, 13 May 2003 11:58:00 -0700 From: Christian Huitema Subject: RE: deadlock problem To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: deadlock problem thread-index: AcMZfIcHQi6s7w4ZSd6z5J9hcxmqrAAAl3qg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 13 May 2003 18:58:53.0337 (UTC) FILETIME=[B28A0090:01C31981] > =09ISOC BoT have for *years* been following an RFC-specified > confirmation > process that does not appear to be in its bylaws. =20 The bylaws specify voting procedures in general. The formal adoption = of the ISOC Board's role in the nomination process is a resolution of th= e Board of Trustees:=20 =09Resolution 98-03 Selection of IAB and IESG members. =09RESOLVED, that the Board accepts the process for=20 =09selection of IAB and IESG members, as documented in=20 =09RFC 2282, and accepts the role of the Board described=20 =09in this process. This resolution amends the previous state, references to the "poised" documents adopted in 1992 and 1993. Presumably, when the new RFC is published, the board will review it. In fact, if an RFC specifies an ISOC action, the ISOC board will be part of the last call. =20 > =09At best, your claim is late in the day -- years late. If IAB or > ISOC really had heartache over this (and I can say that the IAB had= =20 > *no* anxiety > about it during my 4 years on the IAB and I heard zero individual > complaints > about it), that REALLY should have been raised years ago (e.g. at a= ny > of the > IAB Chair transitions or when the first RFC on Nomcom procedures wa= s > published). Well, I have witnessed "some" anxiety, as in last minute phone conferences to make sure that the slate was voted on in time. > =09And I'll note that if you adhere to the position you outline above > (i.e. that how a confirming body decides stuff is their concern onl= y), > then this WG should delete the current text and ought not be discussing > "the way we manage indecision". My point is that the RFC should not mention specific voting rules, e.= g. simple majority rather than consensus or whatever else the confirmati= on body sees as appropriate. > =09As to how to do indecision, I think that boils down to (A) or (C) > versus (B) or (D). I can live with any of those 4. All of A, B, C and D have the drawback that they specify a voting rul= e. I would rather go for a choice between (E) and (F): (Proposal E) For a given nominee to be confirmed, an explicit confirmation by the confirming body is required. Nominees that are not confirmed under th= is rule are considered to be rejected. xor (Proposal F) For a given nominee to be rejected, an explicit rejection by the confirming body is required. Nominees that are not confirmed under th= is rule are considered to be confirmed. How the confirming bodies arrive to explicit confirmation or implicit rejection is their own cooking. -- Christian Huitema From ietf-nomcom-errors@lists.elistx.com Tue May 13 15:45:10 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00K04C21LW@eListX.com> (original mail from rja@extremenetworks.com) ; Tue, 13 May 2003 15:42:01 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00K01C20LU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 15:42:00 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00K01C20LT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 15:42:00 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00FC4C1ZEH@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 15:41:59 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id CCA1667103; Tue, 13 May 2003 16:06:58 -0400 (EDT) Date: Tue, 13 May 2003 15:41:28 -0400 From: RJ Atkinson Subject: Re: deadlock problem In-reply-to: To: Christian Huitema Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tuesday, May 13, 2003, at 14:58 America/Montreal, Christian Huitema wrote: >> At best, your claim is late in the day -- years late. If IAB or >> ISOC really had heartache over this (and I can say that the IAB had >> *no* anxiety >> about it during my 4 years on the IAB and I heard zero individual >> complaints >> about it), that REALLY should have been raised years ago (e.g. at any >> of the >> IAB Chair transitions or when the first RFC on Nomcom procedures was >> published). > > Well, I have witnessed "some" anxiety, as in last minute phone > conferences to make sure that the slate was voted on in time. my bad -- unclear antecedent in my note. "this" in my note quoted above meant "Confirmation process being specified in an RFC" rather than "this" meaning "confirmation process being completed on time". I suspect that "confirmation process being completed on time" is a frequent anxiety -- at least of individuals on the confirming bodies and sometimes of the confirming body as a whole. >> And I'll note that if you adhere to the position you outline > above >> (i.e. that how a confirming body decides stuff is their concern only), >> then this WG should delete the current text and ought not be > discussing >> "the way we manage indecision". > > My point is that the RFC should not mention specific voting rules, e.g. > simple majority rather than consensus or whatever else the confirmation > body sees as appropriate. My point is different: The existing text in the online I-D has always mentioned specific voting rules (e.g. 50%) -- yet no one seemed to have a problem with that existing text until I raised the question very very recently. It seems very curious that some folks are now worried that some specific voting rules are mentioned in the RFC, yet folks were not worried about specific voting rules being in the RFC before the last day or two, even though the text has been there all along. Probably best if we set both of those points (yours and mine) aside, and focus on how to move forward to eliminate deadlock as a problem in confirmation. > All of A, B, C and D have the drawback that they specify a voting rule. > I would rather go for a choice between (E) and (F): > > (Proposal E) > For a given nominee to be confirmed, an explicit confirmation by the > confirming body is required. Nominees that are not confirmed under this > rule are considered to be rejected. > > xor (Proposal F) > For a given nominee to be rejected, an explicit rejection by the > confirming body is required. Nominees that are not confirmed under this > rule are considered to be confirmed. > > How the confirming bodies arrive to explicit confirmation or implicit > rejection is their own cooking. (E) and (F) are OK with me, only if the confirming bodies have internal processes which preclude the confirming body wedging in some deadlock. It might be the case that your wording is trying to preclude such wedging -- not clear whether that is your intent nor whether the wording achieves that goal. Maybe you could at least clarify your intent ? Maybe there is an opportunity to wordsmith it (perhaps using the existing deadlock state in IAB decision process as a test case) to achieve the no-deadlock property ? Thanks, Ran From ietf-nomcom-errors@lists.elistx.com Tue May 13 15:45:13 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00K04C33NU@eListX.com> (original mail from tytso@thunk.org); Tue, 13 May 2003 15:42:39 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00K01C32NQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 15:42:38 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00K01C31NP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 15:42:37 -0400 (EDT) Received: from snap.thunk.org (SNAP.THUNK.ORG [216.175.175.173]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00I5PC316Y@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 15:42:37 -0400 (EDT) Received: from think.thunk.org ([216.175.175.162]) by snap.thunk.org with asmtp (Exim 3.35 #1 (Debian)) id 19Fff3-00033G-00; Tue, 13 May 2003 15:42:05 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19FdE9-00018z-00; Tue, 13 May 2003 13:06:09 -0400 Date: Tue, 13 May 2003 13:06:09 -0400 From: Theodore Ts'o Subject: Re: deadlock problem In-reply-to: <3EC0241A.9060207@acm.org> To: Avri Doria Cc: ietf-nomcom@lists.elistx.com Message-id: <20030513170609.GA4052@think> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.5.4i References: <200305121931.h4CJV0Hg015993@newdev.harvard.edu> <3EC003A7.A63288A3@bell-labs.com> <3EC0241A.9060207@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tue, May 13, 2003 at 07:45:46AM +0900, Avri Doria wrote: > You have been given lots of options from: > - doing nothing and leaving it as written in RFC2727 and 2727bis, > - to making one of the changes {A-D} Mike suggests, > - to removing the clause altogether and leaving it up to > the CB to determine it own processes as Harald suggests. My preference would be - to remove the clause altogether and leaving it up to the CB to determine it own processes as Harald suggests. followed by - change A as suggested by Ran Either is fine with me, with a slight preference towards the first. - Ted From ietf-nomcom-errors@lists.elistx.com Tue May 13 15:45:15 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00K04C3BOX@eListX.com> (original mail from tytso@thunk.org); Tue, 13 May 2003 15:42:47 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00K01C3AOM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 15:42:46 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00K01C39OI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 15:42:45 -0400 (EDT) Received: from snap.thunk.org (SNAP.THUNK.ORG [216.175.175.173]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00I4OC387P@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 15:42:45 -0400 (EDT) Received: from think.thunk.org ([216.175.175.162]) by snap.thunk.org with asmtp (Exim 3.35 #1 (Debian)) id 19Fff2-00033C-00; Tue, 13 May 2003 15:42:04 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19FfMI-0001cd-00; Tue, 13 May 2003 15:22:42 -0400 Date: Tue, 13 May 2003 15:22:42 -0400 From: Theodore Ts'o Subject: Re: deadlock problem In-reply-to: To: RJ Atkinson Cc: Brian E Carpenter , ietf-nomcom@lists.elistx.com Message-id: <20030513192242.GC4052@think> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.5.4i References: <3EC11C34.79E45F20@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tue, May 13, 2003 at 01:02:49PM -0400, RJ Atkinson wrote: > > On Tuesday, May 13, 2003, at 12:24 America/Montreal, Brian E Carpenter > wrote: > >True, unless the IAB chooses to exercise common sense. > > Brian, > > Lack of common sense has never been evident on the IAB, AFAIK. > > Despite that, deadlock HAS been evident. One might legitimately > abstain for common sense reasons. Individuals might legitimately have > different views on a given candidate for common sense reasons. The > intersection of that has lead to deadlock under the current process rule > (and would lead to deadlock on the relevant section of the IAB Charter's > decision process, as several folks have outlined to this list). Ran, I'm not too worried about this. *If* the IAB were to deadlock badly enough that IESG members could not be seated in time for the first IETF meeting, it would look really bad and be very embarassing for the IAB ---- and no doubt, the following year's nomcom would be asking some very hard questions about the sort of people that were serving on the IAB such that the process could break down so badly. At the very least, such a breakdown would likely cause the IAB to seriously reconsider concerning its own internal processes that allowed such a deadlock to happen in the first place. So if it happens, it can be fixed, either by fixing the IAB procedures, or by having the following year's nomcom fix the personnel problem. And if it doesn't happen, well, then we didn't need to fix anything, did we? :-) So I'd just remove the rule, and let each confirming body take the responsibility (and part of responsibilty is the possibility of getting whacked if you screw up) determine its own decision-making procedures. - Ted From ietf-nomcom-errors@lists.elistx.com Tue May 13 15:55:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00L04CE024@eListX.com> (original mail from sob@newdev.harvard.edu) ; Tue, 13 May 2003 15:49:12 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00L01CE022@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 15:49:12 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00L01CDZ21@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 15:49:11 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00I61CDY6Y@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 15:49:11 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h4DJmfH3025821 for ; Tue, 13 May 2003 15:48:41 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4DJmf32025820 for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 15:48:41 -0400 (EDT) Date: Tue, 13 May 2003 15:48:41 -0400 (EDT) From: Scott Bradner Subject: Re: Question 1 about deadlock issue To: ietf-nomcom@lists.elistx.com Message-id: <200305131948.h4DJmf32025820@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Does anyone here believe that the current confirmation text should be > retained as-is ? not me Scott From ietf-nomcom-errors@lists.elistx.com Tue May 13 15:55:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00L04CFG4J@eListX.com> (original mail from rja@extremenetworks.com) ; Tue, 13 May 2003 15:50:04 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00L01CFF4H@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 15:50:03 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00L01CFE4G@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 15:50:02 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00I40CFDCA@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 15:50:01 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id B343C67103; Tue, 13 May 2003 16:15:01 -0400 (EDT) Date: Tue, 13 May 2003 15:49:31 -0400 From: RJ Atkinson Subject: Re: deadlock problem In-reply-to: <20030513192242.GC4052@think> To: Theodore Ts'o Cc: ietf-nomcom@lists.elistx.com Message-id: <03A08E52-857C-11D7-B680-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tuesday, May 13, 2003, at 15:22 America/Montreal, Theodore Ts'o wrote: > So I'd just remove the rule, and let each confirming body take the > responsibility ... This sounds like: 1) you believe the current confirmation process text is broken 2) your preferred fix is to delete the current process text Correct understanding ? Thanks, Ran From ietf-nomcom-errors@lists.elistx.com Tue May 13 16:15:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00L04D4NXF@eListX.com> (original mail from tytso@thunk.org); Tue, 13 May 2003 16:05:11 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00L01D4NX6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 16:05:11 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00L01D4MX4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 16:05:10 -0400 (EDT) Received: from snap.thunk.org (SNAP.THUNK.ORG [216.175.175.173]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00FDKD4LEH@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 16:05:10 -0400 (EDT) Received: from think.thunk.org ([216.175.175.162]) by snap.thunk.org with asmtp (Exim 3.35 #1 (Debian)) id 19Fg0u-000341-00; Tue, 13 May 2003 16:04:40 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19Fg0u-0001hv-00; Tue, 13 May 2003 16:04:40 -0400 Date: Tue, 13 May 2003 16:04:40 -0400 From: Theodore Ts'o Subject: Re: deadlock problem In-reply-to: <03A08E52-857C-11D7-B680-00039357A82A@extremenetworks.com> To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: <20030513200439.GG6312@think> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.5.4i References: <20030513192242.GC4052@think> <03A08E52-857C-11D7-B680-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tue, May 13, 2003 at 03:49:31PM -0400, RJ Atkinson wrote: > > On Tuesday, May 13, 2003, at 15:22 America/Montreal, Theodore Ts'o > wrote: > >So I'd just remove the rule, and let each confirming body take the > >responsibility ... > > This sounds like: > 1) you believe the current confirmation process text is broken > 2) your preferred fix is to delete the current process text > > Correct understanding ? Yes, that is correct. - Ted From ietf-nomcom-errors@lists.elistx.com Tue May 13 19:55:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00604NFJTD@eListX.com> (original mail from jwkckid1@ix.netcom.com) ; Tue, 13 May 2003 19:47:43 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00601NFITB@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 19:47:43 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00601NFITA@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 19:47:42 -0400 (EDT) Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00IGQNFH7P@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 19:47:41 -0400 (EDT) Received: from dialup-209.245.239.46.dial1.dallas1.level3.net ([209.245.239.46] helo=ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 19FjUF-0004ux-00; Tue, 13 May 2003 19:47:11 -0400 Date: Tue, 13 May 2003 18:45:11 -0700 From: Jeff Williams Subject: Re: Question 1 about deadlock issue To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: <3EC19FA7.937C0292@ix.netcom.com> Organization: INEGroup Spokesman MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <731CB764-856E-11D7-B680-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Ran and all, No I don't.. RJ Atkinson wrote: > Does anyone here believe that the current confirmation text should be > retained > as-is ? > > Please speak up on-list if you believe in retaining the current > confirmation > process text as-is. I'd be interested to understand the rationale for > retaining it if anyone wants to retain it. > > Silence will be interpreted as agreement that the current text at issue > either (1) should be edited in some manner xor (2) deleted entirely. > > My goal here is to try to validate that there is broad belief that the > current text should not remain as-is in the final RFC, ignoring for > the moment the question of what change the WG prefers to undertake. > > Thanks, > > Ran > rja@extremenetworks.com > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!) ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From ietf-nomcom-errors@lists.elistx.com Tue May 13 20:45:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00804PYFWK@eListX.com> (original mail from avri@acm.org); Tue, 13 May 2003 20:42:15 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00801PYEWI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 20:42:14 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00801PYEWH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 20:42:14 -0400 (EDT) Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00IL7PYD6Y@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 20:42:13 -0400 (EDT) Received: from acm.org (IDENT:hiUTHvW9tBnnxav8jzJXGRTKskk0LnE4@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h4E0fc322155; Tue, 13 May 2003 20:41:39 -0400 Date: Wed, 14 May 2003 09:41:35 +0900 From: Avri Doria Subject: Re: Question 1 about deadlock issue To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: <3EC190BF.8060300@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 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <731CB764-856E-11D7-B680-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Speaking as chair. While this is an interesting point to know, and I would like to see people respond to it, I am uncomfortable with the notion of change for change sake and for deciding to change something before we know what we are changing it to. The way this WG has been treating change to the Nomcom process is that there has to be positive rough consensus for a particular change before we remove old text. I do not think we should deviate from that practice on this question. At the moment it looks like we are headed toward consensus on a combination of proposals but it is a too early to call it. What I think I see developing is a 2 part solution where: 1st - the confirmation procedure defers to the CB if they have a documented terminating procedure in place. 2nd - includes selection A as the default process for the CB without a process in place. But, I would like to hear more voices on the question in the next couple of days. a. RJ Atkinson wrote: > > Does anyone here believe that the current confirmation text should be > retained > as-is ? > > Please speak up on-list if you believe in retaining the current confirmation > process text as-is. I'd be interested to understand the rationale for > retaining it if anyone wants to retain it. > > Silence will be interpreted as agreement that the current text at issue > either (1) should be edited in some manner xor (2) deleted entirely. > > My goal here is to try to validate that there is broad belief that the > current text should not remain as-is in the final RFC, ignoring for > the moment the question of what change the WG prefers to undertake. > > Thanks, > > Ran > rja@extremenetworks.com > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: > From ietf-nomcom-errors@lists.elistx.com Tue May 13 22:25:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00B04U97P4@eListX.com> (original mail from dee3@torque.pothole.com) ; Tue, 13 May 2003 22:15:07 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00B01U96OY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 22:15:06 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00B01U95ON@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 22:15:05 -0400 (EDT) Received: from zydeco.netbusters.com (zydeco.netbusters.com [66.92.86.178]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00IO8U94BO@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 22:15:04 -0400 (EDT) Received: by zydeco.netbusters.com (Postfix, from userid 513) id 56F06B63BC; Wed, 14 May 2003 02:14:34 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id 5485B7EC1E for ; Tue, 13 May 2003 22:14:34 -0400 (EDT) Date: Tue, 13 May 2003 22:14:34 -0400 (EDT) From: Donald Eastlake 3rd Subject: Re: deadlock problem In-reply-to: <20030513192242.GC4052@think> X-X-Sender: dee3@zydeco.netbusters.com To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I agree with Ted. It's the responsibility of the Nomcom and the confirming bodies to work it out. We get to specify the Nomcom rules. The confirming bodies should specify their own rules. Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Tue, 13 May 2003, Theodore Ts'o wrote: > Date: Tue, 13 May 2003 15:22:42 -0400 > From: Theodore Ts'o > To: RJ Atkinson > Cc: Brian E Carpenter , ietf-nomcom@lists.elistx.com > Subject: Re: deadlock problem > > On Tue, May 13, 2003 at 01:02:49PM -0400, RJ Atkinson wrote: > > > > On Tuesday, May 13, 2003, at 12:24 America/Montreal, Brian E Carpenter > > wrote: > > >True, unless the IAB chooses to exercise common sense. > > > > Brian, > > > > Lack of common sense has never been evident on the IAB, AFAIK. > > > > Despite that, deadlock HAS been evident. One might legitimately > > abstain for common sense reasons. Individuals might legitimately have > > different views on a given candidate for common sense reasons. The > > intersection of that has lead to deadlock under the current process rule > > (and would lead to deadlock on the relevant section of the IAB Charter's > > decision process, as several folks have outlined to this list). > > Ran, > > I'm not too worried about this. *If* the IAB were to deadlock badly > enough that IESG members could not be seated in time for the first > IETF meeting, it would look really bad and be very embarassing for the > IAB ---- and no doubt, the following year's nomcom would be asking > some very hard questions about the sort of people that were serving on > the IAB such that the process could break down so badly. At the very > least, such a breakdown would likely cause the IAB to seriously > reconsider concerning its own internal processes that allowed such a > deadlock to happen in the first place. > > So if it happens, it can be fixed, either by fixing the IAB > procedures, or by having the following year's nomcom fix the personnel > problem. And if it doesn't happen, well, then we didn't need to fix > anything, did we? :-) > > So I'd just remove the rule, and let each confirming body take the > responsibility (and part of responsibilty is the possibility of > getting whacked if you screw up) determine its own decision-making > procedures. > > - Ted > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: > From ietf-nomcom-errors@lists.elistx.com Tue May 13 23:45:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00D03XYKNI@eListX.com> (original mail from ietf-nomcom+moderator@lists.elistx.com); Tue, 13 May 2003 23:35:08 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00D01WW43Y@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 23:12:04 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00D01WW43X@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com) ; Tue, 13 May 2003 23:12:04 -0400 (EDT) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00D04WW33U@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 23:12:03 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00D01WW33S@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 23:12:03 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEU00D01WW23R@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 13 May 2003 23:12:02 -0400 (EDT) Received: from lawyers.ir.bbn.com (d14-69-204-117.clv.wideopenwest.com [69.14.117.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEU00B52WVXS9@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 13 May 2003 23:12:02 -0400 (EDT) Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id 727526B2B7; Tue, 13 May 2003 23:08:10 -0400 (EDT) Date: Tue, 13 May 2003 23:08:10 -0400 From: Mark Allman Subject: Re: Question 1 about deadlock issue In-reply-to: <3EC190BF.8060300@acm.org> Sender: mallman@ir.bbn.com To: Avri Doria Cc: RJ Atkinson , ietf-nomcom@lists.elistx.com Reply-to: mallman@grc.nasa.gov Message-id: <20030514030810.727526B2B7@lawyers.ir.bbn.com> Organization: BBN Technologies/NASA GRC Content-type: TEXT/PLAIN Song-of-the-Day: Long May You Run X-Spam-Status: No, hits=-1.8 required=7.5 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.31 X-Spam-Level: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > 1st - the confirmation procedure defers to the CB if they have a > documented terminating procedure in place. > 2nd - includes selection A as the default process for the CB without > a process in place. This seems reasonable to me. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From ietf-nomcom-errors@lists.elistx.com Wed May 14 03:25:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00K048KWZU@eListX.com> (original mail from brian@hursley.ibm.com) ; Wed, 14 May 2003 03:24:32 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00K018KVZS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 03:24:32 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00K018KVZR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 03:24:31 -0400 (EDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEV00HH98KUG8@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 14 May 2003 03:24:31 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4E7NsE2119708; Wed, 14 May 2003 03:23:55 -0400 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4E7Nips156472; Wed, 14 May 2003 09:23:46 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA18386 from ; Wed, 14 May 2003 09:23:30 +0200 Date: Wed, 14 May 2003 09:23:58 +0200 From: Brian E Carpenter Subject: Re: ISOC by-laws [Re: deadlock problem] To: Scott Bradner Cc: Christian Huitema , ietf-nomcom@lists.elistx.com Message-id: <3EC1EF0E.7902D497@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: <200305131650.h4DGoixU024940@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: We should obsolete 2135 and replace it with a current version. It's unsafe, though, since the only valid version is the one at the URL I sent. 2134 is still valid, fwiw. Brian Scott Bradner wrote: > > RJ Atkinson wrote: > ... > > Is the ISOC Charter published in an RFC anyplace where it would be > > widely accessible ? > > RFC 2134 & 2135 From ietf-nomcom-errors@lists.elistx.com Wed May 14 05:05:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00004CV1NX@eListX.com> (original mail from randy@psg.com); Wed, 14 May 2003 04:57:01 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00001CV1NV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 04:57:01 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00001CV0NU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 04:57:00 -0400 (EDT) Received: from psg.com (psg.com [147.28.0.62]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEV00J89CUZVF@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 14 May 2003 04:57:00 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Fs3q-000OhP-01 for ietf-nomcom@lists.elistx.com; Wed, 14 May 2003 08:56:31 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19FruV-0002fS-8a for ietf-nomcom@lists.elistx.com; Wed, 14 May 2003 10:46:51 +0200 Date: Wed, 14 May 2003 10:46:50 +0200 From: Randy Bush Subject: Re: deadlock problem To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <3EC0FFAB.A4F86E07@hursley.ibm.com> <5.1.0.14.0.20030513113010.028ba188@mail.stevecrocker.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: i continue to be amazed at our hubris to presume we can tell other bodies what processes to use to make their decisions. randy From ietf-nomcom-errors@lists.elistx.com Wed May 14 09:05:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00702O4WH5@eListX.com> (original mail from ietf-nomcom+moderator@lists.elistx.com); Wed, 14 May 2003 09:00:32 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00701O4VH4@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 09:00:31 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00701O4VH3@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com) ; Wed, 14 May 2003 09:00:31 -0400 (EDT) Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00704O4VH0@eListX.com> for ietf-nomcom+moderator@lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 09:00:31 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00701O4UGY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 09:00:30 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00701O4TGW@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 09:00:29 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEV0064SO4SC8@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 14 May 2003 09:00:29 -0400 (EDT) Date: Wed, 14 May 2003 09:00:13 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Question 1 about deadlock issue In-reply-to: <3EC190BF.8060300@acm.org> To: Avri Doria Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <731CB764-856E-11D7-B680-00039357A82A@extremenetworks.com> <3EC190BF.8060300@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Wed, 14 May 2003, Avri Doria wrote: What I think I see developing is a 2 part solution where: 1st - the confirmation procedure defers to the CB if they have a documented terminating procedure in place. This sounds good to me. 2nd - includes selection A as the default process for the CB without a process in place. I object to the default being that a candidate is rejected if the confirming body deadlocks or otherwise is unable or fails to take action. The NOMCOM is the voice of the community and preference should be given to their actions. The confirming body is supposed to check the work of the NOMCOM and if they are unable to do that then there is a serious problem, which itself is fixed by the NOMCOM. Clearly the NOMCOM is the primary authority. I prefer that we be silent on the default action but Proposal B where the default action is confirmation would also be acceptable. Jim From ietf-nomcom-errors@lists.elistx.com Wed May 14 10:35:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00A04S9X8Q@eListX.com> (original mail from rja@extremenetworks.com) ; Wed, 14 May 2003 10:29:57 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00A01S9W8O@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 10:29:56 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00A01S9W8N@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 10:29:56 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEV006G1S9UC8@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 14 May 2003 10:29:55 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 7C5396712A; Wed, 14 May 2003 10:55:01 -0400 (EDT) Date: Wed, 14 May 2003 10:29:23 -0400 From: RJ Atkinson Subject: Re: Question 1 about deadlock issue In-reply-to: <3EC190BF.8060300@acm.org> To: Avri Doria Cc: ietf-nomcom@lists.elistx.com Message-id: <7530E2BA-8618-11D7-B256-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tuesday, May 13, 2003, at 20:41 America/Montreal, Avri Doria wrote: > Speaking as chair. > > While this is an interesting point to know, and I would like to > see people respond to it, I am uncomfortable with the notion of > change for change sake and for deciding to change something > before we know what we are changing it to. Change for the sake of change has NEVER been on the list on this thread. Change to remove a known operational problem (deadlock state that has actually occurred) is what is being discussed. > The way this WG has been treating change to the Nomcom process is > that there has to be positive rough consensus for a particular change > before we remove old text. I do not think we should deviate from > that practice on this question. That is not a requirement from RFC-2026 as amended. So the Chair has no leg to stand on in trying to force the process outlined. > At the moment it looks like we are headed toward consensus on a > combination of proposals but it is a too early to call it. We might or might not be heading to consensus. Chair stifling legitimate list discussion (as the note being replied do has already done) is not terribly helpful. > What I think I see developing is a 2 part solution where: With the Chair's hat on, the Chair ought not be telling the WG what the WG is permitted to think. Please let the discussion flow for several days or even a week. The WG might or might not converge, but heavy-handed chair interference isn't helpful at this early stage. IMHO, Ran Atkinson rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Wed May 14 10:55:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00A04TB0X3@eListX.com> (original mail from rja@extremenetworks.com) ; Wed, 14 May 2003 10:52:12 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00A01TAZX1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 10:52:11 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEV00A01TAZX0@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 14 May 2003 10:52:11 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEV006FWTAYC9@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 14 May 2003 10:52:10 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id CE3EA6712A for ; Wed, 14 May 2003 11:17:17 -0400 (EDT) Date: Wed, 14 May 2003 10:51:39 -0400 From: RJ Atkinson Subject: Question 2 To: ietf-nomcom@lists.elistx.com Message-id: <916AB534-861B-11D7-B256-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Since I haven't seen anyone indicate support for retaining the current text as-is, I'll try to list all of the proposed fixes that have had support from at least one person on the list. I might have missed a proposal by accident, so the point of this note is merely to gather corrections to the draft list of proposed fixes (below). Candidate Fixes: ---------------- - delete current text; no replacement text. - delete current text; add text explicitly saying that confirming bodies set their own rules for confirmation process. - Ran's option (A) - Ran's option (B) {I am possibly confused, but I think (B) is what Jim Galvin is saying.} - Christian's option (E) - Christian's option (F) - StJohns' proposal to delete current text, add (A) but with his editorial change to (A) that it applies if and only if the confirming body has not created a specific confirmation process for itself to use with nominees from IETF Nomcom. Does this list include all of the proposed candidate fixes ? If it does not include your preferred fix, please post your preferred fix to the list so it can get added to this list. Thanks, Ran Atkinson rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Thu May 15 08:45:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00604HOU2P@eListX.com> (original mail from brian@hursley.ibm.com) ; Thu, 15 May 2003 08:36:30 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00601HOT2H@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 08:36:29 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00601HOS2F@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 08:36:28 -0400 (EDT) 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 <0HEX0052YHOR6K@eListX.com>; Thu, 15 May 2003 08:36:28 -0400 (EDT) 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 h4FCZpUm071060; Thu, 15 May 2003 14:35:53 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4FCZZDk052858; Thu, 15 May 2003 14:35:36 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31324 from ; Thu, 15 May 2003 14:35:32 +0200 Date: Thu, 15 May 2003 14:36:03 +0200 From: Brian E Carpenter Subject: Re: Question 1 about deadlock issue To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <3EC389B3.97D4A4AD@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: <731CB764-856E-11D7-B680-00039357A82A@extremenetworks.com> <3EC190BF.8060300@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: James M Galvin wrote: ... > 2nd - includes selection A as the default process for the CB without > a process in place. > > I object to the default being that a candidate is rejected if the > confirming body deadlocks or otherwise is unable or fails to take > action. The NOMCOM is the voice of the community and preference should > be given to their actions. The confirming body is supposed to check the > work of the NOMCOM and if they are unable to do that then there is a > serious problem, which itself is fixed by the NOMCOM. Not if the deadlocked CB is the ISOC Board, and not soon enough if the deadlocked CB is the IAB. > ...Clearly the > NOMCOM is the primary authority. Is that clear? In a checks-and-balances system, there is not always a primary authority, although there may be a final appeals court. > I prefer that we be silent on the default action but Proposal B where > the default action is confirmation would also be acceptable. Ran's original argument on this, which persuaded me to prefer A, was >> if a candidate is so controversial that at least 50% >> of the confirming body is not actively supportive of a given candidate >> then that candidate is clearly not the best choice for the Internet >> community. which says that the CB trumps the Nomcom. We had indeed better be clear about that, one way or the other. Since in our present constitution, the CBs are also the process appeals bodies, we have to be even more clear. Brian From ietf-nomcom-errors@lists.elistx.com Thu May 15 09:45:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00804KJ95D@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Thu, 15 May 2003 09:37:57 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00801KJ95B@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 09:37:57 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00801KJ859@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 09:37:56 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEX005BUKJ76K@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 15 May 2003 09:37:56 -0400 (EDT) Date: Thu, 15 May 2003 09:37:39 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Question 1 about deadlock issue In-reply-to: <3EC389B3.97D4A4AD@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: <731CB764-856E-11D7-B680-00039357A82A@extremenetworks.com> <3EC190BF.8060300@acm.org> <3EC389B3.97D4A4AD@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thu, 15 May 2003, Brian E Carpenter wrote: James M Galvin wrote: > I prefer that we be silent on the default action but Proposal B where > the default action is confirmation would also be acceptable. Ran's original argument on this, which persuaded me to prefer A, was >> if a candidate is so controversial that at least 50% >> of the confirming body is not actively supportive of a given candidate >> then that candidate is clearly not the best choice for the Internet >> community. which says that the CB trumps the Nomcom. We had indeed better be clear about that, one way or the other. Since in our present constitution, the CBs are also the process appeals bodies, we have to be even more clear. While I agree with Ran completely, my concern is I want the CB to take responsibility for its actions. Specifically, if the CB can not agree to confirm a candidate I want the process to force them to actionably reject the candidate. The problem with the default being reject is it sets aside 2 months of hard work of the NOMCOM for 2 weeks of the CB being unable to agree. I'm okay with the CB rejecting a candidate I just want them to actually do it. I am not okay with the CB having the option to step aside and leave the NOMCOM wondering what happened and what to do next. The communication path between the NOMCOM and CB is very narrow. I want to make sure that if it needs to exist it will exist. Letting the CB take no action leaves the NOMCOM disconnected from the CB. Forcing the CB to actually reject a candidate if they can not agree to confirm the candidate ensures that both parties have a path to communicate. Whether or not they will is an entirely separate matter, but the process should not leave a hole like that, in my opinion. I still believe setting a default is more than we need to do, because even with it the process can deadlock so the improvement is marginal at best, but if we must have a default it should favor the NOMCOM and thus should be to confirm. Jim From ietf-nomcom-errors@lists.elistx.com Thu May 15 09:45:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00804KMG7L@eListX.com> (original mail from rja@extremenetworks.com) ; Thu, 15 May 2003 09:39:52 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00801KMF7J@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 09:39:51 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00801KMF7D@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 09:39:51 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEX005CKKME6L@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 15 May 2003 09:39:50 -0400 (EDT) Received: from extremenetworks.com (unknown [10.0.8.119]) by gnat.inet.org (Postfix) with ESMTP id D506567107; Thu, 15 May 2003 10:05:01 -0400 (EDT) Date: Thu, 15 May 2003 09:38:19 -0400 From: RJ Atkinson Subject: Re: Question 1 about deadlock issue In-reply-to: <3EC389B3.97D4A4AD@hursley.ibm.com> To: Brian E Carpenter Cc: James M Galvin , ietf-nomcom@lists.elistx.com Message-id: <7D46469B-86DA-11D7-A0F3-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thursday, May 15, 2003, at 08:36 America/Montreal, Brian E Carpenter wrote: > James M Galvin wrote: > ... >> 2nd - includes selection A as the default process for the CB >> without >> a process in place. >> >> I object to the default being that a candidate is rejected if the >> confirming body deadlocks or otherwise is unable or fails to take >> action. The NOMCOM is the voice of the community and preference >> should >> be given to their actions. The confirming body is supposed to check >> the >> work of the NOMCOM and if they are unable to do that then there is a >> serious problem, which itself is fixed by the NOMCOM. > > Not if the deadlocked CB is the ISOC Board, and not soon enough if the > deadlocked CB is the IAB. Further, having been on IAB for 4 years of confirmations, I can say that the IAB is *unable* to perform any plausible process-check on any Nomcom. The Nomcom confidentiality rules preclude the IAB from having sufficient visibility into how the process was performed for the IAB to perform a meaningful process-check on the Nomcom. So the only check the IAB is really capable of performing is whether the nominated person is a reasonable fit for the position specified. (NB: "reasonable" is deliberately chosen above rather than "ideal" or even "preferred" -- in order to give Nomcom appropriate operating room). >> ...Clearly the >> NOMCOM is the primary authority. > > Is that clear? In a checks-and-balances system, there is not always > a primary authority, although there may be a final appeals court. > >> I prefer that we be silent on the default action but Proposal B where >> the default action is confirmation would also be acceptable. > > Ran's original argument on this, which persuaded me to prefer A, was > >>> if a candidate is so controversial that at least 50% >>> of the confirming body is not actively supportive of a given >>> candidate >>> then that candidate is clearly not the best choice for the Internet >>> community. > > which says that the CB trumps the Nomcom. We had indeed better > be clear about that, one way or the other. Since in our present > constitution, the CBs are also the process appeals bodies, we have to > be even more clear. > > Brian I'm with Brian on this. We can't be ambiguous. If one doesn't like the balance of (A) or (C) or (E) then the implication is that one prefers the balance of (B) or (D) or (F). We'll have to see if a consensus emerges either way on that balance question. Ran From ietf-nomcom-errors@lists.elistx.com Thu May 15 09:55:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00804LB7LJ@eListX.com> (original mail from rja@extremenetworks.com) ; Thu, 15 May 2003 09:54:43 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00801LB6LA@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 09:54:42 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00801LB6L8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 09:54:42 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEX005E5LB56K@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 15 May 2003 09:54:41 -0400 (EDT) Received: from extremenetworks.com (unknown [10.0.8.120]) by gnat.inet.org (Postfix) with ESMTP id 60B9E67115; Thu, 15 May 2003 10:19:56 -0400 (EDT) Date: Thu, 15 May 2003 09:54:08 -0400 From: RJ Atkinson Subject: Re: Question 1 about deadlock issue In-reply-to: To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thursday, May 15, 2003, at 09:37 America/Montreal, James M Galvin wrote: > While I agree with Ran completely, my concern is I want the CB to take > responsibility for its actions. Specifically, if the CB can not agree > to confirm a candidate I want the process to force them to actionably > reject the candidate. > > The problem with the default being reject is it sets aside 2 months of > hard work of the NOMCOM for 2 weeks of the CB being unable to agree. It is never the case that the CB would not be taking responsibility. In practice, most nominees fly through with unanimous support from the CB. It is actually quite rare for a nominee to have any controversy. Even then, it is usual that the controversial nominee can easily obtain a majority of the CB members. So if the CB can't garner at least half of the CB members to actively support some nominee, this is (1) very very unusual, (2) a very bad indication of the candidate, and (3) a strong indication that the Nomcom process might have gone awry somehow. Hence my preference for the (A)/(C)/(E) approach over the (B)/(D)/(F) approach. Reasonable people might well prefer B/D/F over A/C/E. > The communication path between the NOMCOM and CB is very narrow. I > want > to make sure that if it needs to exist it will exist. Letting the CB > take no action leaves the NOMCOM disconnected from the CB. Forcing the > CB to actually reject a candidate if they can not agree to confirm the > candidate ensures that both parties have a path to communicate. > Whether > or not they will is an entirely separate matter, but the process should > not leave a hole like that, in my opinion. In practice, the communication path is moderate in size -- "very narrow" is not something I've ever witnessed. Under the A/C/E approach, the CB must still take action -- hold a poll of the CB members. So "inaction" is NOT at issue in any of these cases. The only difference here is whether the standard for approval is (at least 50% support) [as in B/D/F] or the standard for approval is (less than 50% reject) [as in A/C/E]. You seem to be reading "inaction is permitted" into A/C/E, when in fact that is neither stated nor intended. If you want to propose a sentence to clarify that the CB must hold a poll on each candidate to clarify that, please offer some clarifying text. Cheers, Ran rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Thu May 15 11:15:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00B04OQR17@eListX.com> (original mail from galvin+ietf-nomcom@eListX.com); Thu, 15 May 2003 11:08:52 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00B01OQR15@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 11:08:51 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00B01OQQ13@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 11:08:50 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEX00A2GOQPIA@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 15 May 2003 11:08:50 -0400 (EDT) Date: Thu, 15 May 2003 11:08:33 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Question 1 about deadlock issue In-reply-to: To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thu, 15 May 2003, RJ Atkinson wrote: Under the A/C/E approach, the CB must still take action -- hold a poll of the CB members. So "inaction" is NOT at issue in any of these cases. My concern is the text does not obligate them to report the results of their poll, i.e., the phrase "considered to be rejected" is not strong enough. The only difference here is whether the standard for approval is (at least 50% support) [as in B/D/F] or the standard for approval is (less than 50% reject) [as in A/C/E]. You seem to be reading "inaction is permitted" into A/C/E, when in fact that is neither stated nor intended. If you want to propose a sentence to clarify that the CB must hold a poll on each candidate to clarify that, please offer some clarifying text. Fair enough. I agree with your distinction. Here's my suggestion. Your original text: For a given nominee to be confirmed, at least one-half of the sitting members of the confirming bodies must agree to confirm that nominee. Nominees that are not confirmed under this rule are considered to be rejected. For completeness, here is the actual text from Page 10 of the current draft: 4. The confirming bodies decide their consent according to a mechanism of their own choosing, which must ensure that at least one-half of the sitting members agree with the decision. At least one-half of the sitting members of the confirming bodies must agree to either confirm or reject each individual nominee. The agreement must be decided within a reasonable timeframe. The agreement may be decided by conducting a formal vote, by asserting consensus based on informal exchanges (email), or by whatever mechanism is used to conduct the normal business of the confirming body. And here is what I propose: 4. The confirming bodies decide their consent according to a mechanism of their own choosing, which must ensure that at least one-half of the sitting members agree with the confirmation. At least one-half of the sitting members of the confirming bodies must agree to confirm each individual candidate. The agreement must be decided within a reasonable timeframe. Candidates that are not confirmed under this rule must be rejected and reported as such to the nominating committee. The agreement may be decided by conducting a formal vote, by asserting consensus based on informal exchanges (email), or by whatever mechanism is used to conduct the normal business of the confirming body. Jim From ietf-nomcom-errors@lists.elistx.com Thu May 15 11:35:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00B04PIORU@eListX.com> (original mail from rja@extremenetworks.com) ; Thu, 15 May 2003 11:25:36 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00B01PINRS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 11:25:35 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00B01PINRR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 11:25:35 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEX00A54PIMIA@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 15 May 2003 11:25:34 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 01C0F67107; Thu, 15 May 2003 11:50:48 -0400 (EDT) Date: Thu, 15 May 2003 11:25:01 -0400 From: RJ Atkinson Subject: Re: Question 1 about deadlock issue In-reply-to: To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <65441FA6-86E9-11D7-BB92-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thursday, May 15, 2003, at 11:08 America/Montreal, James M Galvin wrote: > And here is what I propose: > > 4. The confirming bodies decide their consent according to a > mechanism of their own choosing, which must ensure that at > least one-half of the sitting members agree with the > confirmation. > > At least one-half of the sitting members of the confirming > bodies must agree to confirm each individual candidate. The > agreement must be decided within a reasonable timeframe. > Candidates that are not confirmed under this rule must be > rejected and reported as such to the nominating committee. > > The agreement may be decided by conducting a formal vote, by > asserting consensus based on informal exchanges (email), or > by whatever mechanism is used to conduct the normal business > of the confirming body. I'm happy to accept this as a friendly amendment to (A). Are other folks who liked (A) comfortable with the above revision ? I would suggest the further amendment for clarity to change: > Candidates that are not confirmed under this rule must be > rejected and reported as such to the nominating committee. to instead read: Candidates that are not confirmed under this rule must be rejected. The resulting confirmation or rejection of each candidate must be reported to the IETF Nominating Committee. Is that amendment OK with folks ? Thanks very much, Ran rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Thu May 15 11:35:10 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00B04POPZD@eListX.com> (original mail from galvin+ietf-nomcom@eListX.com); Thu, 15 May 2003 11:29:13 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00B01POOZB@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 11:29:13 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00B01POOZ9@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 11:29:12 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEX00A64PONIA@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 15 May 2003 11:29:11 -0400 (EDT) Date: Thu, 15 May 2003 11:28:55 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Question 1 about deadlock issue In-reply-to: <65441FA6-86E9-11D7-BB92-00039357A82A@extremenetworks.com> To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <65441FA6-86E9-11D7-BB92-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thu, 15 May 2003, RJ Atkinson wrote: I would suggest the further amendment for clarity to change: > Candidates that are not confirmed under this rule must be > rejected and reported as such to the nominating committee. to instead read: Candidates that are not confirmed under this rule must be rejected. The resulting confirmation or rejection of each candidate must be reported to the IETF Nominating Committee. Is that amendment OK with folks ? Okay with me. Jim From ietf-nomcom-errors@lists.elistx.com Thu May 15 13:05:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00G04TZGKS@eListX.com> (original mail from randy@psg.com); Thu, 15 May 2003 13:02:04 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00G01TZGKN@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 13:02:04 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00G01TZFKL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 13:02:03 -0400 (EDT) Received: from psg.com (psg.com [147.28.0.62]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEX00BMYTZEH4@eListX.com>; Thu, 15 May 2003 13:02:03 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19GM6l-000LIh-00; Thu, 15 May 2003 17:01:31 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19GM6i-0001E7-Pi; Thu, 15 May 2003 19:01:28 +0200 Date: Thu, 15 May 2003 19:01:28 +0200 From: Randy Bush Subject: Re: Question 1 about deadlock issue To: RJ Atkinson Cc: Brian E Carpenter , James M Galvin , ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <3EC389B3.97D4A4AD@hursley.ibm.com> <7D46469B-86DA-11D7-A0F3-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > So the only check the IAB is really capable of performing is whether > the nominated person is a reasonable fit for the position specified. sounds good to me randy From ietf-nomcom-errors@lists.elistx.com Thu May 15 14:35:14 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00K04Y62FJ@eListX.com> (original mail from sob@newdev.harvard.edu) ; Thu, 15 May 2003 14:32:26 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00K01Y61FH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 14:32:25 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEX00K01Y61FG@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 15 May 2003 14:32:25 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEX00HFWY5R00@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 15 May 2003 14:32:24 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h4FIVhH3013926; Thu, 15 May 2003 14:31:43 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4FIVh2C013925; Thu, 15 May 2003 14:31:43 -0400 (EDT) Date: Thu, 15 May 2003 14:31:43 -0400 (EDT) From: Scott Bradner Subject: Re: Question 1 about deadlock issue In-reply-to: <65441FA6-86E9-11D7-BB92-00039357A82A@extremenetworks.com> To: galvin+ietf-nomcom@eListX.com, rja@extremenetworks.com Cc: ietf-nomcom@lists.elistx.com Message-id: <200305151831.h4FIVh2C013925@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > I'm happy to accept this as a friendly amendment to (A). > Are other folks who liked (A) comfortable with the above revision ? yes From ietf-nomcom-errors@lists.elistx.com Fri May 16 07:45:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEZ003049P1PN@eListX.com> (original mail from brian@hursley.ibm.com) ; Fri, 16 May 2003 07:39:01 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEZ003019OZPH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 07:39:00 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEZ003019OZPE@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 07:38:59 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEZ0024V9OVHW@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 16 May 2003 07:38:58 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4GBcLu9055880; Fri, 16 May 2003 13:38:22 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4GBcAaY153300; Fri, 16 May 2003 13:38:10 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60590 from ; Fri, 16 May 2003 13:38:08 +0200 Date: Fri, 16 May 2003 13:38:38 +0200 From: Brian E Carpenter Subject: Re: Question 1 about deadlock issue To: James M Galvin Cc: RJ Atkinson , ietf-nomcom@lists.elistx.com Message-id: <3EC4CDBE.E16CD75C@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: <65441FA6-86E9-11D7-BB92-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: James M Galvin wrote: > > On Thu, 15 May 2003, RJ Atkinson wrote: > > I would suggest the further amendment for clarity to change: > > > Candidates that are not confirmed under this rule must be > > rejected and reported as such to the nominating committee. > > to instead read: > > Candidates that are not confirmed under this > rule must be rejected. The resulting > confirmation or rejection of each candidate must > be reported to the IETF Nominating Committee. > > Is that amendment OK with folks ? > > Okay with me. > > Jim Yes to both Brian From ietf-nomcom-errors@lists.elistx.com Fri May 16 15:25:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEZ00K04UW67H@eListX.com> (original mail from rja@extremenetworks.com) ; Fri, 16 May 2003 15:16:54 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEZ00K01UW57F@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 15:16:53 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEZ00K01UW47E@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 15:16:52 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEZ00HBFUW4O2@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 16 May 2003 15:16:52 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 866C767107 for ; Fri, 16 May 2003 15:42:22 -0400 (EDT) Date: Fri, 16 May 2003 15:16:21 -0400 From: RJ Atkinson Subject: Option (A1) description In-reply-to: <65441FA6-86E9-11D7-BB92-00039357A82A@extremenetworks.com> To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII; delsp=yes Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: This note serves merely to publish the revised Option (A) in toto for the list to read if folks wish. For clarity, I'll call this Option (A1) going forward. Ran rja@extremenetworks.com ------------------------------------------------------------------------ ------- Option A1: Delete existing Section 4 text regarding how Confirming Bodies perform their confirming and replace with this text: 4. The confirming bodies decide their consent according to a mechanism of their own choosing, which must ensure that at least one-half of the sitting members agree with the confirmation. At least one-half of the sitting members of the confirming bodies must agree to confirm each individual candidate. The agreement must be decided within a reasonable timeframe. Candidates that are not confirmed under this rule must be rejected and reported as such to the nominating committee. The agreement may be decided by conducting a formal vote, by asserting consensus based on informal exchanges (email), or by whatever mechanism is used to conduct the normal business of the confirming body. Candidates that are not confirmed under this rule must be rejected. The resulting confirmation or rejection of each candidate must be reported to the IETF Nominating Committee. ------------------------------------------------------------------------ -------- From ietf-nomcom-errors@lists.elistx.com Fri May 16 15:35:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEZ00K04VHTOO@eListX.com> (original mail from rja@extremenetworks.com) ; Fri, 16 May 2003 15:29:53 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEZ00K01VHSOM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 15:29:52 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HEZ00K01VHSOL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 15:29:52 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEZ00HEYVHRO2@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 16 May 2003 15:29:51 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 0F64B67107; Fri, 16 May 2003 15:55:22 -0400 (EDT) Date: Fri, 16 May 2003 15:29:20 -0400 From: RJ Atkinson Subject: Re: Option (A1) description In-reply-to: To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Someone just pointed out privately that the text below is ambiguous in a couple of places. I'll try to work with Jim and others to come up with agreeable text to clarify this, which will probably become option (A2). Sorry, Ran On Friday, May 16, 2003, at 15:16 America/Montreal, RJ Atkinson wrote: > > This note serves merely to publish the revised Option (A) in toto > for the list to read if folks wish. For clarity, I'll call this > Option (A1) going forward. > > Ran > rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Fri May 16 18:35:17 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF0004043UJQF@eListX.com> (original mail from harald@alvestrand.no); Fri, 16 May 2003 18:30:20 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF0004013UIQ3@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 18:30:18 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF0004013UHPZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 18:30:17 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HF00040J3UGLS@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 16 May 2003 18:30:17 -0400 (EDT) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DEBAE6257C; Sat, 17 May 2003 00:29:43 +0200 (CEST) Date: Fri, 16 May 2003 20:56:52 +0200 From: Harald Tveit Alvestrand Subject: Re: Question 1 about deadlock issue In-reply-to: To: James M Galvin , Brian E Carpenter Cc: ietf-nomcom@lists.elistx.com Message-id: <14518005.1053118612@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.0.2 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <731CB764-856E-11D7-B680-00039357A82A@extremenetworks.com> <3EC190BF.8060300@acm.org> <3EC389B3.97D4A4AD@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On 15. mai 2003 09:37 -0400 James M Galvin wrote: > The problem with the default being reject is it sets aside 2 months of > hard work of the NOMCOM for 2 weeks of the CB being unable to agree. > > I'm okay with the CB rejecting a candidate I just want them to actually > do it. I am not okay with the CB having the option to step aside and > leave the NOMCOM wondering what happened and what to do next. would you be happy if the "defaulting" rule required the CB to hold an explicit vote before the end of the timeout? I read option A's "otherwise it is rejected" as describing the case in which there was no majority, not as describing a case where no vote was taken. Harald From ietf-nomcom-errors@lists.elistx.com Fri May 16 18:35:21 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF0004043UMQQ@eListX.com> (original mail from harald@alvestrand.no); Fri, 16 May 2003 18:30:22 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF0004013UKQG@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 18:30:20 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF0004013UJQ6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 18:30:19 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HF0004133UILG@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 16 May 2003 18:30:18 -0400 (EDT) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 294896256B; Sat, 17 May 2003 00:29:46 +0200 (CEST) Date: Fri, 16 May 2003 21:13:11 +0200 From: Harald Tveit Alvestrand Subject: Re: Question 2 In-reply-to: <65441FA6-86E9-11D7-BB92-00039357A82A@extremenetworks.com> To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: <15497364.1053119591@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.0.2 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <65441FA6-86E9-11D7-BB92-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Short version of this message, from Ran's summary: - StJohns' proposal to delete current text, add (A) but with his editorial change to (A) that it applies if and only if the confirming body has not created a specific confirmation process for itself to use with nominees from IETF Nomcom. I started editing this message below before reading Ran's latest summary, so it looks a bit out-of-context. There's some specific suggestion for text in here, so I'll send the extended version. Take it as a friendly amendment to StJohns' - a proposal for the editorial change. Harald --On 15. mai 2003 11:25 -0400 RJ Atkinson wrote: > On Thursday, May 15, 2003, at 11:08 America/Montreal, James M Galvin > wrote: >> And here is what I propose: >> >> 4. The confirming bodies decide their consent according to a >> mechanism of their own choosing, which must ensure that at >> least one-half of the sitting members agree with the >> confirmation. >> >> At least one-half of the sitting members of the confirming >> bodies must agree to confirm each individual candidate. The >> agreement must be decided within a reasonable timeframe. >> Candidates that are not confirmed under this rule must be >> rejected and reported as such to the nominating committee. >> >> The agreement may be decided by conducting a formal vote, by >> asserting consensus based on informal exchanges (email), or >> by whatever mechanism is used to conduct the normal business >> of the confirming body. > > I'm happy to accept this as a friendly amendment to (A). > Are other folks who liked (A) comfortable with the above revision ? As an alternate text to (A), I am happy with this. As a final text, I am not; since I am happy with text that defaults the CB decision rule but not with text that dictates the CB decision rule, I believe the first sentence should read: 4. The confirming bodies decide their consent according to a mechanism of their own choosing, which produces an explicit decision within the timeframe required by the nomcom process. If the confirming bodies have no such specific rule, the followin rule is expected to be followed: Note: When it comes up in the IAB, as I'm sure it will, I intend to argue in that forum that the IAB should have a rule that says that a majority of the qualified IAB members must confirm a candidate, but that the IESG chair and any IAB member who is proposed for the IESG is disqualified, and that any IAB member who sees a serious conflict of interest may choose to disqualify him/herself. I think this level of detail and interaction with the internal processes of the IAB is inappropriate for nomcom - but the discussion has shown that it needs to be decided. In an extreme case, this could mean that the IESG slate is approved by a single person. And I think that should be allowed to happen if it needs to. Harald From ietf-nomcom-errors@lists.elistx.com Fri May 16 20:15:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF0007048CNE7@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Fri, 16 May 2003 20:07:35 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF0007018CME5@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 20:07:35 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF0007018CME3@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 16 May 2003 20:07:34 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HF0004498CKLS@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 16 May 2003 20:07:34 -0400 (EDT) Date: Fri, 16 May 2003 20:07:15 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Question 1 about deadlock issue In-reply-to: <14518005.1053118612@localhost> To: Harald Tveit Alvestrand Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <731CB764-856E-11D7-B680-00039357A82A@extremenetworks.com> <3EC190BF.8060300@acm.org> <3EC389B3.97D4A4AD@hursley.ibm.com> <14518005.1053118612@localhost> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Fri, 16 May 2003, Harald Tveit Alvestrand wrote: --On 15. mai 2003 09:37 -0400 James M Galvin wrote: > I'm okay with the CB rejecting a candidate I just want them to actually > do it. I am not okay with the CB having the option to step aside and > leave the NOMCOM wondering what happened and what to do next. would you be happy if the "defaulting" rule required the CB to hold an explicit vote before the end of the timeout? Yes, although I like the text from your followup even better, i.e., the NOMCOM should not even say it is one-half, just that a decision must be made. Ran? Jim From ietf-nomcom-errors@lists.elistx.com Sat May 17 10:55:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF100004D0OO0@eListX.com> (original mail from rja@extremenetworks.com) ; Sat, 17 May 2003 10:46:00 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF100001D0NNY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 17 May 2003 10:46:00 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF100001D0NNX@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 17 May 2003 10:45:59 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HF10001MD0MDQ@eListX.com> for ietf-nomcom@lists.elistx.com; Sat, 17 May 2003 10:45:58 -0400 (EDT) Received: from extremenetworks.com (unknown [10.0.8.68]) by gnat.inet.org (Postfix) with ESMTP id 6F0376710F; Sat, 17 May 2003 11:11:31 -0400 (EDT) Date: Sat, 17 May 2003 10:45:20 -0400 From: RJ Atkinson Subject: Re: Question 1 about deadlock issue In-reply-to: To: James M Galvin Cc: Harald Tveit Alvestrand , ietf-nomcom@lists.elistx.com Message-id: <2EDE665E-8876-11D7-9C2C-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Friday, May 16, 2003, at 20:07 America/Montreal, James M Galvin wrote: > Ran? For the moment, I'm mainly trying to collect various options for replacement text (including the "no replacement text" option). I'm not sure what precise new text is being proposed, maybe someone can clarify the entire precise new text. By the way, I think we're up to (H) as the next unused option letter (with some of the previous options being not interesting to anyone as near as I can tell). Ran From ietf-nomcom-errors@lists.elistx.com Mon May 19 14:05:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF500G04BAY16@eListX.com> (original mail from rja@extremenetworks.com) ; Mon, 19 May 2003 13:59:22 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF500G01BAX14@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 19 May 2003 13:59:22 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF500G01BAX13@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 19 May 2003 13:59:21 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HF500F3LBAW44@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 19 May 2003 13:59:21 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id A74E867104 for ; Mon, 19 May 2003 14:25:19 -0400 (EDT) Date: Mon, 19 May 2003 13:58:49 -0400 From: RJ Atkinson Subject: Alternative (G) To: ietf-nomcom@lists.elistx.com Message-id: <8B2F96C0-8A23-11D7-A917-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Alternative (G) comes from Christian Huitema. It replaces alternatives (E) and (F) that earlier came from him. I hope to post Alternative (A2) tomorrow. My own understanding from reading the words below is that the phrase "appropriate majority" leaves it to the confirming body to determine precisely how much of a majority is required to confirm, but that at least a majority (i.e. half of the confirming body plus one) would be required. If that is an incorrect understanding, I'm hoping Christian will correct this note with the correct explanation of the intent. Cheers, Ran rja@extremenetworks.com ---------------------------------------------------------------------- Delete the existing text in 4. and replace with: "4. The confirming bodies decide their consent according to a mechanism of their own choosing. The agreement may be decided by conducting a formal vote, by asserting consensus based on informal exchanges (e.g. email), or by whatever mechanism is used to conduct the normal business of the confirming body. If the appropriate majority of the sitting members of the confirming body agree to confirm a given candidate, then the candidate is confirmed. Candidates that are not confirmed under this rule MUST be rejected. The confirming body MUST make its decision within a reasonable timeframe. The results from the confirming body must be reported promptly to the IETF Nominating Committee." ----------------------------------------------------------------------- From ietf-nomcom-errors@lists.elistx.com Wed May 21 12:25:14 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF800604W9AST@eListX.com> (original mail from rja@extremenetworks.com) ; Wed, 21 May 2003 12:24:46 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF800601W99SR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 21 May 2003 12:24:45 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF800601W98SQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 21 May 2003 12:24:44 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HF8002KOW98B3@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 21 May 2003 12:24:44 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 7A7BC67115 for ; Wed, 21 May 2003 12:50:59 -0400 (EDT) Date: Wed, 21 May 2003 12:24:05 -0400 From: RJ Atkinson Subject: Alternative (A2) To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII; delsp=yes Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Here is alternative (A2) which benefited from edits from several folks, including Jim Galvin and Brian Carpenter. -------------------------------------------------------------------- Delete the existing text in section 4, and replace with this: 4. The confirming bodies decide their consent according to a mechanism of their own choosing, which must ensure that at least one-half of the confirming body's sitting members agree to each candidate's confirmation, failing which the candidate is considered to be rejected. The agreement may be decided by conducting a formal vote, by asserting consensus based on informal exchanges (e.g. email), or by whatever mechanism is used to conduct the normal business of the confirming body. The confirming body must make its decision within a reasonable timeframe. The results from the confirming body must be reported promptly to the nominating committee. ------------------------------------------------------------------------ - From ietf-nomcom-errors@lists.elistx.com Wed May 21 12:35:12 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF800704WPRIX@eListX.com> (original mail from rja@extremenetworks.com) ; Wed, 21 May 2003 12:34:40 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF800701WPQIS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 21 May 2003 12:34:38 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF800701WPQIQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 21 May 2003 12:34:38 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HF8002OKWPKB3@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 21 May 2003 12:34:37 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 5FC0467115 for ; Wed, 21 May 2003 13:00:43 -0400 (EDT) Date: Wed, 21 May 2003 12:33:48 -0400 From: RJ Atkinson Subject: Revised Question 2 To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: At the bottom of this note, I've attempted to list all of the proposed fixes for the deadlock issue in Section 4 that are still being actively proposed. It is likely that I've made a mistake along the way, so this note just attempts to verify that I have the correct list of currently proposed fixes. If your preferred fix is not listed below, please post a note to the list outlining your proposed fix. If your proposal involves replacing the Section 4 text, please include the precise proposed new text for Section 4. Thanks, Ran rja@extremenetworks.com ------------------------------------------------------------- Alternatives still being considered: (NUL) delete the current Section 4 text and have the document be entirely silent about how the confirming bodies confirm/reject nominees. (A2) posted to the list on 21 May 2003, joint from several folks (G) posted to the list on 19 May 2003, from Christian Huitema (H) from Harald Alvestrand's note of 16 May 2003; I do not know what Harald's proposed new wording is. --------------------------------------------------------------- From ietf-nomcom-errors@lists.elistx.com Wed May 21 13:25:03 2003 Return-Path: Return-path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF800A04YRGWH@eListX.com> (original mail from huitema@windows.microsoft.com); Wed, 21 May 2003 13:18:52 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF800A01YRGWF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 21 May 2003 13:18:52 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF800A01YRFWE@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 21 May 2003 13:18:51 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HF8007CUYREPA@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 21 May 2003 13:18:51 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 21 May 2003 10:18:08 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 May 2003 10:18:01 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 21 May 2003 10:17:57 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 May 2003 10:17:56 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Wed, 21 May 2003 10:17:56 -0700 Date: Wed, 21 May 2003 10:17:55 -0700 From: Christian Huitema Subject: RE: Revised Question 2 To: RJ Atkinson , ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Revised Question 2 Thread-Index: AcMfu3qSPDUf5Ge2RiGskIsS1+W83QAAGtOQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 21 May 2003 17:17:56.0093 (UTC) FILETIME=[EB71EAD0:01C31FBC] Let's point out that the only difference between A2 and G is that A2 specifies that the CB procedure must "ensure that at least one-half o= f the confirming body's sitting members agree to each candidate's confirmation." It turns out that is NOT the modus operandi of the ISO= C Board of trustees. Decisions in a face to face meeting of the Board o= f Trustees are according to the following rule: 1) A certain proportion of the trustees must be present (quorum), and= , 2) A majority of those who are present must approve the decision. This is specified as a simple majority in section 10 of the by-laws: = "At all meetings of the Board, a majority of the voting members of the Bo= ard of Trustees then in office shall constitute a quorum for the transact= ion of business and the act of the majority of the Trustees present at an= y meeting at which a quorum is present shall be the act of the Board."= =20 This is a serious difference in practice, and a reason for not includ= ing the "majority of sitting members" text proposed in A2. -- Christian Huitema > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Wednesday, May 21, 2003 9:34 AM > To: ietf-nomcom@lists.elistx.com > Subject: Revised Question 2 >=20 >=20 > =09At the bottom of this note, I've attempted to list all of > the proposed fixes for the deadlock issue in Section 4 that > are still being actively proposed. It is likely that I've made > a mistake along the way, so this note just attempts to verify > that I have the correct list of currently proposed fixes. >=20 > =09If your preferred fix is not listed below, please post > a note to the list outlining your proposed fix. If your > proposal involves replacing the Section 4 text, please > include the precise proposed new text for Section 4. >=20 > Thanks, >=20 > Ran > rja@extremenetworks.com >=20 > ------------------------------------------------------------- > Alternatives still being considered: >=20 > (NUL) delete the current Section 4 text and have the document > =09be entirely silent about how the confirming bodies confirm/reject > =09nominees. > (A2) posted to the list on 21 May 2003, joint from several folks > (G) posted to the list on 19 May 2003, from Christian Huitema > (H) from Harald Alvestrand's note of 16 May 2003; > =09I do not know what Harald's proposed new wording is. > --------------------------------------------------------------- >=20 >=20 > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: From ietf-nomcom-errors@lists.elistx.com Wed May 21 14:05:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF900D040P2GE@eListX.com> (original mail from rja@extremenetworks.com) ; Wed, 21 May 2003 14:00:38 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF900D010P1GC@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 21 May 2003 14:00:38 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HF900D010P1GB@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 21 May 2003 14:00:37 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HF9007OA0P0PA@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 21 May 2003 14:00:36 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 979CB67115; Wed, 21 May 2003 14:26:54 -0400 (EDT) Date: Wed, 21 May 2003 14:00:00 -0400 From: RJ Atkinson Subject: Re: Revised Question 2 In-reply-to: To: Christian Huitema Cc: ietf-nomcom@lists.elistx.com Message-id: <0A1FA18B-8BB6-11D7-95F7-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Wednesday, May 21, 2003, at 13:17 America/Montreal, Christian Huitema wrote: > Let's point out that the only difference between A2 and G is that A2 > specifies that the CB procedure must "ensure that at least one-half of > the confirming body's sitting members agree to each candidate's > confirmation." Alternative (G) requires that more than half must agree, whereas (A2) says "at least one-half". (Please see the phrase "appropriate majority" in that text. "Majority" means at least (more than half). "Simple Majority" has a slightly different definition than "Majority", of course.) > It turns out that is NOT the modus operandi of the ISOC > Board of trustees. Decisions in a face to face meeting of the Board of > Trustees are according to the following rule: > > 1) A certain proportion of the trustees must be present (quorum), and, > 2) A majority of those who are present must approve the decision. > > This is specified as a simple majority in section 10 of the by-laws: > "At > all meetings of the Board, a majority of the voting members of the > Board > of Trustees then in office shall constitute a quorum for the > transaction > of business and the act of the majority of the Trustees present at any > meeting at which a quorum is present shall be the act of the Board." > > This is a serious difference in practice, and a reason for not > including > the "majority of sitting members" text proposed in A2. A2 does not contain the phrase "majority of sitting members". A2 does say "at least half of ... sitting members", which is perhaps what you are intending to comment on. Both A2 and G say that the CB decide their consent according to a mechanism of their own choosing, which provides manuevering room for the CB to have their own rules (example: ISoc BoT's Quorum rule) in addition to what is specified in the RFC. So adopting A2 would not preclude the existing ISoc BoT rules. Adopting A2 would have the effect of additionally requiring that at least half of the sitting members on the ISoc BoT approve IETF-related confirmations. Reasonable people might reach different conclusions on whether that effect is desirable. Reasonable people might also differ on whether one wants a majority to be required for confirmation or whether one wants "at least half" to be required for confirmation. Certainly it is helpful to highlight the differences and discuss them here on the list. Thanks for your note. Thanks very much, Ran rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Thu May 22 09:55:11 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00904JNXXR@eListX.com> (original mail from harald@alvestrand.no); Thu, 22 May 2003 09:47:57 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00901JNWXP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 09:47:56 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00901JNVXO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 09:47:55 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA007ANJNULA@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 09:47:55 -0400 (EDT) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C8058625D9; Thu, 22 May 2003 15:47:15 +0200 (CEST) Date: Thu, 22 May 2003 15:00:28 +0200 From: Harald Tveit Alvestrand Subject: Alternative (H) In-reply-to: To: RJ Atkinson , ietf-nomcom@lists.elistx.com Message-id: <511525194.1053615628@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.0.2 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Since Ran wants specific words, here is alternative (H), written as a minor change to (A2). -------------------------------------------------------------------- Delete the existing text in section 4, and replace with this: 4. The confirming bodies decide their consent according to a rule of their own choosing. If the confirming bodies have no such specific rule, the confirming bodies can decide their consent by ensuring that at least one-half of the confirming body's sitting members agree to each candidate's confirmation, failing which the candidate is considered to be rejected. The agreement may be decided by conducting a formal vote, by asserting consensus based on informal exchanges (e.g. email), or by whatever mechanism is used to conduct the normal business of the confirming body. The confirming body must make its decision within a reasonable timeframe. The results from the confirming body must be reported promptly to the nominating committee. ------------------------------------------------------------------------ - From ietf-nomcom-errors@lists.elistx.com Thu May 22 10:25:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00B04L71NJ@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Thu, 22 May 2003 10:21:01 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00B01L70NH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 10:21:00 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00B01L6ZNF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 10:20:59 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA007IOL6YLA@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 10:20:59 -0400 (EDT) Date: Thu, 22 May 2003 10:20:39 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Alternative (H) In-reply-to: <511525194.1053615628@localhost> To: Harald Tveit Alvestrand Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <511525194.1053615628@localhost> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I would make your first paragraph "singular" and change "can" to a "should," but otherwise I prefer this text to A2. Jim On Thu, 22 May 2003, Harald Tveit Alvestrand wrote: Delete the existing text in section 4, and replace with this: 4. The confirming bodies decide their consent according to a rule of their own choosing. CHANGE THIS: If the confirming bodies have no such specific rule, the confirming bodies can decide their consent by ensuring that at least one-half of the confirming body's sitting members agree to each candidate's confirmation, failing which the candidate is considered to be rejected. TO: If a confirming body has no such specific rule, it should decide its consent by ensuring that at least one-half of its sitting members agree to each candidate's confirmation, failing which the candidate is considered to be rejected. The agreement may be decided by conducting a formal vote, by asserting consensus based on informal exchanges (e.g. email), or by whatever mechanism is used to conduct the normal business of the confirming body. The confirming body must make its decision within a reasonable timeframe. The results from the confirming body must be reported promptly to the nominating committee. From ietf-nomcom-errors@lists.elistx.com Thu May 22 11:15:26 2003 Return-Path: Return-path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00D04NMLO8@eListX.com> (original mail from huitema@windows.microsoft.com); Thu, 22 May 2003 11:13:33 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00D01NMKO4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 11:13:32 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00D01NMKO2@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 11:13:32 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA007K8NMJLC@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 11:13:31 -0400 (EDT) Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 22 May 2003 08:13:31 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 22 May 2003 08:13:30 -0700 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 May 2003 08:13:30 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0) ; Thu, 22 May 2003 08:12:55 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 May 2003 08:12:54 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 22 May 2003 08:12:53 -0700 Date: Thu, 22 May 2003 08:12:52 -0700 From: Christian Huitema Subject: RE: Alternative (H) To: James M Galvin , Harald Tveit Alvestrand Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Alternative (H) Thread-Index: AcMgbVkpKR1OhrOGSwatKQbyUlvoFgABs1EQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 22 May 2003 15:12:53.0909 (UTC) FILETIME=[9E353C50:01C32074] This text has the advantage of not conflicting with ISOC's by-laws, which is good. However, the algorithm as presented does not completel= y resolve the deadlock problem. As proposed, the phrase "failing which = the candidate is considered to be rejected" seem to only apply to the cas= e where the CB has no defined decision rule and resorts to majority voting. > I would make your first paragraph "singular" and change "can" to a > "should," but otherwise I prefer this text to A2. >=20 > Jim >=20 >=20 >=20 > On Thu, 22 May 2003, Harald Tveit Alvestrand wrote: >=20 > Delete the existing text in section 4, and replace with this: >=20 > 4. The confirming bodies decide their consent according to= a rule > of their own choosing. >=20 > CHANGE THIS: >=20 > If the confirming bodies have no such specific rule, the confirming > bodies can decide their consent by ensuring that at least > one-half of the confirming body's sitting members agree to each > candidate's confirmation, failing which the candidate is > considered to be rejected. >=20 > TO: >=20 > If a confirming body has no such specific rule, it should > decide its consent by ensuring that at least one-half of its > sitting members agree to each candidate's confirmation, > failing which the candidate is considered to be rejected. >=20 > The agreement may be decided by conducting a formal vot= e, by > asserting consensus based on informal exchanges (e.g. email), > or > by whatever mechanism is used to conduct the normal business > of > the confirming body. >=20 > The confirming body must make its decision within a reasonable > timeframe. The results from the confirming body must b= e > reported > promptly to the nominating committee. >=20 > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: From ietf-nomcom-errors@lists.elistx.com Thu May 22 12:05:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00F04PQ9RM@eListX.com> (original mail from rja@extremenetworks.com) ; Thu, 22 May 2003 11:58:57 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00F01PQ8RJ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 11:58:56 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00F01PQ8RI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 11:58:56 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA00CBJPQ2WK@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 11:58:55 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 79B8D67103; Thu, 22 May 2003 12:25:15 -0400 (EDT) Date: Thu, 22 May 2003 11:58:10 -0400 From: RJ Atkinson Subject: Re: Alternative (H) In-reply-to: To: Christian Huitema Cc: ietf-nomcom@lists.elistx.com Message-id: <2FE8AE45-8C6E-11D7-B201-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thursday, May 22, 2003, at 11:12 America/Montreal, Christian Huitema wrote: > This text has the advantage of not conflicting with ISOC's by-laws, > which is good. However, the algorithm as presented does not completely > resolve the deadlock problem. As proposed, the phrase "failing which > the > candidate is considered to be rejected" seem to only apply to the case > where the CB has no defined decision rule and resorts to majority > voting. In which way does (H) not solve the deadlock problem ? Do mean that (H) does not solve the deadlock problem in the case that the CB has a voting process that can deadlock ? Or do you mean something else ? Thanks, Ran From ietf-nomcom-errors@lists.elistx.com Thu May 22 12:05:15 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00F04PRBUH@eListX.com> (original mail from rja@extremenetworks.com) ; Thu, 22 May 2003 11:59:35 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00F01PRAU9@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 11:59:35 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00F01PRAU5@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 11:59:34 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA00E4RPR8SI@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 11:59:33 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id AEEA867103; Thu, 22 May 2003 12:26:01 -0400 (EDT) Date: Thu, 22 May 2003 11:58:57 -0400 From: RJ Atkinson Subject: Re: Alternative (H) In-reply-to: To: James M Galvin Cc: Harald Tveit Alvestrand , ietf-nomcom@lists.elistx.com Message-id: <4B706ACA-8C6E-11D7-B201-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Harald, Is Jim's proposed edit (see below) acceptable to you ? Thanks, Ran On Thursday, May 22, 2003, at 10:20 America/Montreal, James M Galvin wrote: > I would make your first paragraph "singular" and change "can" to a > "should," but otherwise I prefer this text to A2. > > Jim > > > > On Thu, 22 May 2003, Harald Tveit Alvestrand wrote: > > Delete the existing text in section 4, and replace with this: > > 4. The confirming bodies decide their consent according to a > rule > of their own choosing. > > CHANGE THIS: > > If the confirming bodies have no such specific rule, the confirming > bodies can decide their consent by ensuring that at least > one-half of the confirming body's sitting members agree to each > candidate's confirmation, failing which the candidate is > considered to be rejected. > > TO: > > If a confirming body has no such specific rule, it should > decide its consent by ensuring that at least one-half of its > sitting members agree to each candidate's confirmation, > failing which the candidate is considered to be rejected. > > The agreement may be decided by conducting a formal vote, > by > asserting consensus based on informal exchanges (e.g. > email), or > by whatever mechanism is used to conduct the normal > business of > the confirming body. > > The confirming body must make its decision within a > reasonable > timeframe. The results from the confirming body must be > reported > promptly to the nominating committee. > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: > From ietf-nomcom-errors@lists.elistx.com Thu May 22 12:05:17 2003 Return-Path: Return-path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00G04PZH6X@eListX.com> (original mail from huitema@windows.microsoft.com); Thu, 22 May 2003 12:04:30 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00G01PZH6V@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 12:04:29 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00G01PZG6U@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 12:04:28 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA00CCOPZFWK@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 12:04:28 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 22 May 2003 09:04:27 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 May 2003 09:03:52 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0) ; Thu, 22 May 2003 09:03:52 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 May 2003 09:03:49 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 22 May 2003 09:03:51 -0700 Date: Thu, 22 May 2003 09:03:50 -0700 From: Christian Huitema Subject: RE: Alternative (H) To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Alternative (H) Thread-Index: AcMgevYqcZnM/h6ZQTObFjV6lKoF7QAACGaA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 22 May 2003 16:03:51.0532 (UTC) FILETIME=[BCB17AC0:01C3207B] > > This text has the advantage of not conflicting with ISOC's by-law= s, > > which is good. However, the algorithm as presented does not completely > > resolve the deadlock problem. As proposed, the phrase "failing wh= ich > > the > > candidate is considered to be rejected" seem to only apply to the case > > where the CB has no defined decision rule and resorts to majority > > voting. >=20 > In which way does (H) not solve the deadlock problem ? >=20 > Do mean that (H) does not solve the deadlock problem in the > case that the CB has a voting process that can deadlock ? Yes. I would propose the following friendly amendment to (H): Delete the existing text in section 4, and replace with this: 4. The confirming bodies decide their consent according to a rule of their own choosing. CHANGE THIS: If the confirming bodies have no such specific rule, the confirmi= ng bodies can decide their consent by ensuring that at least one-half of the confirming body's sitting members agree to each candidate's confirmation, failing which the candidate is considered to be rejected. TO: If a confirming body has no such specific rule, it should decide its consent by ensuring that at least one-half of its sitting members agree to each candidate's confirmation. (Remove: failing which the candidate is considered to be rejected= .) The agreement may be decided by conducting a formal vote, by asserting consensus based on informal exchanges (e.g. email)= , or by whatever mechanism is used to conduct the normal business= of the confirming body. The confirming body must make its decision within a reasonab= le timeframe. The results from the confirming body must be reported promptly to the nominating committee. (Add:) A candidate tha= t is not confirmed should be considered rejected. From ietf-nomcom-errors@lists.elistx.com Thu May 22 12:15:27 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00G04Q8KM7@eListX.com> (original mail from rja@extremenetworks.com) ; Thu, 22 May 2003 12:09:56 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00G01Q8JM4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 12:09:55 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00G01Q8JM3@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 12:09:55 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA00CE7Q8IWK@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 12:09:54 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 905DD67103; Thu, 22 May 2003 12:36:23 -0400 (EDT) Date: Thu, 22 May 2003 12:09:18 -0400 From: RJ Atkinson Subject: Re: Alternative (H) In-reply-to: To: Christian Huitema Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thursday, May 22, 2003, at 12:03 America/Montreal, Christian Huitema wrote: > Yes. I would propose the following friendly amendment to (H): > > Delete the existing text in section 4, and replace with this: > > 4. The confirming bodies decide their consent according to a > rule > of their own choosing. > > CHANGE THIS: > > If the confirming bodies have no such specific rule, the confirming > bodies can decide their consent by ensuring that at least > one-half of the confirming body's sitting members agree to each > candidate's confirmation, failing which the candidate is > considered to be rejected. > > TO: > > If a confirming body has no such specific rule, it should > decide its consent by ensuring that at least one-half of its > sitting members agree to each candidate's confirmation. > (Remove: failing which the candidate is considered to be rejected.) This is confusing to me. I'm unable to identify the change in meaning resulting from the proposed edit, so I must be missing a big clue or two. Please help me understand. Thanks, Ran > The agreement may be decided by conducting a formal vote, by > asserting consensus based on informal exchanges (e.g. email), > or > by whatever mechanism is used to conduct the normal business > of > the confirming body. > > The confirming body must make its decision within a reasonable > timeframe. The results from the confirming body must be > reported > promptly to the nominating committee. (Add:) A candidate that > is > not confirmed should be considered rejected. > From ietf-nomcom-errors@lists.elistx.com Thu May 22 12:35:17 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00H04R3BKF@eListX.com> (original mail from mstjohns@mindspring.com) ; Thu, 22 May 2003 12:28:23 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00H01R37JO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 12:28:22 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00H01R36JL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 12:28:19 -0400 (EDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA00ECJR35SI@eListX.com>; Thu, 22 May 2003 12:28:18 -0400 (EDT) Received: from pcp802197pcs.nrockv01.md.comcast.net ([68.48.86.43] helo=STJOHNS-LAPTOP2.mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 19Isus-0004Lv-00; Thu, 22 May 2003 09:27:42 -0700 Date: Thu, 22 May 2003 12:27:41 -0400 From: Michael StJohns Subject: Current version? In-reply-to: X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <5.2.1.1.2.20030522120526.03077100@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: multipart/alternative; boundary="Boundary_(ID_8LE+h/p3usOf6TK46u2qUQ)" X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d989016df8860d59a96186d7a07946da6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <511525194.1053615628@localhost> <511525194.1053615628@localhost> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --Boundary_(ID_8LE+h/p3usOf6TK46u2qUQ) Content-type: text/plain; format=flowed; charset=us-ascii Jim - The May 8th version of this didn't address the comments and discussion about >The confirming bodies review their respective candidates and, > in consultation with the nominating committee, consent to > some, all, or none of the candidates. The CBs have their own roles and MUST NOT be overly influenced by the Nomcom. So "in consultation with" needs to go. Brian proposed some alternate text which I can live with: > If not all the candidates submitted to a confirming body are > rapidly confirmed, the confirming body continues to communicate > with the nominating committee both to understand the committee's > rationale for the slate and, if appropriate, to explain the reason > why all the candidates were not confirmed. > > 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. --Boundary_(ID_8LE+h/p3usOf6TK46u2qUQ) Content-type: text/html; charset=us-ascii Jim -

The May 8th version of this didn't address the comments and discussion about 


The confirming bodies review
their respective candidates and,
           in
consultation with the nominating committee, consent to
           some, all,
or none of the
candidates.


The CBs have their own roles and MUST NOT be overly influenced by the Nomcom.  So "in consultation with" needs to go.

Brian proposed some alternate text which I can live with:

  If not all the candidates submitted to a confirming body are
  rapidly confirmed, the confirming body continues to communicate
  with the nominating committee both to understand the committee's
  rationale for the slate and, if appropriate, to explain the reason
  why all the candidates were not confirmed. 

  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.

--Boundary_(ID_8LE+h/p3usOf6TK46u2qUQ)-- From ietf-nomcom-errors@lists.elistx.com Thu May 22 12:35:32 2003 Return-Path: Return-path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00H04RACRF@eListX.com> (original mail from huitema@windows.microsoft.com); Thu, 22 May 2003 12:32:36 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00H01RACRD@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 12:32:36 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00H01RABRC@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 12:32:35 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA00EETRAASI@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 12:32:35 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 22 May 2003 09:32:34 -0700 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 May 2003 09:31:59 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0) ; Thu, 22 May 2003 09:31:59 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 May 2003 09:31:58 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 22 May 2003 09:31:58 -0700 Date: Thu, 22 May 2003 09:31:57 -0700 From: Christian Huitema Subject: RE: Alternative (H) To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Alternative (H) Thread-Index: AcMgfIqOoRuwx+t4TLiuHPXohPyQawAAvSkQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 22 May 2003 16:31:58.0534 (UTC) FILETIME=[AA398E60:01C3207F] I just want to tweak the text to make sure that, whatever the decisio= n process of the CB, lack of timely decision is equivalent to rejection= .=20 We probably also need to define "timely". > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Thursday, May 22, 2003 9:09 AM > To: Christian Huitema > Cc: ietf-nomcom@lists.elistx.com > Subject: Re: Alternative (H) >=20 >=20 > On Thursday, May 22, 2003, at 12:03 America/Montreal, Christian Huitema > wrote: > > Yes. I would propose the following friendly amendment to (H): > > > > Delete the existing text in section 4, and replace with this: > > > > 4. The confirming bodies decide their consent according = to a > > rule > > of their own choosing. > > > > CHANGE THIS: > > > > If the confirming bodies have no such specific rule, the confirming > > bodies can decide their consent by ensuring that at least > > one-half of the confirming body's sitting members agree to ea= ch > > candidate's confirmation, failing which the candidate is > > considered to be rejected. > > > > TO: > > > > If a confirming body has no such specific rule, it should > > decide its consent by ensuring that at least one-half of its > > sitting members agree to each candidate's confirmation. > > (Remove: failing which the candidate is considered to be rejected.) >=20 > =09This is confusing to me. I'm unable to identify the change > in meaning resulting from the proposed edit, so I must be missing > a big clue or two. >=20 > =09Please help me understand. >=20 > Thanks, >=20 > Ran >=20 > > The agreement may be decided by conducting a formal vote= , by > > asserting consensus based on informal exchanges (e.g. email), > > or > > by whatever mechanism is used to conduct the normal business > > of > > the confirming body. > > > > The confirming body must make its decision within a reasonable > > timeframe. The results from the confirming body must be > > reported > > promptly to the nominating committee. (Add:) A candidate that > > is > > not confirmed should be considered rejected. > > >=20 From ietf-nomcom-errors@lists.elistx.com Thu May 22 13:15:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00J04SZMTT@eListX.com> (original mail from rja@extremenetworks.com) ; Thu, 22 May 2003 13:09:22 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00J01SZLTR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 13:09:21 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00J01SZKTQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 13:09:20 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA00J2XSZKA0@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 13:09:20 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 3165567103; Thu, 22 May 2003 13:35:47 -0400 (EDT) Date: Thu, 22 May 2003 13:08:42 -0400 From: RJ Atkinson Subject: Re: Alternative (H) In-reply-to: To: Christian Huitema Cc: ietf-nomcom@lists.elistx.com Message-id: <0A65D5FB-8C78-11D7-B201-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thursday, May 22, 2003, at 12:31 America/Montreal, Christian Huitema wrote: > I just want to tweak the text to make sure that, whatever the decision > process of the CB, lack of timely decision is equivalent to rejection. Ah, I get it now. > We probably also need to define "timely". I don't feel a need to define timely, but I won't object to any reasonable proposal on a timeline for the CB to perform its decision process. Ran From ietf-nomcom-errors@lists.elistx.com Thu May 22 14:45:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00104X8GCC@eListX.com> (original mail from galvin+ietf-nomcom@eListX.com); Thu, 22 May 2003 14:41:05 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00101X8GCA@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 14:41:04 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00101X8FC8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 14:41:03 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA00105X8EBW@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 14:41:03 -0400 (EDT) Date: Thu, 22 May 2003 14:40:44 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Current version? In-reply-to: <5.2.1.1.2.20030522120526.03077100@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: <511525194.1053615628@localhost> <511525194.1053615628@localhost> <5.2.1.1.2.20030522120526.03077100@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Speaking as editor, it was determined there was no consensus to change this text. Jim On Thu, 22 May 2003, Michael StJohns wrote: Date: Thu, 22 May 2003 12:27:41 -0400 From: Michael StJohns To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Subject: Current version? Jim - The May 8th version of this didn't address the comments and discussion about >The confirming bodies review their respective candidates and, > in consultation with the nominating committee, consent to > some, all, or none of the candidates. The CBs have their own roles and MUST NOT be overly influenced by the Nomcom. So "in consultation with" needs to go. Brian proposed some alternate text which I can live with: > If not all the candidates submitted to a confirming body are > rapidly confirmed, the confirming body continues to communicate > with the nominating committee both to understand the committee's > rationale for the slate and, if appropriate, to explain the reason > why all the candidates were not confirmed. > > 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. From ietf-nomcom-errors@lists.elistx.com Thu May 22 14:45:16 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00104XECIK@eListX.com> (original mail from mstjohns@mindspring.com) ; Thu, 22 May 2003 14:44:37 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00101XEBI7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 14:44:35 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFA00101XE9I1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 14:44:34 -0400 (EDT) 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 <0HFA00KLMXE9C4@eListX.com>; Thu, 22 May 2003 14:44:33 -0400 (EDT) Received: from pcp802197pcs.nrockv01.md.comcast.net ([68.48.86.43] helo=STJOHNS-LAPTOP2.mindspring.com) by stork.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 19Iv2i-0002wq-00; Thu, 22 May 2003 11:43:56 -0700 Date: Thu, 22 May 2003 14:43:55 -0400 From: Michael StJohns Subject: Re: Current version? In-reply-to: X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <5.2.1.1.2.20030522144248.01b0be48@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d8c5c949dee1ef4e756b8f1e2ba68a213350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <5.2.1.1.2.20030522120526.03077100@pop.mindspring.com> <511525194.1053615628@localhost> <511525194.1053615628@localhost> <5.2.1.1.2.20030522120526.03077100@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I love the passive voice - it hides a host of ills... Who determined? As near as I remember, Brian and I had the discussion, came to a consensus, and there were no opposing opinions. Mike At 14:40 5/22/2003, James M Galvin wrote: >Speaking as editor, it was determined there was no consensus to change >this text. > >Jim > > > > >On Thu, 22 May 2003, Michael StJohns wrote: > > Date: Thu, 22 May 2003 12:27:41 -0400 > From: Michael StJohns > To: James M Galvin > Cc: ietf-nomcom@lists.elistx.com > Subject: Current version? > > Jim - > > The May 8th version of this didn't address the comments and > discussion about > > > >The confirming bodies review their respective candidates and, > > in consultation with the nominating committee, consent to > > some, all, or none of the candidates. > > > The CBs have their own roles and MUST NOT be overly influenced by the > Nomcom. So "in consultation with" needs to go. > > Brian proposed some alternate text which I can live with: > > > If not all the candidates submitted to a confirming body are > > rapidly confirmed, the confirming body continues to communicate > > with the nominating committee both to understand the committee's > > rationale for the slate and, if appropriate, to explain the reason > > why all the candidates were not confirmed. > > > > 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. From ietf-nomcom-errors@lists.elistx.com Thu May 22 16:15:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB005041J2YP@eListX.com> (original mail from rja@extremenetworks.com) ; Thu, 22 May 2003 16:13:50 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB005011J2YJ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 16:13:50 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB005011J1YH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 16:13:49 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFB002FV1J0FH@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 16:13:49 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 2192E67103; Thu, 22 May 2003 16:40:19 -0400 (EDT) Date: Thu, 22 May 2003 16:13:13 -0400 From: RJ Atkinson Subject: Re: Current version? In-reply-to: <5.2.1.1.2.20030522144248.01b0be48@pop.mindspring.com> To: Michael StJohns Cc: James M Galvin , ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thursday, May 22, 2003, at 14:43 America/Montreal, Michael StJohns wrote: > I love the passive voice - it hides a host of ills... > > Who determined? As near as I remember, Brian and I had the > discussion, came to a consensus, and there were no opposing opinions. > > Mike And the person who made that determination please point to the specific list postings in the archive that indicated an opposing consensus ? Thanks, Ran From ietf-nomcom-errors@lists.elistx.com Thu May 22 17:25:10 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB008044JOOB@eListX.com> (original mail from galvin+ietf-nomcom@eListX.com); Thu, 22 May 2003 17:19:00 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB008014JNO9@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 17:18:59 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB008014JMO7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 17:18:58 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFB007424JLKF@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 17:18:58 -0400 (EDT) Date: Thu, 22 May 2003 17:18:38 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Current version? In-reply-to: To: RJ Atkinson Cc: Michael StJohns , ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Speaking as editor, when you have a standing document it is not necessarily about opposing opinions. The question is whether there is consensus (overwhelming or compelling) to change the existing document. Jim On Thu, 22 May 2003, RJ Atkinson wrote: Date: Thu, 22 May 2003 16:13:13 -0400 From: RJ Atkinson To: Michael StJohns Cc: James M Galvin , ietf-nomcom@lists.elistx.com Subject: Re: Current version? On Thursday, May 22, 2003, at 14:43 America/Montreal, Michael StJohns wrote: > I love the passive voice - it hides a host of ills... > > Who determined? As near as I remember, Brian and I had the > discussion, came to a consensus, and there were no opposing opinions. > > Mike And the person who made that determination please point to the specific list postings in the archive that indicated an opposing consensus ? Thanks, Ran ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: From ietf-nomcom-errors@lists.elistx.com Thu May 22 17:55:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB009045VKMK@eListX.com> (original mail from rja@extremenetworks.com) ; Thu, 22 May 2003 17:47:44 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB009015VKMB@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 17:47:44 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB009015VJM2@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 22 May 2003 17:47:43 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFB007865VIKF@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 22 May 2003 17:47:42 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 82ED667103; Thu, 22 May 2003 18:14:12 -0400 (EDT) Date: Thu, 22 May 2003 17:47:06 -0400 From: RJ Atkinson Subject: Re: Current version? In-reply-to: To: James M Galvin Cc: Michael StJohns , ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thursday, May 22, 2003, at 17:18 America/Montreal, James M Galvin wrote: > Speaking as editor, when you have a standing document it is not > necessarily about opposing opinions. The question is whether there is > consensus (overwhelming or compelling) to change the existing document. > > Jim Jim, If the only opinions expressed on list are favourable, under RFC-2026 as amended, I don't see any way one can interpret that as anything but rough consensus. Now if some dissent were visible on the list and there were a mixture of expressed views with no clear trendline, then the situation might be different. Neither Document Editors nor WG Chairs are empowered to ignore the expressed views on-list when determining consensus. And silence does not imply either consent or dissent under normal circumstances. Lots of times folks who agree see no point in posting notes about their agreement -- since the opinion they agree with has already been expressed. Are you claiming there was any visible dissent on the mailing list ? If yes, which messages in the archive should I refer to ? If no, then I don't see how the issue could properly have been determined to be "no change" under RFC-2026 as amended. Thanks, Ran Atkinson rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Fri May 23 00:35:17 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB00L04OL2RH@eListX.com> (original mail from Jim.Bound@hp.com); Fri, 23 May 2003 00:31:50 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB00L01OL1RF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 00:31:49 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB00L01OL1RE@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 00:31:49 -0400 (EDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFB00KA6OL0EQ@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 00:31:48 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0FE8CAAF1 for ; Fri, 23 May 2003 00:30:52 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 23 May 2003 00:30:50 -0400 Date: Fri, 23 May 2003 00:30:50 -0400 From: "Bound, Jim" Subject: Liaisons interoperation with NOMCOM members To: ietf-nomcom@lists.elistx.com Message-id: <9C422444DE99BC46B3AD3C6EAFC9711B0324129B@tayexc13.americas.cpqcorp.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Liaisons interoperation with NOMCOM members Thread-Index: AcMg5Bg+dDVTd0UvTCqb4dAHSDyWAA== content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 23 May 2003 04:30:50.0531 (UTC) FILETIME=[16E5FF30:01C320E4] In the current document it is not clear totally to me that the Liaiso= ns should play a more limited role than currently stated, and this shoul= d be the case. The IAB and IESG Liaisons should only be present during NOMCOM deliberations when requested and should not be part of the NOM= COM discourse, unless they are required for clarfication as Liaisons. Having the Liaisons in the room with the NOMCOM is like having the Government with you in the voting booth, which is not good. Thoughts? Regards, /jim From ietf-nomcom-errors@lists.elistx.com Fri May 23 02:55:27 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB00304V3DBG@eListX.com> (original mail from harald@alvestrand.no); Fri, 23 May 2003 02:52:25 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB00301V3CB8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 02:52:24 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB00301V3BB6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 02:52:23 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFB0021EV3AS6@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 02:52:23 -0400 (EDT) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CCD5261BA7; Fri, 23 May 2003 08:51:41 +0200 (CEST) Date: Thu, 22 May 2003 17:22:19 +0200 From: Harald Tveit Alvestrand Subject: RE: Alternative (H) In-reply-to: To: Christian Huitema , James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <520034720.1053624139@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.0.2 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On 22. mai 2003 08:12 -0700 Christian Huitema wrote: > This text has the advantage of not conflicting with ISOC's by-laws, > which is good. However, the algorithm as presented does not completely > resolve the deadlock problem. As proposed, the phrase "failing which the > candidate is considered to be rejected" seem to only apply to the case > where the CB has no defined decision rule and resorts to majority > voting. I started to put that in, but then discovered that the text I was editing from had added this: > The confirming body must make its decision within a reasonable > timeframe. The results from the confirming body must be reported > promptly to the nominating committee. which translates pretty well to "thou shalt not deadlock". From ietf-nomcom-errors@lists.elistx.com Fri May 23 03:45:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB00404XIWNV@eListX.com> (original mail from harald@alvestrand.no); Fri, 23 May 2003 03:44:56 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB00401XIVNL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 03:44:55 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFB00401XIUNI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 03:44:54 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFB000GLXIT3V@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 03:44:53 -0400 (EDT) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6091A62607; Fri, 23 May 2003 09:44:14 +0200 (CEST) Date: Fri, 23 May 2003 09:11:39 +0200 From: Harald Tveit Alvestrand Subject: Re: Alternative (H) In-reply-to: <4B706ACA-8C6E-11D7-B201-00039357A82A@extremenetworks.com> To: RJ Atkinson , James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <576993572.1053681099@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.0.2 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <4B706ACA-8C6E-11D7-B201-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: the edit is acceptable to me. --On 22. mai 2003 11:58 -0400 RJ Atkinson wrote: > > Harald, > > Is Jim's proposed edit (see below) acceptable to you ? > > Thanks, > > Ran > > On Thursday, May 22, 2003, at 10:20 America/Montreal, James M Galvin > wrote: >> I would make your first paragraph "singular" and change "can" to a >> "should," but otherwise I prefer this text to A2. >> >> Jim >> >> >> >> On Thu, 22 May 2003, Harald Tveit Alvestrand wrote: >> >> Delete the existing text in section 4, and replace with this: >> >> 4. The confirming bodies decide their consent according to a >> rule >> of their own choosing. >> >> CHANGE THIS: >> >> If the confirming bodies have no such specific rule, the confirming >> bodies can decide their consent by ensuring that at least >> one-half of the confirming body's sitting members agree to each >> candidate's confirmation, failing which the candidate is >> considered to be rejected. >> >> TO: >> >> If a confirming body has no such specific rule, it should >> decide its consent by ensuring that at least one-half of its >> sitting members agree to each candidate's confirmation, >> failing which the candidate is considered to be rejected. >> >> The agreement may be decided by conducting a formal vote, >> by >> asserting consensus based on informal exchanges (e.g. >> email), or >> by whatever mechanism is used to conduct the normal >> business of >> the confirming body. >> >> The confirming body must make its decision within a >> reasonable >> timeframe. The results from the confirming body must be >> reported >> promptly to the nominating committee. >> >> ---------------------------------------------------------------- >> To subscribe or unsubscribe from this elist use the subscription >> manager: >> > > > From ietf-nomcom-errors@lists.elistx.com Fri May 23 09:05:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00D04C7KDU@eListX.com> (original mail from brian@hursley.ibm.com) ; Fri, 23 May 2003 09:02:08 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00D01C7JDS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:02:07 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00D01C7JDR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:02:07 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00B3VC7H7T@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 09:02:06 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4ND0ou9035000 for ; Fri, 23 May 2003 15:01:02 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4ND0ONh041622 for ; Fri, 23 May 2003 15:00:35 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61210 from ; Fri, 23 May 2003 15:00:23 +0200 Date: Fri, 23 May 2003 15:00:51 +0200 From: Brian E Carpenter Subject: Re: Current version? To: ietf-nomcom@lists.elistx.com Message-id: <3ECE1B83.1EDF5E25@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: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Mike St J certainly convinced me that the text needed to be changed. Just to refresh the argument, "consult" suggests a level of interdependency that isn't compatible either with the confirming body's independent role or with the strict confidentiality of the Nomcom's discussions. My proposed text describes fairly accurately what has actually happened in my experience (8 years on one of the confirming bodies, and 3 years on the other). Given that nobody disagreed with Mike and I on the list, once we reached agreement, I would certainly challenge the statement that there is no consensus for the change. Brian RJ Atkinson wrote: > > On Thursday, May 22, 2003, at 17:18 America/Montreal, James M Galvin > wrote: > > > Speaking as editor, when you have a standing document it is not > > necessarily about opposing opinions. The question is whether there is > > consensus (overwhelming or compelling) to change the existing document. > > > > Jim > > Jim, > > If the only opinions expressed on list are favourable, under RFC-2026 > as amended, I don't see any way one can interpret that as anything > but rough consensus. Now if some dissent were visible on the list > and there were a mixture of expressed views with no clear trendline, > then the situation might be different. > > Neither Document Editors nor WG Chairs are empowered to ignore the > expressed views on-list when determining consensus. And silence > does not imply either consent or dissent under normal circumstances. > Lots of times folks who agree see no point in posting notes about > their agreement -- since the opinion they agree with has already > been expressed. > > Are you claiming there was any visible dissent on the mailing list ? > If yes, which messages in the archive should I refer to ? > If no, then I don't see how the issue could properly have been > determined to be "no change" under RFC-2026 as amended. > > Thanks, > > Ran Atkinson > rja@extremenetworks.com > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From ietf-nomcom-errors@lists.elistx.com Fri May 23 09:15:10 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00D04CROTT@eListX.com> (original mail from rja@extremenetworks.com) ; Fri, 23 May 2003 09:14:12 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00D01CRNTR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:14:11 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00D01CRNTQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:14:11 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00A79CRMVF@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 09:14:10 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 1326267103; Fri, 23 May 2003 09:40:48 -0400 (EDT) Date: Fri, 23 May 2003 09:13:33 -0400 From: RJ Atkinson Subject: Re: Current version? In-reply-to: <3ECE1B83.1EDF5E25@hursley.ibm.com> To: Brian E Carpenter Cc: ietf-nomcom@lists.elistx.com Message-id: <5B0D7934-8D20-11D7-87EA-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I support Brian and Mike, both in analysis of the problem and in their proposed fix. Regardless of how this item was lost/side-tracked last go around, it needs to get pulled back from never-never-land and added to the "Editor should change text" item list. IMHO, Ran On Friday, May 23, 2003, at 09:00 America/Montreal, Brian E Carpenter wrote: > Mike St J certainly convinced me that the text needed to be changed. > Just to refresh the argument, "consult" suggests a level of > interdependency > that isn't compatible either with the confirming body's independent > role or with the strict confidentiality of the Nomcom's discussions. > My proposed text describes fairly accurately what has actually > happened in my experience (8 years on one of the confirming bodies, > and 3 years on the other). > > Given that nobody disagreed with Mike and I on the list, once we > reached agreement, I would certainly challenge the statement that > there is no consensus for the change. > > Brian From ietf-nomcom-errors@lists.elistx.com Fri May 23 09:25:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E04CVO11@eListX.com> (original mail from rja@extremenetworks.com) ; Fri, 23 May 2003 09:16:36 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E01CVM0Z@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:16:34 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E01CVM0S@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:16:34 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00B4OCVL7T@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 09:16:33 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id F3DF667108; Fri, 23 May 2003 09:43:10 -0400 (EDT) Date: Fri, 23 May 2003 09:15:56 -0400 From: RJ Atkinson Subject: Re: Alternative (H) In-reply-to: <520034720.1053624139@localhost> To: Harald Tveit Alvestrand Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thursday, May 22, 2003, at 11:22 America/Montreal, Harald Tveit Alvestrand wrote: > --On 22. mai 2003 08:12 -0700 Christian Huitema > wrote: >> This text has the advantage of not conflicting with ISOC's by-laws, >> which is good. However, the algorithm as presented does not completely >> resolve the deadlock problem. As proposed, the phrase "failing which >> the >> candidate is considered to be rejected" seem to only apply to the case >> where the CB has no defined decision rule and resorts to majority >> voting. > > I started to put that in, but then discovered that the text > I was editing from had added this: > >> The confirming body must make its decision within a reasonable >> timeframe. The results from the confirming body must be reported >> promptly to the nominating committee. > > which translates pretty well to "thou shalt not deadlock". The existing text had equivalent phrasing about the need for a quick decision, yet the IAB has deadlocked at least once. (I have no data on the ISoc BoT history). The deadlock problem is real, not ephemeral. So I think there is evidence that Christian is fixing a real problem that the existing vague words don't fully resolve. I'll propose (H2) in a minute, which tries to include Christian's proposal and also Jim Galvin's proposal, with minor wordsmithing. Ran From ietf-nomcom-errors@lists.elistx.com Fri May 23 09:25:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E04D0S6B@eListX.com> (original mail from brian@hursley.ibm.com) ; Fri, 23 May 2003 09:19:41 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E01D0S69@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:19:40 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E01D0R68@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:19:39 -0400 (EDT) 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 <0HFC00A7QD0KVF@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 09:19:39 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4NDHiCi061790 for ; Fri, 23 May 2003 15:18:04 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4NDGTYI179740 for ; Fri, 23 May 2003 15:16:30 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31232 from ; Fri, 23 May 2003 15:16:27 +0200 Date: Fri, 23 May 2003 15:16:55 +0200 From: Brian E Carpenter Subject: Re: Revised Question 2 To: ietf-nomcom@lists.elistx.com Message-id: <3ECE1F47.7C0EF0E4@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: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I'm happy with A2 or with H as amended. Brian RJ Atkinson wrote: > > At the bottom of this note, I've attempted to list all of > the proposed fixes for the deadlock issue in Section 4 that > are still being actively proposed. It is likely that I've made > a mistake along the way, so this note just attempts to verify > that I have the correct list of currently proposed fixes. > > If your preferred fix is not listed below, please post > a note to the list outlining your proposed fix. If your > proposal involves replacing the Section 4 text, please > include the precise proposed new text for Section 4. > > Thanks, > > Ran > rja@extremenetworks.com > > ------------------------------------------------------------- > Alternatives still being considered: > > (NUL) delete the current Section 4 text and have the document > be entirely silent about how the confirming bodies confirm/reject > nominees. > (A2) posted to the list on 21 May 2003, joint from several folks > (G) posted to the list on 19 May 2003, from Christian Huitema > (H) from Harald Alvestrand's note of 16 May 2003; > I do not know what Harald's proposed new wording is. > --------------------------------------------------------------- > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: From ietf-nomcom-errors@lists.elistx.com Fri May 23 09:25:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E04D227C@eListX.com> (original mail from rja@extremenetworks.com) ; Fri, 23 May 2003 09:20:26 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E01D217A@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:20:25 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E01D2079@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:20:24 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00A6PD20VE@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 09:20:24 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id DAEE267103 for ; Fri, 23 May 2003 09:47:01 -0400 (EDT) Date: Fri, 23 May 2003 09:19:47 -0400 From: RJ Atkinson Subject: Alternative (H2) To: ietf-nomcom@lists.elistx.com Message-id: <39ACE8A8-8D21-11D7-87EA-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Trying to combine Harald's proposal, Jim's draft amendment, and Christian's draft amendment, I come up with this. It includes some wordsmithing edits by me, not intended to change the meaning. Would the folks who like (A2) be comfortable dropping that in favour of this ? I am comfortable either with (A2) or the (H2) below. Is Harald OK with this ? Other comments ? Thanks, Ran Atkinson rja@extremenetworks.com -------------------------------------------------------------------- Delete the existing text in section 4, and replace with this: 4. The confirming body decides whether it confirms each candidate using a confirmation decision rule chosen by the confirming body. If a confirming body has no specific confirmation decision rule, then confirming a given candidate should require at least one-half of the Confirming Body's sitting members to agree to that confirmation. The decision may be made by conducting a formal vote, by asserting consensus based on informal exchanges (e.g. email), or by any other mechanism that is used to conduct the normal business of the confirming body. Regardless of which decision rule the confirming body uses, any candidate that is not confirmed under that rule must be rejected. The confirming body must make its decision within a reasonable timeframe. The results from the confirming body must be reported promptly to the nominating committee. ------------------------------------------------------------------------ From ietf-nomcom-errors@lists.elistx.com Fri May 23 09:35:22 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E04DQARG@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Fri, 23 May 2003 09:34:58 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E01DQARE@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:34:58 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E01DQ9RC@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:34:57 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00B5CDQ880@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 09:34:57 -0400 (EDT) Date: Fri, 23 May 2003 09:34:38 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Alternative (H2) In-reply-to: <39ACE8A8-8D21-11D7-87EA-00039357A82A@extremenetworks.com> To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <39ACE8A8-8D21-11D7-87EA-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: This is good for me. Jim On Fri, 23 May 2003, RJ Atkinson wrote: Date: Fri, 23 May 2003 09:19:47 -0400 From: RJ Atkinson To: ietf-nomcom@lists.elistx.com Subject: Alternative (H2) Trying to combine Harald's proposal, Jim's draft amendment, and Christian's draft amendment, I come up with this. It includes some wordsmithing edits by me, not intended to change the meaning. Would the folks who like (A2) be comfortable dropping that in favour of this ? I am comfortable either with (A2) or the (H2) below. Is Harald OK with this ? Other comments ? Thanks, Ran Atkinson rja@extremenetworks.com -------------------------------------------------------------------- Delete the existing text in section 4, and replace with this: 4. The confirming body decides whether it confirms each candidate using a confirmation decision rule chosen by the confirming body. If a confirming body has no specific confirmation decision rule, then confirming a given candidate should require at least one-half of the Confirming Body's sitting members to agree to that confirmation. The decision may be made by conducting a formal vote, by asserting consensus based on informal exchanges (e.g. email), or by any other mechanism that is used to conduct the normal business of the confirming body. Regardless of which decision rule the confirming body uses, any candidate that is not confirmed under that rule must be rejected. The confirming body must make its decision within a reasonable timeframe. The results from the confirming body must be reported promptly to the nominating committee. From ietf-nomcom-errors@lists.elistx.com Fri May 23 09:55:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F04E8392@eListX.com> (original mail from sob@newdev.harvard.edu) ; Fri, 23 May 2003 09:45:39 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F01E8290@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:45:38 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F01E818Z@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:45:37 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00B5TE8080@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 09:45:37 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h4NDisH3026029; Fri, 23 May 2003 09:44:54 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4NDisNW026028; Fri, 23 May 2003 09:44:54 -0400 (EDT) Date: Fri, 23 May 2003 09:44:54 -0400 (EDT) From: Scott Bradner Subject: Re: Alternative (H2) In-reply-to: <39ACE8A8-8D21-11D7-87EA-00039357A82A@extremenetworks.com> To: ietf-nomcom@lists.elistx.com, rja@extremenetworks.com Message-id: <200305231344.h4NDisNW026028@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: we are well into the area of diminishing returns on this can we just say OK to Ran's words and move on? Scott ----- From ietf-nomcom-errors@lists.elistx.com Fri May 23 09:19:58 2003 Date: Fri, 23 May 2003 09:19:47 -0400 From: RJ Atkinson Subject: Alternative (H2) To: ietf-nomcom@lists.elistx.com MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Trying to combine Harald's proposal, Jim's draft amendment, and Christian's draft amendment, I come up with this. It includes some wordsmithing edits by me, not intended to change the meaning. Would the folks who like (A2) be comfortable dropping that in favour of this ? I am comfortable either with (A2) or the (H2) below. Is Harald OK with this ? Other comments ? Thanks, Ran Atkinson rja@extremenetworks.com -------------------------------------------------------------------- Delete the existing text in section 4, and replace with this: 4. The confirming body decides whether it confirms each candidate using a confirmation decision rule chosen by the confirming body. If a confirming body has no specific confirmation decision rule, then confirming a given candidate should require at least one-half of the Confirming Body's sitting members to agree to that confirmation. The decision may be made by conducting a formal vote, by asserting consensus based on informal exchanges (e.g. email), or by any other mechanism that is used to conduct the normal business of the confirming body. Regardless of which decision rule the confirming body uses, any candidate that is not confirmed under that rule must be rejected. The confirming body must make its decision within a reasonable timeframe. The results from the confirming body must be reported promptly to the nominating committee. ------------------------------------------------------------------------ ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: From ietf-nomcom-errors@lists.elistx.com Fri May 23 09:55:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F04E8LAD@eListX.com> (original mail from brian@hursley.ibm.com) ; Fri, 23 May 2003 09:45:57 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F01E8KAB@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:45:56 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F01E8KAA@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:45:56 -0400 (EDT) Received: from d06lmsgate-5.uk.ibm.com (d06lmsgate-5.uk.ibm.com [195.212.29.5]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00B7WE8I7V@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 09:45:55 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d06lmsgate-5.uk.ibm.com (8.12.9/8.12.8) with ESMTP id h4NDjBxr082034 for ; Fri, 23 May 2003 14:45:14 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4NDf3YI232676 for ; Fri, 23 May 2003 15:41:08 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31430 from ; Fri, 23 May 2003 15:41:01 +0200 Date: Fri, 23 May 2003 15:41:30 +0200 From: Brian E Carpenter Subject: Re: Liaisons interoperation with NOMCOM members To: ietf-nomcom@lists.elistx.com Message-id: <3ECE2509.C681D471@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: <9C422444DE99BC46B3AD3C6EAFC9711B0324129B@tayexc13.americas.cpqcorp.net> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: "Bound, Jim" wrote: > > In the current document it is not clear totally to me that the Liaisons > should play a more limited role than currently stated, and this should > be the case. The IAB and IESG Liaisons should only be present during > NOMCOM deliberations when requested and should not be part of the NOMCOM > discourse, unless they are required for clarfication as Liaisons. > Having the Liaisons in the room with the NOMCOM is like having the > Government with you in the voting booth, which is not good. I don't see how the IAB liaison can effectively verify the fairness of the Nomcom's work on the IESG choices unless the IAB liaison is present full time. That can only be fixed by putting the entire responsibility for verifying fairness on the ISOC liaison. The IAB and IESG liaisons need to be present whenever structure, processes and relationships inside their respective bodies are in question. I think the text should make it clear that the Nomcom chair can ask the IAB and IESG liaisons to leave the calls when appropriate, rather than attempting to limit their speech. Brian From ietf-nomcom-errors@lists.elistx.com Fri May 23 09:55:06 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F04EGYDZ@eListX.com> (original mail from sob@newdev.harvard.edu) ; Fri, 23 May 2003 09:50:58 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F01EGXDX@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:50:58 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F01EGXDW@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:50:57 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00A93EGWVF@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 09:50:56 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h4NDoLH3026073 for ; Fri, 23 May 2003 09:50:21 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4NDoLG4026072 for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 09:50:21 -0400 (EDT) Date: Fri, 23 May 2003 09:50:21 -0400 (EDT) From: Scott Bradner Subject: Re: Liaisons interoperation with NOMCOM members To: ietf-nomcom@lists.elistx.com Message-id: <200305231350.h4NDoLG4026072@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I agree with Brian: > I think the text should make it clear that the Nomcom chair can ask > the IAB and IESG liaisons to leave the calls when appropriate, rather > than attempting to limit their speech. Scott From ietf-nomcom-errors@lists.elistx.com Fri May 23 09:55:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F04EMBGY@eListX.com> (original mail from randy@psg.com); Fri, 23 May 2003 09:54:11 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F01EMAGS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:54:10 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00F01EM9GP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 09:54:09 -0400 (EDT) Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00B66EM880@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 09:54:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19JCzD-000EbJ-Sj; Fri, 23 May 2003 06:53:31 -0700 Date: Fri, 23 May 2003 06:53:31 -0700 From: Randy Bush Subject: Re: Liaisons interoperation with NOMCOM members To: Scott Bradner Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <200305231350.h4NDoLG4026072@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: btw, i think both dave and john think they are being constructive and are acting with good intent. i just don't think that is the result. randy From ietf-nomcom-errors@lists.elistx.com Fri May 23 10:25:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00G04FQ3HO@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Fri, 23 May 2003 10:18:03 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00G01FQ2HM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 10:18:02 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00G01FQ1HK@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 10:18:01 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00B7FFQ080@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 10:18:01 -0400 (EDT) Date: Fri, 23 May 2003 10:17:42 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Liaisons interoperation with NOMCOM members In-reply-to: <3ECE2509.C681D471@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: <9C422444DE99BC46B3AD3C6EAFC9711B0324129B@tayexc13.americas.cpqcorp.net> <3ECE2509.C681D471@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Speaking personally, I agree with Brian except that I don't think we need explicit text. Speaking as editor of the document: On Fri, 23 May 2003, Brian E Carpenter wrote: I think the text should make it clear that the Nomcom chair can ask the IAB and IESG liaisons to leave the calls when appropriate, rather than attempting to limit their speech. The text currently states that all members of the committee are explicitly permitted to attend all meetings of the committee. This clarification was added at least one RFC ago to ensure that no one, including liaisons, could be excluded. As I recall, suggesting that certain members can be excluded then opens the discussion for defining the appropriate criteria, and that is a very slippery slope. Note too, that this version of the document has a dispute resolution process that should contribute to the ability of the NOMCOM to successfully address internal issues. It is intended to make it clear that any member of the committee has a path to raise concerns and get them addressed, fairly and expeditiously. Jim From ietf-nomcom-errors@lists.elistx.com Fri May 23 11:05:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00I04HPRCD@eListX.com> (original mail from brian@hursley.ibm.com) ; Fri, 23 May 2003 11:01:03 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00I01HPRCB@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:01:03 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00I01HPQCA@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:01:02 -0400 (EDT) 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 <0HFC00BAPHPP7T@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 11:01:02 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4NF0Llr074146; Fri, 23 May 2003 17:00:21 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4NF0KYI177164; Fri, 23 May 2003 17:00:21 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31290 from ; Fri, 23 May 2003 17:00:18 +0200 Date: Fri, 23 May 2003 17:00:47 +0200 From: Brian E Carpenter Subject: Re: Alternative (H2) To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: <3ECE379F.8B626A7F@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: <39ACE8A8-8D21-11D7-87EA-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: This is fine Brian RJ Atkinson wrote: > > Trying to combine Harald's proposal, Jim's draft amendment, and > Christian's > draft amendment, I come up with this. It includes some wordsmithing > edits by me, not intended to change the meaning. > > Would the folks who like (A2) be comfortable dropping that in favour > of this ? I am comfortable either with (A2) or the (H2) below. > > Is Harald OK with this ? > > Other comments ? > > Thanks, > > Ran Atkinson > rja@extremenetworks.com > > -------------------------------------------------------------------- > Delete the existing text in section 4, and replace with this: > > 4. The confirming body decides whether it confirms each candidate > using a confirmation decision rule chosen by the confirming body. > > If a confirming body has no specific confirmation decision rule, > then confirming a given candidate should require at least > one-half > of the Confirming Body's sitting members to agree to that > confirmation. > > The decision may be made by conducting a formal vote, by > asserting > consensus based on informal exchanges (e.g. email), or by any > other mechanism that is used to conduct the normal business > of the confirming body. > > Regardless of which decision rule the confirming body uses, any > candidate that is not confirmed under that rule must be rejected. > > The confirming body must make its decision within a reasonable > timeframe. The results from the confirming body must be > reported > promptly to the nominating committee. > ------------------------------------------------------------------------ > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: From ietf-nomcom-errors@lists.elistx.com Fri May 23 11:05:11 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00I04HSNHJ@eListX.com> (original mail from mstjohns@mindspring.com) ; Fri, 23 May 2003 11:02:47 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00I01HSMHH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:02:46 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00I01HSMHG@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:02:46 -0400 (EDT) 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 <0HFC00BASHSL7T@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 11:02:45 -0400 (EDT) Received: from pcp802197pcs.nrockv01.md.comcast.net ([68.48.86.43] helo=STJOHNS-LAPTOP2.mindspring.com) by stork.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 19JE3c-0000fh-00; Fri, 23 May 2003 08:02:08 -0700 Date: Fri, 23 May 2003 11:02:08 -0400 From: Michael StJohns Subject: Re: Current version? In-reply-to: <5B0D7934-8D20-11D7-87EA-00039357A82A@extremenetworks.com> X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: avri@acm.org Cc: ietf-nomcom@lists.elistx.com Message-id: <5.2.1.1.2.20030523110102.00b85e88@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4dfab8e0c1b5374ea87e316ed4d8a80c52350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <3ECE1B83.1EDF5E25@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Would the chair please wake up and comment on this thread. At 09:13 5/23/2003, RJ Atkinson wrote: >I support Brian and Mike, both in analysis of the problem and in >their proposed fix. > >Regardless of how this item was lost/side-tracked last go around, >it needs to get pulled back from never-never-land and added to the >"Editor should change text" item list. > >IMHO, > >Ran > > >On Friday, May 23, 2003, at 09:00 America/Montreal, Brian E Carpenter wrote: > >>Mike St J certainly convinced me that the text needed to be changed. >>Just to refresh the argument, "consult" suggests a level of interdependency >>that isn't compatible either with the confirming body's independent >>role or with the strict confidentiality of the Nomcom's discussions. >>My proposed text describes fairly accurately what has actually >>happened in my experience (8 years on one of the confirming bodies, >>and 3 years on the other). >> >>Given that nobody disagreed with Mike and I on the list, once we >>reached agreement, I would certainly challenge the statement that >>there is no consensus for the change. >> >> Brian > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Fri May 23 11:25:12 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00J04IPEGV@eListX.com> (original mail from brian@hursley.ibm.com) ; Fri, 23 May 2003 11:22:26 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00J01IPDGT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:22:25 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00J01IPDGS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:22:25 -0400 (EDT) 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 <0HFC00BA2IPB7Y@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 11:22:24 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4NFLjCi039946 for ; Fri, 23 May 2003 17:21:46 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4NFLjYI191556 for ; Fri, 23 May 2003 17:21:45 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48688 from ; Fri, 23 May 2003 17:21:43 +0200 Date: Fri, 23 May 2003 17:22:11 +0200 From: Brian E Carpenter Subject: Re: Liaisons interoperation with NOMCOM members To: ietf-nomcom@lists.elistx.com Message-id: <3ECE3CA3.FF9394DF@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: <9C422444DE99BC46B3AD3C6EAFC9711B0324129B@tayexc13.americas.cpqcorp.net> <3ECE2509.C681D471@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: James M Galvin wrote: > > Speaking personally, I agree with Brian except that I don't think we > need explicit text. Since the Nomcom chair has explicit discretion for undocumented pieces of process, that is strictly true, but some people seem to want it written. > > Speaking as editor of the document: > > On Fri, 23 May 2003, Brian E Carpenter wrote: > > I think the text should make it clear that the Nomcom chair can ask > the IAB and IESG liaisons to leave the calls when appropriate, > rather than attempting to limit their speech. > > The text currently states that all members of the committee are > explicitly permitted to attend all meetings of the committee. This > clarification was added at least one RFC ago to ensure that no one, > including liaisons, could be excluded. > > As I recall, suggesting that certain members can be excluded then opens > the discussion for defining the appropriate criteria, and that is a very > slippery slope. Indeed, and I would leave that to the Nomcom chair's discretion, and *not* attempt to write down anything more than "The IAB and IESG liaisons may be requested to temporarily leave the conference calls, at the chair's discretion." > > Note too, that this version of the document has a dispute resolution > process that should contribute to the ability of the NOMCOM to > successfully address internal issues. It is intended to make it clear > that any member of the committee has a path to raise concerns and get > them addressed, fairly and expeditiously. Yes, and that is how the chair's decisions can be challenged. Brian From ietf-nomcom-errors@lists.elistx.com Fri May 23 11:45:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00K04JE56U@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Fri, 23 May 2003 11:37:17 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00K01JE46S@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:37:16 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00K01JE46Q@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:37:16 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00ADJJE3VF@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 11:37:15 -0400 (EDT) Date: Fri, 23 May 2003 11:36:56 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Liaisons interoperation with NOMCOM members In-reply-to: <3ECE3CA3.FF9394DF@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: <9C422444DE99BC46B3AD3C6EAFC9711B0324129B@tayexc13.americas.cpqcorp.net> <3ECE2509.C681D471@hursley.ibm.com> <3ECE3CA3.FF9394DF@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Fri, 23 May 2003, Brian E Carpenter wrote: James M Galvin wrote: > > Speaking personally, I agree with Brian except that I don't think we > need explicit text. Since the Nomcom chair has explicit discretion for undocumented pieces of process, that is strictly true, but some people seem to want it written. Still speaking as editor: Actually, the discretion is with the committee as a whole, not the Chair. This was changed at least one RFC ago. Quoting from the document: 5. Nominating Committee Operation 1. All rules and special circumstances not otherwise specified are at the discretion of the committee. Exceptional circumstances will occasionally arise during the normal operation of the nominating committee. This rule is intended to foster the continued forward progress of the committee. Any member of the committee may propose a rule for adoption by the committee. The rule must be approved by all members of the committee according to its established voting mechanism. All members of the committee should consider whether the exception is worthy of mention in the next revision of this document and follow-up accordingly. > As I recall, suggesting that certain members can be excluded then opens > the discussion for defining the appropriate criteria, and that is a very > slippery slope. Indeed, and I would leave that to the Nomcom chair's discretion, and *not* attempt to write down anything more than "The IAB and IESG liaisons may be requested to temporarily leave the conference calls, at the chair's discretion." With the above in mind -- and generalizing the principle -- would the following be acceptable to you: Liaisons and advisors (except the past Chair) may be requested to temporarily leave a discussion at the Chair's discretion. I left it as Chair because I do believe it is reasonable to explicitly give this discretion to the Chair. I added advisors because it seems sensible to apply the principle explicitly to all parties who are not voting members. The exception for the Past Chair is necessary because the position is considered an "advisor" in the text. Jim From ietf-nomcom-errors@lists.elistx.com Fri May 23 11:45:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00K04JHC9O@eListX.com> (original mail from sob@newdev.harvard.edu) ; Fri, 23 May 2003 11:39:12 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00K01JHB9M@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:39:11 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00K01JHB9L@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:39:11 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00ADTJH5VE@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 11:39:10 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h4NFcTH3026557; Fri, 23 May 2003 11:38:29 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4NFcTju026556; Fri, 23 May 2003 11:38:29 -0400 (EDT) Date: Fri, 23 May 2003 11:38:29 -0400 (EDT) From: Scott Bradner Subject: Re: Liaisons interoperation with NOMCOM members In-reply-to: To: brian@hursley.ibm.com, galvin+ietf-nomcom@eListX.com Cc: ietf-nomcom@lists.elistx.com Message-id: <200305231538.h4NFcTju026556@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Liaisons and advisors (except the past Chair) may be requested to temporarily leave a discussion at the Chair's discretion. works for me Scott From ietf-nomcom-errors@lists.elistx.com Fri May 23 12:05:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00L04KEVAH@eListX.com> (original mail from brian@hursley.ibm.com) ; Fri, 23 May 2003 11:59:19 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00L01KEUAF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:59:18 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00L01KETAE@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 11:59:17 -0400 (EDT) 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 <0HFC00AF2KESVF@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 11:59:17 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4NFwdDI022040 for ; Fri, 23 May 2003 17:58:39 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4NFwdNh045766 for ; Fri, 23 May 2003 17:58:39 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA22844 from ; Fri, 23 May 2003 17:58:37 +0200 Date: Fri, 23 May 2003 17:59:06 +0200 From: Brian E Carpenter Subject: Re: Liaisons interoperation with NOMCOM members To: ietf-nomcom@lists.elistx.com Message-id: <3ECE454A.E4678E51@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: <200305231538.h4NFcTju026556@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Scott Bradner wrote: > > Liaisons and advisors (except the past Chair) may be requested > to temporarily leave a discussion at the Chair's discretion. > > works for me Me too Brian From ietf-nomcom-errors@lists.elistx.com Fri May 23 13:35:10 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00404OL908@eListX.com> (original mail from joel@stevecrocker.com) ; Fri, 23 May 2003 13:29:33 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00401OL806@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 13:29:33 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00401OL805@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 13:29:32 -0400 (EDT) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00AMCOL7VF@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 13:29:31 -0400 (EDT) Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4650841 for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 13:28:55 -0400 Date: Fri, 23 May 2003 13:28:51 -0400 From: "Joel M. Halpern" Subject: Re: Liaisons interoperation with NOMCOM members X-Sender: joel@stevecrocker.com@mail.stevecrocker.com To: ietf-nomcom@lists.elistx.com Message-id: <5.1.0.14.0.20030523132641.02917808@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 disagree. I believe that many of the reasons for having the liaisons at all are impossible if they are excluded from most conversations. I do not believe that there is any damage from having the liaisons in the room. I find your analogy misleading. I have not significant objection to the alternative proposal of giving the chair explicit power to exclude the liaisons from selected discussions. Yours, Joel M. Halpern At 12:30 AM 5/23/2003 -0400, Bound, Jim wrote: >In the current document it is not clear totally to me that the Liaisons >should play a more limited role than currently stated, and this should >be the case. The IAB and IESG Liaisons should only be present during >NOMCOM deliberations when requested and should not be part of the NOMCOM >discourse, unless they are required for clarfication as Liaisons. >Having the Liaisons in the room with the NOMCOM is like having the >Government with you in the voting booth, which is not good. > >Thoughts? > >Regards, >/jim > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Fri May 23 14:45:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00704ROQEN@eListX.com> (original mail from Jim.Bound@hp.com); Fri, 23 May 2003 14:36:26 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00701ROPEK@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 14:36:26 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00701ROPEF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 14:36:25 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC0058SROOFR@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 14:36:24 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A30B295B7; Fri, 23 May 2003 14:35:47 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 23 May 2003 14:35:45 -0400 Date: Fri, 23 May 2003 14:35:44 -0400 From: "Bound, Jim" Subject: RE: Liaisons interoperation with NOMCOM members To: Brian E Carpenter , ietf-nomcom@lists.elistx.com Message-id: <9C422444DE99BC46B3AD3C6EAFC9711B04284568@tayexc13.americas.cpqcorp.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Liaisons interoperation with NOMCOM members Thread-Index: AcMhRDv/C4y1EV7jSl2XJkJz13V+IgAFcPZQ content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 23 May 2003 18:35:45.0784 (UTC) FILETIME=[1F9FB780:01C3215A] This is good compromise reading the responses and add great value to = the process for deliberation for issues that are only the business of the nomcom. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com]=20 > Sent: Friday, May 23, 2003 11:59 AM > To: ietf-nomcom@lists.elistx.com > Subject: Re: Liaisons interoperation with NOMCOM members >=20 >=20 > Scott Bradner wrote: > >=20 > > Liaisons and advisors (except the past Chair) may be requeste= d > > to temporarily leave a discussion at the Chair's discretion. > >=20 > > works for me >=20 > Me too >=20 > Brian >=20 > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: >=20 From ietf-nomcom-errors@lists.elistx.com Fri May 23 14:45:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00704RXCNB@eListX.com> (original mail from Jim.Bound@hp.com); Fri, 23 May 2003 14:41:36 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00701RXCN9@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 14:41:36 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00701RXBN8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 14:41:35 -0400 (EDT) Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC0055DRXAYY@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 14:41:35 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8AE1E73B; Fri, 23 May 2003 14:40:52 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 23 May 2003 14:40:51 -0400 Date: Fri, 23 May 2003 14:40:51 -0400 From: "Bound, Jim" Subject: RE: Liaisons interoperation with NOMCOM members To: "Joel M. Halpern" , ietf-nomcom@lists.elistx.com Message-id: <9C422444DE99BC46B3AD3C6EAFC9711B04284569@tayexc13.americas.cpqcorp.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Liaisons interoperation with NOMCOM members Thread-Index: AcMhUNXP3qWN2w0XR6yGEVzKTAq8yQACVh9A content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 23 May 2003 18:40:51.0937 (UTC) FILETIME=[D61AF510:01C3215A] The NOMCOM can need at times an entity without IESG and IAB involveme= nt. Having served on a NOMCOM the example I will use is when the NOMCOM wants to discuss privately and confidentially the issues of keep or replace IESG or IAB members to keep that NOMCOM private conversation =66rom everyone except the NOMCOM members. I can think of others but= that is what I mean't by keeping the Government out of the voting booth. = I agree with Brian why they should be present. This also gives input t= o the NOMCOM if an IESG or IAB member is participating to much in the defense or denial of candidates or existing members to get them out o= f the room because they really should not be doing that other than any other IETF community member as input to the NOMCOM. Bottom line IESG= or IAB should not have any extra or more influence on the actual decisio= n than anyone else that NOMCOM will speak with in the community. I think the proposed wording would fix this and very minor enhancemen= t. Then I am done here with my input on this one. Regards, /jim > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: Friday, May 23, 2003 1:29 PM > To: ietf-nomcom@lists.elistx.com > Subject: Re: Liaisons interoperation with NOMCOM members >=20 >=20 > I disagree. I believe that many of the reasons for having=20 > the liaisons at=20 > all are impossible if they are excluded from most=20 > conversations. I do not believe that there is any damage from=20 > having the liaisons in the=20 > room. I find your analogy misleading. >=20 > I have not significant objection to the alternative proposal=20 > of giving the=20 > chair explicit power to exclude the liaisons from selected=20 > discussions. >=20 > Yours, > Joel M. Halpern >=20 > At 12:30 AM 5/23/2003 -0400, Bound, Jim wrote: > >In the current document it is not clear totally to me that=20 > the Liaisons=20 > >should play a more limited role than currently stated, and=20 > this should=20 > >be the case. The IAB and IESG Liaisons should only be=20 > present during=20 > >NOMCOM deliberations when requested and should not be part of the= =20 > >NOMCOM discourse, unless they are required for clarfication as= =20 > >Liaisons. Having the Liaisons in the room with the NOMCOM is like= =20 > >having the Government with you in the voting booth, which is=20 > not good. > > > >Thoughts? > > > >Regards, > >/jim > > > >---------------------------------------------------------------- > >To subscribe or unsubscribe from this elist use the subscription > >manager: >=20 >=20 >=20 > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: >=20 From ietf-nomcom-errors@lists.elistx.com Fri May 23 16:15:25 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00B04W8SMM@eListX.com> (original mail from dhc@dcrocker.net); Fri, 23 May 2003 16:14:52 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00B01W8RMK@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 16:14:52 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00B01W8RMJ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 16:14:51 -0400 (EDT) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC005G2W8QYY@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 16:14:50 -0400 (EDT) Received: from adsl-67-126-140-113.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4NKDrN25917; Fri, 23 May 2003 13:13:53 -0700 Date: Fri, 23 May 2003 13:14:04 -0700 From: Dave Crocker Subject: Re: Liaisons interoperation with NOMCOM members In-reply-to: To: Randy Bush Cc: Scott Bradner , ietf-nomcom@lists.elistx.com Reply-to: Dave Crocker Message-id: <12710106922.20030523131404@brandenburg.com> Organization: Brandenburg InternetWorking MIME-version: 1.0 X-Mailer: The Bat! (v1.63 Beta/4) Personal Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: <200305231350.h4NDoLG4026072@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Randy, on the offchance that I am the 'dave' you are referring to, I tried to figure out what your posting referred to. It certainly did not refer to the thread it occurred in, since no dave or john had yet posted. so, Randy, please clarify. d/ RB> btw, i think both dave and john think they are being constructive RB> and are acting with good intent. i just don't think that is the RB> result. RB> randy RB> ---------------------------------------------------------------- RB> To subscribe or unsubscribe from this elist use the subscription RB> manager: d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From ietf-nomcom-errors@lists.elistx.com Fri May 23 17:15:12 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E04YMTS6@eListX.com> (original mail from gih@telstra.net); Fri, 23 May 2003 17:06:29 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E01YMSS4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 17:06:28 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFC00E01YMSS3@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 17:06:28 -0400 (EDT) Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFC00B5IYMQHN@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 17:06:27 -0400 (EDT) Received: from gih505.telstra.net (dhcp7.potaroo.net [203.10.60.7]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h4NL5PMS076586; Sat, 24 May 2003 07:05:31 +1000 (EST envelope-from gih@telstra.net) Date: Sat, 24 May 2003 06:56:03 +1000 From: Geoff Huston Subject: RE: Liaisons interoperation with NOMCOM members In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B04284569@tayexc13.americas.cpqcorp.net> X-Sender: gih@kahuna.telstra.net To: "Bound, Jim" , "Joel M. Halpern" , ietf-nomcom@lists.elistx.com Message-id: <5.1.0.14.2.20030524063457.021e9490@kahuna.telstra.net> 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: Jim, A liaison is neither a delegate nor a representative, and while I would be more inclined to sympathize with your proposition if such were the case, given that the liaison role is one more akin to a constrained messenger, then I find your fears of collective interest being exercised upon the nomcom by the IESG or the IAB completely without foundation. Given that I was chairing that Nomcom when you were a member, I can also offer the observation that I saw at no point in time the exercising of IESG influence on the Nomcom, nor IAB influence.. Having been an IAB liaison myself subsequently, again at no point in time were the duties of the liaison during the Nomcom's consideration period being called upon beyond the conveying of explicit queries generated by the Nomcom and their corresponding responses I find it worrisome that there is this unfounded and growing level of mistrust being cast as an undercurrent in many of these considerations, where various bodies are being cast in a role of potential conspirators, and that their influence should be countered through the provision of explicit rules and provisions. What worries me is that when you start to create the frameworks and mechanisms to counter such possible problems you also start to create an environment of mutual distrust, and that is a place I'm sure noone wants to head. At every point in the Nomcom processes there is a point where rules and documented process must give way to community trust in good judgement, as exercised by the chair, as exercised by the members, and as exercised by the liaisons. For that reason I see this particular area (participation of liaisons in the Nomcom) as being one where explicit provisions are going to find it hard to achieve the necessary balance, while the judgement of the nomcom itself appears to me to have been entirely appropriate to date. regards, Geoff At 02:40 PM 23/05/2003 -0400, Bound, Jim wrote: >The NOMCOM can need at times an entity without IESG and IAB involvement. >Having served on a NOMCOM the example I will use is when the NOMCOM >wants to discuss privately and confidentially the issues of keep or >replace IESG or IAB members to keep that NOMCOM private conversation >from everyone except the NOMCOM members. I can think of others but that >is what I mean't by keeping the Government out of the voting booth. I >agree with Brian why they should be present. This also gives input to >the NOMCOM if an IESG or IAB member is participating to much in the >defense or denial of candidates or existing members to get them out of >the room because they really should not be doing that other than any >other IETF community member as input to the NOMCOM. Bottom line IESG or >IAB should not have any extra or more influence on the actual decision >than anyone else that NOMCOM will speak with in the community. > >I think the proposed wording would fix this and very minor enhancement. >Then I am done here with my input on this one. > >Regards, >/jim > > > -----Original Message----- > > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > > Sent: Friday, May 23, 2003 1:29 PM > > To: ietf-nomcom@lists.elistx.com > > Subject: Re: Liaisons interoperation with NOMCOM members > > > > > > I disagree. I believe that many of the reasons for having > > the liaisons at > > all are impossible if they are excluded from most > > conversations. I do not believe that there is any damage from > > having the liaisons in the > > room. I find your analogy misleading. > > > > I have not significant objection to the alternative proposal > > of giving the > > chair explicit power to exclude the liaisons from selected > > discussions. > > > > Yours, > > Joel M. Halpern > > > > At 12:30 AM 5/23/2003 -0400, Bound, Jim wrote: > > >In the current document it is not clear totally to me that > > the Liaisons > > >should play a more limited role than currently stated, and > > this should > > >be the case. The IAB and IESG Liaisons should only be > > present during > > >NOMCOM deliberations when requested and should not be part of the > > >NOMCOM discourse, unless they are required for clarfication as > > >Liaisons. Having the Liaisons in the room with the NOMCOM is like > > >having the Government with you in the voting booth, which is > > not good. > > > > > >Thoughts? > > > > > >Regards, > > >/jim > > > > > >---------------------------------------------------------------- > > >To subscribe or unsubscribe from this elist use the subscription > > >manager: > > > > > > > > ---------------------------------------------------------------- > > 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 Fri May 23 22:15:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00204CNQI8@eListX.com> (original mail from randy@psg.com); Fri, 23 May 2003 22:09:26 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00201CNPI5@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 22:09:25 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00201CNOHY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 22:09:24 -0400 (EDT) Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFD00JN1CNNRB@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 22:09:24 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19JOSi-000KH6-Tf; Fri, 23 May 2003 19:08:45 -0700 Date: Fri, 23 May 2003 19:08:44 -0700 From: Randy Bush Subject: Re: Liaisons interoperation with NOMCOM members To: Dave Crocker Cc: Scott Bradner , ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <200305231350.h4NDoLG4026072@newdev.harvard.edu> <12710106922.20030523131404@brandenburg.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: it should be obvious by the kind tone of the message that it was a forgery. > on the offchance that I am the 'dave' you are referring to, I tried to > figure out what your posting referred to. It certainly did not refer to > the thread it occurred in, since no dave or john had yet posted. > > so, Randy, please clarify. > > d/ > > RB> btw, i think both dave and john think they are being constructive > RB> and are acting with good intent. i just don't think that is the > RB> result. > > RB> randy > > > RB> ---------------------------------------------------------------- > RB> To subscribe or unsubscribe from this elist use the subscription > RB> manager: > > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > From ietf-nomcom-errors@lists.elistx.com Fri May 23 22:45:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00304DX9P2@eListX.com> (original mail from dhc@dcrocker.net); Fri, 23 May 2003 22:36:45 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00301DX8P0@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 22:36:44 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00301DX7OZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 22:36:43 -0400 (EDT) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFD0031EDX61W@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 22:36:42 -0400 (EDT) Received: from adsl-67-126-140-113.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4O2ZjN13137; Fri, 23 May 2003 19:35:45 -0700 Date: Fri, 23 May 2003 19:35:49 -0700 From: Dave Crocker Subject: Re: Liaisons interoperation with NOMCOM members In-reply-to: To: Randy Bush Cc: ietf-nomcom@lists.elistx.com Reply-to: Dave Crocker Message-id: <6433012239.20030523193549@brandenburg.com> Organization: Brandenburg InternetWorking MIME-version: 1.0 X-Mailer: The Bat! (v1.63 Beta/4) Personal Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: <200305231350.h4NDoLG4026072@newdev.harvard.edu> <12710106922.20030523131404@brandenburg.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Randy, alas, from the received headers, this means that your system, psg.com, has been compromised. i guess that would explain a number of different postings purporting to be from you, recently, that did indeed have a more even-handed tone than usual. d/ RB> it should be obvious by the kind tone of the message that it was RB> a forgery. >> on the offchance that I am the 'dave' you are referring to, I tried to >> figure out what your posting referred to. It certainly did not refer to >> the thread it occurred in, since no dave or john had yet posted. >> >> so, Randy, please clarify. >> >> d/ >> >> RB> btw, i think both dave and john think they are being constructive >> RB> and are acting with good intent. i just don't think that is the >> RB> result. >> >> RB> randy >> >> >> RB> ---------------------------------------------------------------- >> RB> To subscribe or unsubscribe from this elist use the subscription >> RB> manager: >> >> >> >> d/ >> -- >> Dave Crocker >> Brandenburg InternetWorking >> Sunnyvale, CA USA , >> RB> ---------------------------------------------------------------- RB> To subscribe or unsubscribe from this elist use the subscription RB> manager: d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From ietf-nomcom-errors@lists.elistx.com Fri May 23 22:45:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00304E9NVO@eListX.com> (original mail from randy@psg.com); Fri, 23 May 2003 22:44:11 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00301E9NVM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 22:44:11 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00301E9MVL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 22:44:10 -0400 (EDT) Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFD0032VE9L1W@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 22:44:09 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19JP0O-00044o-0z; Fri, 23 May 2003 19:43:32 -0700 Date: Fri, 23 May 2003 19:43:31 -0700 From: Randy Bush Subject: Re: Liaisons interoperation with NOMCOM members To: Dave Crocker Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <200305231350.h4NDoLG4026072@newdev.harvard.edu> <12710106922.20030523131404@brandenburg.com> <6433012239.20030523193549@brandenburg.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: as i think even charlie agreed, security is indeed an important issue for today's internet. randy > alas, from the received headers, this means that your system, psg.com, > has been compromised. > > i guess that would explain a number of different postings purporting to > be from you, recently, that did indeed have a more even-handed tone than > usual. > > d/ > > RB> it should be obvious by the kind tone of the message that it was > RB> a forgery. > > >> on the offchance that I am the 'dave' you are referring to, I tried to > >> figure out what your posting referred to. It certainly did not refer to > >> the thread it occurred in, since no dave or john had yet posted. > >> > >> so, Randy, please clarify. > >> > >> d/ > >> > >> RB> btw, i think both dave and john think they are being constructive > >> RB> and are acting with good intent. i just don't think that is the > >> RB> result. > >> > >> RB> randy > >> > >> > >> RB> ---------------------------------------------------------------- > >> RB> To subscribe or unsubscribe from this elist use the subscription > >> RB> manager: > >> > >> > >> > >> d/ > >> -- > >> Dave Crocker > >> Brandenburg InternetWorking > >> Sunnyvale, CA USA , > >> > > > RB> ---------------------------------------------------------------- > RB> To subscribe or unsubscribe from this elist use the subscription > RB> manager: > > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > From ietf-nomcom-errors@lists.elistx.com Fri May 23 22:45:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00304EA4WP@eListX.com> (original mail from dee3@torque.pothole.com) ; Fri, 23 May 2003 22:44:28 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00301EA3WN@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 22:44:27 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00301EA2WM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 22:44:26 -0400 (EDT) Received: from zydeco.netbusters.com (zydeco.netbusters.com [66.92.86.178]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFD0032YEA11W@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 22:44:26 -0400 (EDT) Received: by zydeco.netbusters.com (Postfix, from userid 513) id 5AA63B6430; Sat, 24 May 2003 02:43:48 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id 595327EC1E for ; Fri, 23 May 2003 22:43:48 -0400 (EDT) Date: Fri, 23 May 2003 22:43:48 -0400 (EDT) From: Donald Eastlake 3rd Subject: RE: Liaisons interoperation with NOMCOM members In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B04284569@tayexc13.americas.cpqcorp.net> X-X-Sender: dee3@zydeco.netbusters.com To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Fri, 23 May 2003, Bound, Jim wrote: > Date: Fri, 23 May 2003 14:40:51 -0400 > From: "Bound, Jim" > To: Joel M. Halpern , ietf-nomcom@lists.elistx.com > Subject: RE: Liaisons interoperation with NOMCOM members > > The NOMCOM can need at times an entity without IESG and IAB involvement. > Having served on a NOMCOM the example I will use is when the NOMCOM > wants to discuss privately and confidentially the issues of keep or > replace IESG or IAB members to keep that NOMCOM private conversation > from everyone except the NOMCOM members. I can think of others but that I have never encoutered any problem, as a member of serveral NOMCOMs or chair of one, with Liaisons. Not only no undue influence on selections but even no problems when discussion touched on the the actual individual IAB or IESG member who is the Liaison. (Since how well the IAB or IESG members will work together is a NOMCOM consideration, there can be occasion to discuss whether a candidate would work well with someone who is a Liaison.) Liaisons are bound by NOMCOM confidentiality. The NOMCOM should expect, so as to get the maximum benefit from the Liaisons, that all its conversations to be with the Liaisons present except in VERY unusual circumstances. > is what I mean't by keeping the Government out of the voting booth. I > agree with Brian why they should be present. This also gives input to > the NOMCOM if an IESG or IAB member is participating to much in the > defense or denial of candidates or existing members to get them out of > the room because they really should not be doing that other than any > other IETF community member as input to the NOMCOM. Bottom line IESG or > IAB should not have any extra or more influence on the actual decision > than anyone else that NOMCOM will speak with in the community. This is nonsense. One of the reasons the IAB and IESG Liaison are present is so that their experience as to how the IAB and IESG actually operate can be called on. True, former members could provide some of that. But the Liaison has the most current view and because of that facet of their role they have and should have more influence on some NOMCOM decisions than the average community member. It is a bad move to change the rules to make it appear that exclusion of the Liaisons would in any way be an ordinary or normal thing. I see no reason to make it be at the discretion of the chair. But there is no harm is a brief section saying that they can be excluded under extraordinary circumstances by the NOMCOM committee. Donald > I think the proposed wording would fix this and very minor enhancement. > Then I am done here with my input on this one. > > Regards, > /jim > > > -----Original Message----- > > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > > Sent: Friday, May 23, 2003 1:29 PM > > To: ietf-nomcom@lists.elistx.com > > Subject: Re: Liaisons interoperation with NOMCOM members > > > > > > I disagree. I believe that many of the reasons for having > > the liaisons at > > all are impossible if they are excluded from most > > conversations. I do not believe that there is any damage from > > having the liaisons in the > > room. I find your analogy misleading. > > > > I have not significant objection to the alternative proposal > > of giving the > > chair explicit power to exclude the liaisons from selected > > discussions. > > > > Yours, > > Joel M. Halpern > > > > At 12:30 AM 5/23/2003 -0400, Bound, Jim wrote: > > >In the current document it is not clear totally to me that > > the Liaisons > > >should play a more limited role than currently stated, and > > this should > > >be the case. The IAB and IESG Liaisons should only be > > present during > > >NOMCOM deliberations when requested and should not be part of the > > >NOMCOM discourse, unless they are required for clarfication as > > >Liaisons. Having the Liaisons in the room with the NOMCOM is like > > >having the Government with you in the voting booth, which is > > not good. > > > > > >Thoughts? > > > > > >Regards, > > >/jim > > > > > >---------------------------------------------------------------- > > >To subscribe or unsubscribe from this elist use the subscription > > >manager: > > > > > > > > ---------------------------------------------------------------- > > 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 Fri May 23 23:15:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00404FNKWA@eListX.com> (original mail from Jim.Bound@hp.com); Fri, 23 May 2003 23:14:08 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00401FNJW8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 23:14:07 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00401FNJW7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 23:14:07 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFD0035NFNI1V@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 23:14:06 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2D8C9B939; Fri, 23 May 2003 23:13:29 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 23 May 2003 23:13:29 -0400 Date: Fri, 23 May 2003 23:13:28 -0400 From: "Bound, Jim" Subject: RE: Liaisons interoperation with NOMCOM members To: Donald Eastlake 3rd , ietf-nomcom@lists.elistx.com Message-id: <9C422444DE99BC46B3AD3C6EAFC9711B04284593@tayexc13.americas.cpqcorp.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Liaisons interoperation with NOMCOM members Thread-Index: AcMhnlRt1e9beAvnQVSHk4zJiXG87QAAvCuw content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 24 May 2003 03:13:29.0046 (UTC) FILETIME=[72C55760:01C321A2] Donald, I guess the view is how one views confidentiality. I have no comment= on my nomcom experience one way or the other it would be improper and it= is fine if we view it differently. > > The NOMCOM can need at times an entity without IESG and IAB=20 > > involvement. Having served on a NOMCOM the example I will=20 > use is when=20 > > the NOMCOM wants to discuss privately and confidentially=20 > the issues of=20 > > keep or replace IESG or IAB members to keep that NOMCOM private= =20 > > conversation from everyone except the NOMCOM members. I=20 > can think of=20 > > others but that >=20 > I have never encoutered any problem, as a member of serveral=20 > NOMCOMs or chair of one, with Liaisons. Not only no undue=20 > influence on selections but even no problems when discussion=20 > touched on the the actual individual IAB or IESG member who=20 > is the Liaison. (Since how well the IAB or IESG members will=20 > work together is a NOMCOM consideration, there can be=20 > occasion to discuss whether a candidate would work well with=20 > someone who is a Liaison.) Good to hear you have not. The point is that there is a potential fo= r "conflict of interest". The potential should be removed completely b= y the simple statement that the nomcom may ask Liaisons not be part of certain deliberations. This is prudent. >=20 > Liaisons are bound by NOMCOM confidentiality. The NOMCOM=20 > should expect, so as to get the maximum benefit from the=20 > Liaisons, that all its conversations to be with the Liaisons=20 > present except in VERY unusual circumstances. This is not the point at all so I will not respond. >=20 > > is what I mean't by keeping the Government out of the=20 > voting booth. I=20 > > agree with Brian why they should be present. This also=20 > gives input to=20 > > the NOMCOM if an IESG or IAB member is participating to much in t= he=20 > > defense or denial of candidates or existing members to get=20 > them out of=20 > > the room because they really should not be doing that other=20 > than any=20 > > other IETF community member as input to the NOMCOM. Bottom=20 > line IESG=20 > > or IAB should not have any extra or more influence on the actual= =20 > > decision than anyone else that NOMCOM will speak with in the=20 > > community. >=20 > This is nonsense. The above means nothing to me? No comment. > One of the reasons the IAB and IESG Liaison=20 > are present is so that their experience as to how the IAB and=20 > IESG actually operate can be called on. True, former members=20 > could provide some of that. But the Liaison has the most=20 > current view and because of that facet of their role they=20 > have and should have more influence on some NOMCOM decisions=20 > than the average community member. Brian convinced me that Liaisons should be present for the reasons yo= u state, and will take the high ground on that view. But, Liaisons cou= ld be present during deliberations when a Liaison opinion when not asked= in the heat of debate could sway a decision. That is a conflict of interest and we should have in our proceedings a statement to prevent that problem if it is deemed to be a potentail problem. >=20 > It is a bad move to change the rules to make it appear that=20 > exclusion of the Liaisons would in any way be an ordinary or=20 > normal thing. I see no reason to make it be at the discretion=20 > of the chair. But there is no harm is a brief section saying=20 > that they can be excluded under extraordinary circumstances=20 > by the NOMCOM committee. I don't care how it is said but only that there is a clause to ask th= em to leave the room under circumstances where there could be a conflict= of interest. And the text is very clear. Regards, /jim >=20 > Donald >=20 > > I think the proposed wording would fix this and very minor=20 > > enhancement. Then I am done here with my input on this one. > >=20 > > Regards, > > /jim > >=20 > > > -----Original Message----- > > > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > > > Sent: Friday, May 23, 2003 1:29 PM > > > To: ietf-nomcom@lists.elistx.com > > > Subject: Re: Liaisons interoperation with NOMCOM members > > >=20 > > >=20 > > > I disagree. I believe that many of the reasons for having > > > the liaisons at=20 > > > all are impossible if they are excluded from most=20 > > > conversations. I do not believe that there is any damage from= =20 > > > having the liaisons in the=20 > > > room. I find your analogy misleading. > > >=20 > > > I have not significant objection to the alternative proposal > > > of giving the=20 > > > chair explicit power to exclude the liaisons from selected=20 > > > discussions. > > >=20 > > > Yours, > > > Joel M. Halpern > > >=20 > > > At 12:30 AM 5/23/2003 -0400, Bound, Jim wrote: > > > >In the current document it is not clear totally to me that > > > the Liaisons > > > >should play a more limited role than currently stated, and > > > this should > > > >be the case. The IAB and IESG Liaisons should only be > > > present during > > > >NOMCOM deliberations when requested and should not be part of = the > > > >NOMCOM discourse, unless they are required for clarfication as= =20 > > > >Liaisons. Having the Liaisons in the room with the=20 > NOMCOM is like=20 > > > >having the Government with you in the voting booth, which is= =20 > > > not good. > > > > > > > >Thoughts? > > > > > > > >Regards, > > > >/jim > > > > > > > >--------------------------------------------------------------= -- > > > >To subscribe or unsubscribe from this elist use the subscripti= on > > > >manager: > > >=20 > > >=20 > > >=20 > > > ---------------------------------------------------------------= - > > > To subscribe or unsubscribe from this elist use the subscriptio= n > > > manager: > > >=20 > >=20 > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: > >=20 >=20 >=20 >=20 > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: >=20 From ietf-nomcom-errors@lists.elistx.com Fri May 23 23:25:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00504FYQ45@eListX.com> (original mail from avri@acm.org); Fri, 23 May 2003 23:20:50 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00501FYP43@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 23:20:49 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00501FYO42@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 23:20:48 -0400 (EDT) Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFD0036QFYN1V@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 23:20:48 -0400 (EDT) Received: from acm.org (IDENT:TaKmfBOEsLd0KoWxA5y34H7jvksi4UWp@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h4O3K7j19376; Fri, 23 May 2003 23:20:07 -0400 Date: Fri, 23 May 2003 22:19:56 -0500 From: Avri Doria Subject: Re: Current version? To: Michael StJohns Cc: ietf-nomcom@lists.elistx.com Message-id: <3ECEE4DC.3000905@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 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <3ECE1B83.1EDF5E25@hursley.ibm.com> <5.2.1.1.2.20030523110102.00b85e88@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I have been traveling and away from any computer lines for several days. I managed to find access and was greeted by your lovely wake-up call. I will read through the thread and respond. If an answer requires searching the archives, it may, be another 3 days before I can respond as my access is very limited and then I will be away from networks again for a few days. Mike, I apologize for taking a vacation and being away from my email for 3 days. a. Michael StJohns wrote: > Would the chair please wake up and comment on this thread. > > > At 09:13 5/23/2003, RJ Atkinson wrote: > > >> I support Brian and Mike, both in analysis of the problem and in >> their proposed fix. >> >> Regardless of how this item was lost/side-tracked last go around, >> it needs to get pulled back from never-never-land and added to the >> "Editor should change text" item list. >> >> IMHO, >> >> Ran >> >> >> On Friday, May 23, 2003, at 09:00 America/Montreal, Brian E Carpenter >> wrote: >> >>> Mike St J certainly convinced me that the text needed to be changed. >>> Just to refresh the argument, "consult" suggests a level of >>> interdependency >>> that isn't compatible either with the confirming body's independent >>> role or with the strict confidentiality of the Nomcom's discussions. >>> My proposed text describes fairly accurately what has actually >>> happened in my experience (8 years on one of the confirming bodies, >>> and 3 years on the other). >>> >>> Given that nobody disagreed with Mike and I on the list, once we >>> reached agreement, I would certainly challenge the statement that >>> there is no consensus for the change. >>> >>> Brian >> >> >> >> ---------------------------------------------------------------- >> To subscribe or unsubscribe from this elist use the subscription >> manager: > > > > From ietf-nomcom-errors@lists.elistx.com Fri May 23 23:35:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00504G61A8@eListX.com> (original mail from Jim.Bound@hp.com); Fri, 23 May 2003 23:25:13 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00501G60A6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 23:25:12 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00501G5ZA5@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 23 May 2003 23:25:11 -0400 (EDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFD0038TG5Y1W@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 23 May 2003 23:25:10 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 471087418; Fri, 23 May 2003 23:24:33 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 23 May 2003 23:24:33 -0400 Date: Fri, 23 May 2003 23:24:32 -0400 From: "Bound, Jim" Subject: RE: Liaisons interoperation with NOMCOM members To: Geoff Huston , "Joel M. Halpern" , ietf-nomcom@lists.elistx.com Message-id: <9C422444DE99BC46B3AD3C6EAFC9711B032412AC@tayexc13.americas.cpqcorp.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Liaisons interoperation with NOMCOM members Thread-Index: AcMhbxiAJTIxVzi9RxemxVfkoazZtQAM2GCg content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 24 May 2003 03:24:33.0151 (UTC) FILETIME=[FE9BB8F0:01C321A3] Geoff, > A liaison is neither a delegate nor a representative, and=20 > while I would be=20 > more > inclined to sympathize with your proposition if such were=20 > the case, given that the liaison role is one more akin to a=20 > constrained messenger, then I find your fears of collective=20 > interest being exercised upon the nomcom by the IESG or the=20 > IAB completely without foundation.=20 I don't have a foundation other than there is the potential for a conflict of interest if there is no way under any circumstances to remove the Liaisons from the room. Please don't read into the word remove it is a valid word, it is like accountability, fired, hired, e= tc. What I believe or feel or what you believe or feel is not relative. What the quesiton is objectively is there a potential for a conflict = of interest? I say there is? That is all nothing more or nothing less. >Given that I was chairing=20 > that Nomcom when you were a member, I can also offer the=20 > observation that I saw at no point in time the exercising of=20 > IESG influence on the Nomcom, nor IAB influence.. Having been=20 > an IAB liaison myself subsequently, again at no point in time=20 > were the duties of the liaison during the Nomcom's=20 > consideration period being called upon beyond the conveying=20 > of explicit queries generated by the Nomcom and their=20 > corresponding responses Again I will not comment on my experience other than there was bad an= d good, and room for improvement. And I think much has improved as a n= ote since that event. But this is not the point of my input. >=20 > I find it worrisome that there is this unfounded and growing=20 > level of mistrust being cast as an undercurrent in many of=20 > these considerations, where various bodies are being cast in=20 > a role of potential conspirators, and that their influence=20 > should be countered through the provision of explicit rules=20 > and provisions. What worries me is that when you start to=20 > create the frameworks and mechanisms to counter such possible=20 > problems you also start to create an environment of mutual=20 > distrust, and that is a place I'm sure noone wants to head. Well I assume this is rhetorical comment and not to me from what I se= nt to Nomcom. Rhetorically in response I can say at a high level I trust= no authority completely ahywhwere, and believe it wise to remove all conflict of interest in such bodies whenever possible. I am making a suggestion to remove a potential. If you would like to hear my perso= nal views of the IETF process be glad to do this with you over a beer or = ice tea, but not part of this process, I do not see the added value to th= is conversation. >=20 > At every point in the Nomcom processes there is a point where=20 > rules and documented process must give way to community trust=20 > in good judgement, as exercised by the chair, as exercised by=20 > the members, and as exercised by the liaisons. For that=20 > reason I see this particular area (participation of liaisons=20 > in the Nomcom) as being one where explicit provisions are=20 > going to find it hard to achieve the necessary balance, while=20 > the judgement of the nomcom itself appears to me to have been=20 > entirely appropriate to date. What has been done is not known because it cannot be fully disclosed. If someone had done something dishonorable you would have no right to even discuss it here. That is the good thing about the NOMCOM deliberations. =20 THere is the potential for conflict of interest. Period. =20 Regards, /jim >=20 > regards, >=20 > Geoff >=20 > At 02:40 PM 23/05/2003 -0400, Bound, Jim wrote: > >The NOMCOM can need at times an entity without IESG and IAB=20 > >involvement. Having served on a NOMCOM the example I will=20 > use is when=20 > >the NOMCOM wants to discuss privately and confidentially the=20 > issues of=20 > >keep or replace IESG or IAB members to keep that NOMCOM private= =20 > >conversation from everyone except the NOMCOM members. I can=20 > think of=20 > >others but that is what I mean't by keeping the Government=20 > out of the=20 > >voting booth. I agree with Brian why they should be present. Thi= s=20 > >also gives input to the NOMCOM if an IESG or IAB member is=20 > >participating to much in the defense or denial of candidates or= =20 > >existing members to get them out of the room because they=20 > really should=20 > >not be doing that other than any other IETF community member=20 > as input=20 > >to the NOMCOM. Bottom line IESG or IAB should not have any extra = or=20 > >more influence on the actual decision than anyone else that=20 > NOMCOM will=20 > >speak with in the community. > > > >I think the proposed wording would fix this and very minor=20 > enhancement.=20 > >Then I am done here with my input on this one. > > > >Regards, > >/jim > > > > > -----Original Message----- > > > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > > > Sent: Friday, May 23, 2003 1:29 PM > > > To: ietf-nomcom@lists.elistx.com > > > Subject: Re: Liaisons interoperation with NOMCOM members > > > > > > > > > I disagree. I believe that many of the reasons for having the= =20 > > > liaisons at all are impossible if they are excluded from most > > > conversations. I do not believe that there is any damage from > > > having the liaisons in the > > > room. I find your analogy misleading. > > > > > > I have not significant objection to the alternative proposal of= =20 > > > giving the chair explicit power to exclude the liaisons from= =20 > > > selected discussions. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 12:30 AM 5/23/2003 -0400, Bound, Jim wrote: > > > >In the current document it is not clear totally to me that > > > the Liaisons > > > >should play a more limited role than currently stated, and > > > this should > > > >be the case. The IAB and IESG Liaisons should only be > > > present during > > > >NOMCOM deliberations when requested and should not be=20 > part of the=20 > > > >NOMCOM discourse, unless they are required for clarfication as= =20 > > > >Liaisons. Having the Liaisons in the room with the=20 > NOMCOM is like=20 > > > >having the Government with you in the voting booth, which is > > > not good. > > > > > > > >Thoughts? > > > > > > > >Regards, > > > >/jim > > > > > > > >--------------------------------------------------------------= -- > > > >To subscribe or unsubscribe from this elist use the subscripti= on > > > >manager: > > > > > > > > > > > > ---------------------------------------------------------------= - > > > To subscribe or unsubscribe from this elist use the subscriptio= n > > > manager: > > > > > > >---------------------------------------------------------------- > >To subscribe or unsubscribe from this elist use the subscription > >manager: >=20 >=20 >=20 >=20 From ietf-nomcom-errors@lists.elistx.com Sat May 24 00:15:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00604IG0L9@eListX.com> (original mail from avri@acm.org); Sat, 24 May 2003 00:14:24 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00601IFZL1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 24 May 2003 00:14:23 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFD00601IFYKZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 24 May 2003 00:14:22 -0400 (EDT) Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFD003DPIFX1V@eListX.com>; Sat, 24 May 2003 00:14:22 -0400 (EDT) Received: from acm.org (IDENT:FlAP/F9pOgfl5APpT0NyldRjKCydvj85@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h4O4Dij22911; Sat, 24 May 2003 00:13:44 -0400 Date: Fri, 23 May 2003 23:13:33 -0500 From: Avri Doria Subject: Re: Current version? To: ietf-nomcom@lists.elistx.com Cc: Michael StJohns , James M Galvin Message-id: <3ECEF16D.5000803@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 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <511525194.1053615628@localhost> <511525194.1053615628@localhost> <5.2.1.1.2.20030522120526.03077100@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: As far as I can tell the discussion of this did fall through the cracks. There was this suggestion of some language and then the public discussion stopped. Perhaps this counts as a consensus of 2, now 3, because of silence of the majority. At this point, given the importance of this specification, as opposed to just accepting that, I would like people on this list to look at this proposed change and to voice their opinions on it. Should silence persist, then I will have to declare the language as consensus language. As I said previously, I will be away from the network for another few days. a. Michael StJohns wrote: > Jim - > > The May 8th version of this didn't address the comments and discussion > about > > >>The confirming bodies review >>their respective candidates and, >> in >>consultation with the nominating committee, consent to >> some, all, >>or none of the >>candidates. >> > > > The CBs have their own roles and MUST NOT be overly influenced by the > Nomcom. So "in consultation with" needs to go. > > Brian proposed some alternate text which I can live with: > >> If not all the candidates submitted to a confirming body are >> rapidly confirmed, the confirming body continues to communicate >> with the nominating committee both to understand the committee's >> rationale for the slate and, if appropriate, to explain the reason >> why all the candidates were not confirmed. >> >> 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. > > From ietf-nomcom-errors@lists.elistx.com Sat May 24 15:35:10 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFE00704OTK9Y@eListX.com> (original mail from dhc@dcrocker.net); Sat, 24 May 2003 15:29:44 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFE00701OTJ9W@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 24 May 2003 15:29:43 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFE00701OTI9V@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 24 May 2003 15:29:42 -0400 (EDT) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFE000IROTH5B@eListX.com> for ietf-nomcom@lists.elistx.com; Sat, 24 May 2003 15:29:42 -0400 (EDT) Received: from ppp-67-126-240-86.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4OJHKN13823; Sat, 24 May 2003 12:18:56 -0700 Date: Sat, 24 May 2003 12:16:25 -0700 From: Dave Crocker Subject: Re: Liaisons interoperation with NOMCOM members In-reply-to: To: Donald Eastlake 3rd Cc: ietf-nomcom@lists.elistx.com Reply-to: Dave Crocker Message-id: <1149132358.20030524121625@brandenburg.com> Organization: Brandenburg InternetWorking MIME-version: 1.0 X-Mailer: The Bat! (v1.63 Beta/4) Personal Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Donald, DE3> I have never encoutered any problem, as a member of serveral NOMCOMs or DE3> chair of one, with Liaisons. Whereas others (yes, including me) *have* encountered some problems. And the really interesting part about the problems is that they flowed from some very natural situations in which everybody was working hard at being helpful. In other words, this is not about nefarious intent and it is not even about liaisons who are personally problematic. It is about the potential for distorting the process with nothing but the best of intentions. Liaisons inherently have an extremely large amount of power. They are the experts. They are the folks doing the job of running the IETF. They deserve the respect the rest of the committee gives them. But liaisons who are too active in the process will naturally convert "respect" to become "deference". And anything that causes Nomcom members to defer to the Liaisons spells the end of the independence that is essential in the Nomcom process. When we have a Nomcom that is substantially laced with highly experienced IETF people, there is at least a counterbalancing force. The influence of Liaisons can still be at least distracting, but at least it is mitigated. When the Nomcom is notably less experienced, the influence has nothing moderating it. A Nomcom process needs to be pristine. Having Liaisons who participate in candidate and community interviews, who participate actively in the direct Nomcom deliberations and who take partisan positions for or against various candidates is simply not appropriate. >> Bottom line IESG or >> IAB should not have any extra or more influence on the actual decision >> than anyone else that NOMCOM will speak with in the community. DE3> This is nonsense. And therein lies the core issue. Should the IESG and IAB have more leverage than the rest of the community, when choosing folks to work on the IAB or IESG? My own view is that it is nonsense to think that the needs and desires of the rest of the community are less important. DE3> One of the reasons the IAB and IESG Liaison are DE3> present is so that their experience as to how the IAB and IESG actually DE3> operate can be called on. That's a reporting job. Not a lobbying job. It is about information, not "influence." d/ ps. Personally I'm not particularly concerned about the Liaisons' presence as much as their activity. -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From ietf-nomcom-errors@lists.elistx.com Sat May 24 17:05:36 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFE00904T5LRK@eListX.com> (original mail from dhc@dcrocker.net); Sat, 24 May 2003 17:03:21 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFE00901T5LRI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 24 May 2003 17:03:21 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFE00901T5KRH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 24 May 2003 17:03:20 -0400 (EDT) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFE0079TT5J9U@eListX.com> for ietf-nomcom@lists.elistx.com; Sat, 24 May 2003 17:03:19 -0400 (EDT) Received: from ppp-67-126-240-86.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4OL2GN23877; Sat, 24 May 2003 14:02:16 -0700 Date: Sat, 24 May 2003 14:02:31 -0700 From: Dave Crocker Subject: Re: Liaisons interoperation with NOMCOM members In-reply-to: To: Randy Bush Cc: ietf-nomcom@lists.elistx.com Reply-to: Dave Crocker Message-id: <7555497871.20030524140231@brandenburg.com> Organization: Brandenburg InternetWorking MIME-version: 1.0 X-Mailer: The Bat! (v1.63 Beta/4) Personal Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: <200305231350.h4NDoLG4026072@newdev.harvard.edu> <12710106922.20030523131404@brandenburg.com> <6433012239.20030523193549@brandenburg.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Randy, RB> as i think even charlie agreed, security is indeed an important issue RB> for today's internet. Yet another, wonderfully clever unresponsive response. Gosh you're good at them. However, since your original posting was in fact *not* a forgery, it means that an area director has made a public statement that a couple of contributors are having a destructive effect. Your position carries an obligation to do more than simply make such pronouncements. You have an obligation to explain them. On the natural assumption that you, yourself, have constructive intent, then please engage in forthcoming dialogue, rather than just launching such public criticisms and then trying to dodge the consequences. d/ >> alas, from the received headers, this means that your system, psg.com, >> has been compromised. >> >> i guess that would explain a number of different postings purporting to >> be from you, recently, that did indeed have a more even-handed tone than >> usual. >> >> d/ >> >> RB> it should be obvious by the kind tone of the message that it was >> RB> a forgery. >> >> >> on the offchance that I am the 'dave' you are referring to, I tried to >> >> figure out what your posting referred to. It certainly did not refer to >> >> the thread it occurred in, since no dave or john had yet posted. >> >> >> >> so, Randy, please clarify. >> >> >> >> d/ >> >> >> >> RB> btw, i think both dave and john think they are being constructive >> >> RB> and are acting with good intent. i just don't think that is the >> >> RB> result. >> >> >> >> RB> randy >> >> >> >> >> >> RB> >> ---------------------------------------------------------------- >> >> RB> To subscribe or unsubscribe from this elist use the subscription >> >> RB> manager: >> >> >> >> >> >> >> >> d/ >> >> -- >> >> Dave Crocker >> >> Brandenburg InternetWorking >> >> Sunnyvale, CA USA , >> >> >> >> >> RB> ---------------------------------------------------------------- >> RB> To subscribe or unsubscribe from this elist use the subscription >> RB> manager: >> >> >> >> d/ >> -- >> Dave Crocker >> Brandenburg InternetWorking >> Sunnyvale, CA USA , >> RB> ---------------------------------------------------------------- RB> To subscribe or unsubscribe from this elist use the subscription RB> manager: d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From ietf-nomcom-errors@lists.elistx.com Sat May 24 20:25:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFF00E04277OW@eListX.com> (original mail from harald@alvestrand.no); Sat, 24 May 2003 20:18:43 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFF00E01276OU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 24 May 2003 20:18:42 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFF00E01275OT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 24 May 2003 20:18:41 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFF009M927437@eListX.com> for ietf-nomcom@lists.elistx.com; Sat, 24 May 2003 20:18:41 -0400 (EDT) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 13CB5623F9; Sun, 25 May 2003 02:18:02 +0200 (CEST) Date: Sun, 25 May 2003 02:18:02 +0200 From: Harald Tveit Alvestrand Subject: Re: Alternative (H2) In-reply-to: <39ACE8A8-8D21-11D7-87EA-00039357A82A@extremenetworks.com> To: RJ Atkinson , ietf-nomcom@lists.elistx.com Message-id: <23630000.1053821882@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: <39ACE8A8-8D21-11D7-87EA-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I have no problems with this version. --On fredag, mai 23, 2003 09:19:47 -0400 RJ Atkinson wrote: > -------------------------------------------------------------------- > Delete the existing text in section 4, and replace with this: > > 4. The confirming body decides whether it confirms each candidate > using a confirmation decision rule chosen by the confirming body. > > If a confirming body has no specific confirmation decision rule, > then confirming a given candidate should require at least one-half > of the Confirming Body's sitting members to agree to that > confirmation. > > The decision may be made by conducting a formal vote, by asserting > consensus based on informal exchanges (e.g. email), or by any > other mechanism that is used to conduct the normal business > of the confirming body. > > Regardless of which decision rule the confirming body uses, any > candidate that is not confirmed under that rule must be rejected. > > The confirming body must make its decision within a reasonable > timeframe. The results from the confirming body must be reported > promptly to the nominating committee. > ------------------------------------------------------------------------ From ietf-nomcom-errors@lists.elistx.com Sat May 24 20:35:11 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFF00E042TGZF@eListX.com> (original mail from harald@alvestrand.no); Sat, 24 May 2003 20:32:04 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFF00E012TFZ6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 24 May 2003 20:32:03 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFF00E012TEZ4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 24 May 2003 20:32:02 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFF009NK2TD37@eListX.com> for ietf-nomcom@lists.elistx.com; Sat, 24 May 2003 20:32:02 -0400 (EDT) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 583E9621FA; Sun, 25 May 2003 02:31:23 +0200 (CEST) Date: Sun, 25 May 2003 02:31:23 +0200 From: Harald Tveit Alvestrand Subject: Re: Current version? In-reply-to: <5.2.1.1.2.20030522120526.03077100@pop.mindspring.com> To: Michael StJohns , James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <26740000.1053822683@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: <511525194.1053615628@localhost> <511525194.1053615628@localhost> <5.2.1.1.2.20030522120526.03077100@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Since Avri asked, and speaking only for myself: I'm not so worried about influence between bodies as Mike is, but I believe the process will function well under Brian's proposed text. So count me as mildly supportive (55/45) of the change. Harald --On torsdag, mai 22, 2003 12:27:41 -0400 Michael StJohns wrote: > Jim - > > The May 8th version of this didn't address the comments and discussion > about > > > > > The confirming bodies review > their respective candidates and, > in > consultation with the nominating committee, consent to > some, all, > or none of the > candidates. > > > > The CBs have their own roles and MUST NOT be overly influenced by the > Nomcom. So "in consultation with" needs to go. > > Brian proposed some alternate text which I can live with: > > > If not all the candidates submitted to a confirming body are > rapidly confirmed, the confirming body continues to communicate > with the nominating committee both to understand the committee's > rationale for the slate and, if appropriate, to explain the reason > why all the candidates were not confirmed. > > 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. > > From ietf-nomcom-errors@lists.elistx.com Sun May 25 18:25:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFG00704RKJ80@eListX.com> (original mail from dee3@torque.pothole.com) ; Sun, 25 May 2003 18:24:19 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFG00701RKH7V@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sun, 25 May 2003 18:24:18 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFG00701RKH7U@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sun, 25 May 2003 18:24:17 -0400 (EDT) Received: from zydeco.netbusters.com (zydeco.netbusters.com [66.92.86.178]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFG0056ZRKGM6@eListX.com> for ietf-nomcom@lists.elistx.com; Sun, 25 May 2003 18:24:16 -0400 (EDT) Received: by zydeco.netbusters.com (Postfix, from userid 513) id 59898B63E3; Sun, 25 May 2003 22:23:37 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id 564787EC1F for ; Sun, 25 May 2003 18:23:37 -0400 (EDT) Date: Sun, 25 May 2003 18:23:37 -0400 (EDT) From: Donald Eastlake 3rd Subject: Re: Liaisons interoperation with NOMCOM members In-reply-to: <1149132358.20030524121625@brandenburg.com> X-X-Sender: dee3@zydeco.netbusters.com To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Dave, On Sat, 24 May 2003, Dave Crocker wrote: > Date: Sat, 24 May 2003 12:16:25 -0700 > From: Dave Crocker > Reply-To: Dave Crocker > To: Donald Eastlake 3rd > Cc: ietf-nomcom@lists.elistx.com > Subject: Re: Liaisons interoperation with NOMCOM members > > Donald, > > DE3> I have never encoutered any problem, as a member of serveral NOMCOMs or > DE3> chair of one, with Liaisons. > > Whereas others (yes, including me) *have* encountered some problems. > > And the really interesting part about the problems is that they flowed > from some very natural situations in which everybody was working hard at > being helpful. > > In other words, this is not about nefarious intent and it is not even > about liaisons who are personally problematic. > > It is about the potential for distorting the process with nothing but > the best of intentions. I never said anything about "nefarious intent". If something is a distortion is a value judgement. > Liaisons inherently have an extremely large amount of power. They are > the experts. They are the folks doing the job of running the IETF. They > deserve the respect the rest of the committee gives them. Power? Liaisons have less official "power" than voting nomcom member in that they can't even vote on candidates. They might or might not have more influence, depending on the other members of the nomcom. > But liaisons who are too active in the process will naturally convert > "respect" to become "deference". And anything that causes Nomcom members > to defer to the Liaisons spells the end of the independence that is > essential in the Nomcom process. "Deference" or "resentment". The nomcom process is not and never was intended to be an isolated independent exercise is some dream world. The nomcom is supposed to do its best to reflect the IETF community including the IAB and IESG. > When we have a Nomcom that is substantially laced with highly > experienced IETF people, there is at least a counterbalancing force. The > influence of Liaisons can still be at least distracting, but at least it > is mitigated. > > When the Nomcom is notably less experienced, the influence has nothing > moderating it. Let's see here. The Liaisons are fine if there is an the nomcom that has other experienced members. But if the nomcom has, due to some fluke, nothing but inexperienced members (and, presumably, an ineffective chair), then it is better for the nomcom to flounder in inexperience and ignorance and make inexperineced and ignorant choices than, under those circumstances, for the Liaisons to have more influence than they might have with an experience nomcom. That's an interesting point of view but I don't agree. > A Nomcom process needs to be pristine. I consider the above statement to be essentially content free. All real world organizational structure decisions are compromises with good and bad aspects. The only selection process I would consider "pristine" would be one that was completely random and or had only purely object criterial. But this would produce a poor IAB and IESG. A good part of the job of IAB and IESG members is interpersonal relations and there is no way for their selection to, as practical matter, be other than subjective. > Having Liaisons who participate in candidate and community interviews, > who participate actively in the direct Nomcom deliberations and who take > partisan positions for or against various candidates is simply not > appropriate. It's up to the nomcom whether Liaisons do interviews on behalf of the nomcom and report back. I tend to agree that they shouldn't but I don't see a need for a rule here. As for participating in deliberations and taking a position, it's up to the other members and, primarily, the chair to see that things are handled in a balanced fashion. And note that I never said Liaiaon's couldn't be excluded from some nomcom activities. Just that I think that should only be done under extraordinary circumstances. > >> Bottom line IESG or > >> IAB should not have any extra or more influence on the actual decision > >> than anyone else that NOMCOM will speak with in the community. > > DE3> This is nonsense. > > And therein lies the core issue. Should the IESG and IAB have more > leverage than the rest of the community, when choosing folks to work on > the IAB or IESG? > > My own view is that it is nonsense to think that the needs and desires > of the rest of the community are less important. What I meant to say was that I would certainly expect a Liaison to have more influence than the average member of the IETF community. More than the *average member*, not more than the entire rest of the IETF community. > DE3> One of the reasons the IAB and IESG Liaison are > DE3> present is so that their experience as to how the IAB and IESG actually > DE3> operate can be called on. > > That's a reporting job. Not a lobbying job. It's entirely possible for something to be discussed in the nomcom for which input about IAB/IESG procedures/experience would be useful without the nomcom realizing this. The Liaisons should be present, except under very unusual circumstances, and should be able to speak up. If a Liaison is really perceived as a problem, there has always been a procedure whereby the nomcom can kick someone out of the nomcom, including the Liaisons, forcing the body they are form to pick a new Liaison. Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com > It is about information, not "influence." > > d/ > > ps. Personally I'm not particularly concerned about the Liaisons' > presence as much as their activity. From ietf-nomcom-errors@lists.elistx.com Sun May 25 18:35:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFG00704RSXFM@eListX.com> (original mail from dhc@dcrocker.net); Sun, 25 May 2003 18:29:21 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFG00701RSWFK@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sun, 25 May 2003 18:29:20 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFG00701RSWFJ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sun, 25 May 2003 18:29:20 -0400 (EDT) Received: from joy.songbird.com (songbird.com [208.184.79.7]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFG0061IRSVVA@eListX.com> for ietf-nomcom@lists.elistx.com; Sun, 25 May 2003 18:29:19 -0400 (EDT) Received: from bbprime (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4PMSKN14847; Sun, 25 May 2003 15:28:20 -0700 Date: Sun, 25 May 2003 12:01:28 -0700 From: Dave Crocker Subject: Re: Current version? In-reply-to: <26740000.1053822683@askvoll.hjemme.alvestrand.no> To: Harald Tveit Alvestrand Cc: ietf-nomcom@lists.elistx.com Reply-to: Dave Crocker Message-id: <476361477.20030525120128@brandenburg.com> Organization: Brandenburg InternetWorking MIME-version: 1.0 X-Mailer: The Bat! (v1.63 Beta/4) Personal Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: <511525194.1053615628@localhost> <511525194.1053615628@localhost> <5.2.1.1.2.20030522120526.03077100@pop.mindspring.com> <26740000.1053822683@askvoll.hjemme.alvestrand.no> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Harald, HTA> I'm not so worried about influence between bodies as Mike is, but I believe HTA> the process will function well under Brian's proposed text. HTA> So count me as mildly supportive (55/45) of the change. Sometimes, a confirming body could cite an alternative candidate, by way of trying to highlight some distinctions, concerns, or the like about a current candidate. In a perfect world, that style of communication would be fine. However it really is too easy for the CB to decide that it knows of a better candidate and, essentially, to try to preempt the nomcom. This is of course done with the best of intentions, but it serves to negate the long and complicated process that a nomcom goes through. So we have one of those rare occasions in which Harald and I agree on something: this is a yeah for the proposed change. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From ietf-nomcom-errors@lists.elistx.com Mon May 26 04:05:27 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFH00104IAM7O@eListX.com> (original mail from harald@alvestrand.no); Mon, 26 May 2003 04:01:34 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFH00101IAK7K@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 26 May 2003 04:01:33 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFH00101IAJ7J@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 26 May 2003 04:01:31 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFH00IFUIAICI@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 26 May 2003 04:01:31 -0400 (EDT) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB56E625B6; Mon, 26 May 2003 10:00:51 +0200 (CEST) Date: Mon, 26 May 2003 10:00:51 +0200 From: Harald Tveit Alvestrand Subject: Re: Liaisons interoperation with NOMCOM members In-reply-to: To: Donald Eastlake 3rd , ietf-nomcom@lists.elistx.com Message-id: <85190000.1053936051@askvoll.hjemme.alvestrand.no> MIME-version: 1.0 X-Mailer: Mulberry/2.2.1 (Linux/x86) Content-type: text/plain; format=flowed; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: inline References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On s=F8ndag, mai 25, 2003 18:23:37 -0400 Donald Eastlake 3rd=20 wrote: >> Having Liaisons who participate in candidate and community intervi= ews, >> who participate actively in the direct Nomcom deliberations and wh= o take >> partisan positions for or against various candidates is simply not >> appropriate. > > It's up to the nomcom whether Liaisons do interviews on behalf of t= he > nomcom and report back. I tend to agree that they shouldn't but I d= on't > see a need for a rule here. As for participating in deliberations a= nd > taking a position, it's up to the other members and, primarily, the > chair to see that things are handled in a balanced fashion. on the one nomcom I've participated in as a liaison from the IESG, I= =20 objected to being asked to do candidate interviews - because I believ= ed it=20 was proper for the voting members of the nomcom to get that informati= on=20 directly, not via the liaison. This argument was accepted by the nomcom at that time. I guess it has= =20 become part of the folklore since. (note - the record at http://www.ietf.org/NomCom.html needs to be che= cked=20 by someone whose memory is better than mine..... I can't find that= =20 nomcom.... and I'm pretty sure the nomcom listed as "1995-1996" is th= e one=20 that selected me for Apps AD back in 1995..... odd numbering....) Harald From ietf-nomcom-errors@lists.elistx.com Mon May 26 19:05:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFI00504NWXGM@eListX.com> (original mail from Jim.Bound@hp.com); Mon, 26 May 2003 19:00:33 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFI00501NWWGK@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 26 May 2003 19:00:32 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFI00501NWVGJ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 26 May 2003 19:00:31 -0400 (EDT) Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFI00160NWVAG@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 26 May 2003 19:00:31 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id A043666C; Mon, 26 May 2003 18:59:52 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 26 May 2003 18:59:52 -0400 Date: Mon, 26 May 2003 18:59:51 -0400 From: "Bound, Jim" Subject: RE: Liaisons interoperation with NOMCOM members To: Donald Eastlake 3rd , ietf-nomcom@lists.elistx.com Message-id: <9C422444DE99BC46B3AD3C6EAFC9711B042845B9@tayexc13.americas.cpqcorp.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Liaisons interoperation with NOMCOM members Thread-Index: AcMjDFU72Hinv97HTk6QHgJTL7KETwAzZQhg content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 26 May 2003 22:59:52.0493 (UTC) FILETIME=[843CDDD0:01C323DA] Donald, If two voting nomcom members are discussing a candidate and the merit= s of that candidate to be selected by that nomcom as input to IETF nomc= om process, should a Liaison participate in the discussion about that candidate pro or con? I emphatically believe that if the Liaison does and was not asked to participate that is a conflict of interest? The issue is would the simple text Brian suggested give recourse to prevent this problem from happening. Example. From situtation above. Chair of Nomcom states: Dear, Liaisons we are about to engage in a debate on the specific candidate= s and we feel your presence here is not required for this dicussion and would like to do this just with the voting members. What is wrong with the above? /jim From ietf-nomcom-errors@lists.elistx.com Mon May 26 23:15:22 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFI00E04ZOIPK@eListX.com> (original mail from dee3@torque.pothole.com) ; Mon, 26 May 2003 23:14:42 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFI00E01ZOHPI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 26 May 2003 23:14:41 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFI00E01ZOGPH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 26 May 2003 23:14:41 -0400 (EDT) Received: from zydeco.netbusters.com (zydeco.netbusters.com [66.92.86.178]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFI001LUZOGAE@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 26 May 2003 23:14:40 -0400 (EDT) Received: by zydeco.netbusters.com (Postfix, from userid 513) id 3E2C6B6414; Tue, 27 May 2003 03:14:01 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id 3D0017EC1C for ; Mon, 26 May 2003 23:14:01 -0400 (EDT) Date: Mon, 26 May 2003 23:14:01 -0400 (EDT) From: Donald Eastlake 3rd Subject: RE: Liaisons interoperation with NOMCOM members In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B042845B9@tayexc13.americas.cpqcorp.net> X-X-Sender: dee3@zydeco.netbusters.com To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Hi Jim, On Mon, 26 May 2003, Bound, Jim wrote: > Date: Mon, 26 May 2003 18:59:51 -0400 > From: "Bound, Jim" > To: Donald Eastlake 3rd , > ietf-nomcom@lists.elistx.com > Subject: RE: Liaisons interoperation with NOMCOM members > > Donald, > > If two voting nomcom members are discussing a candidate and the merits > of that candidate to be selected by that nomcom as input to IETF nomcom > process, should a Liaison participate in the discussion about that > candidate pro or con? I would say rarely. I don't recall any of the liaisons doing what I would generally call "participating in discussion" in the sense of arguing much. But quite likely at some time one of them said something like, when it seemed that candidate X was going to be on the short list or the like, "I think X and IESG member Y with whom they will have to work have had some difficulties about Z. You should consider asking each of them about this." or something like that. > I emphatically believe that if the Liaison does and was not asked to > participate that is a conflict of interest? Pffah. All you need to do is crank your conflict-of-interest sensitivity up high enough and you can paralyze any organization. I was meaning to reply to that effect to your other message wherin your go on and on about "potential conflict of interest". Everyone in the IETF has potential conflicts of interest. They may have company or academic commitment to certain ideas or protocols. Why do we let authors make comments in discussion about their very own drafts? Isn't that a clear conflict of interest? Etc. Etc. What about potential CONGRUITY of interest? How about the theory that Liaisons most probably want the IAB and IESG and the nomcom and IETF to work well and produce good results? > The issue is would the simple text Brian suggested give recourse to > prevent this problem from happening. I don't like Brian's wording for two reasons: Because the exclusion of a Liaison should be an extraordinary step while someone could read his wording to mean you can do it anytime you like on a whim, and because it makes it at the discretion of the chair while I think it should be a nomcom decision. > Example. From situtation above. Chair of Nomcom states: Dear, > Liaisons we are about to engage in a debate on the specific candidates > and we feel your presence here is not required for this dicussion and > would like to do this just with the voting members. > > What is wrong with the above? If it's really true that "we" don't want the Liaisons, the nomcom can vote to exclude them under the current draft or, indeed, vote to expell them if there was a chronic problem. If it's not true that "we" don't want the Liaisons, then the chair is lying. Suppose your suggested exclusion happens. In the discussion, a member of the nomcom says "The IESG consists of technical geniuses. I'm sure they make all of their decisions in a purely logical fashion, probably using the first order predicate calculus. Candidate X is a real whiz at logic as well as being the world expert on facet Q of routing. True, candidate X only speaks Aramaic and doesn't seem to have any charisma, but since the IESG is a techncial body, I'm sure they are the best candidate." Wouldn't it be OK for the IESG Liaison to butt in and point out that, while technical competance is required, the bulk of the job an every AD is interpersonal relations? That the IESG actually doesn't decide everything using the first order predicate calculus? > /jim Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com From ietf-nomcom-errors@lists.elistx.com Tue May 27 01:25:28 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00I045MPKO@eListX.com> (original mail from Jim.Bound@hp.com); Tue, 27 May 2003 01:23:13 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00I015MOKM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 01:23:12 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00I015MNKL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 01:23:11 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFJ00GAS5MN5L@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 27 May 2003 01:23:11 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8E919B5A3; Tue, 27 May 2003 01:22:31 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Tue, 27 May 2003 01:22:31 -0400 Date: Tue, 27 May 2003 01:22:30 -0400 From: "Bound, Jim" Subject: RE: Liaisons interoperation with NOMCOM members To: Donald Eastlake 3rd , ietf-nomcom@lists.elistx.com Message-id: <9C422444DE99BC46B3AD3C6EAFC9711B032412B5@tayexc13.americas.cpqcorp.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Liaisons interoperation with NOMCOM members Thread-Index: AcMj/hd37XnmqBWOSsm5meJZHG0w1gAEI6XA content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 27 May 2003 05:22:31.0390 (UTC) FILETIME=[F8CE87E0:01C3240F] Hi Donald, I think I see where we differ. I can see CONGRUITY of course. I don't want to trust or not trust the Liaisons to do the right or wr= ong thing. I just want the clause that gives the NOMCOM options and for them to understand why those options are there. Of course we can as community members always send mail with input to the NOMCOM we don't trust the Liaisons, and I have never done that.=20 I also feel that in the IETF it is harder to remove an IESG or IAB member that it is to remove a congressman or senator in the governmen= t I live with in the world I live in today. I feel the IETF is run like= an academic institution and that is not going to work anymore is my gut feeling. We cannot overhaul the entire process but we can put checks and balances in and the proposed text by Brian in fact does that. I would like to hear more arguments that state this can be done as opposed to we can trust them? The proposed wording would not be used unless it was needed and if it is needed then so be it. Don't forget I am compromising here. I don't want the IESG or IAB members even on the or near the NOMCOM and believe all interaction wi= th them should be Q and A. If I fight this in the greater community tha= t will be my posture and suggestion for IETF wide discussion. I think if this WG can do a simple thing like Brian suggested it shou= ld cover the issue and I rest my case. But if not then it requires much more discussion and a bunch of related threads within the area of conflict of Interest. /jim=20 > -----Original Message----- > From: Donald Eastlake 3rd [mailto:dee3@torque.pothole.com]=20 > Sent: Monday, May 26, 2003 11:14 PM > To: ietf-nomcom@lists.elistx.com > Subject: RE: Liaisons interoperation with NOMCOM members >=20 >=20 > Hi Jim, >=20 > On Mon, 26 May 2003, Bound, Jim wrote: >=20 > > Date: Mon, 26 May 2003 18:59:51 -0400 > > From: "Bound, Jim" > > To: Donald Eastlake 3rd , > > ietf-nomcom@lists.elistx.com > > Subject: RE: Liaisons interoperation with NOMCOM members > >=20 > > Donald, > >=20 > > If two voting nomcom members are discussing a candidate and=20 > the merits=20 > > of that candidate to be selected by that nomcom as input to IETF= =20 > > nomcom process, should a Liaison participate in the=20 > discussion about=20 > > that candidate pro or con? >=20 > I would say rarely. I don't recall any of the liaisons doing=20 > what I would generally call "participating in discussion" in=20 > the sense of arguing much. But quite likely at some time one=20 > of them said something like, when it seemed that candidate X=20 > was going to be on the short list or the like, "I think X and=20 > IESG member Y with whom they will have to work have had some=20 > difficulties about Z. You should consider asking each of them=20 > about this." or something like that. >=20 > > I emphatically believe that if the Liaison does and was not=20 > asked to=20 > > participate that is a conflict of interest? >=20 > Pffah. All you need to do is crank your conflict-of-interest=20 > sensitivity up high enough and you can paralyze any=20 > organization. I was meaning to reply to that effect to your=20 > other message wherin your go on and on about "potential=20 > conflict of interest". Everyone in the IETF has potential=20 > conflicts of interest. They may have company or academic=20 > commitment to certain ideas or protocols. Why do we let=20 > authors make comments in discussion about their very own=20 > drafts? Isn't that a clear conflict of interest? Etc. Etc. >=20 > What about potential CONGRUITY of interest? How about the theory th= at=20 > Liaisons most probably want the IAB and IESG and the nomcom=20 > and IETF to=20 > work well and produce good results? >=20 > > The issue is would the simple text Brian suggested give recourse = to=20 > > prevent this problem from happening. >=20 > I don't like Brian's wording for two reasons: Because the=20 > exclusion of a Liaison should be an extraordinary step while=20 > someone could read his wording to mean you can do it anytime=20 > you like on a whim, and because it makes it at the discretion=20 > of the chair while I think it should be a nomcom decision. >=20 > > Example. From situtation above. Chair of Nomcom states: Dear,= =20 > > Liaisons we are about to engage in a debate on the specific=20 > candidates=20 > > and we feel your presence here is not required for this=20 > dicussion and=20 > > would like to do this just with the voting members. > > > > What is wrong with the above? >=20 > If it's really true that "we" don't want the Liaisons, the=20 > nomcom can vote to exclude them under the current draft or,=20 > indeed, vote to expell them if there was a chronic problem.=20 > If it's not true that "we" don't want the Liaisons, then the=20 > chair is lying. >=20 > Suppose your suggested exclusion happens. In the discussion,=20 > a member of the nomcom says "The IESG consists of technical=20 > geniuses. I'm sure they make all of their decisions in a=20 > purely logical fashion, probably using the first order=20 > predicate calculus. Candidate X is a real whiz at logic as=20 > well as being the world expert on facet Q of routing. True,=20 > candidate X only speaks Aramaic and doesn't seem to have any=20 > charisma, but since the IESG is a techncial body, I'm sure=20 > they are the best candidate." =20 > Wouldn't it be OK for the IESG Liaison to butt in and point=20 > out that, while technical competance is required, the bulk of=20 > the job an every AD is interpersonal relations? That the IESG=20 > actually doesn't decide everything using the first order=20 > predicate calculus? >=20 > > /jim >=20 > Thanks, > Donald=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd dee3@torque.pothole.c= om > 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(= w) > Milford, MA 01757 USA Donald.Eastlake@motorola.c= om >=20 >=20 >=20 > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: >=20 From ietf-nomcom-errors@lists.elistx.com Tue May 27 02:15:24 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00K047ZW1N@eListX.com> (original mail from harald@alvestrand.no); Tue, 27 May 2003 02:14:20 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00K017ZV1L@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 02:14:19 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00K017ZU1K@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 02:14:18 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFJ00GE17ZQHU@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 27 May 2003 02:14:18 -0400 (EDT) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7798D625AB; Tue, 27 May 2003 08:13:34 +0200 (CEST) Date: Tue, 27 May 2003 08:13:37 +0200 From: Harald Tveit Alvestrand Subject: RE: Liaisons interoperation with NOMCOM members In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B032412B5@tayexc13.americas.cpqcorp.net> To: "Bound, Jim" , ietf-nomcom@lists.elistx.com Message-id: <43990000.1054016017@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: <9C422444DE99BC46B3AD3C6EAFC9711B032412B5@tayexc13.americas.cpqcorp.net> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On tirsdag, mai 27, 2003 01:22:30 -0400 "Bound, Jim" wrote: > I also feel that in the IETF it is harder to remove an IESG or IAB > member that it is to remove a congressman or senator in the government formally, it's far easier, but unlike with Congressmen, nobody's ever seriously tried.... this may either tell you something about how many bad Congressmen there are versus IESG/IAB members, or how many enemies Congressmen have compared to IESG/IAB members.... Harald From ietf-nomcom-errors@lists.elistx.com Tue May 27 02:55:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00L049JP58@eListX.com> (original mail from dhc@dcrocker.net); Tue, 27 May 2003 02:47:49 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00L019JP56@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 02:47:49 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00L019JO55@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 02:47:48 -0400 (EDT) Received: from clint.songbird.com (budgetdesign-graphics.com [208.184.79.11]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFJ00GO19JN5L@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 27 May 2003 02:47:47 -0400 (EDT) Received: from bbprime (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by clint.songbird.com (8.11.6/8.11.6) with ESMTP id h4R6nmi17275; Mon, 26 May 2003 23:49:48 -0700 Date: Mon, 26 May 2003 23:47:02 -0700 From: Dave Crocker Subject: Re: Liaisons interoperation with NOMCOM members In-reply-to: To: Donald Eastlake 3rd Cc: ietf-nomcom@lists.elistx.com Reply-to: Dave Crocker Message-id: <1119398713.20030526234702@brandenburg.com> Organization: Brandenburg InternetWorking MIME-version: 1.0 X-Mailer: The Bat! (v1.63 Beta/6) Personal Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Donald, >> process, should a Liaison participate in the discussion about that >> candidate pro or con? DE3> I would say rarely. I don't recall any of the liaisons doing what I DE3> would generally call "participating in discussion" in the sense of DE3> arguing much. I do. In fact they were rather vigorous. >> I emphatically believe that if the Liaison does and was not asked to >> participate that is a conflict of interest? DE3> Pffah. All you need to do is crank your conflict-of-interest sensitivity DE3> up high enough and you can paralyze any organization. and that's almost as fun as the effect on the organization of cranking it too low. DE3> What about potential CONGRUITY of interest? How about the theory that DE3> Liaisons most probably want the IAB and IESG and the nomcom and IETF to DE3> work well and produce good results? oh. you mean that besides being dedicated and well-intentioned, such folk wouldn't *also* rather have people selected who they liked, who agreed with them, and who would make their own job of AD or IAB participant easier, such as a personal friend? And if, by some extraordinary chance a liaison did want those additional things, you believe their ability to affect the outcome in that direction would not be a conflict of interest? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From ietf-nomcom-errors@lists.elistx.com Tue May 27 08:05:13 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00604NWDUJ@eListX.com> (original mail from brian@hursley.ibm.com) ; Tue, 27 May 2003 07:57:50 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00601NWDUH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 07:57:49 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00601NWCUG@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 07:57:48 -0400 (EDT) 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 <0HFJ003EANWARW@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 27 May 2003 07:57:47 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4R9IKXA079264 for ; Tue, 27 May 2003 13:56:51 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4R7wm4A133318 for ; Tue, 27 May 2003 09:58:49 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29036 from ; Tue, 27 May 2003 09:58:47 +0200 Date: Tue, 27 May 2003 09:59:14 +0200 From: Brian E Carpenter Subject: Re: Liaisons interoperation with NOMCOM members To: ietf-nomcom@lists.elistx.com Message-id: <3ED31AD2.7578A113@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: <1119398713.20030526234702@brandenburg.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Dave Crocker wrote: ... > DE3> What about potential CONGRUITY of interest? How about the theory that > DE3> Liaisons most probably want the IAB and IESG and the nomcom and IETF to > DE3> work well and produce good results? > > oh. > > you mean that besides being dedicated and well-intentioned, such folk > wouldn't *also* rather have people selected who they liked, who agreed > with them, and who would make their own job of AD or IAB participant > easier, such as a personal friend? And if, by some extraordinary chance > a liaison did want those additional things, you believe their ability to > affect the outcome in that direction would not be a conflict of > interest? We are not, I assume, trying to construct some form of perfect democracy here. We are trying to construct an IAB and IESG that can work smoothly as an extended team. I don't object to existing working relationships and friendships being a factor in selecting the team, among all the other factors. Conflict of interest is inevitable. The issue is not to avoid it, but how to ensure checks and balances to prevent unfairness. Brian From ietf-nomcom-errors@lists.elistx.com Tue May 27 09:15:15 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00904RD2R0@eListX.com> (original mail from rja@extremenetworks.com) ; Tue, 27 May 2003 09:12:39 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00901RD2QY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 09:12:38 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFJ00901RD1QX@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 09:12:37 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFJ004NLRD0HW@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 27 May 2003 09:12:36 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id B34D567103; Tue, 27 May 2003 09:39:46 -0400 (EDT) Date: Tue, 27 May 2003 09:11:51 -0400 From: RJ Atkinson Subject: Re: Current version? In-reply-to: <476361477.20030525120128@brandenburg.com> To: Dave Crocker Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Sunday, May 25, 2003, at 15:01 America/Montreal, Dave Crocker wrote: > Sometimes, a confirming body could cite an alternative candidate, by > way > of trying to highlight some distinctions, concerns, or the like about a > current candidate. In a perfect world, that style of communication > would be fine. > > However it really is too easy for the CB to decide that it knows of a > better candidate and, essentially, to try to preempt the nomcom. This > is > of course done with the best of intentions, but it serves to negate the > long and complicated process that a nomcom goes through. Alternately, the Nomcom might justify picking candidate X on grounds that no other candidates existed, rather than on the basis that X was qualified for the position on the merits. That would be equally inappropriate -- and equally precluded by the new wording. Sounds like this fix helps a number of things. Ran From ietf-nomcom-errors@lists.elistx.com Tue May 27 14:05:24 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFK002044MWKO@eListX.com> (original mail from jwkckid1@ix.netcom.com) ; Tue, 27 May 2003 13:59:20 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFK002014MVKM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 13:59:20 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFK002014MVKL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 13:59:19 -0400 (EDT) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFK0003F4MUSY@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 27 May 2003 13:59:18 -0400 (EDT) Received: from dialup-67.30.21.228.dial1.dallas1.level3.net ([67.30.21.228] helo=ix.netcom.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 19Kiib-0002Sr-00; Tue, 27 May 2003 13:58:38 -0400 Date: Tue, 27 May 2003 12:56:13 -0700 From: Jeff Williams Subject: Re: Liaisons interoperation with NOMCOM members To: Brian E Carpenter Cc: ietf-nomcom@lists.elistx.com Message-id: <3ED3C2DC.887C3DC@ix.netcom.com> Organization: INEGroup Spokesman MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <1119398713.20030526234702@brandenburg.com> <3ED31AD2.7578A113@hursley.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Brian and all, Brian E Carpenter wrote: > Dave Crocker wrote: > ... > > DE3> What about potential CONGRUITY of interest? How about the theory that > > DE3> Liaisons most probably want the IAB and IESG and the nomcom and IETF to > > DE3> work well and produce good results? > > > > oh. > > > > you mean that besides being dedicated and well-intentioned, such folk > > wouldn't *also* rather have people selected who they liked, who agreed > > with them, and who would make their own job of AD or IAB participant > > easier, such as a personal friend? And if, by some extraordinary chance > > a liaison did want those additional things, you believe their ability to > > affect the outcome in that direction would not be a conflict of > > interest? > > We are not, I assume, trying to construct some form of perfect > democracy here. We are trying to construct an IAB and IESG that > can work smoothly as an extended team. > > I don't object to existing working relationships and friendships > being a factor in selecting the team, among all the other factors. Relationships, maybe, friendships as a factor, not a good idea. > > > Conflict of interest is inevitable. The issue is not to avoid it, > but how to ensure checks and balances to prevent unfairness. I don't agree that COI cannot be eliminated or at least reduced dramatically. In fact, if not directly addressed, COI will become almost immediately a limiting factor in effectiveness. > > > Brian > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard ================================================================ CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From ietf-nomcom-errors@lists.elistx.com Tue May 27 22:25:14 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFK00004RO6OS@eListX.com> (original mail from dee3@torque.pothole.com) ; Tue, 27 May 2003 22:16:54 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFK00001RO5OQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 22:16:53 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFK00001RO5OP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 27 May 2003 22:16:53 -0400 (EDT) Received: from zydeco.netbusters.com (zydeco.netbusters.com [66.92.86.178]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFK00EC5RO4ZB@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 27 May 2003 22:16:52 -0400 (EDT) Received: by zydeco.netbusters.com (Postfix, from userid 513) id 29C1BB63CB; Wed, 28 May 2003 02:16:12 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id 285997EC1E for ; Tue, 27 May 2003 22:16:12 -0400 (EDT) Date: Tue, 27 May 2003 22:16:12 -0400 (EDT) From: Donald Eastlake 3rd Subject: RE: Liaisons interoperation with NOMCOM members In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B032412B5@tayexc13.americas.cpqcorp.net> X-X-Sender: dee3@zydeco.netbusters.com To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Hi Jim, On Tue, 27 May 2003, Bound, Jim wrote: > Date: Tue, 27 May 2003 01:22:30 -0400 > From: "Bound, Jim" > To: Donald Eastlake 3rd , > ietf-nomcom@lists.elistx.com > Subject: RE: Liaisons interoperation with NOMCOM members > > Hi Donald, > > I think I see where we differ. I can see CONGRUITY of course. > > I don't want to trust or not trust the Liaisons to do the right or wrong > thing. I just want the clause that gives the NOMCOM options and for > them to understand why those options are there. Of course we can as > community members always send mail with input to the NOMCOM we don't > trust the Liaisons, and I have never done that. Well, we seem to be just arguing about the wording. The nomcom has options now. Adding a sentence about this to make it more obvious is fine with me. But I can't see why you want it to be at the whim of the nomcom chair. Since you don't have much trust of the Liaisons, why do you trust the chair? > I also feel that in the IETF it is harder to remove an IESG or IAB > member that it is to remove a congressman or senator in the government I > live with in the world I live in today. I feel the IETF is run like an > academic institution and that is not going to work anymore is my gut > feeling. We cannot overhaul the entire process but we can put checks > and balances in and the proposed text by Brian in fact does that. Opinions differ on such things. Many feel the businesses are becoming too dominent in the IETF. > I would like to hear more arguments that state this can be done as > opposed to we can trust them? The proposed wording would not be used > unless it was needed and if it is needed then so be it. Again, I'm puzzled as to why you want this "need" to be determined by the chair rather than nomcom voting members. Thanks, Donald > Don't forget I am compromising here. I don't want the IESG or IAB > members even on the or near the NOMCOM and believe all interaction with > them should be Q and A. If I fight this in the greater community that > will be my posture and suggestion for IETF wide discussion. > I think if this WG can do a simple thing like Brian suggested it should > cover the issue and I rest my case. But if not then it requires much > more discussion and a bunch of related threads within the area of > conflict of Interest. > > /jim > > > -----Original Message----- > > From: Donald Eastlake 3rd [mailto:dee3@torque.pothole.com] > > Sent: Monday, May 26, 2003 11:14 PM > > To: ietf-nomcom@lists.elistx.com > > Subject: RE: Liaisons interoperation with NOMCOM members > > > > > > Hi Jim, > > > > On Mon, 26 May 2003, Bound, Jim wrote: > > > > > Date: Mon, 26 May 2003 18:59:51 -0400 > > > From: "Bound, Jim" > > > To: Donald Eastlake 3rd , > > > ietf-nomcom@lists.elistx.com > > > Subject: RE: Liaisons interoperation with NOMCOM members > > > > > > Donald, > > > > > > If two voting nomcom members are discussing a candidate and > > the merits > > > of that candidate to be selected by that nomcom as input to IETF > > > nomcom process, should a Liaison participate in the > > discussion about > > > that candidate pro or con? > > > > I would say rarely. I don't recall any of the liaisons doing > > what I would generally call "participating in discussion" in > > the sense of arguing much. But quite likely at some time one > > of them said something like, when it seemed that candidate X > > was going to be on the short list or the like, "I think X and > > IESG member Y with whom they will have to work have had some > > difficulties about Z. You should consider asking each of them > > about this." or something like that. > > > > > I emphatically believe that if the Liaison does and was not > > asked to > > > participate that is a conflict of interest? > > > > Pffah. All you need to do is crank your conflict-of-interest > > sensitivity up high enough and you can paralyze any > > organization. I was meaning to reply to that effect to your > > other message wherin your go on and on about "potential > > conflict of interest". Everyone in the IETF has potential > > conflicts of interest. They may have company or academic > > commitment to certain ideas or protocols. Why do we let > > authors make comments in discussion about their very own > > drafts? Isn't that a clear conflict of interest? Etc. Etc. > > > > What about potential CONGRUITY of interest? How about the theory that > > Liaisons most probably want the IAB and IESG and the nomcom > > and IETF to > > work well and produce good results? > > > > > The issue is would the simple text Brian suggested give recourse to > > > prevent this problem from happening. > > > > I don't like Brian's wording for two reasons: Because the > > exclusion of a Liaison should be an extraordinary step while > > someone could read his wording to mean you can do it anytime > > you like on a whim, and because it makes it at the discretion > > of the chair while I think it should be a nomcom decision. > > > > > Example. From situtation above. Chair of Nomcom states: Dear, > > > Liaisons we are about to engage in a debate on the specific > > candidates > > > and we feel your presence here is not required for this > > dicussion and > > > would like to do this just with the voting members. > > > > > > What is wrong with the above? > > > > If it's really true that "we" don't want the Liaisons, the > > nomcom can vote to exclude them under the current draft or, > > indeed, vote to expell them if there was a chronic problem. > > If it's not true that "we" don't want the Liaisons, then the > > chair is lying. > > > > Suppose your suggested exclusion happens. In the discussion, > > a member of the nomcom says "The IESG consists of technical > > geniuses. I'm sure they make all of their decisions in a > > purely logical fashion, probably using the first order > > predicate calculus. Candidate X is a real whiz at logic as > > well as being the world expert on facet Q of routing. True, > > candidate X only speaks Aramaic and doesn't seem to have any > > charisma, but since the IESG is a techncial body, I'm sure > > they are the best candidate." > > Wouldn't it be OK for the IESG Liaison to butt in and point > > out that, while technical competance is required, the bulk of > > the job an every AD is interpersonal relations? That the IESG > > actually doesn't decide everything using the first order > > predicate calculus? > > > > > /jim > > > > Thanks, > > Donald > > ====================================================================== > > Donald E. Eastlake 3rd dee3@torque.pothole.com > > 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) > > Milford, MA 01757 USA Donald.Eastlake@motorola.com > > > > > > > > ---------------------------------------------------------------- > > 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 Wed May 28 00:45:26 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFK00504Y7NRK@eListX.com> (original mail from Jim.Bound@hp.com); Wed, 28 May 2003 00:38:11 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFK00501Y7MRI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 28 May 2003 00:38:10 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFK00501Y7LRH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 28 May 2003 00:38:09 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFK00ENFY7KZ0@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 28 May 2003 00:38:09 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 81CD7BEDD; Wed, 28 May 2003 00:37:28 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 28 May 2003 00:37:28 -0400 Date: Wed, 28 May 2003 00:37:27 -0400 From: "Bound, Jim" Subject: RE: Liaisons interoperation with NOMCOM members To: Donald Eastlake 3rd , ietf-nomcom@lists.elistx.com Message-id: <9C422444DE99BC46B3AD3C6EAFC9711B04284608@tayexc13.americas.cpqcorp.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Liaisons interoperation with NOMCOM members Thread-Index: AcMkv1wbbRNForFVQluafLp7bHi5sQAEVbHg content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 28 May 2003 04:37:28.0359 (UTC) FILETIME=[D8167B70:01C324D2] Donald, Error Return-code not NULL. Not sure how it happened I do not state = how this is done nor have opinion it should be chair. I believe that is upto the WG and those consistently participating in this exercise. M= y reason for being here is to bring the issue and stay here till it is done or not done and leave, or just leave out of frustration vs cost = of my time. So it sounds correct to me it is the nomcom body that does this not the chair. And I don't even think it will be used hopefully ever. But, if it is needed we gave the NOMCOM this in those extreme circumstances as you put it and that on our part is quite prudent. On IETF more like business. I don't think so. The one business principle I am trying to get the community to see is the issue of time-to-market. This is not my turf I come here to build standards o= r make sure ones I know will have the best chance of correct implementation. My turf is else where and it is in industry and much different game. The IETF is not perceived today as open, able to keep= up in the 21st century as a standards body, holds up technology, and tha= t is my view of what I hear. But that is just me. When we are done wi= th this discussion I will leave and it pains me as much to hear that whi= ch is counter to all my views as it is for many here to hear my views. So lets just make a decision and move on one way or the other if that= is possible. Unless I get a direct question I have nothing else to say or defend a= t this point. Not to Donald .................... P.S. and for some don't come up to me in the IETF and tell me "Jim I really thought what you said was right to let you know or it was wron= g" Please I won't respect you and I might vomit on you. I respect those more who completely disagree with me and discuss it, and have the ner= ve to speak up and defend their point of view publicly. Thats the IETFe= rs I respect even if I completely disagree with them. Regards, /jim Regards, /jim > -----Original Message----- > From: Donald Eastlake 3rd [mailto:dee3@torque.pothole.com] > Sent: Tuesday, May 27, 2003 10:16 PM > To: ietf-nomcom@lists.elistx.com > Subject: RE: Liaisons interoperation with NOMCOM members >=20 >=20 > Hi Jim, >=20 > On Tue, 27 May 2003, Bound, Jim wrote: >=20 > > Date: Tue, 27 May 2003 01:22:30 -0400 > > From: "Bound, Jim" > > To: Donald Eastlake 3rd , > > ietf-nomcom@lists.elistx.com > > Subject: RE: Liaisons interoperation with NOMCOM members > >=20 > > Hi Donald, > >=20 > > I think I see where we differ. I can see CONGRUITY of course. > >=20 > > I don't want to trust or not trust the Liaisons to do the right o= r > > wrong thing. I just want the clause that gives the NOMCOM=20 > options and > > for them to understand why those options are there. Of > course we can > > as community members always send mail with input to the NOMCOM we > > don't trust the Liaisons, and I have never done that. >=20 > Well, we seem to be just arguing about the wording. The > nomcom has options now. Adding a sentence about this to make=20 > it more obvious is fine with me. But I can't see why you want=20 > it to be at the whim of the nomcom chair. Since you don't=20 > have much trust of the Liaisons, why do you trust the chair? >=20 > > I also feel that in the IETF it is harder to remove an IESG or IA= B > > member that it is to remove a congressman or senator in the=20 > government I > > live with in the world I live in today. I feel the IETF=20 > is run like an > > academic institution and that is not going to work anymore > is my gut > > feeling. We cannot overhaul the entire process but we can > put checks > > and balances in and the proposed text by Brian in fact does that. >=20 > Opinions differ on such things. Many feel the businesses are > becoming too dominent in the IETF. >=20 > > I would like to hear more arguments that state this can be done a= s > > opposed to we can trust them? The proposed wording would=20 > not be used > > unless it was needed and if it is needed then so be it. >=20 > Again, I'm puzzled as to why you want this "need" to be determined = by > the chair rather than nomcom voting members. >=20 > Thanks, > Donald >=20 > > Don't forget I am compromising here. I don't want the IESG or IA= B > > members even on the or near the NOMCOM and believe all interactio= n=20 > > with them should be Q and A. If I fight this in the=20 > greater community > > that will be my posture and suggestion for IETF wide discussion. = I > > think if this WG can do a simple thing like Brian suggested=20 > it should > > cover the issue and I rest my case. But if not then it > requires much > > more discussion and a bunch of related threads within the area of > > conflict of Interest. > >=20 > > /jim > >=20 > > > -----Original Message----- > > > From: Donald Eastlake 3rd [mailto:dee3@torque.pothole.com] > > > Sent: Monday, May 26, 2003 11:14 PM > > > To: ietf-nomcom@lists.elistx.com > > > Subject: RE: Liaisons interoperation with NOMCOM members > > >=20 > > >=20 > > > Hi Jim, > > >=20 > > > On Mon, 26 May 2003, Bound, Jim wrote: > > >=20 > > > > Date: Mon, 26 May 2003 18:59:51 -0400 > > > > From: "Bound, Jim" > > > > To: Donald Eastlake 3rd , > > > > ietf-nomcom@lists.elistx.com > > > > Subject: RE: Liaisons interoperation with NOMCOM members > > > >=20 > > > > Donald, > > > >=20 > > > > If two voting nomcom members are discussing a candidate and > > > the merits > > > > of that candidate to be selected by that nomcom as input to I= ETF > > > > nomcom process, should a Liaison participate in the > > > discussion about > > > > that candidate pro or con? > > >=20 > > > I would say rarely. I don't recall any of the liaisons doing wh= at=20 > > > I would generally call "participating in discussion" in the sen= se=20 > > > of arguing much. But quite likely at some time one of them sai= d=20 > > > something like, when it seemed that candidate X was going to be= on > > > the short list or the like, "I think X and IESG member Y with w= hom > > > they will have to work have had some difficulties about Z. You= =20 > > > should consider asking each of them about this." or something l= ike > > > that. > > >=20 > > > > I emphatically believe that if the Liaison does and was not > > > asked to > > > > participate that is a conflict of interest? > > >=20 > > > Pffah. All you need to do is crank your conflict-of-interest= =20 > > > sensitivity up high enough and you can paralyze any organizatio= n.=20 > > > I was meaning to reply to that effect to your other message whe= rin > > > your go on and on about "potential conflict of interest". Every= one > > > in the IETF has potential conflicts of interest. They may have= =20 > > > company or academic commitment to certain ideas or protocols. W= hy=20 > > > do we let authors make comments in discussion about their very = own > > > drafts? Isn't that a clear conflict of interest? Etc. Etc. > > >=20 > > > What about potential CONGRUITY of interest? How about the theor= y > > > that > > > Liaisons most probably want the IAB and IESG and the nomcom= =20 > > > and IETF to=20 > > > work well and produce good results? > > >=20 > > > > The issue is would the simple text Brian suggested give > recourse > > > > to > > > > prevent this problem from happening. > > >=20 > > > I don't like Brian's wording for two reasons: Because the=20 > > > exclusion of a Liaison should be an extraordinary step while= =20 > > > someone could read his wording to mean you can do it anytime yo= u=20 > > > like on a whim, and because it makes it at the discretion of th= e=20 > > > chair while I think it should be a nomcom decision. > > >=20 > > > > Example. From situtation above. Chair of Nomcom states: De= ar, > > > > Liaisons we are about to engage in a debate on the specific > > > candidates > > > > and we feel your presence here is not required for this > > > dicussion and > > > > would like to do this just with the voting members. > > > > > > > > What is wrong with the above? > > >=20 > > > If it's really true that "we" don't want the Liaisons, the nomc= om=20 > > > can vote to exclude them under the current draft or, indeed, vo= te=20 > > > to expell them if there was a chronic problem. If it's not true= =20 > > > that "we" don't want the Liaisons, then the chair is lying. > > >=20 > > > Suppose your suggested exclusion happens. In the discussion, a= =20 > > > member of the nomcom says "The IESG consists of technical=20 > > > geniuses. I'm sure they make all of their decisions in a purely= =20 > > > logical fashion, probably using the first order predicate=20 > > > calculus. Candidate X is a real whiz at logic as well as being = the > > > world expert on facet Q of routing. True, candidate X only spea= ks=20 > > > Aramaic and doesn't seem to have any charisma, but since the IE= SG=20 > > > is a techncial body, I'm sure they are the best candidate." > > > Wouldn't it be OK for the IESG Liaison to butt in and point= =20 > > > out that, while technical competance is required, the bulk of= =20 > > > the job an every AD is interpersonal relations? That the IESG= =20 > > > actually doesn't decide everything using the first order=20 > > > predicate calculus? > > >=20 > > > > /jim > > >=20 > > > Thanks, > > > Donald > > >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > Donald E. Eastlake 3rd =20 > dee3@torque.pothole.com > > > 155 Beaver Street +1-508-634-2066(h)=20 > +1-508-851-8280(w) > > > Milford, MA 01757 USA =20 > Donald.Eastlake@motorola.com > > >=20 > > >=20 > > >=20 > > > ---------------------------------------------------------------= - > > > To subscribe or unsubscribe from this elist use the subscriptio= n > > > manager: > > >=20 > >=20 > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: > >=20 >=20 >=20 > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: >=20 From ietf-nomcom-errors@lists.elistx.com Fri May 30 02:15:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFO00304RMSRC@eListX.com> (original mail from kre@munnari.OZ.AU); Fri, 30 May 2003 02:06:28 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFO00301RMQR7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 30 May 2003 02:06:27 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFO00301RMOR3@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 30 May 2003 02:06:24 -0400 (EDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFO0019YRMJHJ@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 30 May 2003 02:06:23 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4U65XP07463; Fri, 30 May 2003 13:05:33 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4U5rGE08313; Fri, 30 May 2003 12:53:20 +0700 (ICT) Date: Fri, 30 May 2003 12:53:15 +0700 From: Robert Elz Subject: Re: Alternative (H2) In-reply-to: <23630000.1053821882@askvoll.hjemme.alvestrand.no> To: Harald Tveit Alvestrand Cc: RJ Atkinson , ietf-nomcom@lists.elistx.com Message-id: <8311.1054273995@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <23630000.1053821882@askvoll.hjemme.alvestrand.no> <39ACE8A8-8D21-11D7-87EA-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Sun, 25 May 2003 02:18:02 +0200 From: Harald Tveit Alvestrand Message-ID: <23630000.1053821882@askvoll.hjemme.alvestrand.no> | I have no problems with this version. | | --On fredag, mai 23, 2003 09:19:47 -0400 RJ Atkinson | wrote: | | > -------------------------------------------------------------------- | > Delete the existing text in section 4, and replace with this: | > | > 4. The confirming body decides whether it confirms each candidate | > using a confirmation decision rule chosen by the confirming body. | > | > If a confirming body has no specific confirmation decision rule, | > then confirming a given candidate should require at least one-half | > of the Confirming Body's sitting members to agree to that | > confirmation. | > | > The decision may be made by conducting a formal vote, by asserting | > consensus based on informal exchanges (e.g. email), or by any | > other mechanism that is used to conduct the normal business | > of the confirming body. | > | > Regardless of which decision rule the confirming body uses, any | > candidate that is not confirmed under that rule must be rejected. | > | > The confirming body must make its decision within a reasonable | > timeframe. The results from the confirming body must be reported | > promptly to the nominating committee. | > ------------------------------------------------------------------------ I haven't had time to read this list for ages, and am just catching up. I think I have read all of this thread - and I think you're all attempting to solve the wrong problem. That is, Ran says that the IAB has deadlocked (the IAB's nature must have changed a lot since I was there...) and that that poses a problem for the nomcom. Fine - that should be fixed. But the proposed solution is to start (even in this mild form) to tell the confirming body how it should make its decision? That's absurd. It is only getting even slight credence because the confirming body everyone is concentrating on is the IAB, and everyone feels like they have the right to tell the IAB how it should function (and perhaps they do - but that's part of the IAB charter revision/approval process, not the nomcom process). Christian pointed out how insane this is for the ISOC, the other confirming body. But take it one step further - assume that (sometime in some distant future perhaps - however unlikely it seems) that the confirming body was to be General Motors - are we proposing to tell them how they make a decision? Or to make it even more clear, say the confirming body was to be the US state department - would we be suggesting to them that they should hold a vote (of whom?) to make a decision. This is all simply wrong. We ask the conforming body to make a decision. If they say yes (as a body) or no (as a body) then that's fine, that's what we asked for. It matters to us not even slightly what method they used to make that decision. If they say nothing, no matter what the reason, we cannot, as a solution for that attempt to force an answer from them. Rather we need a fallback decision should the conforming body not make one, as no matter how much we try (using our rules) to force one out of them, they can always just prevaricate. So, I'd suggest that the text be more like 4. The confirming body decides whether it confirms each candidate. That decision must be made within a reasonable timeframe. Failing a decision, the slate of candidates, or any candidate not explicitly confirmed or rejected, will be considered to have been PQRSed. Whether PQRS is confirm or reject doesn't matter to me (it makes a difference but isn't one I have concluded that one is better than the other). This is all we need - if the confirming body chooses not to make a decision, because of laziness, deadlock, or any other reason, the world must go on, it cannot simply stall forever. The mechanism by which a decision is made, if one is made, doesn't matter (and how would anyone necessarily know whether 7 of 12 IAB members voted yes, or whether 5 of the 7 who bothered to attend the meeting voted yes) ? The only other issue is whether "reasonable timeframe" ought to be nailed down more precisely (if it isn't already) - which I'd guess would be a good idea. kre From ietf-nomcom-errors@lists.elistx.com Fri May 30 04:05:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFO00604WZPW6@eListX.com> (original mail from harald@alvestrand.no); Fri, 30 May 2003 04:02:13 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFO00601WZMW4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 30 May 2003 04:02:11 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFO00601WZLW2@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 30 May 2003 04:02:09 -0400 (EDT) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFO000QYWZJML@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 30 May 2003 04:02:07 -0400 (EDT) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0BCC6622AC; Fri, 30 May 2003 10:01:26 +0200 (CEST) Date: Fri, 30 May 2003 10:01:26 +0200 From: Harald Tveit Alvestrand Subject: Re: Alternative (H2) In-reply-to: <8311.1054273995@munnari.OZ.AU> To: Robert Elz Cc: RJ Atkinson , ietf-nomcom@lists.elistx.com Message-id: <46400000.1054281686@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: <23630000.1053821882@askvoll.hjemme.alvestrand.no> <39ACE8A8-8D21-11D7-87EA-00039357A82A@extremenetworks.com> <8311.1054273995@munnari.OZ.AU> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On fredag, mai 30, 2003 12:53:15 +0700 Robert Elz wrote: > I haven't had time to read this list for ages, and am just catching up. > I think I have read all of this thread - and I think you're all attempting > to solve the wrong problem. > > That is, Ran says that the IAB has deadlocked (the IAB's nature must have > changed a lot since I was there...) and that that poses a problem for the > nomcom. > > Fine - that should be fixed. > > But the proposed solution is to start (even in this mild form) to tell the > confirming body how it should make its decision? actually the previous nomcom RFC told the confirming body how to make its decision, and not only did it, but did it sloppily. we're trying to back away from that (at least I am). once the IAB makes a decision on how it wants to decide on confirmations, the second paragraph of (H2) becomes inoperative, so your text and alternative (H2) become more or less functionally equivalent. (The third paragraph of (H2) is a no-op already; you can't fail to conform to a text that says "anything's allowed".) that's where I want to go.... Harald From ietf-nomcom-errors@lists.elistx.com Fri May 30 05:55:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFP00904244MG@eListX.com> (original mail from kre@munnari.OZ.AU); Fri, 30 May 2003 05:52:52 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFP00901243ME@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 30 May 2003 05:52:51 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFP00901241MD@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 30 May 2003 05:52:49 -0400 (EDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFP0059723XBU@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 30 May 2003 05:52:47 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4U9q2P00343; Fri, 30 May 2003 16:52:02 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4U9aSE09824; Fri, 30 May 2003 16:36:28 +0700 (ICT) Date: Fri, 30 May 2003 16:36:28 +0700 From: Robert Elz Subject: Re: Alternative (H2) In-reply-to: <46400000.1054281686@askvoll.hjemme.alvestrand.no> To: Harald Tveit Alvestrand Cc: RJ Atkinson , ietf-nomcom@lists.elistx.com Message-id: <9822.1054287388@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <46400000.1054281686@askvoll.hjemme.alvestrand.no> <23630000.1053821882@askvoll.hjemme.alvestrand.no> <39ACE8A8-8D21-11D7-87EA-00039357A82A@extremenetworks.com> <8311.1054273995@munnari.OZ.AU> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Fri, 30 May 2003 10:01:26 +0200 From: Harald Tveit Alvestrand Message-ID: <46400000.1054281686@askvoll.hjemme.alvestrand.no> | actually the previous nomcom RFC told the confirming body how to make its | decision, and not only did it, but did it sloppily. we're trying to back | away from that (at least I am). yes, I agree with that. | that's where I want to go.... It sounds like we agree - I just don't think we need all those words to get to the desired result. That is, it isn't our business to care what the confirming body's rules for decision making are, in any sense at all, nor to even enquire whether they have any. All that matters to us is whether or not they actually have confirmed the slate of candidates, not how they got there. Of course, the selection of confirming bodies is up to us, and how well they do their job is something to consider from time to time - whether they should be replaced by someone else (I see no need to consider any of that now however). And, where an IETF body is involved, its charter will get reviewed from time to time, and its rules can be considered and approved in that context. kre From ietf-nomcom-errors@lists.elistx.com Fri May 30 10:35:41 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFP00J04F0KNZ@eListX.com> (original mail from rja@extremenetworks.com) ; Fri, 30 May 2003 10:31:33 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFP00J01F0HNW@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 30 May 2003 10:31:30 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFP00J01F0GNT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 30 May 2003 10:31:28 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFP00I2LF0EL6@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 30 May 2003 10:31:26 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 7579C67103; Fri, 30 May 2003 10:59:12 -0400 (EDT) Date: Fri, 30 May 2003 10:30:42 -0400 From: RJ Atkinson Subject: Re: Alternative (H2) In-reply-to: <9822.1054287388@munnari.OZ.AU> To: Robert Elz Cc: ietf-nomcom@lists.elistx.com Message-id: <4ACB5D12-92AB-11D7-B79B-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Friday, May 30, 2003, at 05:36 America/Montreal, Robert Elz wrote: > It sounds like we agree - I just don't think we need all those words to > get to the desired result. That is, it isn't our business to care > what > the confirming body's rules for decision making are, in any sense at > all, > nor to even enquire whether they have any. All that matters to us is > whether or not they actually have confirmed the slate of candidates, > not > how they got there. We *do* care that the Confirming Body doesn't deadlock without any decision, which is known to have happened. And I think that deadlock was not the result of putting an inappropriate/unwise set of people onto that Confirming Body. Your mileage might vary. I was there. That deadlock would have occurred under the rules of the previous Nomcom RFC (which were the rules actually applied) or under the normal IAB rule for decision-making (which is correctly rigged to NOP when there is contention[1], see IAB Charter RFC to see those current default rule). So Harald's assessment is quite correct IMHO: - As soon as IAB creates their own rules, the contingent rule no longer applies. - Until then, we at least eliminate the deadlock state that is currently legislated. The anxiety you seem to be concerned about -- excessive legislation of rules -- is actually *fixed* by H2, not made worse by it. And as Scott Bradner correctly observed a week or so back, we've done a tremendous amount of collective wordsmithing to end up with H2. Yet more wordsmithing of H2 is unlikely to help in any meaningful way. IMHO, we need to just adopt the H2 text as replacement for the current broken text and move forward with identifying/resolving any other open issues with this draft. Ran [1] On architectural matters, for example, if there is no consensus either way inside the IAB on some issue, it is far better to do nothing than to make a statement which might be seriously flawed technically. From ietf-nomcom-errors@lists.elistx.com Sat May 31 15:05:18 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFR00C04MBXF2@eListX.com> (original mail from kre@munnari.OZ.AU); Sat, 31 May 2003 15:04:45 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFR00C01MBWF0@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 31 May 2003 15:04:44 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFR00C01MBWEZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 31 May 2003 15:04:44 -0400 (EDT) Received: from fuchsia.home (ip24.coe.tnet.co.th [203.146.155.24]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFR00C0BMBR1V@eListX.com> for ietf-nomcom@lists.elistx.com; Sat, 31 May 2003 15:04:43 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h4VJ2IwW019551; Sun, 01 Jun 2003 02:02:19 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4VIvBT08318; Sun, 01 Jun 2003 01:58:11 +0700 (ICT) Date: Sun, 01 Jun 2003 01:57:11 +0700 From: Robert Elz Subject: Re: Alternative (H2) In-reply-to: <4ACB5D12-92AB-11D7-B79B-00039357A82A@extremenetworks.com> To: RJ Atkinson Cc: ietf-nomcom@lists.elistx.com Message-id: <8316.1054407431@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <4ACB5D12-92AB-11D7-B79B-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Fri, 30 May 2003 10:30:42 -0400 From: RJ Atkinson Message-ID: <4ACB5D12-92AB-11D7-B79B-00039357A82A@extremenetworks.com> | We *do* care that the Confirming Body doesn't deadlock without | any decision, No, we don't. What we care about is getting a decision. If there's no decision, it is irrelevant whether it is because of deadlock, or because they haven't even met once to consider the issue, or ... You're focussing on solving a particular problem you saw, and not looking at the broader issue. | That deadlock would have occurred under the rules of the previous | Nomcom RFC I agree that getting rid of the rule that is there now on how the confirming body should act is a good idea. | So Harald's assessment is quite correct IMHO: | - As soon as IAB creates their own rules, the contingent rule | no longer applies. First, it isn't "the IAB", it is "the conforming body", and second, we really should not care how they make a decision. Eg: what would you do if the confirming body created a rule "when confirming candidates from the IETF nomcom, three months must elapse for study before a vote can be taken" ? | The anxiety you seem to be concerned about -- excessive legislation | of rules -- is actually *fixed* by H2, not made worse by it. While in some cases that is what I worry about, in this case, that isn't it at all. It is that it is totally inappropriate for us to be making any rules at all. | And as Scott Bradner correctly observed a week or so back, we've done | a tremendous amount of collective wordsmithing to end up with H2. Yet | more wordsmithing of H2 is unlikely to help in any meaningful way. I think all that has been based upon attempting to solve the wrong problem. That is, it has all been aimed at finding a way to force an answer, one way of the other, out of the confirming body (and particularly when that is the IAB). That's simply wrong. We cannot make another organisation do anything, or do it in a way we choose, just because we say so (for the purposes of this discuccion, you should consider the IAB to be a totally independent organisation to the IETF - more like the ISOC, the other confirming body that these rules also apply to). | IMHO, we need to just adopt the H2 text as replacement for the current | broken text and move forward with identifying/resolving any other open | issues with this draft. Once again, the right way to fix this, is to decide what should happen if the confirming body says neither yes, nor no within a reasonable period. It should be irrelevant to us why they got into that position (internal deadlock, didn't feel like calling a meeting as all members were on extended vacation, ...). That completely solves the deadlock problem in the correct way, and also provides for all kinds of other things that might go wrong (and after thinking about it, I think the answer has to be "confirmed" if there's no explicit rejection, otherwise we have a potential loop, where the confirming body never does anything, and a default reject applies every time). kre From ietf-nomcom-errors@lists.elistx.com Sat May 31 15:45:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFR00F0BNRHAO@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Sat, 31 May 2003 15:35:41 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFR00F01NRGAL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 31 May 2003 15:35:40 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFR00F01NREA9@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 31 May 2003 15:35:38 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFR00C3NNRC1W@eListX.com> for ietf-nomcom@lists.elistx.com; Sat, 31 May 2003 15:35:36 -0400 (EDT) Date: Sat, 31 May 2003 15:35:14 -0400 (Eastern Daylight Time) From: James M Galvin Subject: Re: Alternative (H2) In-reply-to: <8316.1054407431@munnari.OZ.AU> To: Robert Elz Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <4ACB5D12-92AB-11D7-B79B-00039357A82A@extremenetworks.com> <8316.1054407431@munnari.OZ.AU> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Sun, 1 Jun 2003, Robert Elz wrote: (and after thinking about it, I think the answer has to be "confirmed" if there's no explicit rejection, otherwise we have a potential loop, where the confirming body never does anything, and a default reject applies every time). Logically, I agree with you, but I don't think logic is the correct choice here. Looking at it the other way, if the confirming body can not agree that the NOMCOM has done the best job it could have done, we want there to be a deadlock because we want that issue to surface and be visible to the community. In other words, a deadlock in this case is considered a feature. Jim From ietf-nomcom-errors@lists.elistx.com Sat May 31 17:45:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFR00304THHKT@eListX.com> (original mail from kre@munnari.OZ.AU); Sat, 31 May 2003 17:39:17 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFR00301THGKL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 31 May 2003 17:39:16 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFR00301THEKJ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 31 May 2003 17:39:14 -0400 (EDT) Received: from fuchsia.home (ip26.coe.tnet.co.th [203.146.155.26]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFR00CE6THA1V@eListX.com>; Sat, 31 May 2003 17:39:13 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h4VLcQwW007078; Sun, 01 Jun 2003 04:38:26 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4VLbuT11623; Sun, 01 Jun 2003 04:37:57 +0700 (ICT) Date: Sun, 01 Jun 2003 04:37:56 +0700 From: Robert Elz Subject: Re: Alternative (H2) In-reply-to: To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <11621.1054417076@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <4ACB5D12-92AB-11D7-B79B-00039357A82A@extremenetworks.com> <8316.1054407431@munnari.OZ.AU> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Sat, 31 May 2003 15:35:14 -0400 (Eastern Daylight Time) From: James M Galvin Message-ID: | Looking at it the other way, if the confirming body can not agree that | the NOMCOM has done the best job it could have done, we want there to be | a deadlock because we want that issue to surface and be visible to the | community. I know what you're getting at, but I think that if we ever have any of the candidates confirmed by default, because the confirming body was unable (or unwilling) to say yes or no, that will be quite visible enough (if necessary, the rules can say that this needs to be notified on the ietf-announce list - not necessarily specifying which candidate). But I don't think we can allow ourselves to get into a situation where we have only a half the IESG (and depending which year, perhaps no IETF chair). Having only half the IAB might be harmless enough, but for the IESG I think the IETF as a whole would almost collapse. Do recall that the conformation process is supposed to be just a check that the nomcom process hasn't gone wild - in general we trust the nomcom to have produced adequate results. If the confirming body disagrees, fine, and there's plenty of chance for deadlock (inter-group dispute) there. But if the confirming body is just unable to make a decision, I think the correct default is to trust the nomcom output. For a (perhaps far fetched) example, consider would would happen should some year, sometime during February, when the ISOC and IAB are both in the process of confirming the nomcom's results, the ISOC is suddenly wound up for some reason or other - it no longer exists. The new IAB members have not been confirmed. I guess we could live with that until we complete a revision of this doc and appoint a new confirming body, and they consider the question. But (I believe, and even if this is not correct now, it could be at this unknown future time) the ISOC pays for the IAB phone calls for their meetings. No ISOC, no phone calls. Confirmation discussions are too sensitive for e-mail (or so the IAB has decided) - so no IESG confirmation gets done either. None of this because of anything even remotely connected to the actual slate of candidates put forward by the nomcom. In any of these kinds of cases (including where the conforming body is simply deadlocked because of disagreements internally about the nomcom results) I think the correct thing is to accept the nomcom output. And then come back here and figure out how to fix whatever went wrong, if a fix is needed. kre From ietf-nomcom-errors@lists.elistx.com Sat May 31 20:35:06 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFS00J041D4CO@eListX.com> (original mail from rja@extremenetworks.com) ; Sat, 31 May 2003 20:29:28 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFS00J011D3CM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 31 May 2003 20:29:27 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HFS00J011D2CL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 31 May 2003 20:29:26 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFS00G111D14L@eListX.com> for ietf-nomcom@lists.elistx.com; Sat, 31 May 2003 20:29:25 -0400 (EDT) Received: from extremenetworks.com (ssh.extremenetworks.com [10.0.2.2]) by gnat.inet.org (Postfix) with ESMTP id 51B4167104; Sat, 31 May 2003 20:57:27 -0400 (EDT) Date: Sat, 31 May 2003 20:28:41 -0400 From: RJ Atkinson Subject: Re: Alternative (H2) In-reply-to: <8316.1054407431@munnari.OZ.AU> To: Robert Elz Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Saturday, May 31, 2003, at 14:57 America/Montreal, Robert Elz wrote: > | We *do* care that the Confirming Body doesn't deadlock without > | any decision, > > No, we don't. What we care about is getting a decision. If there's > no decision, it is irrelevant whether it is because of deadlock, or > because they haven't even met once to consider the issue, or ... I'm sorry for my unclear use of language. To try to be clear, in the English language as used in Virginia, where I happen to live, "deadlock" has the meaning "not getting a decision". > You're focussing on solving a particular problem you saw, and not > looking at the broader issue. Wrong. I'm looking at the whole issue, including but not in any way limited to the specific problem being discussed right now. My primary goal is to ensure that we get some decision, which is one reason that I started by proposing several different possible approaches to ensuring that a decision is reached. > | So Harald's assessment is quite correct IMHO: > | - As soon as IAB creates their own rules, the contingent rule > | no longer applies. > > First, it isn't "the IAB", it is "the conforming body", and second, > we really should not care how they make a decision. The problem we are fixing is a known *inability* to make a decision in some cases. > Once again, the right way to fix this, is to decide what should happen > if > the confirming body says neither yes, nor no within a reasonable > period. If you really think you will persuade folks, a more productive approach might be to post some specific proposed text (call it "J" maybe) and see if others buy into that. So far, I'm not at all persuaded by your commentary. I remain quite happy with the H2 language as solving the known problem. Best wishes, Ran rja@extremenetworks.com