From bernie@ietf.hoeneisen.ch Wed Jun 3 00:00:20 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33293A6B85 for ; Wed, 3 Jun 2009 00:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlFpx7xJGYKc for ; Wed, 3 Jun 2009 00:00:20 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 1D0E43A6A2A for ; Wed, 3 Jun 2009 00:00:19 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1MBkSR-0003SD-Pf for ietf-nomcom@ietf.org; Wed, 03 Jun 2009 09:00:19 +0200 Date: Wed, 3 Jun 2009 09:00:19 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: NomCom Discussion Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 07:00:21 -0000 Hi, Reviewing the latest "openlist" reminded me of some earlier question / suggestion I made earlier to the ietf-nomcom list. So far I have not got any feedback. Probably as it was buried under some much hotter topic (in the same email)... Here is comes again: * 3rd paragraph and former NomCom members: "It is consistent with this rule for current nominating committee members who have served on prior nominating committees to advise the current committee on deliberations and results of the prior committee, as necessary and appropriate." As I understand this, current NomCom members who have served on prior NomComs are allowed to share information they have as a result of their membership in prior NomComs. - Could anybody confirm, that my understanding about this is correct? * Suggestion for change: I suggest to explicitely allow any member of a former NomCom to share with the current NomCom any information relevant to the current NomCom. Such kind of information is most useful to current NomComs. - Any opinions on changing this as suggested? - How about changing this along with "openlist"? (Note that this part of RFC 3777 is already cited in "openlist".) cheers, Bernie From jmh@joelhalpern.com Wed Jun 3 06:01:27 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49FF3A6D99 for ; Wed, 3 Jun 2009 06:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrk-2D9yyxLs for ; Wed, 3 Jun 2009 06:01:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E7B8E3A6CA6 for ; Wed, 3 Jun 2009 06:01:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9C23F4300BE; Wed, 3 Jun 2009 06:01:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id EC6EF43009C; Wed, 3 Jun 2009 06:01:17 -0700 (PDT) Message-ID: <4A267416.1000507@joelhalpern.com> Date: Wed, 03 Jun 2009 09:01:10 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Bernie Hoeneisen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 13:01:27 -0000 I don't read things the same way you do. I don't think someone who was on nomcom A and is now on nomcom B can tell B "nomcom A, in discussing person X, found major problem Y." Nor, in fact, can they relay any other aspects of the discussion within nomcom A to nomcom B. They can say "Personally, I have problem Y with person X." There are of course multiple gray areas in between. Assuming that my reading is accurate, I would also prefer not to change that. (To take an extreme example, I have a fairly good archive of last year's nomcom. As far as I am concerned I can not, and should not be allowed to, forward that archive to Mary, or to her committee, even though I am an advisor to that committee and presumably allowed to provide personally known factual information to that committee.) Yours, Joel Bernie Hoeneisen wrote: > Hi, > > Reviewing the latest "openlist" reminded me of some earlier question / > suggestion I made earlier to the ietf-nomcom list. So far I have not got > any feedback. Probably as it was buried under some much hotter topic (in > the same email)... > > > Here is comes again: > > * 3rd paragraph and former NomCom members: > > "It is consistent with this rule for current nominating committee > members who have served on prior nominating committees to advise > the current committee on deliberations and results of the prior > committee, as necessary and appropriate." > > As I understand this, current NomCom members who have served on prior > NomComs are allowed to share information they have as a result of their > membership in prior NomComs. > > - Could anybody confirm, that my understanding about this is correct? > > > * Suggestion for change: > > I suggest to explicitely allow any member of a former NomCom to share > with the current NomCom any information relevant to the current NomCom. > Such kind of information is most useful to current NomComs. > > - Any opinions on changing this as suggested? > > - How about changing this along with "openlist"? > (Note that this part of RFC 3777 is already cited in "openlist".) > > > cheers, > Bernie > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From rdroms@cisco.com Wed Jun 3 06:08:12 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E093A6F13 for ; Wed, 3 Jun 2009 06:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UMS1HRd8QGy for ; Wed, 3 Jun 2009 06:08:11 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AECFC3A6C39 for ; Wed, 3 Jun 2009 06:08:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,298,1241395200"; d="scan'208";a="172186091" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 03 Jun 2009 13:08:13 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n53D8Cr0023076; Wed, 3 Jun 2009 09:08:12 -0400 Received: from [161.44.65.104] ([161.44.65.104]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n53D8C6e023693; Wed, 3 Jun 2009 13:08:12 GMT Message-Id: <19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> From: Ralph Droms To: "Joel M. Halpern" In-Reply-To: <4A267416.1000507@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 3 Jun 2009 09:08:12 -0400 References: <4A267416.1000507@joelhalpern.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2988; t=1244034492; x=1244898492; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[ietf-nomcom]=20Confidentiality=20and=2 0information=20from=20former=20NomCom=20members |Sender:=20 |To:=20=22Joel=20M.=20Halpern=22=20; bh=5PrZNbOzbNKP+4NjK5/nv8xotBKY5203h2T6SD3RqVc=; b=TH5b5dUFGsIbjvcrwVDJ74hlSgayXORrxfakw/R3kUnmSUd7uwFN0LYHIH txskekXL3fVXIHzSNXZ2b6hBx9gimLQfJBep2X+JZDVSmGnZVkzj7TmJC6s7 lxSy73Jr0c; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 13:08:12 -0000 Joel - I agree with your interpretation of the confidentiality requirements. When I was in the situation you are in now, as past NomCom chair I do not think I had the right to make any of the information from the NomCom I chaired to the subsequent NomCom to which I was an advisor. And I would not want to change that rule. - Ralph On Jun 3, 2009, at 9:01 AM 6/3/09, Joel M. Halpern wrote: > I don't read things the same way you do. > I don't think someone who was on nomcom A and is now on nomcom B can > tell B "nomcom A, in discussing person X, found major problem Y." > Nor, in fact, can they relay any other aspects of the discussion > within nomcom A to nomcom B. > They can say "Personally, I have problem Y with person X." > There are of course multiple gray areas in between. > > Assuming that my reading is accurate, I would also prefer not to > change that. (To take an extreme example, I have a fairly good > archive of last year's nomcom. As far as I am concerned I can not, > and should not be allowed to, forward that archive to Mary, or to > her committee, even though I am an advisor to that committee and > presumably allowed to provide personally known factual information > to that committee.) > > Yours, > Joel > > Bernie Hoeneisen wrote: >> Hi, >> Reviewing the latest "openlist" reminded me of some earlier >> question / suggestion I made earlier to the ietf-nomcom list. So >> far I have not got any feedback. Probably as it was buried under >> some much hotter topic (in the same email)... >> Here is comes again: >> * 3rd paragraph and former NomCom members: >> "It is consistent with this rule for current nominating committee >> members who have served on prior nominating committees to advise >> the current committee on deliberations and results of the prior >> committee, as necessary and appropriate." >> As I understand this, current NomCom members who have served on >> prior >> NomComs are allowed to share information they have as a result of >> their >> membership in prior NomComs. >> - Could anybody confirm, that my understanding about this is >> correct? >> * Suggestion for change: >> I suggest to explicitely allow any member of a former NomCom to >> share >> with the current NomCom any information relevant to the current >> NomCom. >> Such kind of information is most useful to current NomComs. >> - Any opinions on changing this as suggested? >> - How about changing this along with "openlist"? >> (Note that this part of RFC 3777 is already cited in "openlist".) >> cheers, >> Bernie >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom From john@jck.com Wed Jun 3 06:36:01 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2723A6A04 for ; Wed, 3 Jun 2009 06:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU82lGsyu4bn for ; Wed, 3 Jun 2009 06:36:01 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id C131A3A68D8 for ; Wed, 3 Jun 2009 06:36:00 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MBqdL-00016Z-GV; Wed, 03 Jun 2009 09:35:59 -0400 Date: Wed, 03 Jun 2009 09:35:58 -0400 From: John C Klensin To: "Joel M. Halpern" , Bernie Hoeneisen Message-ID: In-Reply-To: <4A267416.1000507@joelhalpern.com> References: <4A267416.1000507@joelhalpern.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 13:36:01 -0000 --On Wednesday, June 03, 2009 09:01 -0400 "Joel M. Halpern" wrote: > I don't read things the same way you do. > I don't think someone who was on nomcom A and is now on nomcom > B can tell B "nomcom A, in discussing person X, found major > problem Y." Nor, in fact, can they relay any other aspects of > the discussion within nomcom A to nomcom B. > They can say "Personally, I have problem Y with person X." > There are of course multiple gray areas in between. > > Assuming that my reading is accurate, I would also prefer not > to change that. (To take an extreme example, I have a fairly > good archive of last year's nomcom. As far as I am concerned > I can not, and should not be allowed to, forward that archive > to Mary, or to her committee, even though I am an advisor to > that committee and presumably allowed to provide personally > known factual information to that committee.) +1. I think that previous nomcom chairs and participants can share information about the general criteria and processes that previous Nomcoms used to inform their decisions --as long as that is done factually and without implication that the new/current Nomcom is obligated to do things the same way-- but not any information about candidates or candidate evaluations. john From bernie@ietf.hoeneisen.ch Wed Jun 3 07:36:59 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CAA3A6B49 for ; Wed, 3 Jun 2009 07:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00ncZZvxL2kP for ; Wed, 3 Jun 2009 07:36:58 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 2B3053A6887 for ; Wed, 3 Jun 2009 07:36:58 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1MBraD-0003uo-UJ; Wed, 03 Jun 2009 16:36:49 +0200 Date: Wed, 3 Jun 2009 16:36:49 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Ralph Droms In-Reply-To: <19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> Message-ID: References: <4A267416.1000507@joelhalpern.com> <19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 14:36:59 -0000 Hi Ralph, Joel et al. I looks like there is no common understanding of the following part of RFC 3777: "It is consistent with this rule for current nominating committee members who have served on prior nominating committees to advise the current committee on deliberations and results of the prior committee, as necessary and appropriate." Could anybody explain this further (what does this forbid/allow?), and in particular for what reason it was put there when RFC 3777 was drafted? cheers, Bernie On Wed, 3 Jun 2009, Ralph Droms wrote: > Joel - I agree with your interpretation of the confidentiality requirements. > When I was in the situation you are in now, as past NomCom chair I do not > think I had the right to make any of the information from the NomCom I > chaired to the subsequent NomCom to which I was an advisor. And I would not > want to change that rule. > > - Ralph > > On Jun 3, 2009, at 9:01 AM 6/3/09, Joel M. Halpern wrote: > >> I don't read things the same way you do. >> I don't think someone who was on nomcom A and is now on nomcom B can tell B >> "nomcom A, in discussing person X, found major problem Y." Nor, in fact, >> can they relay any other aspects of the discussion within nomcom A to >> nomcom B. >> They can say "Personally, I have problem Y with person X." >> There are of course multiple gray areas in between. >> >> Assuming that my reading is accurate, I would also prefer not to change >> that. (To take an extreme example, I have a fairly good archive of last >> year's nomcom. As far as I am concerned I can not, and should not be >> allowed to, forward that archive to Mary, or to her committee, even though >> I am an advisor to that committee and presumably allowed to provide >> personally known factual information to that committee.) >> >> Yours, >> Joel >> >> Bernie Hoeneisen wrote: >>> Hi, >>> Reviewing the latest "openlist" reminded me of some earlier question / >>> suggestion I made earlier to the ietf-nomcom list. So far I have not got >>> any feedback. Probably as it was buried under some much hotter topic (in >>> the same email)... >>> Here is comes again: >>> * 3rd paragraph and former NomCom members: >>> "It is consistent with this rule for current nominating committee >>> members who have served on prior nominating committees to advise >>> the current committee on deliberations and results of the prior >>> committee, as necessary and appropriate." >>> As I understand this, current NomCom members who have served on prior >>> NomComs are allowed to share information they have as a result of their >>> membership in prior NomComs. >>> - Could anybody confirm, that my understanding about this is correct? >>> * Suggestion for change: >>> I suggest to explicitely allow any member of a former NomCom to share >>> with the current NomCom any information relevant to the current NomCom. >>> Such kind of information is most useful to current NomComs. >>> - Any opinions on changing this as suggested? >>> - How about changing this along with "openlist"? >>> (Note that this part of RFC 3777 is already cited in "openlist".) >>> cheers, >>> Bernie >>> _______________________________________________ >>> ietf-nomcom mailing list >>> ietf-nomcom@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom > From spencer@wonderhamster.org Wed Jun 3 08:12:27 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514F63A6FE5 for ; Wed, 3 Jun 2009 08:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=2.378, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycGQF4ORfl+0 for ; Wed, 3 Jun 2009 08:12:26 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 5EF3D3A6FE4 for ; Wed, 3 Jun 2009 08:12:26 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1MBs8g0Vv8-000fy1; Wed, 03 Jun 2009 11:12:27 -0400 Message-ID: <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> From: "Spencer Dawkins" To: "NomComDiscussion" References: <4213D9AF36794C9484FE218C65E7BE4B@china.huawei.com><4A1ABE1F.7060207@joelhalpern.com> <0D8D6DBC6D4E46A5B6F12F91ABBFDD5C@china.huawei.com> Date: Wed, 3 Jun 2009 10:12:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+ymBByFpDFwQi5tAw3w7NoBZBlhIoW5pIUzUh EfhQ5bxSYV6q3Ooc3Utde4aUWDX2xt0BipoQrDVNvNuAHupuCs 4X5cRAsVOGeSfdrxTwqWvQZe7LqIqcA3k79C7U8Cpk= Subject: Re: [ietf-nomcom] draft-dawkins-nomcom-openlist-03.txt posted X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 15:12:27 -0000 Russ has provided AD feedback on this draft, almost all of which I would consider editorial/nits in nature, but he did come up with a question that led to another question in my mind, and I wanted feedback from the group before submitting openlist-04. In openlist-03 Section 6, Russ flagged this text (Russ's comments are prefaced by ">"): We note that (for example) the Internet Architecture Board publishes the nominee list for their representative to the Internet Society Board of Trustees, without apparent ill effects, but we are also willing to accept that a NomCom might consider nominees whose names have not been announced, for a variety of reasons, if this is the right thing to do, in NomCom's judgement. > I realize that this is not the normative part of the text, but the > last bit raises a concern. Clarity is needed here. RFC 3777 says: > > None of the Chair, liaisons, or advisors vote on the selection of > candidates. They do vote on all other issues before the > committee unless otherwise specified in this document. > > So, are the Chair, liaisons, and advisors part of the NomCom's > judgement here. I think that the document needs to be clear on > this point. So, would such a decision be part of the "selection > of candidates" or is it part of the process that includes the > Chair, liaisons, and advisors in the voting pool. My take on this is that the judgement needs to be the judgement of the voting membership - I would be very uncomfortable with having a bunch of non-voting members overrule the voting membership to say that a nominee should be considered with no community feedback. I could be wrong about this, of course, so I'm curious what others think. My question (based on Russ's question) is - in the actual normative section (Section 7), I had this related text: The NomCom may consider nominees without asking for community feedback. Does this need to include any reference to the judgement of either the voting membership or the entire membership of NomCom? Thanks, Spencer From jmh@joelhalpern.com Wed Jun 3 09:03:14 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53FB13A6B88 for ; Wed, 3 Jun 2009 09:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6nt03nnYgQ8 for ; Wed, 3 Jun 2009 09:03:13 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 718D03A68FD for ; Wed, 3 Jun 2009 09:03:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5F922430229; Wed, 3 Jun 2009 09:03:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 69283430153; Wed, 3 Jun 2009 09:03:14 -0700 (PDT) Message-ID: <4A269EBA.70305@joelhalpern.com> Date: Wed, 03 Jun 2009 12:03:06 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Bernie Hoeneisen References: <4A267416.1000507@joelhalpern.com> <19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 16:03:14 -0000 I don't know what to make of that text. While I can imagine exceptions, as a general rule that is so obviously a bad idea that it never occurred to me it was within the rules. Joel Bernie Hoeneisen wrote: > Hi Ralph, Joel et al. > > I looks like there is no common understanding of the following part of > RFC 3777: > > "It is consistent with this rule for current nominating committee > members who have served on prior nominating committees to advise > the current committee on deliberations and results of the prior > committee, as necessary and appropriate." > > Could anybody explain this further (what does this forbid/allow?), and > in particular for what reason it was put there when RFC 3777 was drafted? > > cheers, > Bernie > > > On Wed, 3 Jun 2009, Ralph Droms wrote: > >> Joel - I agree with your interpretation of the confidentiality >> requirements. When I was in the situation you are in now, as past >> NomCom chair I do not think I had the right to make any of the >> information from the NomCom I chaired to the subsequent NomCom to >> which I was an advisor. And I would not want to change that rule. >> >> - Ralph >> >> On Jun 3, 2009, at 9:01 AM 6/3/09, Joel M. Halpern wrote: >> >>> I don't read things the same way you do. >>> I don't think someone who was on nomcom A and is now on nomcom B can >>> tell B "nomcom A, in discussing person X, found major problem Y." >>> Nor, in fact, can they relay any other aspects of the discussion >>> within nomcom A to nomcom B. >>> They can say "Personally, I have problem Y with person X." >>> There are of course multiple gray areas in between. >>> >>> Assuming that my reading is accurate, I would also prefer not to >>> change that. (To take an extreme example, I have a fairly good >>> archive of last year's nomcom. As far as I am concerned I can not, >>> and should not be allowed to, forward that archive to Mary, or to her >>> committee, even though I am an advisor to that committee and >>> presumably allowed to provide personally known factual information to >>> that committee.) >>> >>> Yours, >>> Joel >>> >>> Bernie Hoeneisen wrote: >>>> Hi, >>>> Reviewing the latest "openlist" reminded me of some earlier question >>>> / suggestion I made earlier to the ietf-nomcom list. So far I have >>>> not got any feedback. Probably as it was buried under some much >>>> hotter topic (in the same email)... >>>> Here is comes again: >>>> * 3rd paragraph and former NomCom members: >>>> "It is consistent with this rule for current nominating committee >>>> members who have served on prior nominating committees to advise >>>> the current committee on deliberations and results of the prior >>>> committee, as necessary and appropriate." >>>> As I understand this, current NomCom members who have served on prior >>>> NomComs are allowed to share information they have as a result of their >>>> membership in prior NomComs. >>>> - Could anybody confirm, that my understanding about this is correct? >>>> * Suggestion for change: >>>> I suggest to explicitely allow any member of a former NomCom to share >>>> with the current NomCom any information relevant to the current NomCom. >>>> Such kind of information is most useful to current NomComs. >>>> - Any opinions on changing this as suggested? >>>> - How about changing this along with "openlist"? >>>> (Note that this part of RFC 3777 is already cited in "openlist".) >>>> cheers, >>>> Bernie >>>> _______________________________________________ >>>> ietf-nomcom mailing list >>>> ietf-nomcom@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-nomcom >>> _______________________________________________ >>> ietf-nomcom mailing list >>> ietf-nomcom@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> > From kre@munnari.OZ.AU Wed Jun 3 09:36:01 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7350C3A6B43 for ; Wed, 3 Jun 2009 09:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK-2no1bEnmf for ; Wed, 3 Jun 2009 09:36:00 -0700 (PDT) Received: from jade.coe.psu.ac.th (unknown [IPv6:2001:3c8:9009:181::2]) by core3.amsl.com (Postfix) with ESMTP id 4166C3A6AB9 for ; Wed, 3 Jun 2009 09:35:57 -0700 (PDT) Received: from epsilon.noi.kre.to (jade.coe.psu.ac.th [202.28.99.196]) by jade.coe.psu.ac.th with ESMTP id n53GZjJU019147; Wed, 3 Jun 2009 23:35:46 +0700 (ICT) Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.2/8.14.2) with ESMTP id n53GZ629006433; Wed, 3 Jun 2009 23:35:21 +0700 (ICT) From: Robert Elz To: "Spencer Dawkins" In-Reply-To: <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> References: <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> <4213D9AF36794C9484FE218C65E7BE4B@china.huawei.com><4A1ABE1F.7060207@joelhalpern.com> <0D8D6DBC6D4E46A5B6F12F91ABBFDD5C@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jun 2009 23:35:06 +0700 Message-ID: <20525.1244046906@epsilon.noi.kre.to> Sender: kre@munnari.OZ.AU Cc: NomComDiscussion Subject: Re: [ietf-nomcom] draft-dawkins-nomcom-openlist-03.txt posted X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 16:36:01 -0000 Date: Wed, 3 Jun 2009 10:12:21 -0500 From: "Spencer Dawkins" Message-ID: <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> | My take on this is that the judgement needs to be the judgement of the | voting membership - I would be very uncomfortable with having a bunch of | non-voting members overrule the voting membership I don't think the latter is really possible, is it? And we should make sure we keep it that way - that is, the voting members of the nomcom are greater in number (by a notable margin) than the sum of everyone else - so on any issue, if the voting members are of a common view, that view will always prevail. The only time the liaison (etc) opinion will affect the result is when the voting members are (close to) evenly divided - that is, effectively, when the voting part of the nomcom is essentially undecided. I see no harm in that circumstance, and probably a benefit, in having the guidance from the liaisons (assuming they're all more or less of one mind, if they're split too, then a small majority amongst them isn't going to alter anything except the most evenly divided voting member opinion) to make choices. The only issue that we have wanted to keep the liaisons (etc) out of is the actual choice of candidates - and that only to avoid suspicion that appointed nomcom members are effectively running an old boys club. Even there, as long as the voting membership size is of the order of twice the number of liaisons, etc, which I think it is, the voting members are always in control whenever they, or even most of them, want to be - so I don't think we need extra rules. Leave this is just another issue for each nomcom to specify internally as part of its own procedural issues - they can decide who gets to vote on issues like this, if they need to (I think it's clear that everyone gets a vote to decide the question, but if they desire, the voting members can vote as a block to exclude the others from voting on other issues). kre From spencer@wonderhamster.org Wed Jun 3 09:45:06 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751A828C117 for ; Wed, 3 Jun 2009 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=1.188, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsOQ0027fOld for ; Wed, 3 Jun 2009 09:45:05 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 76E8A28C107 for ; Wed, 3 Jun 2009 09:45:04 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MBtaF016P-000ctx; Wed, 03 Jun 2009 12:45:01 -0400 Message-ID: From: "Spencer Dawkins" To: "Robert Elz" References: <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> <4213D9AF36794C9484FE218C65E7BE4B@china.huawei.com><4A1ABE1F.7060207@joelhalpern.com> <0D8D6DBC6D4E46A5B6F12F91ABBFDD5C@china.huawei.com> <20525.1244046906@epsilon.noi.kre.to> Date: Wed, 3 Jun 2009 11:44:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/c8BbF1GYJUXSnH5LrjcZmfgricSy+sU4izbg 5vF7QxDyZth67llyZj7TByU/n3t0KuZi3YBMI/k+ktuZOwddt/ DNzK7jBrz1G7+NkkAE80xih8l6juL+Q2IrwcsSXONE= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] draft-dawkins-nomcom-openlist-03.txt posted X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 16:45:06 -0000 Hi, Robert, Thanks for catching my bad math. You understood what I meant to say - I was uncomfortable with a majority of the voting volunteers having one opinion, but that opinion being reversed when the non-voting members are polled, when the question is, "can we consider X as a nominee, without asking the community for input?" I am, of course, holding off on submitting openlist-04 to get more feedback on this, so others are invited to express opinions as well. Thanks, Spencer > Date: Wed, 3 Jun 2009 10:12:21 -0500 > From: "Spencer Dawkins" > Message-ID: <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> > > | My take on this is that the judgement needs to be the judgement of the > | voting membership - I would be very uncomfortable with having a bunch > of > | non-voting members overrule the voting membership > > I don't think the latter is really possible, is it? And we should make > sure > we keep it that way - that is, the voting members of the nomcom are > greater > in number (by a notable margin) than the sum of everyone else - so on any > issue, if the voting members are of a common view, that view will always > prevail. > > The only time the liaison (etc) opinion will affect the result is when the > voting members are (close to) evenly divided - that is, effectively, when > the voting part of the nomcom is essentially undecided. I see no harm in > that circumstance, and probably a benefit, in having the guidance from the > liaisons (assuming they're all more or less of one mind, if they're split > too, then a small majority amongst them isn't going to alter anything > except > the most evenly divided voting member opinion) to make choices. > > The only issue that we have wanted to keep the liaisons (etc) out of is > the > actual choice of candidates - and that only to avoid suspicion that > appointed nomcom members are effectively running an old boys club. Even > there, as long as the voting membership size is of the order of twice the > number of liaisons, etc, which I think it is, the voting members are > always > in control whenever they, or even most of them, want to be - so I don't > think we need extra rules. > > Leave this is just another issue for each nomcom to specify internally as > part of its own procedural issues - they can decide who gets to vote on > issues like this, if they need to (I think it's clear that everyone gets a > vote to decide the question, but if they desire, the voting members can > vote as a block to exclude the others from voting on other issues). > > kre > > From jmh@joelhalpern.com Wed Jun 3 09:56:03 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C233A6D8A for ; Wed, 3 Jun 2009 09:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tYZsAFLnstC for ; Wed, 3 Jun 2009 09:56:02 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 76ED13A6B7D for ; Wed, 3 Jun 2009 09:56:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 77060430153 for ; Wed, 3 Jun 2009 09:56:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 90BEE4301FF for ; Wed, 3 Jun 2009 09:56:03 -0700 (PDT) Message-ID: <4A26AB1C.5020902@joelhalpern.com> Date: Wed, 03 Jun 2009 12:55:56 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NomComDiscussion References: <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> <4213D9AF36794C9484FE218C65E7BE4B@china.huawei.com><4A1ABE1F.7060207@joelhalpern.com> <0D8D6DBC6D4E46A5B6F12F91ABBFDD5C@china.huawei.com> <20525.1244046906@epsilon.noi.kre.to> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ietf-nomcom] draft-dawkins-nomcom-openlist-03.txt posted X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 16:56:03 -0000 I suspect that this gets into cases that are better left unspecified, and let the nomcom chair figure out what works depending upon the specific situation. Frankly, if it is this close, the chair probably has some work to do to anyway. If one starts creating hypotheticals, I think this is a case where the liaisons would not get to vote. (Note, my preference is not to write a rule at all.) Reasoning for how I would conclude if I had to: Imagine that the situation is such that a majority of the voting members what to consider the candidate, but not a sufficient majority to overrule the liaisons (otherwise there is no question, and no need for a policy.) Suppose that majority would indeed make that person their first choice. Then they, as the voting members of the nomcom, are clearly free to make that choice. And the liaisons should not be able to stop them from making that choice. (The reason I don't think a rule is needed is that it is the chair's job to ensure that the liaisons do not unduly influence the actual selection. This case would clearly be an undue influence, and the chair would do what is necessary to avoid the problem.) Yours, Joel Spencer Dawkins wrote: > Hi, Robert, > > Thanks for catching my bad math. You understood what I meant to say - I > was uncomfortable with a majority of the voting volunteers having one > opinion, but that opinion being reversed when the non-voting members are > polled, when the question is, "can we consider X as a nominee, without > asking the community for input?" > > I am, of course, holding off on submitting openlist-04 to get more > feedback on this, so others are invited to express opinions as well. > > Thanks, > > Spencer > > >> Date: Wed, 3 Jun 2009 10:12:21 -0500 >> From: "Spencer Dawkins" >> Message-ID: <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> >> >> | My take on this is that the judgement needs to be the judgement of the >> | voting membership - I would be very uncomfortable with having a >> bunch of >> | non-voting members overrule the voting membership >> >> I don't think the latter is really possible, is it? And we should >> make sure >> we keep it that way - that is, the voting members of the nomcom are >> greater >> in number (by a notable margin) than the sum of everyone else - so on any >> issue, if the voting members are of a common view, that view will always >> prevail. >> >> The only time the liaison (etc) opinion will affect the result is when >> the >> voting members are (close to) evenly divided - that is, effectively, when >> the voting part of the nomcom is essentially undecided. I see no >> harm in >> that circumstance, and probably a benefit, in having the guidance from >> the >> liaisons (assuming they're all more or less of one mind, if they're split >> too, then a small majority amongst them isn't going to alter anything >> except >> the most evenly divided voting member opinion) to make choices. >> >> The only issue that we have wanted to keep the liaisons (etc) out of >> is the >> actual choice of candidates - and that only to avoid suspicion that >> appointed nomcom members are effectively running an old boys club. Even >> there, as long as the voting membership size is of the order of twice the >> number of liaisons, etc, which I think it is, the voting members are >> always >> in control whenever they, or even most of them, want to be - so I don't >> think we need extra rules. >> >> Leave this is just another issue for each nomcom to specify internally as >> part of its own procedural issues - they can decide who gets to vote on >> issues like this, if they need to (I think it's clear that everyone >> gets a >> vote to decide the question, but if they desire, the voting members can >> vote as a block to exclude the others from voting on other issues). >> >> kre >> >> > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From spencer@wonderhamster.org Wed Jun 3 10:24:41 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A03D3A6DA6 for ; Wed, 3 Jun 2009 10:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzBVF6rf+S7X for ; Wed, 3 Jun 2009 10:24:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 303233A7053 for ; Wed, 3 Jun 2009 10:23:56 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1MBuBU1LuP-000g6T; Wed, 03 Jun 2009 13:23:32 -0400 Message-ID: <45AF7631CA034AD0AEF6849305D12874@china.huawei.com> From: "Spencer Dawkins" To: "Joel M. Halpern" , "Bernie Hoeneisen" References: <4A267416.1000507@joelhalpern.com><19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> <4A269EBA.70305@joelhalpern.com> Date: Wed, 3 Jun 2009 12:23:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19uuK7ii5MlAnD1cIHMtS0KZV8U9w8dUGiNo2k vhrhAPb0ER2KuWxW5z7yFVBpCbhl4km2xTFY+cdBxY1RmWeFNJ 2HLIzyfuKj3lP7CspPXZR0ZdZYuLi1eJZMvg7dbdr0= Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 17:24:41 -0000 OK, I'd really like for someone to tell us what this text was intended to allow, because I'm seeing a past NomCom chair saying that it's obviously broken, but the text is in the process BCP... :-( Thanks, Spencer >I don't know what to make of that text. While I can imagine exceptions, as >a general rule that is so obviously a bad idea that it never occurred to me >it was within the rules. > > Joel > > Bernie Hoeneisen wrote: >> Hi Ralph, Joel et al. >> >> I looks like there is no common understanding of the following part of >> RFC 3777: >> >> "It is consistent with this rule for current nominating committee >> members who have served on prior nominating committees to advise >> the current committee on deliberations and results of the prior >> committee, as necessary and appropriate." >> >> Could anybody explain this further (what does this forbid/allow?), and in >> particular for what reason it was put there when RFC 3777 was drafted? >> >> cheers, >> Bernie >> >> >> On Wed, 3 Jun 2009, Ralph Droms wrote: >> >>> Joel - I agree with your interpretation of the confidentiality >>> requirements. When I was in the situation you are in now, as past NomCom >>> chair I do not think I had the right to make any of the information from >>> the NomCom I chaired to the subsequent NomCom to which I was an advisor. >>> And I would not want to change that rule. >>> >>> - Ralph >>> >>> On Jun 3, 2009, at 9:01 AM 6/3/09, Joel M. Halpern wrote: >>> >>>> I don't read things the same way you do. >>>> I don't think someone who was on nomcom A and is now on nomcom B can >>>> tell B "nomcom A, in discussing person X, found major problem Y." Nor, >>>> in fact, can they relay any other aspects of the discussion within >>>> nomcom A to nomcom B. >>>> They can say "Personally, I have problem Y with person X." >>>> There are of course multiple gray areas in between. >>>> >>>> Assuming that my reading is accurate, I would also prefer not to change >>>> that. (To take an extreme example, I have a fairly good archive of >>>> last year's nomcom. As far as I am concerned I can not, and should not >>>> be allowed to, forward that archive to Mary, or to her committee, even >>>> though I am an advisor to that committee and presumably allowed to >>>> provide personally known factual information to that committee.) >>>> >>>> Yours, >>>> Joel >>>> >>>> Bernie Hoeneisen wrote: >>>>> Hi, >>>>> Reviewing the latest "openlist" reminded me of some earlier question / >>>>> suggestion I made earlier to the ietf-nomcom list. So far I have not >>>>> got any feedback. Probably as it was buried under some much hotter >>>>> topic (in the same email)... >>>>> Here is comes again: >>>>> * 3rd paragraph and former NomCom members: >>>>> "It is consistent with this rule for current nominating committee >>>>> members who have served on prior nominating committees to advise >>>>> the current committee on deliberations and results of the prior >>>>> committee, as necessary and appropriate." >>>>> As I understand this, current NomCom members who have served on prior >>>>> NomComs are allowed to share information they have as a result of >>>>> their >>>>> membership in prior NomComs. >>>>> - Could anybody confirm, that my understanding about this is correct? >>>>> * Suggestion for change: >>>>> I suggest to explicitely allow any member of a former NomCom to share >>>>> with the current NomCom any information relevant to the current >>>>> NomCom. >>>>> Such kind of information is most useful to current NomComs. >>>>> - Any opinions on changing this as suggested? >>>>> - How about changing this along with "openlist"? >>>>> (Note that this part of RFC 3777 is already cited in "openlist".) >>>>> cheers, >>>>> Bernie >>>>> _______________________________________________ >>>>> ietf-nomcom mailing list >>>>> ietf-nomcom@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-nomcom >>>> _______________________________________________ >>>> ietf-nomcom mailing list >>>> ietf-nomcom@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-nomcom >>> >> > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From john-ietf@jck.com Wed Jun 3 10:47:57 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF4E3A67DF for ; Wed, 3 Jun 2009 10:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7Vgx5gzzx9i for ; Wed, 3 Jun 2009 10:47:56 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 9F8C53A6AA6 for ; Wed, 3 Jun 2009 10:47:56 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MBuZ5-0009ul-Nj; Wed, 03 Jun 2009 13:47:51 -0400 Date: Wed, 03 Jun 2009 13:47:50 -0400 From: John C Klensin To: Spencer Dawkins , "Joel M. Halpern" , Bernie Hoeneisen Message-ID: In-Reply-To: <45AF7631CA034AD0AEF6849305D12874@china.huawei.com> References: <4A267416.1000507@joelhalpern.com> <19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> <4A269EBA.70305@joelhalpern.com> <45AF7631CA034AD0AEF6849305D12874@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 17:47:57 -0000 --On Wednesday, June 03, 2009 12:23 -0500 Spencer Dawkins wrote: > OK, I'd really like for someone to tell us what this text was > intended to allow, because I'm seeing a past NomCom chair > saying that it's obviously broken, but the text is in the > process BCP... > > :-( I'd be happy to hear from the author of that text (whomever that might be), but I believe it is more or less consistent with my earlier note: Nomcom N should reasonably have access to information about general criteria, decision processes, and procedures used from Nomcom N-1 (and possibly N-2 and further back). That information may be used to inform Nomcom choices about processes and criteria, but Nomcom N may also move in different directions --at their discretion and within whatever constrains exist in 3777 and its offspring. Neither Nomcom N nor anyone else get access to information about actual candidates, candidate statements, input about candidates, or Nomcom discussion of candidates. In other words, "deliberations and results" is about principles and process, not candidates. Otherwise, this text would be, IMO, hopelessly inconsistent with the rest of 3777. john From spencer@wonderhamster.org Wed Jun 3 13:27:58 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36B93A6885 for ; Wed, 3 Jun 2009 13:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKNG-5kl39LC for ; Wed, 3 Jun 2009 13:27:56 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 60A503A698F for ; Wed, 3 Jun 2009 13:27:56 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1MBx300e9C-000fjc; Wed, 03 Jun 2009 16:26:59 -0400 Message-ID: <08F14AF00EE243ADB97195FF941685AF@china.huawei.com> From: "Spencer Dawkins" To: "John C Klensin" , "Joel M. Halpern" , "Bernie Hoeneisen" References: <4A267416.1000507@joelhalpern.com> <19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> <4A269EBA.70305@joelhalpern.com> <45AF7631CA034AD0AEF6849305D12874@china.huawei.com> Date: Wed, 3 Jun 2009 15:26:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/ZMouhbOd3eYhoBJaFg9tAxnpnAplmEoUCFRb 9cu9L1MMUYkwzketZGf4zfrX07O8XVEMoplCcCQ8pMwa8+tmz8 ymDAjzV+QODL8PaOMJYz9TYZOt1HrsKp3iBEpAHa0E= Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 20:27:58 -0000 Hi, John, OK, I went back and looked at 3777, and I'm not feeling much better about this text. > I'd be happy to hear from the author of that text (whomever > that might be), but I believe it is more or less consistent with > my earlier note: > > Nomcom N should reasonably have access to information about > general criteria, decision processes, and procedures used from > Nomcom N-1 (and possibly N-2 and further back). That > information may be used to inform Nomcom choices about processes > and criteria, but Nomcom N may also move in different directions > --at their discretion and within whatever constrains exist in > 3777 and its offspring. > > Neither Nomcom N nor anyone else get access to information about > actual candidates, candidate statements, input about candidates, > or Nomcom discussion of candidates. > > In other words, "deliberations and results" is about principles > and process, not candidates. Otherwise, this text would be, > IMO, hopelessly inconsistent with the rest of 3777. > > john Let me begin by saying I agree with what YOUR note said ("general criteria, decision processes, and procedures"). I may be confused, but I could be convinced that 3777 uses the word "deliberations" to describe precisely what you're hoping would NOT be included. I'm looking at text like 10. The Chair announces the open positions to be reviewed, the desired expertise provided by the IETF Executive Director, and the call for nominees. The call for nominees must include a request for comments regarding the past performance of incumbents, which will be considered during the *deliberations* of the nominating committee. and 14. The nominating committee advises the confirming bodies of their candidates, specifying a single candidate for each open position and testifying as to how each candidate meets the qualifications of an open position. For each candidate, the testimony must include a brief statement of the qualifications for the position that is being filled, which may be exactly the expertise that was requested. If the qualifications differ from the expertise originally requested a brief statement explaining the difference must be included. The testimony may include either or both of a brief resume of the candidate and a brief summary of the *deliberations* of the nominating committee. So, as a non-3777 wonk, I'm thinking that the text that Bernie was struggling with, could be improved. I don't think we need to wait for a fix to advance openlist, but I hope this does get fixed at some point. Thanks, Spencer From john-ietf@jck.com Wed Jun 3 16:54:03 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF223A6927 for ; Wed, 3 Jun 2009 16:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTELRJmcrhk7 for ; Wed, 3 Jun 2009 16:54:02 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id DF2063A6964 for ; Wed, 3 Jun 2009 16:53:47 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MC0HC-0000iu-Tq; Wed, 03 Jun 2009 19:53:47 -0400 Date: Wed, 03 Jun 2009 19:53:44 -0400 From: John C Klensin To: Spencer Dawkins , "Joel M. Halpern" , Bernie Hoeneisen Message-ID: In-Reply-To: <08F14AF00EE243ADB97195FF941685AF@china.huawei.com> References: <4A267416.1000507@joelhalpern.com> <19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> <4A269EBA.70305@joelhalpern.com> <45AF7631CA034AD0AEF6849305D12874@china.huawei.com> <08F14AF00EE243ADB97195FF941685AF@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 23:54:03 -0000 --On Wednesday, June 03, 2009 15:26 -0500 Spencer Dawkins wrote: > Hi, John, > > OK, I went back and looked at 3777, and I'm not feeling much > better about this text. >... I trust it is obvious by now that, if we managed to have the same quality of clear and unambiguous writing, and coverage of the necessary cases, in our protocol documents that we do in our procedural one, either the Internet would have collapsed long ago or the IETF would be irrelevant to it. Of course, the number of do-overs that have been required in the IPR space is the poster child for this, but the Nomcom and related processes are really not much better. To make things worse, we are often protected by the Robustness Principle where protocol documents are concerned, but we don't have analogies and a consensus understanding about how to apply them in these cases. >... > Let me begin by saying I agree with what YOUR note said > ("general criteria, decision processes, and procedures"). > > I may be confused, but I could be convinced that 3777 uses the > word "deliberations" to describe precisely what you're hoping > would NOT be included. I'm looking at text like > > 10. The Chair announces the open positions to be reviewed, > the > desired expertise provided by the IETF Executive > Director, and the call for nominees. There are documents on this earth that, because of exception care or divine guidance, have the property that every use of a word has exactly the same meaning and that every change in vocabulary means something. For better or worse, IETF procedural documents are not among them. See above. >... > So, as a non-3777 wonk, I'm thinking that the text that Bernie > was struggling with, could be improved. I don't think we need > to wait for a fix to advance openlist, but I hope this does > get fixed at some point. Certainly it would be a good idea to do that. It would be, IMO, an even better idea to rewrite all of our procedural documents from scratch, using an absolutely consistent style and examining every sentence to be sure that it doesn't leave odd edge cases. I would also like a pony. john From jwkckid1@ix.netcom.com Wed Jun 3 17:46:33 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87D63A6B7C for ; Wed, 3 Jun 2009 17:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcdcJ0+iQMEj for ; Wed, 3 Jun 2009 17:46:32 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 934313A6B3B for ; Wed, 3 Jun 2009 17:46:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=O1MMfOFKx+/diW9Tqw0LmzgpBYLsIf5ggc0lvOp8EtZLR80ogzy5/H9GfiEy9BlG; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.102.102] (helo=ix.netcom.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MC166-0002o8-Kw; Wed, 03 Jun 2009 20:46:23 -0400 Message-ID: <4A271956.4DC40E17@ix.netcom.com> Date: Wed, 03 Jun 2009 17:46:14 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John C Klensin References: <4A267416.1000507@joelhalpern.com> <19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> <4A269EBA.70305@joelhalpern.com> <45AF7631CA034AD0AEF6849305D12874@china.huawei.com> <08F14AF00EE243ADB97195FF941685AF@china.huawei.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606883433fa1c6280848e563b42a103696d6c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.102.102 Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information fromformer NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 00:46:33 -0000 John and all, All good suggestions here John, and as you indicate not likely to substancially occur. I would like a a new Volt. >:) John C Klensin wrote: > --On Wednesday, June 03, 2009 15:26 -0500 Spencer Dawkins > wrote: > > > Hi, John, > > > > OK, I went back and looked at 3777, and I'm not feeling much > > better about this text. > >... > > I trust it is obvious by now that, if we managed to have the > same quality of clear and unambiguous writing, and coverage of > the necessary cases, in our protocol documents that we do in our > procedural one, either the Internet would have collapsed long > ago or the IETF would be irrelevant to it. Of course, the > number of do-overs that have been required in the IPR space is > the poster child for this, but the Nomcom and related processes > are really not much better. To make things worse, we are often > protected by the Robustness Principle where protocol documents > are concerned, but we don't have analogies and a consensus > understanding about how to apply them in these cases. > > >... > > Let me begin by saying I agree with what YOUR note said > > ("general criteria, decision processes, and procedures"). > > > > I may be confused, but I could be convinced that 3777 uses the > > word "deliberations" to describe precisely what you're hoping > > would NOT be included. I'm looking at text like > > > > 10. The Chair announces the open positions to be reviewed, > > the > > desired expertise provided by the IETF Executive > > Director, and the call for nominees. > > There are documents on this earth that, because of exception > care or divine guidance, have the property that every use of a > word has exactly the same meaning and that every change in > vocabulary means something. For better or worse, IETF > procedural documents are not among them. See above. > > >... > > So, as a non-3777 wonk, I'm thinking that the text that Bernie > > was struggling with, could be improved. I don't think we need > > to wait for a fix to advance openlist, but I hope this does > > get fixed at some point. > > Certainly it would be a good idea to do that. It would be, IMO, > an even better idea to rewrite all of our procedural documents > from scratch, using an absolutely consistent style and examining > every sentence to be sure that it doesn't leave odd edge cases. > > I would also like a pony. > > john > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 From spencer@wonderhamster.org Wed Jun 3 19:49:24 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E493A6BCC for ; Wed, 3 Jun 2009 19:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nopdF20k0kzy for ; Wed, 3 Jun 2009 19:49:23 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 586673A6BFA for ; Wed, 3 Jun 2009 19:49:23 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MC3192Pr5-000d9p; Wed, 03 Jun 2009 22:49:24 -0400 Message-ID: <82A78E4D3AB74DEBACEA9ED0EF20B9EC@china.huawei.com> From: "Spencer Dawkins" To: "NomComDiscussion" References: <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> <4213D9AF36794C9484FE218C65E7BE4B@china.huawei.com><4A1ABE1F.7060207@joelhalpern.com> <0D8D6DBC6D4E46A5B6F12F91ABBFDD5C@china.huawei.com> <20525.1244046906@epsilon.noi.kre.to> <4A26AB1C.5020902@joelhalpern.com> Date: Wed, 3 Jun 2009 21:49:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/eRdGojiY4x5JvFy3ufOhNADebZ7PKiFvQ822 7yWlZpGbrNOD0+mDRd9p6sBQwoi8uP2DMPOCOtKA0Nnndwh0IH IEMePCNama97SLZJMbUWjo/aS9duqYicCxvAUYiCGw= Subject: Re: [ietf-nomcom] draft-dawkins-nomcom-openlist-03.txt posted X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 02:49:24 -0000 I'm going to take Joel's suggestion here, and remove the non-normative text that led to Russ's question, and to my question. Posting openlist-04 in a few minutes... Thanks, Spencer >I suspect that this gets into cases that are better left unspecified, and >let the nomcom chair figure out what works depending upon the specific >situation. > > Frankly, if it is this close, the chair probably has some work to do to > anyway. > > If one starts creating hypotheticals, I think this is a case where the > liaisons would not get to vote. (Note, my preference is not to write a > rule at all.) Reasoning for how I would conclude if I had to: > Imagine that the situation is such that a majority of the voting members > what to consider the candidate, but not a sufficient majority to overrule > the liaisons (otherwise there is no question, and no need for a policy.) > Suppose that majority would indeed make that person their first choice. > Then they, as the voting members of the nomcom, are clearly free to make > that choice. And the liaisons should not be able to stop them from making > that choice. > > (The reason I don't think a rule is needed is that it is the chair's job > to ensure that the liaisons do not unduly influence the actual selection. > This case would clearly be an undue influence, and the chair would do what > is necessary to avoid the problem.) > > Yours, > Joel > > > Spencer Dawkins wrote: >> Hi, Robert, >> >> Thanks for catching my bad math. You understood what I meant to say - I >> was uncomfortable with a majority of the voting volunteers having one >> opinion, but that opinion being reversed when the non-voting members are >> polled, when the question is, "can we consider X as a nominee, without >> asking the community for input?" >> >> I am, of course, holding off on submitting openlist-04 to get more >> feedback on this, so others are invited to express opinions as well. >> >> Thanks, >> >> Spencer >> >> >>> Date: Wed, 3 Jun 2009 10:12:21 -0500 >>> From: "Spencer Dawkins" >>> Message-ID: <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> >>> >>> | My take on this is that the judgement needs to be the judgement of >>> the >>> | voting membership - I would be very uncomfortable with having a bunch >>> of >>> | non-voting members overrule the voting membership >>> >>> I don't think the latter is really possible, is it? And we should make >>> sure >>> we keep it that way - that is, the voting members of the nomcom are >>> greater >>> in number (by a notable margin) than the sum of everyone else - so on >>> any >>> issue, if the voting members are of a common view, that view will always >>> prevail. >>> >>> The only time the liaison (etc) opinion will affect the result is when >>> the >>> voting members are (close to) evenly divided - that is, effectively, >>> when >>> the voting part of the nomcom is essentially undecided. I see no harm >>> in >>> that circumstance, and probably a benefit, in having the guidance from >>> the >>> liaisons (assuming they're all more or less of one mind, if they're >>> split >>> too, then a small majority amongst them isn't going to alter anything >>> except >>> the most evenly divided voting member opinion) to make choices. >>> >>> The only issue that we have wanted to keep the liaisons (etc) out of is >>> the >>> actual choice of candidates - and that only to avoid suspicion that >>> appointed nomcom members are effectively running an old boys club. >>> Even >>> there, as long as the voting membership size is of the order of twice >>> the >>> number of liaisons, etc, which I think it is, the voting members are >>> always >>> in control whenever they, or even most of them, want to be - so I don't >>> think we need extra rules. >>> >>> Leave this is just another issue for each nomcom to specify internally >>> as >>> part of its own procedural issues - they can decide who gets to vote on >>> issues like this, if they need to (I think it's clear that everyone gets >>> a >>> vote to decide the question, but if they desire, the voting members can >>> vote as a block to exclude the others from voting on other issues). >>> >>> kre >>> >>> >> >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From spencer@wonderhamster.org Wed Jun 3 20:04:32 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2928A3A6A53 for ; Wed, 3 Jun 2009 20:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzpNao+4M-C0 for ; Wed, 3 Jun 2009 20:04:31 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 2DAEA3A677D for ; Wed, 3 Jun 2009 20:03:38 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MC3Ew1kAS-000cuB; Wed, 03 Jun 2009 23:03:40 -0400 Message-ID: <2514A2D5F8994B0AA313FD41CF11B1D3@china.huawei.com> From: "Spencer Dawkins" To: "NomComDiscussion" References: Date: Wed, 3 Jun 2009 22:03:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX191s7+yYFFfDwuJr9+0bbOTenWBsxjAjoYOP1W hbyHOIiacs1P5no/ycsUQ4oTD8iu8W8axXaB3oIpfLjbfQQRlx GpjS4LhrmGA72lUKsgp7dYIFqJh1J1PxROArWFne4M= Subject: [ietf-nomcom] draft-dawkins-nomcom-openlist-04.txt posted X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 03:04:32 -0000 Just to let people know, I posted an update to -openlist (available at http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-openlist-04.txt). This revision addresses AD review comments from Russ Housley. Please comment to this mailing list, of course. Thanks, Spencer From leslie@thinkingcat.com Thu Jun 4 13:52:10 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CA13A6C7B for ; Thu, 4 Jun 2009 13:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIW5Hn2KmLTS for ; Thu, 4 Jun 2009 13:52:09 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id C18203A68A5 for ; Thu, 4 Jun 2009 13:52:09 -0700 (PDT) Received: from beethoven.local ([::ffff:209.183.196.229]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Thu, 04 Jun 2009 16:52:09 -0400 id 01584292.4A2833F9.00003D8A Message-ID: <4A2833EE.7010905@thinkingcat.com> Date: Thu, 04 Jun 2009 16:51:58 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: John C Klensin References: <4A267416.1000507@joelhalpern.com> <19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> <4A269EBA.70305@joelhalpern.com> <45AF7631CA034AD0AEF6849305D12874@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 20:52:10 -0000 I'm neither the author of the text, nor a previous NomCom chair, but let me say that your characterization of the intention resonates with my dim recollections from when the document was put together, as well as discussions I've heard from NomComs: starting up a NomCom cold each year is a lot of overhead, and not every NomCom will face precisely the same challenges. It's good to be able to draw on generalities of previous experience and actions. Leslie. John C Klensin wrote: > > --On Wednesday, June 03, 2009 12:23 -0500 Spencer Dawkins > wrote: > >> OK, I'd really like for someone to tell us what this text was >> intended to allow, because I'm seeing a past NomCom chair >> saying that it's obviously broken, but the text is in the >> process BCP... >> >> :-( > > I'd be happy to hear from the author of that text (whomever > that might be), but I believe it is more or less consistent with > my earlier note: > > Nomcom N should reasonably have access to information about > general criteria, decision processes, and procedures used from > Nomcom N-1 (and possibly N-2 and further back). That > information may be used to inform Nomcom choices about processes > and criteria, but Nomcom N may also move in different directions > --at their discretion and within whatever constrains exist in > 3777 and its offspring. > > Neither Nomcom N nor anyone else get access to information about > actual candidates, candidate statements, input about candidates, > or Nomcom discussion of candidates. > > In other words, "deliberations and results" is about principles > and process, not candidates. Otherwise, this text would be, > IMO, hopelessly inconsistent with the rest of 3777. > > john > > > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From sm@resistor.net Thu Jun 4 16:56:20 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98E53A691E for ; Thu, 4 Jun 2009 16:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyuULuIxCjQQ for ; Thu, 4 Jun 2009 16:56:19 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 87E193A684E for ; Thu, 4 Jun 2009 16:56:19 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n54Nu8i1016251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jun 2009 16:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1244159780; x=1244246180; bh=OQzLFPn7Cc3MmT1ZcJrfNR2p57dBfDeT9iFCGc8RbG8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=sgDr/SXept7LB+6xMFTms2CIPTBTg9z4UVCZ43FFEpNqd6leqsAkfcQIhaa/4VYwG ZJV2dIfn9vTIlCiIqEexbirSxt1H48uHe6ogs+bIfA/UYdge60SfzgpgIeF57nY5zY wWRlyF0g/Dukcii4TcHdRkyxn/ixjkDi/ziSkbSc= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=JitgABnAJNILnC1bDhsOIkYaz2FAYAO6VRLY4R1byVHRXLQPWD4wk55W5jUEK29/j go3Eip30foBP+oSQ8chw+wqbocAYxV2PR3i99B7klfcE7A5Jf2U/X1mzXhRTxpBP5Bg LiGWjGPqUHBcOElpIQ0dFMyN6m0B//I6lTTbSFE= Message-Id: <6.2.5.6.2.20090604155529.028dbea0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 04 Jun 2009 16:53:35 -0700 To: Spencer Dawkins , ietf-nomcom@ietf.org From: SM In-Reply-To: <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> References: <4213D9AF36794C9484FE218C65E7BE4B@china.huawei.com> <4A1ABE1F.7060207@joelhalpern.com> <0D8D6DBC6D4E46A5B6F12F91ABBFDD5C@china.huawei.com> <2AF59AFA1A37420994FD1D7C563CEB03@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ietf-nomcom] draft-dawkins-nomcom-openlist-04 (was: draft-dawkins-nomcom-openlist-03.txt posted) X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 23:56:20 -0000 Hi Spencer, At 08:12 03-06-2009, Spencer Dawkins wrote: >Russ has provided AD feedback on this draft, almost all of which I >would consider editorial/nits in nature, but he did come up with a >question that led to another question in my mind, and I wanted >feedback from the group before submitting openlist-04. > >In openlist-03 Section 6, Russ flagged this text (Russ's comments >are prefaced by ">"): > > We note that (for example) the Internet Architecture Board publishes > the nominee list for their representative to the Internet Society > Board of Trustees, without apparent ill effects, but we are also > willing to accept that a NomCom might consider nominees whose names > have not been announced, for a variety of reasons, if this is the > right thing to do, in NomCom's judgement. This is more of a comment. We only have to look at the discussion of having an open list to see that opinions on "the right thing to do" is not shared by everyone. You could use: We note that (for example) the Internet Architecture Board publishes the nominee list for their representative to the Internet Society Board of Trustees, without apparent ill effects, but we are also willing to accept that a NomCom might consider nominees whose names have not been announced. There is no need to say "for a variety of reasons" as none of these reasons are discussed. Obviously, NomCom will do it if it believes that it is the right thing to do. >>I realize that this is not the normative part of the text, but the >>last bit raises a concern. Clarity is needed here. RFC 3777 says: >> >> None of the Chair, liaisons, or advisors vote on the selection of >> candidates. They do vote on all other issues before the >> committee unless otherwise specified in this document. >> >>So, are the Chair, liaisons, and advisors part of the NomCom's >>judgement here. I think that the document needs to be clear on >>this point. So, would such a decision be part of the "selection >>of candidates" or is it part of the process that includes the >>Chair, liaisons, and advisors in the voting pool. > >My take on this is that the judgement needs to be the judgement of >the voting membership - I would be very uncomfortable with having a >bunch of non-voting members overrule the voting membership to say >that a nominee should be considered with no community feedback. There isn't a voting and non-voting membership according to the quoted paragraph from RFC 3777. Whether the person votes depends on what's specified in RFC 3777. Considering nominees is part of the selection of candidates. Advisors don't get to vote on the "we note ..." paragraph. BTW, do we have to keep the "we note" and the "we are willing" etc. throughout the document? Once this draft gets approved, it's not about what "the community are willing to accept". NomCom does their job and the community does not have any say. If the community doesn't like the way things were done, it can rewrite the "rules". >I could be wrong about this, of course, so I'm curious what others think. > >My question (based on Russ's question) is - in the actual normative >section (Section 7), I had this related text: > > The NomCom may consider nominees without asking for community > feedback. > >Does this need to include any reference to the judgement of either >the voting membership or the entire membership of NomCom? That's part of the selection of candidates. If there is any doubt, then you'll have to go and specify the "rules". At 09:55 03-06-2009, Joel M. Halpern wrote: >I suspect that this gets into cases that are better left >unspecified, and let the nomcom chair figure out what works >depending upon the specific situation. Agreed. >(The reason I don't think a rule is needed is that it is the chair's >job to ensure that the liaisons do not unduly influence the actual >selection. This case would clearly be an undue influence, and the >chair would do what is necessary to avoid the problem.) Yes. Regards, -sm From rdroms@cisco.com Fri Jun 5 03:57:57 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83B73A6C61 for ; Fri, 5 Jun 2009 03:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cysbGBGQ0VEd for ; Fri, 5 Jun 2009 03:57:56 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 525823A6C5F for ; Fri, 5 Jun 2009 03:57:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,310,1241395200"; d="scan'208";a="46308312" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Jun 2009 10:57:58 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n55Avwks021206 for ; Fri, 5 Jun 2009 06:57:58 -0400 Received: from bxb-rdroms-8716.cisco.com (bxb-rdroms-8716.cisco.com [10.98.10.87]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n55AvwBx005172 for ; Fri, 5 Jun 2009 10:57:58 GMT Message-Id: <24F8DAC6-7BD0-4DA0-8975-382ED34DA027@cisco.com> From: Ralph Droms To: NomCom Discussion In-Reply-To: <4A2833EE.7010905@thinkingcat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 5 Jun 2009 06:57:58 -0400 References: <4A267416.1000507@joelhalpern.com> <19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> <4A269EBA.70305@joelhalpern.com> <45AF7631CA034AD0AEF6849305D12874@china.huawei.com> <4A2833EE.7010905@thinkingcat.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2773; t=1244199478; x=1245063478; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[ietf-nomcom]=20Confidentiality=20and=2 0information=20from=20former=09NomCom=20members |Sender:=20 |To:=20NomCom=20Discussion=20; bh=fHblew5Htb7zbrr6u68fqtVz/9SIBciMFxuPtr5edJY=; b=0SJhO3/eRCAcwjf5Z3ii4dmC1dTDJXjtj09Q8HKgeofUpp76g/hTVGPxiM lWOdmqeE33nRbjLCyFHtw0gN87+lx2rnbiGt7BxBSZZzg1XNPABAyGHOHzYl TOD1YIU5zN; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 10:57:58 -0000 I agree with John's statement: "In other words, 'deliberations and results' is about principles and process, not candidates." I'm pretty sure that's the way the text has been interpreted by NomCom chairs. At some point, we should update the spec to match the running code. - Ralph On Jun 4, 2009, at 4:51 PM 6/4/09, Leslie Daigle wrote: > > I'm neither the author of the text, nor a previous NomCom chair, but > let me say that your characterization of the intention resonates > with my dim recollections from when the document was put together, > as well as discussions I've heard from NomComs: starting up a > NomCom cold each year is a lot of overhead, and not every NomCom > will face precisely the same challenges. It's good to be able to > draw on generalities of previous experience and actions. > > Leslie. > > John C Klensin wrote: >> --On Wednesday, June 03, 2009 12:23 -0500 Spencer Dawkins >> wrote: >>> OK, I'd really like for someone to tell us what this text was >>> intended to allow, because I'm seeing a past NomCom chair >>> saying that it's obviously broken, but the text is in the >>> process BCP... >>> >>> :-( >> I'd be happy to hear from the author of that text (whomever >> that might be), but I believe it is more or less consistent with >> my earlier note: >> Nomcom N should reasonably have access to information about >> general criteria, decision processes, and procedures used from >> Nomcom N-1 (and possibly N-2 and further back). That >> information may be used to inform Nomcom choices about processes >> and criteria, but Nomcom N may also move in different directions >> --at their discretion and within whatever constrains exist in >> 3777 and its offspring. >> Neither Nomcom N nor anyone else get access to information about >> actual candidates, candidate statements, input about candidates, >> or Nomcom discussion of candidates. >> In other words, "deliberations and results" is about principles >> and process, not candidates. Otherwise, this text would be, >> IMO, hopelessly inconsistent with the rest of 3777. >> john >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom > > -- > > ------------------------------------------------------------------- > "Reality: > Yours to discover." > -- ThinkingCat > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom From housley@vigilsec.com Sun Jun 7 15:15:37 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87CE63A6A41 for ; Sun, 7 Jun 2009 15:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s29rxV2HC3EN for ; Sun, 7 Jun 2009 15:15:36 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id A7D903A692E for ; Sun, 7 Jun 2009 15:15:36 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 751EC9A472C for ; Sun, 7 Jun 2009 18:15:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id SxqWom6ibXfT for ; Sun, 7 Jun 2009 18:15:40 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-96-255-144-213.washdc.fios.verizon.net [96.255.144.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id AF4829A4725 for ; Sun, 7 Jun 2009 18:15:42 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 07 Jun 2009 18:15:36 -0400 To: ietf-nomcom@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090607221542.AF4829A4725@odin.smetech.net> Subject: [ietf-nomcom] Last Call: draft-dawkins-nomcom-dont-wait X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 22:15:37 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-dont-wait-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18212&rfc_flag=0 From narten@us.ibm.com Fri Jun 12 13:57:45 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10CC3A69B5 for ; Fri, 12 Jun 2009 13:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VouWX9A+K2JW for ; Fri, 12 Jun 2009 13:57:45 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 2A3ED3A697D for ; Fri, 12 Jun 2009 13:57:45 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5CKv5MC019903 for ; Fri, 12 Jun 2009 14:57:05 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5CKvim0205182 for ; Fri, 12 Jun 2009 14:57:44 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5CKviLN015408 for ; Fri, 12 Jun 2009 14:57:44 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-48-42-29.mts.ibm.com [9.48.42.29]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n5CKvgsj015358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 14:57:44 -0600 Received: from cichlid.raleigh.ibm.com (cichlid [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n5CKvfP7004451; Fri, 12 Jun 2009 16:57:42 -0400 Message-Id: <200906122057.n5CKvfP7004451@cichlid.raleigh.ibm.com> To: "Joel M. Halpern" In-reply-to: <4A269EBA.70305@joelhalpern.com> References: <4A267416.1000507@joelhalpern.com> <19CBC7B8-FF79-4037-BD3A-60B4887CA3A2@cisco.com> <4A269EBA.70305@joelhalpern.com> Comments: In-reply-to "Joel M. Halpern" message dated "Wed, 03 Jun 2009 12:03:06 -0400." Date: Fri, 12 Jun 2009 16:57:41 -0400 From: Thomas Narten Cc: NomCom Discussion Subject: Re: [ietf-nomcom] Confidentiality and information from former NomCom members X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 20:57:45 -0000 > I don't know what to make of that text. While I can imagine exceptions, > as a general rule that is so obviously a bad idea that it never occurred > to me it was within the rules. My recollection is that the text got added at some point to deal specifically with situations where a nomcom was considering a candidate, and (by chance) a specific member of the nomcom had specific information about that candidate learned as a result of having been on a previous nomcom. Before that text was added, the nomcom member wasn't allowed to provide such information. I.e., they were effectively gagged from providing presumably important and relevant information. That situation had apparently happened. (Yes, I recognize that the words in the 3777 are much broader than needed to cover this.) Thomas From john@jck.com Sun Jun 14 15:07:56 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E20C3A6963 for ; Sun, 14 Jun 2009 15:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xD0oMkyk9E8 for ; Sun, 14 Jun 2009 15:07:54 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 6F8CA3A69DC for ; Sun, 14 Jun 2009 15:07:53 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MFxrr-0002sA-VW; Sun, 14 Jun 2009 18:08:01 -0400 Date: Sun, 14 Jun 2009 18:07:58 -0400 From: John C Klensin To: "Joel M. Halpern" , NomComDiscussion Message-ID: <36E1A7176AF78A864F74EAC6@PST.JCK.COM> In-Reply-To: <4A1D5086.9080702@joelhalpern.com> References: <4A1D5086.9080702@joelhalpern.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 22:07:56 -0000 Sorry to have taken so long to get back to this. Other work... Joel, at the risk of being heretical, the job of the Nomcom is not exclusively to "pick the best candidate". It doesn't have enough information to do that, partially because (with one qualification that I'll discuss below) incumbents are a known quantity while non-incumbent nominees are not. So the job, in practice, is to evaluate the strength of an incumbent's performance, the advantages and disadvantages of long tenure, and then to make a judgment about whether an alternate nominee would be worth the risk than any non-incumbent might constitute. Only if there is no incumbent does the Nomcom, in practice, actually get to make a "best candidate" decision with all of the Nominees evaluated on an equal basis. If you tell me that isn't what happens, I'll have to believe you somehow because I don't have the inside information that you do, but what I know about organizational behavior and selection/ election processes causes me to doubt that any other formulation is plausible, even though "pick the best candidate" sounds good in theory. Even if that were the only factor, if there is an incumbent who is willing to serve another term, a Nomcom realistically has to balance the qualities and record of that incumbent against the calculated risks posed by other nominees. Another job of the Nomcom --and the rules that enable it-- is to ensure that the maximum number of qualified people are willing to offer themselves as nominees for a given role. If there are impediments that discourage people from being nominated who might be willing and able to serve, we should seek to eliminate or reduce those impediments. Consider, for example, that we keep pushing the date at which nominees are expected to tentatively commit themselves further and further back. The RFC5078 timeline implies about eight months between the first announcement of open positions and call for nominees and the date on which decisions are announced. Now let's assume that we've got some potential nominees who have to go to their management in June and say "I'd like to sign up for a two-year position with the IETF. It requires that you commit, right now, to dedicating two years of my time, starting next March, to this role which I may or may not get. That commitment implies that I shouldn't be put on projects in the next eight months which would be in trouble if I had to drop them in March with, if we are lucky, a month's notice, so I'm on reduced functionality for eight months and then may largely disappear for two years. "Incidentally, while the rules would permit us to back out in February if circumstances change, draft-dawkins-nomcom-openlist will make that much more obvious, and possibly an embarrassment to the company, especially if I'm the only non-incumbent nominee. And, since, at least statistically, the Nomcom routinely returns incumbents, especially those who have served only one previous term, the odds of my actually being selected are low." That scenario is _not_ a way to build large nominee pools. Worse, our current expectation is essentially that the same people will not only do it once but, after not being selected that year, will come back to their managers three or four months after the selections are announced and say "Remember what we went through last time? I think we should do it again.". Perhaps large companies who are willing to donate a certain fraction of their staffs to the IETF don't care. Perhaps people who work for such companies but who are in a position to allocate very significant fractions of their time however they like are unaffected. I think the IETF would be better off with much more diversity in the nominee pools -- while I'm grateful for the dedication of the companies involved, I don't believe that it is a good sign that, of the membership on the IESG and IAB, three companies support three people each and another one supports two. I'm not concerned about conspiracy theories here but about the observation that, with nearly 25% of the Nomcom-appointed IESG and IAB positions in the hands of four organizations, how much trouble we would be in if one or more of them got into serious trouble and withdrew support. I do not believe that this proposal will solve the problem of concentration of slots in the hands of a few organizations (if indeed once considers it a problem). But I think anything we can do that broadens the Nomcom's effective range of choices would be a good idea. >From my point of view, your reaction to the proposal is based on an assumption that the current model has no adverse consequences. I think it does and am suggesting that those consequences are severe enough that it is time to make the tradeoffs somewhat differently. Some specific comments below. --On Wednesday, May 27, 2009 10:39 -0400 "Joel M. Halpern" wrote: > Having read the draft, it seems to me that this is a bad idea. > > Firstly, I am not sure what problem it solves. There is > apparently some concern about whether the nomcom is returning > too many or too few incumbents. Actually, that is not a concern or problem we were trying to solve in this draft. Instead, we started with the knowledge that, whether it was reasonable or not, about half were returned each time (as you note). We examined the "ask the boss" scenario outlined above and some similar ones and added in the concerns about "running against" someone (especially an incumbent) from the same or a related organization that have been expressed in conjunction with discussions of draft-dawkins-nomcom-openlist and concluded that, on balance, we would have much higher odds of having a good nominee pool when it was needed if we separated incumbent evaluation from consideration of new Nominees. We also believe (although we could be wrong, especially given the tendency for work to expand to fill the available time) that the separation would reduce the total workload, and time requirements, on the Nomcom. If it did and the effect of that were to broaden the pool of Nomcom volunteers, that would also, in our opinion, be good for the IETF. >... > At the same time, this proposal seems to actually make it > harder for the nomcom to do a good job. The goal is to > appoint the best available person to the job. > Choosing to re-appoint or not re-appoint an incumbent without > comparison with considering who else may be available and > qualified is not, it seems to me, able to meet that goal. Our disconnect here lies in your use of "best available". Certainly, that is correct if what you intended to say is "best available among those who volunteered to be nominees. But the current model is almost certainly reducing the number of available nominees. In some ways, that makes the Nomcom's job easier. But encouraging people to nominate themselves against incumbents who, statistically, will be returned anyway does not give you a good pool of "available" nominees when the Nomcom needs them. If you don't consider it a breach of confidentiality (since you would not need to discuss any particular candidate, I think it does not), it would help in this discussion if you would reveal the number of plausible nominees you had available for each slot in the last year. > It seems to me that the general notion of how many incumbents > ought to be returned in any given cycle depends heavily on how > many good alternatives there are. So I would hate to require > the committee to make that decision without having that > information. It seems to me that, if a Nomcom starts making decisions about how many incumbents to return, as a count, we are in deep trouble. Fred's rumored examples, in which "all of the incumbents were deemed good to return but the nomcom felt obliged to sacrifice one, and did so, with quite a bit of hurt feelings around the community. [...] And one could just as easily imagine a case in which the nomcom felt that none should be returned." both strike me as serious mistakes. Indeed, while nothing in either the current system or the proposed one could stop a Nomcom from going down some sort of "quota of incumbents to be returned" path if it decided it wanted to, part of the intent of the proposal is to focus attention away from that approach. There are a few implicit assumptions in this model which I will try to clarify in the next draft. One of them is that incumbents should be evaluated on performance --both theirs and that of the body to which they are contributing-- and returned there are signs of non-performance, bad behavior, or burnout. Of course, that doesn't obligate those incumbents to be available for additional terms. But the read-in costs and uncertainties of putting in a new person are sufficiently high that, if an incumbent is serving well and effectively in a body that is working well and wants to continue doing so, we should "let" him or her. If we don't believe that, then this is a bad proposal. But, again, if one judges from the statistics, that is, with rare exceptions, exactly how Nomcoms are behaving. The difference is that they are behaving that way after exerting more or less considerable efforts to collect other nominees (possibly making those people unavailable when they are really needed, as discussed above) and after spending lots of their time to see if they can do better. > More important than the abstract failure mode, there are > multiple specific failure modes that would do a disservice to > the community and the nomcom. If the nomcom has many > qualified incumbents, if doing a stand-alone evaluation it may > choose to return rather more incumbents than it would if it > knew that some of those seats had good nominees available. You can't have it both ways. One goal is well-qualified people with minimum risk that they cannot or will not do the job. If that is it, then the discussion about incumbents above is relevant because "good nominees" are always going to be a risk, if only because we've had ample examples of the Peter Principle playing out in the IETF as well as in other organizational settings. A different goal is to insure turnover by preferring "good nominees" to incumbents. If that is your preference, the way to accomplish it is to be explicit about it and impose rotation rules (term limits, more or less) with an exception procedure. > Similarly, if the nomcom wishes to choose among the > incumbents, because it feels that the good ones would still > represent returning too many, the nomcom really needs to know > who else is available. Conversely, it is quite possible that > the nomcom would, in a stand-alone evaluation, decide that > some incumbent was not quite as good as they would like, and > choose not to appoint him. Only to discover that said > incumbent is significantly better than any of the nominees > they evaluate. Here is where we have a significant difference of opinion that, I believe, would make a real difference. Let's assume that we have an incumbent who is not very good but sort of getting by despite several liabilities, and potential other nominees who are unlikely to be any better. At that point, it seems to me that you are suggesting that, under the current system, the Nomcom should select, not a "good" or "best" candidate (because there isn't one) but rather pick the least bad one. The proposed system would certainly make that harder. By contrast, I believe that, if an incumbent is not performing well, returning him or her is almost always a mistake. It weakens the IETF and the relevant body to have someone who is underperforming continue. Perhaps worse, we've had a number of cases in which someone has been returned to a body in spite of a record of bad behavior, only to have that person behave as if reappointment constitutes endorsement of the behavior and increase it. We've also found that comments from Nomcoms or others are of no help in preventing further inappropriate behavior. >From that perspective, if the Nomcom makes a decision that someone is not performing adequately, I believe that person should be retired or removed. If the Nomcom cannot then find a nominee in whom it has high confidence, I believe that any of the three alternatives are better than going back to the incumbent: the Nomcom searches harder and gets more creative, the Nomcom decides to take the risk with a Nominee who has at least not already proven to be inappropriate for the role, or the Nomcom explicitly decides to not fill the position because there are no plausible candidates. In the latter case, I'd expect the relevant body to be forced to either run short-handed or restructure and that either of those options would be better for the IETF that proceeding with weak leadership because some earlier structure required it. The proposed model makes the "retire the underperforming incumbent" scenario a little more efficient and likely to succeed, but the comments above apply even under the current model: if a Nomcom deliberately puts a "least unsatisfactory" nominee (whether incumbent or not) into a job, it is doing the community no favors. And, as I have suggested above, the proposed model is reasonably likely to give the Nomcom a broader range of choices and thereby lower the odds of getting into that situation. > The document seems to suggest that the answer to some of these > issues is to assume that there are always enough good > nominees, and that if there are not, maybe the seat should go > unfilled. This is sufficiently far from my understanding of > the realities that it seems a dangerous assumption. Again, my observation of the realities is that selection of the "best available" person, even if that person is known to be weak as a candidate, is not merely a danger, but an almost-certain problem. > There is another dimension in which I have serious concerns > with this proposal. One of the things the nomcom evaluates, > for all bodies, is the balance of members. That balance may, > in different years, be reflective of different aspects of > skills, knowledge, contacts, etc... But That kind of > balancing has been seen as important in may cases. > Pre-selecting which incumbents will remain, and which will > not, means that such balancing can not be used as part of the > selection. Again, I don't think so. Resignations and other rare and exceptional cases notwithstanding, a Nomcom does not get the option of replacing (or considering replacing) more than half of a given body in a given year. Given that, any attempted "balancing" has to consider balance with at least half the membership of the relevant body as a given -- the balance must consider the incumbents who are not up for renewal, a group whom the Nomcom cannot affect. So the question is whether choices of which incumbents to return can significantly aid or interfere with balance given that established base. I believe that, if the body is sufficiently out of balance that special considerations of incumbents are needed, that lack of balance will usually show up as disfunction and make it clear which incumbents should be removed, regardless of the order in which things are done. Conversely, if the perceived imbalance is dictated by principles too subtle to show up in that way, I'm willing to sacrifice giving the Nomcom an option that would seem to put "balance" ahead of "best candidate". YMMD. > Also, it is my opinion that this would significantly increase > the time for the selection process. The selection process is > not linear. As such, while the number of seats to be filled > has some effect on the time, it is not a significant factor. > (Issues of collecting input, and whether particular choices > are easy or hard, make more difference.) While this work could > possibly be overlapped with some portion of the nomination > selection, it clearly would need to be completed, confirmed, > and announced before nominations were considered usable, since > nominations would clearly need these results if this process > were to take place. As such, I believe it would add several > months to the process. Here, I am at a disadvantage because I don't have your in-Nomcom experience. But my reading of the situation is that a review of, at most, a dozen people, without any need to compare them to others, is not going to take very long as compared to an in-depth review of several people per open slot. And, by eliminating slots that need to be considered, and for which nominees need to be collected, one can further reduce workload. I don't see how it could be otherwise unless there is a desire to drag things out. > It is also the case that the differences in kinds of seats > makes some difference. Even if it were somehow concluded that > this made sense for the IESG, I can not see why one would > apply it to the IAB. In the case of the IAB, one is not > nominated against any one individual, but rather nominated for > a seat in a pool. As such, none of the arguments presented > about the open nominee list seem to apply to the IAB. And > even more than the IESG (where some balancing issues do apply) > the community consensus has seemed to me quite clear that > balance of various kinds are a set of very important factors > in selecting IAB members. When we started with this, we started with an "IESG only" assumption. While it seemed useful to explore whether it could (and should) also be applied to the IAB and any other Nomcom-selected positions, I'd be happy to go back to "IESG only" if that proposal made sense. >... best, john From jmh@joelhalpern.com Sun Jun 14 18:27:18 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875383A6BB2 for ; Sun, 14 Jun 2009 18:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SYBXMBJzics for ; Sun, 14 Jun 2009 18:27:16 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id BA14C3A6BA2 for ; Sun, 14 Jun 2009 18:27:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E8846437E53 for ; Sun, 14 Jun 2009 18:27:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.16.7.16] (unknown [12.53.162.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A4FCD437E20 for ; Sun, 14 Jun 2009 18:27:23 -0700 (PDT) Message-ID: <4A35A370.2030201@joelhalpern.com> Date: Sun, 14 Jun 2009 21:27:12 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NomComDiscussion References: <4A1D5086.9080702@joelhalpern.com> <36E1A7176AF78A864F74EAC6@PST.JCK.COM> In-Reply-To: <36E1A7176AF78A864F74EAC6@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 01:27:18 -0000 John's reply on his alternative nomcom procedure emphasized one dimension taht I want to explore a bit on its own. John's interesting note is removed, because I at least need to think more about it. A number of his comments and quesitons, if I have understood him right, relate to the question of getting enough good nominees. This is indeed a problem. I believe, and I may be mistaken, that this problem is reflective of both IETF cultural and corporate perspectives. I think this can be addressed, and should be addressed. Where we disagree on this is whether the right way to deal with it is by changing the rules. Note: I do not know enough about social dynamics to know how to get some of these changes through. Firstly, we have got to convince the community that even with regard to 1 term ADs (the most extreme example where there is known reticence to run), being willing to run, and saying so, has got to be seen as a contribution to the community, rather than as a competition. That is, the assertion someone is being asked to makes should not be "I am better than the incumbent," but rather "I believe I could do this job, and I am willing to do so." The point is that the community needs folks willing and able to make that second statement. It ought to be seen as a warning to any area that they have a problem if there are not a number of credible people making that statement. And folks need to understand that it is a service, to the IETF as a whole and their area, to say that (and mean it) even if they think the area is in good shape and they would like to see the incumbent continue. Two positive examples: In one area, a nomcom went looking for nominees. The nomcom found a number. Most of them said "If X still wants the job, give it to him. If you won't do that, for whatever reason, then I am willing to serve." That is good for the nomcom, good for the area, and good for the IETF as as whole. In another area, In know that the AD who was up for reappointment said to his area leadership that he is willing to be appointed again, but that he would strongly engourage other folks to offer themselves to the nomcom, so as to enable the nomcom to make the judgment. Both of these represent positive attitudes towards the process. Having folks refuse to be nominated, or refuse to serve, hinders the process. The other side of the coin is the corporate support issue. That needs some attention. But there are multiple subtle problems there, and changing the odds in the one regard of incumbents does not address the major issues I see. Thus, I will punt on that for now. Yours, Joel M. Halpern From barryleiba.mailing.lists@gmail.com Thu Jun 18 21:49:28 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD60F3A698F for ; Thu, 18 Jun 2009 21:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWMviBnpiREH for ; Thu, 18 Jun 2009 21:49:27 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 3FF043A6A56 for ; Thu, 18 Jun 2009 21:49:27 -0700 (PDT) Received: by bwz9 with SMTP id 9so1521083bwz.37 for ; Thu, 18 Jun 2009 21:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=g6o9iNck9uSeZALwEBmdnigL9TR0ol+DK8Q8xfpc4Us=; b=NRnT4L1Kk065J+YfPdpCBexo7N/nYH1xxU6OEDQ+g8538G13Him2UvOQxGWCjtsAle ZM5XZVt+iRam0+5t4yw6gOhGe02Tf4pU5uKBPhQ1c5NqWQaAiYIaF1wUMqKeiEXzvXJc TUcIuFBHP4qkzpnqoM8knwJPo70DZfybVevNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=a7oO3hTUHsJsod7hB+bVv1uIa3pnrwKEWDqFIKMrYhO3A5iSGKuDNKCkcmKyK/5jvK Vjab4wDsVqc5FK8173zl6Yp+NUqT1G5Z16UzPX8sMCfiXvglnCOfU051jMyzx2lRdgv1 +1kXCcwcTdogt77v4x6w+dJfSQtT7azEk4va4= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.223.122.204 with SMTP id m12mr1838242far.73.1245386977722; Thu, 18 Jun 2009 21:49:37 -0700 (PDT) In-Reply-To: <36E1A7176AF78A864F74EAC6@PST.JCK.COM> References: <4A1D5086.9080702@joelhalpern.com> <36E1A7176AF78A864F74EAC6@PST.JCK.COM> Date: Fri, 19 Jun 2009 00:49:37 -0400 X-Google-Sender-Auth: 6c4df742bb3c44fb Message-ID: <6c9fcc2a0906182149q4ae1e57bs39b24d4561281634@mail.gmail.com> From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NomComDiscussion Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 04:49:28 -0000 There's a lot of stuff here, and I've set it aside and come back to it a few times. When I first read John's proposal, I thought many of the same things that Joel mentioned, about giving the NomCom more options to think of the slate holistically, rather than breaking the process down into stages, and so on. The further discussion has given me a different understanding. As I see it, the main failure mode in John's proposal is this one: There is an incumbent that the NomCom will be happy to return to her position, with little or no reservation. And there is at least one *significantly* better candidate who would volunteer for the position if the NomCom chose to open it up. I suggest that the other cases are either neutral or show the new proposal as better than what we have. So let's consider how likely the failure mode is to happen, and the relative effect a failure has on the IETF. I can't speak to the likelihood, but I can suggest that with the current system, it's not just the NomCom that would happily reappoint the incumbent. The community as a whole probably knows that she's doing well and will likely be reappointed, and so history shows that there are likely to be few who volunteer for her spot. That means that with the current system, we probably won't have much of a choice anyway, and so the superstar replacement probably won't be available anyway. In other words, it probably turns into a failure mode for both systems, old as well as new. As to the effect the failure has: By definition, the IETF has not gotten the optimal leader in that position. But the IETF *does* have an effective leader whom the NomCom is happy with. It strikes me that that's not so bad -- not a very serious failure. And, so, opposing my initial "gut" response (and with the understanding that I have not served on a NomCom), I find myself agreeing with John. Barry From jmh@joelhalpern.com Fri Jun 19 06:22:13 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BAEA3A6A66 for ; Fri, 19 Jun 2009 06:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.664 X-Spam-Level: X-Spam-Status: No, score=-3.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPlqqw571XQR for ; Fri, 19 Jun 2009 06:22:12 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 866CE3A6A57 for ; Fri, 19 Jun 2009 06:22:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E28F1437E49; Fri, 19 Jun 2009 06:22:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id D8766437E20; Fri, 19 Jun 2009 06:22:24 -0700 (PDT) Message-ID: <4A3B910D.5080606@joelhalpern.com> Date: Fri, 19 Jun 2009 09:22:21 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Barry Leiba References: <4A1D5086.9080702@joelhalpern.com> <36E1A7176AF78A864F74EAC6@PST.JCK.COM> <6c9fcc2a0906182149q4ae1e57bs39b24d4561281634@mail.gmail.com> In-Reply-To: <6c9fcc2a0906182149q4ae1e57bs39b24d4561281634@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John C Klensin , NomComDiscussion Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 13:22:13 -0000 Actually, if I thought the case below was the likely worst problem with the proposed separated appointment, then whatever my overall reaction was, it would be mild. The problem you describe is clearly one we can live with. Before I comment on Barry's note, and John's suggestion further, let me make a different point. John suggested in one of his notes that approving the current open-list change would be a distraction from evaluating his proposal. I would strongly disagree. It is possible, and even practical, to approve the open-list change NOW. This will allow the current nomcom (that Mary is chairing) to make use of the open-list procedure. There is no way we are going to approve John's proposed change quickly. Can we please approve the open-list procedure, even while we discuss whether we want to make larger changes. I can not speak for anyone else, but I do not see an argument of the form "We just approved X, so we should not consider very different Y just now" to be an acceptable response to the idea once we have approved open-list. Returning to John's proposal, as I said, my concern is not with the case of a strong AD and a hypothetical superstar new nominee. My concern is on the other end. And I suspect (although it is always hard to tell, even in face-to-face discussions much less email), that John's and my basic disagreement comes much more when there is no superstar, or even outstanding candidate. THe basic problem is when it is not clear cut whether the nomcom should re-appoint a given sitting individual. Assume that the person has served two terms. (The single term cases confuse the issue.) We do not, and should not in my opinion, have a rule that says "out after two." So the nomcom has to evaluate the person. They have to evaluate how well that person is doing their job. How well that person will fit with the partially known set of other people both in terms of style and in terms of skills. (I have been told of cases where the nomcom litterally had to chose between people because two people could not serve together. Also, sometimes nomcoms will use other appointments to compensate for weaknesses in one appointment.) And I consider it unacceptable to just leave the seat unfilled if we have someone who can probably do a decent job. But I would hate to have to do an initial round appointing someone who is only expected to probably do a decent job. Sometimes, if the nomcom beats the bushes a bit, good nominees surface. Sometimes, when the nomcom beats the bushes, they just get scratches on their hands. Failing to appoint an AD because the procedure says "you can not go back to the decent but not great candidate you passed over because he is an incumbent" seems like a bad box to put yourself in. Yours, Joel M. Halpern Barry Leiba wrote: > There's a lot of stuff here, and I've set it aside and come back to it > a few times. When I first read John's proposal, I thought many of the > same things that Joel mentioned, about giving the NomCom more options > to think of the slate holistically, rather than breaking the process > down into stages, and so on. > > The further discussion has given me a different understanding. > > As I see it, the main failure mode in John's proposal is this one: > There is an incumbent that the NomCom will be happy to return to her > position, with little or no reservation. And there is at least one > *significantly* better candidate who would volunteer for the position > if the NomCom chose to open it up. > > I suggest that the other cases are either neutral or show the new > proposal as better than what we have. So let's consider how likely > the failure mode is to happen, and the relative effect a failure has > on the IETF. > > I can't speak to the likelihood, but I can suggest that with the > current system, it's not just the NomCom that would happily reappoint > the incumbent. The community as a whole probably knows that she's > doing well and will likely be reappointed, and so history shows that > there are likely to be few who volunteer for her spot. That means > that with the current system, we probably won't have much of a choice > anyway, and so the superstar replacement probably won't be available > anyway. > > In other words, it probably turns into a failure mode for both > systems, old as well as new. > > As to the effect the failure has: By definition, the IETF has not > gotten the optimal leader in that position. But the IETF *does* have > an effective leader whom the NomCom is happy with. > > It strikes me that that's not so bad -- not a very serious failure. > > And, so, opposing my initial "gut" response (and with the > understanding that I have not served on a NomCom), I find myself > agreeing with John. > > Barry > From bernie@ietf.hoeneisen.ch Fri Jun 19 10:26:52 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B5B3A684A for ; Fri, 19 Jun 2009 10:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHZCB8I+sc+P for ; Fri, 19 Jun 2009 10:26:50 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 439B63A6812 for ; Fri, 19 Jun 2009 10:26:49 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1MHhrR-0005Nm-VX; Fri, 19 Jun 2009 19:26:46 +0200 Date: Fri, 19 Jun 2009 19:26:45 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "Joel M. Halpern" In-Reply-To: <4A3B910D.5080606@joelhalpern.com> Message-ID: References: <4A1D5086.9080702@joelhalpern.com> <36E1A7176AF78A864F74EAC6@PST.JCK.COM> <6c9fcc2a0906182149q4ae1e57bs39b24d4561281634@mail.gmail.com> <4A3B910D.5080606@joelhalpern.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: John C Klensin , Barry Leiba , NomComDiscussion Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 17:26:52 -0000 To state my point, I can support what Joel already said: - We should not hold up openlist because of John's proposal, as the latter is a rather radical change to the existing process. IMHO John's proposal belongs to a 3777bis-like discussion, whereas openlist is just an optimization of 3777. - I share Joel's concerns as NomCom's task is to select a whole group of people that needs to address many tasks as a group. Balance of skills and compatibility of people within this group are of high importance for the good of the community. As I understood John's proposal, it limits the possibilities of NomCom to select a group that meets the mentioned requirements. Even with the current rules this can be really challenging. cheers, Bernie On Fri, 19 Jun 2009, Joel M. Halpern wrote: > Actually, if I thought the case below was the likely worst problem with the > proposed separated appointment, then whatever my overall reaction was, it > would be mild. The problem you describe is clearly one we can live with. > > Before I comment on Barry's note, and John's suggestion further, let me make > a different point. > John suggested in one of his notes that approving the current open-list > change would be a distraction from evaluating his proposal. I would strongly > disagree. > It is possible, and even practical, to approve the open-list change NOW. > This will allow the current nomcom (that Mary is chairing) to make use of the > open-list procedure. > There is no way we are going to approve John's proposed change quickly. > Can we please approve the open-list procedure, even while we discuss whether > we want to make larger changes. I can not speak for anyone else, but I do > not see an argument of the form "We just approved X, so we should not > consider very different Y just now" to be an acceptable response to the idea > once we have approved open-list. > > > > Returning to John's proposal, as I said, my concern is not with the case of a > strong AD and a hypothetical superstar new nominee. My concern is on the > other end. And I suspect (although it is always hard to tell, even in > face-to-face discussions much less email), that John's and my basic > disagreement comes much more when there is no superstar, or even outstanding > candidate. > > THe basic problem is when it is not clear cut whether the nomcom should > re-appoint a given sitting individual. Assume that the person has served two > terms. (The single term cases confuse the issue.) We do not, and should not > in my opinion, have a rule that says "out after two." So the nomcom has to > evaluate the person. They have to evaluate how well that person is doing > their job. How well that person will fit with the partially known set of > other people both in terms of style and in terms of skills. (I have been > told of cases where the nomcom litterally had to chose between people because > two people could not serve together. Also, sometimes nomcoms will use other > appointments to compensate for weaknesses in one appointment.) > And I consider it unacceptable to just leave the seat unfilled if we have > someone who can probably do a decent job. But I would hate to have to do an > initial round appointing someone who is only expected to probably do a decent > job. > > Sometimes, if the nomcom beats the bushes a bit, good nominees surface. > Sometimes, when the nomcom beats the bushes, they just get scratches on their > hands. Failing to appoint an AD because the procedure says "you can not go > back to the decent but not great candidate you passed over because he is an > incumbent" seems like a bad box to put yourself in. > > Yours, > Joel M. Halpern > > > Barry Leiba wrote: >> There's a lot of stuff here, and I've set it aside and come back to it >> a few times. When I first read John's proposal, I thought many of the >> same things that Joel mentioned, about giving the NomCom more options >> to think of the slate holistically, rather than breaking the process >> down into stages, and so on. >> >> The further discussion has given me a different understanding. >> >> As I see it, the main failure mode in John's proposal is this one: >> There is an incumbent that the NomCom will be happy to return to her >> position, with little or no reservation. And there is at least one >> *significantly* better candidate who would volunteer for the position >> if the NomCom chose to open it up. >> >> I suggest that the other cases are either neutral or show the new >> proposal as better than what we have. So let's consider how likely >> the failure mode is to happen, and the relative effect a failure has >> on the IETF. >> >> I can't speak to the likelihood, but I can suggest that with the >> current system, it's not just the NomCom that would happily reappoint >> the incumbent. The community as a whole probably knows that she's >> doing well and will likely be reappointed, and so history shows that >> there are likely to be few who volunteer for her spot. That means >> that with the current system, we probably won't have much of a choice >> anyway, and so the superstar replacement probably won't be available >> anyway. >> >> In other words, it probably turns into a failure mode for both >> systems, old as well as new. >> >> As to the effect the failure has: By definition, the IETF has not >> gotten the optimal leader in that position. But the IETF *does* have >> an effective leader whom the NomCom is happy with. >> >> It strikes me that that's not so bad -- not a very serious failure. >> >> And, so, opposing my initial "gut" response (and with the >> understanding that I have not served on a NomCom), I find myself >> agreeing with John. >> >> Barry >> > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From jmh@joelhalpern.com Fri Jun 19 13:02:44 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C89A3A6C34 for ; Fri, 19 Jun 2009 13:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.657 X-Spam-Level: X-Spam-Status: No, score=-3.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymFrq+2qgkAn for ; Fri, 19 Jun 2009 13:02:42 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3E74E3A6BF9 for ; Fri, 19 Jun 2009 13:02:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B70D2430214; Fri, 19 Jun 2009 13:02:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 133AB4301E0; Fri, 19 Jun 2009 13:02:54 -0700 (PDT) Message-ID: <4A3BEEEB.60502@joelhalpern.com> Date: Fri, 19 Jun 2009 16:02:51 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christian Huitema References: <4A1D5086.9080702@joelhalpern.com> <36E1A7176AF78A864F74EAC6@PST.JCK.COM> <6c9fcc2a0906182149q4ae1e57bs39b24d4561281634@mail.gmail.com> <4A3B910D.5080606@joelhalpern.com> <6B55F0F93C3E9D45AF283313B8D342BA014437@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA014437@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NomComDiscussion Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 20:02:44 -0000 I believe most nomcoms understand that turnover is important. So far, the community has refrained from turning that into a hard and fast rule, which I think is a good thing. Looking at the history, there has been consistent turnover at about the level I would like to see, or maybe a bit faster than I am think is really desirable, but within reason. Yours, Joel Christian Huitema wrote: >> THe basic problem is when it is not clear cut whether the nomcom should >> re-appoint a given sitting individual. Assume that the person has >> served two terms. (The single term cases confuse the issue.) We do >> not, and should not in my opinion, have a rule that says "out after >> two." So the nomcom has to evaluate the person... > > I understand the desire to not have term limits, but such limits are actually the best way to avoid the failure mode I fear most, the "old boyz club". If there is not some kind of limit, or at least encouragement to the nomcom to "get new blood", incumbents can be there for life, as long as they are not grossly incompetent, or bored. > > -- Christian Huitema > > > > From sm@resistor.net Fri Jun 19 14:10:40 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54513A68BC for ; Fri, 19 Jun 2009 14:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 085KVmBjOWwg for ; Fri, 19 Jun 2009 14:10:39 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id A14E53A6824 for ; Fri, 19 Jun 2009 14:10:39 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n5JLAdYK013109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jun 2009 14:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1245445848; x=1245532248; bh=UR9LcOQ/Ys6UR+lZMLPgJHoQ7LQdum6kXg8Jw65qvgU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=DIp6sX9sU3jjrKOtJrnQriYVfOOQwynbpG1f7N85LtQ0k80TlkkI36UEZEHDsoJ6T NZ/++7Mkvb3LxgKlCOsyv4lrdOpZBvsOUTg3rn/J1YG94oWm6MjYud7XoCtnCugc2L aQpVjfzFX/AY8xU1elTbd49VtUEFSpqXDZDDOFfQ= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=eJcXZn/06vWokpjpJy6jxbq7TkYt/gW5buF85IkRBgzlehnlL68XBapTEnlk5AGlN 3hPmoBn0pvhI/KC29nCYHtNgS0Ecx/ZxNqyt0Qp6Kj7nycuYwT+z7x24KFgKAE8SSLn jlXBTTAH5/DuRfPOJUH5MokM+NYIreK//EHbN4c= Message-Id: <6.2.5.6.2.20090619123239.03040128@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 19 Jun 2009 14:07:49 -0700 To: "Joel M. Halpern" From: SM In-Reply-To: <4A3B910D.5080606@joelhalpern.com> References: <4A1D5086.9080702@joelhalpern.com> <36E1A7176AF78A864F74EAC6@PST.JCK.COM> <6c9fcc2a0906182149q4ae1e57bs39b24d4561281634@mail.gmail.com> <4A3B910D.5080606@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: NomComDiscussion Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 21:10:40 -0000 Hi Joel, At 06:22 19-06-2009, Joel M. Halpern wrote: >John suggested in one of his notes that approving the current >open-list change would be a distraction from evaluating his >proposal. I would strongly disagree. Having an open list fulfills our innate curiosity. If the open-list change goes through, it will delay John's proposal as the community will wait to see the results. These micro-changes, which may have major effects, have brought up questions about the process. There was a comment about whether a sentence in draft-dawkins-nomcom-openlist should have used a "must" instead of a "should". This highlights the frame of mind in reading that document. We are accustomed to using RFC 2119 key words in documenting protocols. Is this document a protocol or to put it differently, will we reach the best outcome by following a protocol? Even draft-dawkins-nomcom-openlist has exceptions. In my opinion, this shows that we cannot craft narrow rules as we also have to consider the circumstances. Is there an ideal candidate for the opening? If there were, we would be choosing a stereotype which would prevent any change in the body from within. That can be good if we want to go on with business as usual. But that creates a disconnect between the community and the body. The feedback from the community demonstrates that most participants keep away from process issues. We only have to look at the NomCom roll call each year to see that it is a particular subset of the community. Regards, -sm From huitema@windows.microsoft.com Fri Jun 19 12:29:09 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E10D3A6B52 for ; Fri, 19 Jun 2009 12:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMA4LRHiqKGt for ; Fri, 19 Jun 2009 12:29:08 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 0A8383A6ADA for ; Fri, 19 Jun 2009 12:29:07 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 19 Jun 2009 12:29:20 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.601.1; Fri, 19 Jun 2009 12:29:20 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.224]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Fri, 19 Jun 2009 12:29:20 -0700 From: Christian Huitema To: "Joel M. Halpern" , Barry Leiba Thread-Topic: [ietf-nomcom] Changing the candidate selection model Thread-Index: AcntPNYHkH62t+UWR2qNehIHXw849QDly9OAABHoMoAAAfnfEA== Date: Fri, 19 Jun 2009 19:29:19 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA014437@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <4A1D5086.9080702@joelhalpern.com> <36E1A7176AF78A864F74EAC6@PST.JCK.COM> <6c9fcc2a0906182149q4ae1e57bs39b24d4561281634@mail.gmail.com> <4A3B910D.5080606@joelhalpern.com> In-Reply-To: <4A3B910D.5080606@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 21 Jun 2009 09:59:26 -0700 Cc: John C Klensin , NomComDiscussion Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 19:29:09 -0000 > THe basic problem is when it is not clear cut whether the nomcom should > re-appoint a given sitting individual. Assume that the person has > served two terms. (The single term cases confuse the issue.) We do > not, and should not in my opinion, have a rule that says "out after > two." So the nomcom has to evaluate the person... I understand the desire to not have term limits, but such limits are actual= ly the best way to avoid the failure mode I fear most, the "old boyz club".= If there is not some kind of limit, or at least encouragement to the nomco= m to "get new blood", incumbents can be there for life, as long as they are= not grossly incompetent, or bored. -- Christian Huitema From spencer@wonderhamster.org Sun Jun 21 10:41:26 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E15D3A6CE6 for ; Sun, 21 Jun 2009 10:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-o7ujzKlJeS for ; Sun, 21 Jun 2009 10:41:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 798A23A69D9 for ; Sun, 21 Jun 2009 10:41:22 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MIR2q1zS6-000d01; Sun, 21 Jun 2009 13:41:36 -0400 Message-ID: <1C77F73ECFC44126B40F5B9541F0DC33@china.huawei.com> From: "Spencer Dawkins" To: "John C Klensin" , "Joel M. Halpern" , "NomComDiscussion" References: <4A1D5086.9080702@joelhalpern.com> <36E1A7176AF78A864F74EAC6@PST.JCK.COM> Date: Sun, 21 Jun 2009 12:41:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18+s57++WUVYVN6t/jeopo8Sj+d11HIm7H4mAW sUpdnfOtX9HtKeAyMpBokKvfhIh19BjodFYWk3ACbAX3UFyz1U pDvjFrYBmwOc4alkE1QKLLy9ZLsHV481NQaloL7GHg= Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 17:41:26 -0000 Sorry that I disappeared just before you sent this reply. On balance I think that it was well-written and (even more exciting to me) addresses MY issues that we've discussed, even the ones I think may very well not apply to you on corporate support. If it seems to you that a positive statement would be helpful, please let me know, and I'll say so onlist. If it seems that I'd be more likely to wake up one or more flakes, please let me know, and I'll be quiet! Thanks, Spencer > Sorry to have taken so long to get back to this. Other work... > > Joel, at the risk of being heretical, the job of the Nomcom is > not exclusively to "pick the best candidate". It doesn't have > enough information to do that, partially because (with one > qualification that I'll discuss below) incumbents are a known > quantity while non-incumbent nominees are not. So the job, in > practice, is to evaluate the strength of an incumbent's > performance, the advantages and disadvantages of long tenure, > and then to make a judgment about whether an alternate nominee > would be worth the risk than any non-incumbent might constitute. > Only if there is no incumbent does the Nomcom, in practice, > actually get to make a "best candidate" decision with all of the > Nominees evaluated on an equal basis. > > If you tell me that isn't what happens, I'll have to believe you > somehow because I don't have the inside information that you do, > but what I know about organizational behavior and selection/ > election processes causes me to doubt that any other formulation > is plausible, even though "pick the best candidate" sounds good > in theory. Even if that were the only factor, if there is an > incumbent who is willing to serve another term, a Nomcom > realistically has to balance the qualities and record of that > incumbent against the calculated risks posed by other nominees. > > Another job of the Nomcom --and the rules that enable it-- is to > ensure that the maximum number of qualified people are willing > to offer themselves as nominees for a given role. If there are > impediments that discourage people from being nominated who > might be willing and able to serve, we should seek to eliminate > or reduce those impediments. > > Consider, for example, that we keep pushing the date at which > nominees are expected to tentatively commit themselves further > and further back. The RFC5078 timeline implies about eight > months between the first announcement of open positions and call > for nominees and the date on which decisions are announced. Now > let's assume that we've got some potential nominees who have to > go to their management in June and say > > "I'd like to sign up for a two-year position with the > IETF. It requires that you commit, right now, to > dedicating two years of my time, starting next March, to > this role which I may or may not get. That commitment > implies that I shouldn't be put on projects in the next > eight months which would be in trouble if I had to drop > them in March with, if we are lucky, a month's notice, > so I'm on reduced functionality for eight months and > then may largely disappear for two years. > > "Incidentally, while the rules would permit us to back > out in February if circumstances change, > draft-dawkins-nomcom-openlist will make that much more > obvious, and possibly an embarrassment to the company, > especially if I'm the only non-incumbent nominee. And, > since, at least statistically, the Nomcom routinely > returns incumbents, especially those who have served > only one previous term, the odds of my actually being > selected are low." > > That scenario is _not_ a way to build large nominee pools. > Worse, our current expectation is essentially that the same > people will not only do it once but, after not being selected > that year, will come back to their managers three or four months > after the selections are announced and say "Remember what we > went through last time? I think we should do it again.". > Perhaps large companies who are willing to donate a certain > fraction of their staffs to the IETF don't care. Perhaps people > who work for such companies but who are in a position to > allocate very significant fractions of their time however they > like are unaffected. > > I think the IETF would be better off with much more diversity in > the nominee pools -- while I'm grateful for the dedication of > the companies involved, I don't believe that it is a good sign > that, of the membership on the IESG and IAB, three companies > support three people each and another one supports two. I'm > not concerned about conspiracy theories here but about the > observation that, with nearly 25% of the Nomcom-appointed IESG > and IAB positions in the hands of four organizations, how much > trouble we would be in if one or more of them got into serious > trouble and withdrew support. > > I do not believe that this proposal will solve the problem of > concentration of slots in the hands of a few organizations (if > indeed once considers it a problem). But I think anything we > can do that broadens the Nomcom's effective range of choices > would be a good idea. > >>From my point of view, your reaction to the proposal is based on > an assumption that the current model has no adverse > consequences. I think it does and am suggesting that those > consequences are severe enough that it is time to make the > tradeoffs somewhat differently. > > Some specific comments below. > > --On Wednesday, May 27, 2009 10:39 -0400 "Joel M. Halpern" > wrote: > >> Having read the draft, it seems to me that this is a bad idea. >> >> Firstly, I am not sure what problem it solves. There is >> apparently some concern about whether the nomcom is returning >> too many or too few incumbents. > > Actually, that is not a concern or problem we were trying to > solve in this draft. Instead, we started with the knowledge > that, whether it was reasonable or not, about half were returned > each time (as you note). We examined the "ask the boss" > scenario outlined above and some similar ones and added in the > concerns about "running against" someone (especially an > incumbent) from the same or a related organization that have > been expressed in conjunction with discussions of > draft-dawkins-nomcom-openlist and concluded that, on balance, we > would have much higher odds of having a good nominee pool when > it was needed if we separated incumbent evaluation from > consideration of new Nominees. > > We also believe (although we could be wrong, especially given > the tendency for work to expand to fill the available time) that > the separation would reduce the total workload, and time > requirements, on the Nomcom. If it did and the effect of that > were to broaden the pool of Nomcom volunteers, that would also, > in our opinion, be good for the IETF. > >>... >> At the same time, this proposal seems to actually make it >> harder for the nomcom to do a good job. The goal is to >> appoint the best available person to the job. >> Choosing to re-appoint or not re-appoint an incumbent without >> comparison with considering who else may be available and >> qualified is not, it seems to me, able to meet that goal. > > Our disconnect here lies in your use of "best available". > Certainly, that is correct if what you intended to say is "best > available among those who volunteered to be nominees. But the > current model is almost certainly reducing the number of > available nominees. In some ways, that makes the Nomcom's job > easier. But encouraging people to nominate themselves against > incumbents who, statistically, will be returned anyway does not > give you a good pool of "available" nominees when the Nomcom > needs them. > > If you don't consider it a breach of confidentiality (since you > would not need to discuss any particular candidate, I think it > does not), it would help in this discussion if you would reveal > the number of plausible nominees you had available for each slot > in the last year. > >> It seems to me that the general notion of how many incumbents >> ought to be returned in any given cycle depends heavily on how >> many good alternatives there are. So I would hate to require >> the committee to make that decision without having that >> information. > > It seems to me that, if a Nomcom starts making decisions about > how many incumbents to return, as a count, we are in deep > trouble. Fred's rumored examples, in which "all of the > incumbents were deemed good to return but the nomcom felt > obliged to sacrifice one, and did so, with quite a bit of hurt > feelings around the community. [...] And one could just as > easily imagine a case in which the nomcom felt that none should > be returned." both strike me as serious mistakes. > > Indeed, while nothing in either the current system or the > proposed one could stop a Nomcom from going down some sort of > "quota of incumbents to be returned" path if it decided it > wanted to, part of the intent of the proposal is to focus > attention away from that approach. There are a few implicit > assumptions in this model which I will try to clarify in the > next draft. One of them is that incumbents should be evaluated > on performance --both theirs and that of the body to which they > are contributing-- and returned there are signs of > non-performance, bad behavior, or burnout. Of course, that > doesn't obligate those incumbents to be available for additional > terms. But the read-in costs and uncertainties of putting in a > new person are sufficiently high that, if an incumbent is > serving well and effectively in a body that is working well and > wants to continue doing so, we should "let" him or her. > > If we don't believe that, then this is a bad proposal. But, > again, if one judges from the statistics, that is, with rare > exceptions, exactly how Nomcoms are behaving. The difference is > that they are behaving that way after exerting more or less > considerable efforts to collect other nominees (possibly making > those people unavailable when they are really needed, as > discussed above) and after spending lots of their time to see if > they can do better. > >> More important than the abstract failure mode, there are >> multiple specific failure modes that would do a disservice to >> the community and the nomcom. If the nomcom has many >> qualified incumbents, if doing a stand-alone evaluation it may >> choose to return rather more incumbents than it would if it >> knew that some of those seats had good nominees available. > > You can't have it both ways. One goal is well-qualified people > with minimum risk that they cannot or will not do the job. If > that is it, then the discussion about incumbents above is > relevant because "good nominees" are always going to be a risk, > if only because we've had ample examples of the Peter Principle > playing out in the IETF as well as in other organizational > settings. A different goal is to insure turnover by preferring > "good nominees" to incumbents. If that is your preference, the > way to accomplish it is to be explicit about it and impose > rotation rules (term limits, more or less) with an exception > procedure. > >> Similarly, if the nomcom wishes to choose among the >> incumbents, because it feels that the good ones would still >> represent returning too many, the nomcom really needs to know >> who else is available. Conversely, it is quite possible that >> the nomcom would, in a stand-alone evaluation, decide that >> some incumbent was not quite as good as they would like, and >> choose not to appoint him. Only to discover that said >> incumbent is significantly better than any of the nominees >> they evaluate. > > Here is where we have a significant difference of opinion that, > I believe, would make a real difference. Let's assume that we > have an incumbent who is not very good but sort of getting by > despite several liabilities, and potential other nominees who > are unlikely to be any better. At that point, it seems to me > that you are suggesting that, under the current system, the > Nomcom should select, not a "good" or "best" candidate (because > there isn't one) but rather pick the least bad one. The > proposed system would certainly make that harder. > > By contrast, I believe that, if an incumbent is not performing > well, returning him or her is almost always a mistake. It > weakens the IETF and the relevant body to have someone who is > underperforming continue. Perhaps worse, we've had a number of > cases in which someone has been returned to a body in spite of a > record of bad behavior, only to have that person behave as if > reappointment constitutes endorsement of the behavior and > increase it. We've also found that comments from Nomcoms or > others are of no help in preventing further inappropriate > behavior. > >>From that perspective, if the Nomcom makes a decision that > someone is not performing adequately, I believe that person > should be retired or removed. If the Nomcom cannot then find a > nominee in whom it has high confidence, I believe that any of > the three alternatives are better than going back to the > incumbent: the Nomcom searches harder and gets more creative, > the Nomcom decides to take the risk with a Nominee who has at > least not already proven to be inappropriate for the role, or > the Nomcom explicitly decides to not fill the position because > there are no plausible candidates. In the latter case, I'd > expect the relevant body to be forced to either run short-handed > or restructure and that either of those options would be better > for the IETF that proceeding with weak leadership because some > earlier structure required it. > > The proposed model makes the "retire the underperforming > incumbent" scenario a little more efficient and likely to > succeed, but the comments above apply even under the current > model: if a Nomcom deliberately puts a "least unsatisfactory" > nominee (whether incumbent or not) into a job, it is doing the > community no favors. And, as I have suggested above, the > proposed model is reasonably likely to give the Nomcom a broader > range of choices and thereby lower the odds of getting into that > situation. > >> The document seems to suggest that the answer to some of these >> issues is to assume that there are always enough good >> nominees, and that if there are not, maybe the seat should go >> unfilled. This is sufficiently far from my understanding of >> the realities that it seems a dangerous assumption. > > Again, my observation of the realities is that selection of the > "best available" person, even if that person is known to be weak > as a candidate, is not merely a danger, but an almost-certain > problem. > >> There is another dimension in which I have serious concerns >> with this proposal. One of the things the nomcom evaluates, >> for all bodies, is the balance of members. That balance may, >> in different years, be reflective of different aspects of >> skills, knowledge, contacts, etc... But That kind of >> balancing has been seen as important in may cases. >> Pre-selecting which incumbents will remain, and which will >> not, means that such balancing can not be used as part of the >> selection. > > Again, I don't think so. Resignations and other rare and > exceptional cases notwithstanding, a Nomcom does not get the > option of replacing (or considering replacing) more than half of > a given body in a given year. Given that, any attempted > "balancing" has to consider balance with at least half the > membership of the relevant body as a given -- the balance must > consider the incumbents who are not up for renewal, a group whom > the Nomcom cannot affect. So the question is whether choices > of which incumbents to return can significantly aid or interfere > with balance given that established base. I believe that, if > the body is sufficiently out of balance that special > considerations of incumbents are needed, that lack of balance > will usually show up as disfunction and make it clear which > incumbents should be removed, regardless of the order in which > things are done. Conversely, if the perceived imbalance is > dictated by principles too subtle to show up in that way, I'm > willing to sacrifice giving the Nomcom an option that would seem > to put "balance" ahead of "best candidate". YMMD. > >> Also, it is my opinion that this would significantly increase >> the time for the selection process. The selection process is >> not linear. As such, while the number of seats to be filled >> has some effect on the time, it is not a significant factor. >> (Issues of collecting input, and whether particular choices >> are easy or hard, make more difference.) While this work could >> possibly be overlapped with some portion of the nomination >> selection, it clearly would need to be completed, confirmed, >> and announced before nominations were considered usable, since >> nominations would clearly need these results if this process >> were to take place. As such, I believe it would add several >> months to the process. > > Here, I am at a disadvantage because I don't have your in-Nomcom > experience. But my reading of the situation is that a review > of, at most, a dozen people, without any need to compare them to > others, is not going to take very long as compared to an > in-depth review of several people per open slot. And, by > eliminating slots that need to be considered, and for which > nominees need to be collected, one can further reduce workload. > I don't see how it could be otherwise unless there is a desire > to drag things out. > >> It is also the case that the differences in kinds of seats >> makes some difference. Even if it were somehow concluded that >> this made sense for the IESG, I can not see why one would >> apply it to the IAB. In the case of the IAB, one is not >> nominated against any one individual, but rather nominated for >> a seat in a pool. As such, none of the arguments presented >> about the open nominee list seem to apply to the IAB. And >> even more than the IESG (where some balancing issues do apply) >> the community consensus has seemed to me quite clear that >> balance of various kinds are a set of very important factors >> in selecting IAB members. > > When we started with this, we started with an "IESG only" > assumption. While it seemed useful to explore whether it could > (and should) also be applied to the IAB and any other > Nomcom-selected positions, I'd be happy to go back to "IESG > only" if that proposal made sense. > >>... > > best, > john > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From spencer@wonderhamster.org Sun Jun 21 11:11:32 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BDAF3A68F9 for ; Sun, 21 Jun 2009 11:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ5csteUpGfG for ; Sun, 21 Jun 2009 11:11:29 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 658CB3A67B4 for ; Sun, 21 Jun 2009 11:11:29 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MIRVz01jt-000d9y; Sun, 21 Jun 2009 14:11:42 -0400 Message-ID: <810DA0DF808E4062B65E157354CEE032@china.huawei.com> From: "Spencer Dawkins" To: "John C Klensin" , "Joel M. Halpern" , "NomComDiscussion" References: <4A1D5086.9080702@joelhalpern.com><36E1A7176AF78A864F74EAC6@PST.JCK.COM> <1C77F73ECFC44126B40F5B9541F0DC33@china.huawei.com> Date: Sun, 21 Jun 2009 13:11:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19lRN9L95p5SiWcKcTY9DFMNHLZaa1qHVC1HL5 X4x7HAL7gQ0AlfxIzE27H8N7T91rX3egSZAPHFz1Su2xdc1ULW jPE5s1qaO+CrVcZ6dbEh1emH4q0XVQNt44l0/uBBQo= Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 18:11:32 -0000 Obviously this was sent in error... my apologies to all. Spencer > Sorry that I disappeared just before you sent this reply. > > On balance I think that it was well-written and (even more exciting to me) > addresses MY issues that we've discussed, even the ones I think may very > well not apply to you on corporate support. > > If it seems to you that a positive statement would be helpful, please let > me know, and I'll say so onlist. If it seems that I'd be more likely to > wake up one or more flakes, please let me know, and I'll be quiet! > > Thanks, > > Spencer > > >> Sorry to have taken so long to get back to this. Other work... >> >> Joel, at the risk of being heretical, the job of the Nomcom is >> not exclusively to "pick the best candidate". It doesn't have >> enough information to do that, partially because (with one >> qualification that I'll discuss below) incumbents are a known >> quantity while non-incumbent nominees are not. So the job, in >> practice, is to evaluate the strength of an incumbent's >> performance, the advantages and disadvantages of long tenure, >> and then to make a judgment about whether an alternate nominee >> would be worth the risk than any non-incumbent might constitute. >> Only if there is no incumbent does the Nomcom, in practice, >> actually get to make a "best candidate" decision with all of the >> Nominees evaluated on an equal basis. >> >> If you tell me that isn't what happens, I'll have to believe you >> somehow because I don't have the inside information that you do, >> but what I know about organizational behavior and selection/ >> election processes causes me to doubt that any other formulation >> is plausible, even though "pick the best candidate" sounds good >> in theory. Even if that were the only factor, if there is an >> incumbent who is willing to serve another term, a Nomcom >> realistically has to balance the qualities and record of that >> incumbent against the calculated risks posed by other nominees. >> >> Another job of the Nomcom --and the rules that enable it-- is to >> ensure that the maximum number of qualified people are willing >> to offer themselves as nominees for a given role. If there are >> impediments that discourage people from being nominated who >> might be willing and able to serve, we should seek to eliminate >> or reduce those impediments. >> >> Consider, for example, that we keep pushing the date at which >> nominees are expected to tentatively commit themselves further >> and further back. The RFC5078 timeline implies about eight >> months between the first announcement of open positions and call >> for nominees and the date on which decisions are announced. Now >> let's assume that we've got some potential nominees who have to >> go to their management in June and say >> >> "I'd like to sign up for a two-year position with the >> IETF. It requires that you commit, right now, to >> dedicating two years of my time, starting next March, to >> this role which I may or may not get. That commitment >> implies that I shouldn't be put on projects in the next >> eight months which would be in trouble if I had to drop >> them in March with, if we are lucky, a month's notice, >> so I'm on reduced functionality for eight months and >> then may largely disappear for two years. >> >> "Incidentally, while the rules would permit us to back >> out in February if circumstances change, >> draft-dawkins-nomcom-openlist will make that much more >> obvious, and possibly an embarrassment to the company, >> especially if I'm the only non-incumbent nominee. And, >> since, at least statistically, the Nomcom routinely >> returns incumbents, especially those who have served >> only one previous term, the odds of my actually being >> selected are low." >> >> That scenario is _not_ a way to build large nominee pools. >> Worse, our current expectation is essentially that the same >> people will not only do it once but, after not being selected >> that year, will come back to their managers three or four months >> after the selections are announced and say "Remember what we >> went through last time? I think we should do it again.". >> Perhaps large companies who are willing to donate a certain >> fraction of their staffs to the IETF don't care. Perhaps people >> who work for such companies but who are in a position to >> allocate very significant fractions of their time however they >> like are unaffected. >> >> I think the IETF would be better off with much more diversity in >> the nominee pools -- while I'm grateful for the dedication of >> the companies involved, I don't believe that it is a good sign >> that, of the membership on the IESG and IAB, three companies >> support three people each and another one supports two. I'm >> not concerned about conspiracy theories here but about the >> observation that, with nearly 25% of the Nomcom-appointed IESG >> and IAB positions in the hands of four organizations, how much >> trouble we would be in if one or more of them got into serious >> trouble and withdrew support. >> >> I do not believe that this proposal will solve the problem of >> concentration of slots in the hands of a few organizations (if >> indeed once considers it a problem). But I think anything we >> can do that broadens the Nomcom's effective range of choices >> would be a good idea. >> >>>From my point of view, your reaction to the proposal is based on >> an assumption that the current model has no adverse >> consequences. I think it does and am suggesting that those >> consequences are severe enough that it is time to make the >> tradeoffs somewhat differently. >> >> Some specific comments below. >> >> --On Wednesday, May 27, 2009 10:39 -0400 "Joel M. Halpern" >> wrote: >> >>> Having read the draft, it seems to me that this is a bad idea. >>> >>> Firstly, I am not sure what problem it solves. There is >>> apparently some concern about whether the nomcom is returning >>> too many or too few incumbents. >> >> Actually, that is not a concern or problem we were trying to >> solve in this draft. Instead, we started with the knowledge >> that, whether it was reasonable or not, about half were returned >> each time (as you note). We examined the "ask the boss" >> scenario outlined above and some similar ones and added in the >> concerns about "running against" someone (especially an >> incumbent) from the same or a related organization that have >> been expressed in conjunction with discussions of >> draft-dawkins-nomcom-openlist and concluded that, on balance, we >> would have much higher odds of having a good nominee pool when >> it was needed if we separated incumbent evaluation from >> consideration of new Nominees. >> >> We also believe (although we could be wrong, especially given >> the tendency for work to expand to fill the available time) that >> the separation would reduce the total workload, and time >> requirements, on the Nomcom. If it did and the effect of that >> were to broaden the pool of Nomcom volunteers, that would also, >> in our opinion, be good for the IETF. >> >>>... >>> At the same time, this proposal seems to actually make it >>> harder for the nomcom to do a good job. The goal is to >>> appoint the best available person to the job. >>> Choosing to re-appoint or not re-appoint an incumbent without >>> comparison with considering who else may be available and >>> qualified is not, it seems to me, able to meet that goal. >> >> Our disconnect here lies in your use of "best available". >> Certainly, that is correct if what you intended to say is "best >> available among those who volunteered to be nominees. But the >> current model is almost certainly reducing the number of >> available nominees. In some ways, that makes the Nomcom's job >> easier. But encouraging people to nominate themselves against >> incumbents who, statistically, will be returned anyway does not >> give you a good pool of "available" nominees when the Nomcom >> needs them. >> >> If you don't consider it a breach of confidentiality (since you >> would not need to discuss any particular candidate, I think it >> does not), it would help in this discussion if you would reveal >> the number of plausible nominees you had available for each slot >> in the last year. >> >>> It seems to me that the general notion of how many incumbents >>> ought to be returned in any given cycle depends heavily on how >>> many good alternatives there are. So I would hate to require >>> the committee to make that decision without having that >>> information. >> >> It seems to me that, if a Nomcom starts making decisions about >> how many incumbents to return, as a count, we are in deep >> trouble. Fred's rumored examples, in which "all of the >> incumbents were deemed good to return but the nomcom felt >> obliged to sacrifice one, and did so, with quite a bit of hurt >> feelings around the community. [...] And one could just as >> easily imagine a case in which the nomcom felt that none should >> be returned." both strike me as serious mistakes. >> >> Indeed, while nothing in either the current system or the >> proposed one could stop a Nomcom from going down some sort of >> "quota of incumbents to be returned" path if it decided it >> wanted to, part of the intent of the proposal is to focus >> attention away from that approach. There are a few implicit >> assumptions in this model which I will try to clarify in the >> next draft. One of them is that incumbents should be evaluated >> on performance --both theirs and that of the body to which they >> are contributing-- and returned there are signs of >> non-performance, bad behavior, or burnout. Of course, that >> doesn't obligate those incumbents to be available for additional >> terms. But the read-in costs and uncertainties of putting in a >> new person are sufficiently high that, if an incumbent is >> serving well and effectively in a body that is working well and >> wants to continue doing so, we should "let" him or her. >> >> If we don't believe that, then this is a bad proposal. But, >> again, if one judges from the statistics, that is, with rare >> exceptions, exactly how Nomcoms are behaving. The difference is >> that they are behaving that way after exerting more or less >> considerable efforts to collect other nominees (possibly making >> those people unavailable when they are really needed, as >> discussed above) and after spending lots of their time to see if >> they can do better. >> >>> More important than the abstract failure mode, there are >>> multiple specific failure modes that would do a disservice to >>> the community and the nomcom. If the nomcom has many >>> qualified incumbents, if doing a stand-alone evaluation it may >>> choose to return rather more incumbents than it would if it >>> knew that some of those seats had good nominees available. >> >> You can't have it both ways. One goal is well-qualified people >> with minimum risk that they cannot or will not do the job. If >> that is it, then the discussion about incumbents above is >> relevant because "good nominees" are always going to be a risk, >> if only because we've had ample examples of the Peter Principle >> playing out in the IETF as well as in other organizational >> settings. A different goal is to insure turnover by preferring >> "good nominees" to incumbents. If that is your preference, the >> way to accomplish it is to be explicit about it and impose >> rotation rules (term limits, more or less) with an exception >> procedure. >> >>> Similarly, if the nomcom wishes to choose among the >>> incumbents, because it feels that the good ones would still >>> represent returning too many, the nomcom really needs to know >>> who else is available. Conversely, it is quite possible that >>> the nomcom would, in a stand-alone evaluation, decide that >>> some incumbent was not quite as good as they would like, and >>> choose not to appoint him. Only to discover that said >>> incumbent is significantly better than any of the nominees >>> they evaluate. >> >> Here is where we have a significant difference of opinion that, >> I believe, would make a real difference. Let's assume that we >> have an incumbent who is not very good but sort of getting by >> despite several liabilities, and potential other nominees who >> are unlikely to be any better. At that point, it seems to me >> that you are suggesting that, under the current system, the >> Nomcom should select, not a "good" or "best" candidate (because >> there isn't one) but rather pick the least bad one. The >> proposed system would certainly make that harder. >> >> By contrast, I believe that, if an incumbent is not performing >> well, returning him or her is almost always a mistake. It >> weakens the IETF and the relevant body to have someone who is >> underperforming continue. Perhaps worse, we've had a number of >> cases in which someone has been returned to a body in spite of a >> record of bad behavior, only to have that person behave as if >> reappointment constitutes endorsement of the behavior and >> increase it. We've also found that comments from Nomcoms or >> others are of no help in preventing further inappropriate >> behavior. >> >>>From that perspective, if the Nomcom makes a decision that >> someone is not performing adequately, I believe that person >> should be retired or removed. If the Nomcom cannot then find a >> nominee in whom it has high confidence, I believe that any of >> the three alternatives are better than going back to the >> incumbent: the Nomcom searches harder and gets more creative, >> the Nomcom decides to take the risk with a Nominee who has at >> least not already proven to be inappropriate for the role, or >> the Nomcom explicitly decides to not fill the position because >> there are no plausible candidates. In the latter case, I'd >> expect the relevant body to be forced to either run short-handed >> or restructure and that either of those options would be better >> for the IETF that proceeding with weak leadership because some >> earlier structure required it. >> >> The proposed model makes the "retire the underperforming >> incumbent" scenario a little more efficient and likely to >> succeed, but the comments above apply even under the current >> model: if a Nomcom deliberately puts a "least unsatisfactory" >> nominee (whether incumbent or not) into a job, it is doing the >> community no favors. And, as I have suggested above, the >> proposed model is reasonably likely to give the Nomcom a broader >> range of choices and thereby lower the odds of getting into that >> situation. >> >>> The document seems to suggest that the answer to some of these >>> issues is to assume that there are always enough good >>> nominees, and that if there are not, maybe the seat should go >>> unfilled. This is sufficiently far from my understanding of >>> the realities that it seems a dangerous assumption. >> >> Again, my observation of the realities is that selection of the >> "best available" person, even if that person is known to be weak >> as a candidate, is not merely a danger, but an almost-certain >> problem. >> >>> There is another dimension in which I have serious concerns >>> with this proposal. One of the things the nomcom evaluates, >>> for all bodies, is the balance of members. That balance may, >>> in different years, be reflective of different aspects of >>> skills, knowledge, contacts, etc... But That kind of >>> balancing has been seen as important in may cases. >>> Pre-selecting which incumbents will remain, and which will >>> not, means that such balancing can not be used as part of the >>> selection. >> >> Again, I don't think so. Resignations and other rare and >> exceptional cases notwithstanding, a Nomcom does not get the >> option of replacing (or considering replacing) more than half of >> a given body in a given year. Given that, any attempted >> "balancing" has to consider balance with at least half the >> membership of the relevant body as a given -- the balance must >> consider the incumbents who are not up for renewal, a group whom >> the Nomcom cannot affect. So the question is whether choices >> of which incumbents to return can significantly aid or interfere >> with balance given that established base. I believe that, if >> the body is sufficiently out of balance that special >> considerations of incumbents are needed, that lack of balance >> will usually show up as disfunction and make it clear which >> incumbents should be removed, regardless of the order in which >> things are done. Conversely, if the perceived imbalance is >> dictated by principles too subtle to show up in that way, I'm >> willing to sacrifice giving the Nomcom an option that would seem >> to put "balance" ahead of "best candidate". YMMD. >> >>> Also, it is my opinion that this would significantly increase >>> the time for the selection process. The selection process is >>> not linear. As such, while the number of seats to be filled >>> has some effect on the time, it is not a significant factor. >>> (Issues of collecting input, and whether particular choices >>> are easy or hard, make more difference.) While this work could >>> possibly be overlapped with some portion of the nomination >>> selection, it clearly would need to be completed, confirmed, >>> and announced before nominations were considered usable, since >>> nominations would clearly need these results if this process >>> were to take place. As such, I believe it would add several >>> months to the process. >> >> Here, I am at a disadvantage because I don't have your in-Nomcom >> experience. But my reading of the situation is that a review >> of, at most, a dozen people, without any need to compare them to >> others, is not going to take very long as compared to an >> in-depth review of several people per open slot. And, by >> eliminating slots that need to be considered, and for which >> nominees need to be collected, one can further reduce workload. >> I don't see how it could be otherwise unless there is a desire >> to drag things out. >> >>> It is also the case that the differences in kinds of seats >>> makes some difference. Even if it were somehow concluded that >>> this made sense for the IESG, I can not see why one would >>> apply it to the IAB. In the case of the IAB, one is not >>> nominated against any one individual, but rather nominated for >>> a seat in a pool. As such, none of the arguments presented >>> about the open nominee list seem to apply to the IAB. And >>> even more than the IESG (where some balancing issues do apply) >>> the community consensus has seemed to me quite clear that >>> balance of various kinds are a set of very important factors >>> in selecting IAB members. >> >> When we started with this, we started with an "IESG only" >> assumption. While it seemed useful to explore whether it could >> (and should) also be applied to the IAB and any other >> Nomcom-selected positions, I'd be happy to go back to "IESG >> only" if that proposal made sense. >> >>>... >> >> best, >> john >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From john-ietf@jck.com Sun Jun 21 19:58:20 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F81E28C18E for ; Sun, 21 Jun 2009 19:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tysqqqwOh2Fx for ; Sun, 21 Jun 2009 19:58:19 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 81E2528C108 for ; Sun, 21 Jun 2009 19:58:18 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MIZjm-0003kz-8z; Sun, 21 Jun 2009 22:58:26 -0400 Date: Sun, 21 Jun 2009 22:58:25 -0400 From: John C Klensin To: Barry Leiba , "Joel M. Halpern" Message-ID: <60437ED43CD30EAF5FD59CA7@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: NomComDiscussion Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 02:58:20 -0000 --On Friday, June 19, 2009 00:49 -0400 Barry Leiba wrote: >... > I suggest that the other cases are either neutral or show the > new proposal as better than what we have. So let's consider > how likely the failure mode is to happen, and the relative > effect a failure has on the IETF. > > I can't speak to the likelihood, but I can suggest that with > the current system, it's not just the NomCom that would > happily reappoint the incumbent. The community as a whole > probably knows that she's doing well and will likely be > reappointed, and so history shows that there are likely to be > few who volunteer for her spot. That means that with the > current system, we probably won't have much of a choice > anyway, and so the superstar replacement probably won't be > available anyway. > > In other words, it probably turns into a failure mode for both > systems, old as well as new. > > As to the effect the failure has: By definition, the IETF has > not gotten the optimal leader in that position. But the IETF > *does* have an effective leader whom the NomCom is happy with. > It strikes me that that's not so bad -- not a very serious > failure. Right. And, fwiw, if the "ask your management for permission to stand as a nominee" scenario I outlined in an earlier note applies and the superstar replacement is persuaded to be a Nominee in year N but the incumbent is chosen anyway, the odds of the superstar being available in year N+1 (when there might be a weaker incumbent or someone ready to step down) go down at least slightly. That is one of the scenarios that leads me to believe that "incumbents first" would sometimes improve the quality of the nominee pool when it was important to have a good-quality pool, i.e., when either there is a vacancy (incumbent not willing to serve again) or a problem (incumbent fairly clearly in need of replacement). --On Friday, June 19, 2009 09:22 -0400 "Joel M. Halpern" wrote: > Returning to John's proposal, as I said, my concern is not > with the case of a strong AD and a hypothetical superstar new > nominee. My concern is on the other end. And I suspect > (although it is always hard to tell, even in face-to-face > discussions much less email), that John's and my basic > disagreement comes much more when there is no superstar, or > even outstanding candidate. Actually, I think our most basic disagreement lies somewhere else (see below). > THe basic problem is when it is not clear cut whether the > nomcom should re-appoint a given sitting individual. Assume > that the person has served two terms. (The single term cases > confuse the issue.) We do not, and should not in my opinion, > have a rule that says "out after two." So the nomcom has to > evaluate the person. They have to evaluate how well that > person is doing their job. How well that person will fit with > the partially known set of other people both in terms of style > and in terms of skills. (I have been told of cases where the > nomcom litterally had to chose between people because two > people could not serve together. Also, sometimes nomcoms will > use other appointments to compensate for weaknesses in one > appointment.) > And I consider it unacceptable to just leave the seat unfilled > if we have someone who can probably do a decent job. But I > would hate to have to do an initial round appointing someone > who is only expected to probably do a decent job. Also ignoring the single term case, I think that the empirical experience -- in the community, not necessarily the Nomcoms-- has been that, when an AD or other incumbent has served for two or more terms and can only be expected to do a "decent" job, it is time to get him or her out because, statistically and observationally, the behavior and quality of job performance always get worse. That may not be true for incumbent superstars, but they aren't at issue in this example. This case is where we have a fundamental difference of opinion. I think the IETF is put at risk when a Nomcom has few enough qualified nominees that is has to start making decisions on the basis of "this particular nominee is only the best of a bad lot, but is he or she better than nothing". Obviously, sometimes those appointments work out, but that isn't the issue. I believe that, if the Nomcom doesn't have (and can't find) an adequate number of Nominees who are both willing to serve and highly qualified, it is actually very important to take that as a symptom of "not enough depth in this particular area" and force the relevant body and the community to take that as a fact and deal with it. I am willing to leave the definitions of "adequate" and "highly qualified" to the Nomcom, but I don't want to see any appointments made for which the Nomcom perceives that they had to scrape the bottom of the proverbial barrel. > Sometimes, if the nomcom beats the bushes a bit, good nominees > surface. Sometimes, when the nomcom beats the bushes, they > just get scratches on their hands. Failing to appoint an AD > because the procedure says "you can not go back to the decent > but not great candidate you passed over because he is an > incumbent" seems like a bad box to put yourself in. I don't want to put words into your mouth here, but it sounds to me that you are willing to go quite a bit further in the direction of a probably-unsatisfactory candidate in order to make sure that a slot gets filled, while I would prefer to empower the Nomcom to say "we have examined all of the possibilities, beaten the bushes, and can't find a Nominee we are really happy with -- so the community needs to make another plan. Put differently, I can see lots of reasons to either retain an incumbent or to drop one. But I don't see "after performing an evaluation and weighing the issues, we'd really prefer to retire this person, but are willing to live with another term if we can't find anyone else or if all the people we can find are worse" as a acceptable reason for retention. That is especially so because I believe I've seen situations in which a Nomcom has returned someone who had burned out because they couldn't find anyone better and that the result of that decision has usually been unfortunate. While I can accept that there possible situations very near that boundary that you would consider failure cases, I consider any "no choice" situation to be a sufficient failure that there is no win either way. john From erosen@cisco.com Mon Jun 22 07:29:10 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77E6228C1F0 for ; Mon, 22 Jun 2009 07:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaUFAef6GKVr for ; Mon, 22 Jun 2009 07:29:08 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5C2C128C1CB for ; Mon, 22 Jun 2009 07:29:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,268,1243814400"; d="scan'208";a="48186469" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Jun 2009 14:29:23 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5METNlR021055; Mon, 22 Jun 2009 10:29:23 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5METNZL011875; Mon, 22 Jun 2009 14:29:23 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n5METL4H016880; Mon, 22 Jun 2009 10:29:21 -0400 To: John C Klensin In-reply-to: Your message of Sun, 21 Jun 2009 22:58:25 -0400. <60437ED43CD30EAF5FD59CA7@PST.JCK.COM> Date: Mon, 22 Jun 2009 10:29:21 -0400 Message-ID: <16879.1245680961@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=521; t=1245680963; x=1246544963; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20[ietf-nomcom]=20Changing=20the=20candid ate=20selection=20model=20 |Sender:=20 |To:=20John=20C=20Klensin=20; bh=+8Mw5K2sIAZ0fjXZyiMKQgegIWDWzmJy/IfzHi0+6Hw=; b=o6Kd1lEfwNZW9ZuP9RQ7rjdoGjehOZieLg3+1lte8fH0V0P5PbvlJnSqIA +nMkJoBe2ntikaYgzlAYqHDkFIoBKA8rztJtC8REe3G5hbo4ZOqpxur98AyZ 5+y3Wa16m4; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Barry Leiba , NomComDiscussion Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 14:29:10 -0000 > "incumbents first" would sometimes improve the quality of the nominee pool I think this really ignores the political realities. If the first thing the nomcom had to do was to have an up/down vote on each incumbent, no incumbent would ever be removed. The procedures for selecting the nomcom do not select for people with the backbone to make hard decisions like this. Especially not when there are liaisons from the powers that be who are offering help and keeping an eye on everything. From john-ietf@jck.com Mon Jun 22 08:02:28 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598E928C1FD for ; Mon, 22 Jun 2009 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpz4KhQlaemC for ; Mon, 22 Jun 2009 08:02:27 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 3FCC23A6A66 for ; Mon, 22 Jun 2009 08:02:27 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MIl2d-000NHf-Bl; Mon, 22 Jun 2009 11:02:39 -0400 Date: Mon, 22 Jun 2009 11:02:38 -0400 From: John C Klensin To: Christian Huitema , "Joel M. Halpern" , Barry Leiba Message-ID: In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA014437@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <4A1D5086.9080702@joelhalpern.com> <36E1A7176AF78A864F74EAC6@PST.JCK.COM> <6c9fcc2a0906182149q4ae1e57bs39b24d4561281634@mail.gmail.com> <4A3B910D.5080606@joelhalpern.com> <6B55F0F93C3E9D45AF283313B8D342BA014437@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: NomComDiscussion Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 15:02:28 -0000 --On Friday, June 19, 2009 19:29 +0000 Christian Huitema wrote: > I understand the desire to not have term limits, but such > limits are actually the best way to avoid the failure mode I > fear most, the "old boyz club". If there is not some kind of > limit, or at least encouragement to the nomcom to "get new > blood", incumbents can be there for life, as long as they are > not grossly incompetent, or bored. Christian, I agree with you about the motivation for term limits although I find them pretty distasteful. You might recall that the now-ancient predecessor to this draft, while not actually including term limits, encouraged the Nomcom to think in terms of "default return" after one term and "default retire" after two. The difficulty I see with term limits is that they cut several ways. If they are set short enough (but at more than one term), they become an entitlement: retiring someone earlier becomes a big deal. If they are set too long, while they may still be effective at preventing lifetime appointments, they are not effective in removing those who have burned out. And there are always edge cases in which term limits dictate outcomes that are not desirable in particular situations. My sense is that, if we look at results, the Nomcoms have been reasonably good at getting rid of the nearly grossly incompetent and that they, in combination with incumbent good sense, have been reasonably good at getting rid of the bored and exhausted. Where they have been less successful is in detecting the incumbents who performed well early in their time in office but who are well along the path to burnout, who have developed abusive behaviors, have developed an exaggerated view of their own (or the IESG's) knowledge or importance and hence are in need of retirement before things get worse. Lack of success in that area --possibly combined with the "possibly better than the alternatives" attitude that I discussed in my response to Joel-- has resulted, IMO, in several people being reappointed to serve one term too long. Our hope is that giving Nomcoms a clear and separate focus on incumbent performance without the distraction of thinking about possible replacements will permit better input and analysis of trends in incumbent performance and hence retirement of those who are showing signs of burnout or cumulative poor behavior before those symptoms develop to the point of causing damage. There is a risk in the approach which I'm surprised that no one has noticed: If a Nomcom got lazy, returning the incumbents without evaluation could save them a lot of work. However, I don't think our experience indicates that Nomcoms have any propensity to get lazy in that way, so I'm not concerned about it in practice. john From john-ietf@jck.com Mon Jun 22 21:43:31 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA81B3A6E38 for ; Mon, 22 Jun 2009 21:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHuynfpYl9ju for ; Mon, 22 Jun 2009 21:43:31 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id CB6783A6E36 for ; Mon, 22 Jun 2009 21:43:30 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MIxr3-000LRA-AV; Tue, 23 Jun 2009 00:43:33 -0400 Date: Tue, 23 Jun 2009 00:43:32 -0400 From: John C Klensin To: erosen@cisco.com Message-ID: In-Reply-To: <16879.1245680961@erosen-linux> References: <16879.1245680961@erosen-linux> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Barry Leiba , NomComDiscussion Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 04:43:32 -0000 --On Monday, June 22, 2009 10:29 -0400 Eric Rosen wrote: > >> "incumbents first" would sometimes improve the quality of the >> nominee pool > I think this really ignores the political realities. If the > first thing the nomcom had to do was to have an up/down vote > on each incumbent, no incumbent would ever be removed. The > procedures for selecting the nomcom do not select for > people with the backbone to make hard decisions like > this. Especially not when there are liaisons from the > powers that be who are offering help and keeping an eye on > everything. I assume you have actually read the draft, rather than taking the comments that have been made about it out of context and responding to them. If you have not read the draft, I doubt that the comments that follow will be very helpful. The first thing the Nomcom has to do is to perform a careful and thoughtful, area by area and slot by slot performance review without the distractions of non-incumbent nominees. The intention is that those reviews be performed even on areas where the incumbent is voluntarily stepping down. Having performed that evaluation, the Nomcom then decides which of the incumbents that are willing to serve again it wants to return. The expectation is that the reviews will be very helpful in considering nominees for slots to which incumbents are not returned. Of course, if a Nomcom is lazy or indifferent enough that it simply skips the evaluation process and returns all of the incumbents, then we are in big trouble. Should a Nomcom decide to behave that way, I believe that we can have exactly the same failure case with the current setup so the proposal doesn't make things any worse. And, fwiw, while I've seen Nomcoms make decisions that I consider wrong-headed, I've never seen any symptoms of that level of irresponsibility -- my impression has been that at least most members of most Nomcoms take their responsibilities very seriously. I've got similar reactions to your comment (I'm tempted to say "innuendo") about the liaisons. While I think they are necessary, I've always been concerned about the risk of unreasonable influences from the bodies to which people are going to be appointed (e.g., enhancement of what Christian referred to as the "old boyz club") and direct or indirect leaks back to those bodies (e.g., candor in comments about nominees, especially about incumbents, who are part of the same "club" as the liaison can lead to resentments, even if no details are disclosed outside the Nomcom). But I don't have a better solution. Do you? john From erosen@cisco.com Wed Jun 24 08:10:23 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548483A6C9F for ; Wed, 24 Jun 2009 08:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8gzJpMciwOh for ; Wed, 24 Jun 2009 08:10:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4DAB428C2C3 for ; Wed, 24 Jun 2009 08:10:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,283,1243814400"; d="scan'208";a="205005364" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2009 15:10:04 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5OFA3qw006115; Wed, 24 Jun 2009 11:10:03 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5OFA3xs023076; Wed, 24 Jun 2009 15:10:03 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n5OFA2jO008609; Wed, 24 Jun 2009 11:10:02 -0400 To: John C Klensin In-reply-to: Your message of Tue, 23 Jun 2009 00:43:32 -0400. Date: Wed, 24 Jun 2009 11:10:02 -0400 Message-ID: <8608.1245856202@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2949; t=1245856203; x=1246720203; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20[ietf-nomcom]=20Changing=20the=20candid ate=20selection=20model=20 |Sender:=20 |To:=20John=20C=20Klensin=20; bh=FUYHH2XvtEqBgUSIZbr3+0trVPukR2XY/4SOrcSpxGQ=; b=HeQD/VMie1pQjjDDyuUG9tUk6KXfXR3zOmRU8G37to3Pi9eb8Fqg6UNI+C wyU40c74ATq5A4QauH2IneKVUcohUFWzI4ZRUv4N4uSXYvCbUp4bd7c275jb h1CLy+/MqM; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Barry Leiba , NomComDiscussion Subject: Re: [ietf-nomcom] Changing the candidate selection model X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 15:10:23 -0000 The context for most of the nomcom discussions is the assumption that nomcom is some sort of blue ribbon commission, whose task is to determine the objective facts and then to make objective decisions based on those facts. I think that assumption is just a myth. Choosing the IESG/IAB is an essentially political process, not a fact-finding exercise. If we are going to talk about changing the procedures, we should use our knowledge about how political processes actually work in practice. I think it shows way too much hubris to assume that the IETF is somehow going to set up a process that produces some objectively superior result, even if such a thing could be assumed to exist. Political processes tend to work in a certain way, and the way they work is largely independent of the intentions of the people who drew up the rules. > Of course, if a Nomcom is lazy or indifferent enough that it > simply skips the evaluation process and returns all of the > incumbents, then we are in big trouble. Should a Nomcom decide > to behave that way, I believe that we can have exactly the same > failure case with the current setup so the proposal doesn't make > things any worse. I certainly disagree; in politics there's a maxim that "you can't beat somebody with nobody". The chances of ousting an incumbent are much lower if it is not known who will replace him/her. There are some exceptions to this maxim; a highly factionalized group may agree to oust an incumbent without having any hope of agreeing on a replacement. While you seem to think that this is a valid outcome, it usually doesn't work out very well in practice. (See, e.g., the Weimar Republic.) > The first thing the Nomcom has to do is to perform a careful and > thoughtful, area by area and slot by slot performance review > without the distractions of non-incumbent nominees. These process details don't matter. Unless the nomcom happens by chance to be dominated by political opponents of the incumbent, the tendency will be to keep the incumbent unless there is consensus for a replacement. > I've got similar reactions to your comment (I'm tempted to say > "innuendo") about the liaisons. While I think they are > necessary, I've always been concerned about the risk of > unreasonable influences from the bodies to which people are > going to be appointed Some people have strong convictions and are immune to such influences, but many people are very susceptible to influence from the "leadership", especially if they know that the leadership is watching their every move. So I think the liaisons really add a corrupt influence to the process. The nomcom should be able to call on representatives of the leadership when they require information, but it's really outrageous to have liaisons sit with them on a regular basis. From spencer@wonderhamster.org Fri Jun 26 06:24:30 2009 Return-Path: X-Original-To: ietf-nomcom@core3.amsl.com Delivered-To: ietf-nomcom@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C3A3A6AD8 for ; Fri, 26 Jun 2009 06:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLGB6XMZxNTR for ; Fri, 26 Jun 2009 06:24:29 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id C10EC3A6B21 for ; Fri, 26 Jun 2009 06:24:29 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MKBK10lvF-000CLR; Fri, 26 Jun 2009 09:18:30 -0400 Message-ID: <953857E3A140495389EBA3B35B1026B4@china.huawei.com> From: "Spencer Dawkins" To: "NomComDiscussion" Date: Fri, 26 Jun 2009 08:18:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19nur9WlCHrAO3q9G62h4oFC3sWfOHSCzpWuGd KUmLC3TgAWmX0l3TnmovH4bYJXKqV+WWHeJ4G7FOc2CJUpljn7 Lo42ddAtDZRDWMkW7SbwPm2YcFcXdCTOU39bX8prSs= Subject: [ietf-nomcom] Fw: Last Call: draft-dawkins-nomcom-dont-wait (Nominating CommitteeProcess: Earlier Announcement of Open Positions and Solicitation ofVolunteers) to BCP X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions of possible revisions to the NomCom process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 13:24:30 -0000 (sorry - inadvertently sent to ietf-nomcom@ietf.COM)... Spencer ----- Original Message ----- From: "Spencer Dawkins" To: "Pekka Savola" ; "Russ Housley" Cc: ; Sent: Wednesday, June 24, 2009 4:51 PM Subject: Re: Last Call: draft-dawkins-nomcom-dont-wait (Nominating CommitteeProcess: Earlier Announcement of Open Positions and Solicitation ofVolunteers) to BCP > Hi, Pekka, > > Russ asked me to prepare OLD/NEW text for an editor's note on this: > >>> The IETF Executive Director, who is part of the Secretariat, already has >>> a role in NomCom. The IETF Executive Director provides the requirements >>> for the open positions. >>> >>> Would you be more comfortable if the Executive Director were named as >>> the responsible party? >> >> Yes. I'd be even more comfortable if the text could be inclusive, for >> example that either NomCom chair or IETF exec director could send out the >> announcement, but if shared responsibility seems like a bad idea, I can >> accept that argument. > > Here's what I'm suggesting. I left the primary responsibility for this > with the Chair, if the Chair HAS been named. > > Thanks, > > Spencer > > OLD: > > 3. Discussion > > This document proposes that the IETF Secretariat will issue the > announcement of open positions and the solicitation for names of > volunteers on behalf of the Incoming NomCom Chair who will be named > by the ISOC President. This allows the search for the Incoming > NomCom Chair and volunteers to proceed in parallel. > > NEW: > > 3. Discussion > > This document proposes that the IETF Executive Director will issue the > announcement of open positions and the solicitation for names of > volunteers on behalf of the Incoming NomCom Chair who will be named > by the ISOC President, if the Incoming NomCom Chair has not yet been > named. This allows the search for the Incoming NomCom Chair and > volunteers to proceed in parallel. > > OLD: > > 4. Updated text from RFC 3777 > > For [RFC3777], in section 4, "Nominating Committee Selection", bullet > 13, which states: > > The Chair obtains the list of IESG and IAB positions to be > reviewed and announces it along with a solicitation for names of > volunteers from the IETF community willing to serve on the > nominating committee. > > this text is replaced with the following text: > > The IETF Secretariat obtains the list of positions to be reviewed > and announces it along with a solicitation for names of volunteers > from the IETF community willing to serve on the nominating > committee. > > NEW: > > 4. Updated text from RFC 3777 > > For [RFC3777], in section 4, "Nominating Committee Selection", bullet > 13, which states: > > The Chair obtains the list of IESG and IAB positions to be > reviewed and announces it along with a solicitation for names of > volunteers from the IETF community willing to serve on the > nominating committee. > > this text is replaced with the following text: > > The Chair (or the IETF Executive Director, if no Chair has been > named) > obtains the list of positions to be reviewed and announces it along > with a solicitation for names of volunteers from the IETF community > willing to serve on the nominating committee. > > Comments? > > Thanks, > > Spencer