From danny@tcb.net Wed May 6 01:06:48 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 5EC2B3A6A4C for ; Wed, 6 May 2009 01:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.217 X-Spam-Level: X-Spam-Status: No, score=-0.217 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 rzJ89i-sH6lw for ; Wed, 6 May 2009 01:06:41 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id A130C3A6E2D for ; Wed, 6 May 2009 01:04:59 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C39232684EA; Wed, 6 May 2009 02:06:26 -0600 (MDT) Received: from 10-1-15-10.aa.arbor.net (division.aa.arbor.net [204.181.64.3]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 06 May 2009 02:06:26 -0600 (MDT) (envelope-from danny@tcb.net) From: Danny McPherson To: Spencer Dawkins In-Reply-To: X-Priority: 3 References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> Message-Id: 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, 6 May 2009 02:06:07 -0600 X-Mailer: Apple Mail (2.930.3) Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 06 May 2009 08:06:48 -0000 Spencer et al., It seems to me we've reached [near] consensus on and I'd _really like to see this I-D pushed to IETF LC and recommendations instituted before the next NomCom cycle - which is approaching fast. Were there any outstanding actions that need to be updated or can we ask to progress? -danny From danny@tcb.net Wed May 6 01:09:25 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 93EB53A6BF7 for ; Wed, 6 May 2009 01:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[AWL=0.887, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 5+DkRFrC8QOo for ; Wed, 6 May 2009 01:09:18 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id C87C73A68C4 for ; Wed, 6 May 2009 01:08:23 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 19FF82684EA; Wed, 6 May 2009 02:09:51 -0600 (MDT) Received: from 10-1-15-10.aa.arbor.net (division.aa.arbor.net [204.181.64.3]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 06 May 2009 02:09:50 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: <78AC15D5-A786-4BE7-BFF9-162E2C9568CD@tcb.net> From: Danny McPherson To: Spencer Dawkins 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, 6 May 2009 02:09:32 -0600 X-Mailer: Apple Mail (2.930.3) Cc: NomComDiscussion Discussion Subject: [ietf-nomcom] Publish 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: Wed, 06 May 2009 08:09:25 -0000 Spencer et al., I believe we should progress this draft as well, are there any outstanding issues that need to be addressed? -danny From danny@tcb.net Wed May 6 01:38: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 2BC1F3A6952 for ; Wed, 6 May 2009 01:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.242 X-Spam-Level: X-Spam-Status: No, score=-0.242 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 7JpnCPwahLdP for ; Wed, 6 May 2009 01:38:26 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id D8E8A3A6A4C for ; Wed, 6 May 2009 01:38:13 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 192FF2684EA; Wed, 6 May 2009 02:39:41 -0600 (MDT) Received: from 10-1-15-10.aa.arbor.net (division.aa.arbor.net [204.181.64.3]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 06 May 2009 02:39:40 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: <63BCC206-FF3C-41B4-A705-6B9DFC048E77@tcb.net> From: Danny McPherson To: James M Galvin In-Reply-To: <521D64E2491B56B31E9E196D@201-131-220-159.icannmeeting.org> 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, 6 May 2009 02:39:23 -0600 References: <521D64E2491B56B31E9E196D@201-131-220-159.icannmeeting.org> X-Mailer: Apple Mail (2.930.3) Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] I-D Action:draft-galvin-rfc3777bis-00.txt (fwd) 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, 06 May 2009 08:38:33 -0000 Jim, Are there any outstanding issues with this document? I recall comments triggered by Brian Carpenter and John Klensin, did you pull any necessary text updates from those thread? Are there other changes necessary here before we progress? I heard that at the plenary someone said they believed that the IAOC-related changes alone weren't enough to mandate a 3777 update here, what do other folks think about that? I'd prefer not to lump the dont-wait and openlist I-Ds in with this, as they'll likely be much longer getting progressed if we do that. Do others have thoughts on this? -danny On Mar 4, 2009, at 11:04 AM, James M Galvin wrote: > > > -------- Forwarded Message -------- > Date: March 4, 2009 9:45:01 AM -0800 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D Action:draft-galvin-rfc3777bis-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Operation of the Nominating and Recall Committees > Author(s) : J. Galvin > Filename : draft-galvin-rfc3777bis-00.txt > Pages : 41 > Date : 2009-03-04 > > <1> > The IETF uses two committees to manage the selection, confirmation, > and recall of some or all of the individuals who serve terms of > membership on the bodies that support its operation. As of the > publication of this document the list of bodies includes the IESG, > IAB, and the IAOC. This document is a self-consistent, organized > compilation of the process as it was known at the time of > publication.Discussion of this Draft > > <2> > Please direct all comments, suggestions, and questions regarding this > draft to the following mailing list: > <3> > > ietf-nomcom@ietf.org > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-galvin-rfc3777bis-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > -------- End Forwarded Message -------- > > > From: Internet-Drafts@ietf.org > Date: March 4, 2009 10:45:01 AM MST > To: i-d-announce@ietf.org > Subject: I-D Action:draft-galvin-rfc3777bis-00.txt > Reply-To: internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Operation of the Nominating and Recall Committees > Author(s) : J. Galvin > Filename : draft-galvin-rfc3777bis-00.txt > Pages : 41 > Date : 2009-03-04 > > <1> > The IETF uses two committees to manage the selection, confirmation, > and recall of some or all of the individuals who serve terms of > membership on the bodies that support its operation. As of the > publication of this document the list of bodies includes the IESG, > IAB, and the IAOC. This document is a self-consistent, organized > compilation of the process as it was known at the time of > publication.Discussion of this Draft > > <2> > Please direct all comments, suggestions, and questions regarding this > draft to the following mailing list: > <3> > > ietf-nomcom@ietf.org > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-galvin-rfc3777bis-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom From leslie@thinkingcat.com Wed May 6 03:21: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 C2A243A6A73 for ; Wed, 6 May 2009 03:21: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 QD1BOWlOzMfw for ; Wed, 6 May 2009 03:21:46 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 43C653A6C88 for ; Wed, 6 May 2009 03:21:19 -0700 (PDT) Received: from dhcp-24-201.ripemtg.ripe.net ([::ffff:193.0.24.201]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 06 May 2009 06:22:43 -0400 id 0158431B.4A0164F4.000073E0 Message-ID: <4A0164EA.7050909@thinkingcat.com> Date: Wed, 06 May 2009 06:22:34 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Danny McPherson References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 06 May 2009 10:21:52 -0000 BTW, the current version is -02. For myself -- I would like to see a version that didn't include "Spencer's personal opinion" before it goes out to any kind of last call. (The text is either trying to be consensus, and doesn't need the phrase as an intro, or it truly is a personal opinion that should fade before publication as an RFC, IMO). Leslie. Danny McPherson wrote: > > Spencer et al., > It seems to me we've reached [near] consensus on > > and I'd _really like to see this I-D pushed to IETF LC and > recommendations instituted before the next NomCom cycle - > which is approaching fast. > > Were there any outstanding actions that need to be updated or > can we ask to progress? > > -danny > > _______________________________________________ > 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 bernie@hoeneisen.ch Wed May 6 01:53:02 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 178633A6987 for ; Wed, 6 May 2009 01:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 kqaQcEgRa175 for ; Wed, 6 May 2009 01:53:01 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id E62FD3A6C95 for ; Wed, 6 May 2009 01:52:32 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1M1ct2-0007x6-8J; Wed, 06 May 2009 10:53:56 +0200 Date: Wed, 6 May 2009 10:53:56 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Danny McPherson In-Reply-To: <63BCC206-FF3C-41B4-A705-6B9DFC048E77@tcb.net> Message-ID: References: <521D64E2491B56B31E9E196D@201-131-220-159.icannmeeting.org> <63BCC206-FF3C-41B4-A705-6B9DFC048E77@tcb.net> 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@hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 06 May 2009 09:15:51 -0700 Cc: NomCom Discussion , James M Galvin Subject: Re: [ietf-nomcom] I-D Action:draft-galvin-rfc3777bis-00.txt (fwd) 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, 06 May 2009 08:53:02 -0000 Danny, et al., On Wed, 6 May 2009, Danny McPherson wrote: > Are there other changes necessary here before we progress? I > heard that at the plenary someone said they believed that the > IAOC-related changes alone weren't enough to mandate a 3777 > update here, what do other folks think about that? > > I'd prefer not to lump the dont-wait and openlist I-Ds in > with this, as they'll likely be much longer getting progressed > if we do that. > > Do others have thoughts on this? AFAIK there was consensus on the IAOC issues, namely: - the IAOC can appoint a liaison to the NomCom (optional appointment) - the way the IAOC selection has been handled by Nomcom in the last couple of years shall be reflected to 3777bis Have I missed any futher issue? cheers, Bernie, member of IETF NomCom From spencer@wonderhamster.org Wed May 6 11:35:02 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 664E328C26C for ; Wed, 6 May 2009 11:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_20=-0.74] 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 ZsNX-S0b2g7p for ; Wed, 6 May 2009 11:34:55 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id C19B828C10A for ; Wed, 6 May 2009 11:26:15 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1M1lqB2Ece-000g3q; Wed, 06 May 2009 14:27:37 -0400 Message-ID: <13CF7985E3AA4223A1B4974F2941530F@china.huawei.com> From: "Spencer Dawkins" To: "Danny McPherson" References: <78AC15D5-A786-4BE7-BFF9-162E2C9568CD@tcb.net> Date: Wed, 6 May 2009 13:27:15 -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/ORAGYB5TJl/o0YLFC4I2GVDhk4yWpJkuajvB 9w/PB3TSn7RR2mFJWiVgff7ET5Dx7fAKGxrCOrtUDoJegQ35GA vQdwYUY6GcSaY+B3pJkrwb0oLUs6ltBYUha6S1WC58= Cc: NomComDiscussion Discussion Subject: Re: [ietf-nomcom] Publish 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: Wed, 06 May 2009 18:35:02 -0000 Hi, Danny, After listening to the audio and reviewing the minutes from IETF 74 plenary, I believe that the changes required are to make it clear that at the past chair's request, the secretariat can issue the solicitation of volunteers, and can perform other start-up tasks which in the chair's opinion are only administrative in nature. Sam expressed a hope that we would take more seriously the NomCom responsibility to consider the positions under review before issuing an announcement of open positions - that happens before the NomCom is even formed, so there's not a time for the NomCom membership to ask questions. I'll add a note about this (so we don't forget it), but I'm hoping that we defer this topic into a more general consideration of the NomCom process (including roles of liaisons, eligibility criteria, etc). After looking at the draft, I'm also thinking that I should be using "Incoming NomCom Chair" and "Outgoing NomCom Chair" terminology in this draft, to prevent confusion about who can request what, at any moment in time. I'm assuming that the NomCom Chair continues to serve as NomCom Chair until a replacement is selected, and then begins to serve as Past NomCom Chair. I'll try to include that, unless people object. Does anyone think I'm missing something? Thanks, Spencer > Spencer et al., > I believe we should progress this draft as well, are > there any outstanding issues that need to be addressed? > > > > > -danny > From spencer@wonderhamster.org Wed May 6 13:21:34 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 747FB3A6A7A for ; Wed, 6 May 2009 13:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.442, 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 cmM3JN2rarYJ for ; Wed, 6 May 2009 13:21:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id A8C0628C289 for ; Wed, 6 May 2009 13:20:37 -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-1M1ncr16CB-000cvj; Wed, 06 May 2009 16:22:00 -0400 Message-ID: <560EEA8251504ADF9DEA7BD3720EADEB@china.huawei.com> From: "Spencer Dawkins" To: "Danny McPherson" References: <78AC15D5-A786-4BE7-BFF9-162E2C9568CD@tcb.net> Date: Wed, 6 May 2009 15:21:37 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_10F8_01C9CE5E.59580C40" 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: V01U2FsdGVkX18JfTVauoClm86V4k20qxkLYahMwTnWl2yzyLd tqPVD0VaUkdBjzhPP/hEJku0scs0yNppemqcWZxIAZtPtX4MiY Lb+zBHiw+PIqbwn2u/LWxSi81S6T4TuRaIOH957YJg= Cc: NomComDiscussion Discussion Subject: Re: [ietf-nomcom] Publish 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: Wed, 06 May 2009 20:21:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_10F8_01C9CE5E.59580C40 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit I started with this one (sorry, but it's shorter ;-). Could you let me know if it looks ready to submit? Thanks, Spencer > Spencer et al., > I believe we should progress this draft as well, are > there any outstanding issues that need to be addressed? > > > > > -danny > ------=_NextPart_000_10F8_01C9CE5E.59580C40 Content-Type: text/xml; name="draft-dawkins-nomcom-dont-wait-02.xml" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-dawkins-nomcom-dont-wait-02.xml" ]> =20 Nominating Committee Process: Earlier = Announcement of Open Positions and=20 Solicitation of Volunteers Huawei Technologies = (USA)
+1 214 755 3870 spencer@wonderhamster.org
=20 =20 RAI Network Working Group This document updates RFC 3777, Section 4, Bullet 13 to allow = announcement of open positions=20 and solicitation of volunteers to be issued before a Nominating and = Recall Committee=20 Chair has been named by the Internet Society President.
The Internet Engineering Steering Group (IESG), the Internet = Architecture Board (IAB),=20 and at-large IETF representatives to the IETF Administrative Oversight = Committee (IAOC) are=20 selected by a "Nominating and Recall Committee" (universally = abbreviated as "NomCom"). defines how the NomCom is selected, and = the processes it follows as it selects candidates for these positions. This document describes an issue with = that causes an avoidable delay in the NomCom process, and specifies a normative update to resolve the = issue.
is the latest in a series of revisions = to the NomCom process.=20 has been updated once since 2004, but this update ( did not change normative = text (it replaced a sample timeline). identified a serial delay in the process = described in=20 , in section 4,=20 "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. =09 The solicitation must permit the community at least 30 days during which they may choose to volunteer to be selected for = the nominating committee. =09 The list of open positions is published with the solicitation to facilitate community members choosing between volunteering for an open position and volunteering for the nominating committee. The result is that the Incoming NomCom=20 Chair is the only person who can announce the list of open positions=20 and solicitation for names of volunteers, a process that requires 30 days for public = solicitation. =09 Since this is the first step in=20 organizing the NomCom committee, delays in selecting the Incoming = NomCom Chair translate=20 directly into delays in issuing the solicitation and organizing the = NomCom. This proved problematic in practice in 2008-2009, when Joel Halpern = was named NomCom Chair less=20 than 30 days prior to the Second IETF meeting. If the 30-day = solicitation had already taken=20 place, the Nomcom could have conducted face-to-face interviews at the = Second IETF meeting, but since the required 30-day solicitation didn't start until = Joel=20 was named,=20 Joel was unable to assemble his NomCom before the Second IETF meeting, = and the NomCom had to carry out these interviews using e-mail and = conference calls. It is desirable to allow the solicitation and announcement to take = place in a timely manner=20 so that when=20 an Incoming NomCom Chair IS named, the NomCom Chair can immediately = begin executing the NomCom process.
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=20 search for the Incoming NomCom Chair and volunteers to proceed in = parallel. This process change covers only the the announcement of open = positions and solicitation for names of volunteers. The goal of this process change is=20 *not* to allow the NomCom process to move to completion without an = Incoming NomCom Chair,=20 it is only to ensure that the Incoming NomCom Chair can begin executing the NomCom process without an avoidable delay, and can use = face-to-face time at=20 the Second IETF meeting effectively for this purpose. During discussions in the IETF 74 timeframe, it was suggested that = we also allow the secretariat to perform other clerical tasks that aren't called out specifically in = the NomCom=20 process, but which clearly do not require NomCom chair judgement. This = document does not provide guidance about specific clerical tasks that would be = appropriate for the=20 secretariat to=20 carry out. Instead, either the Incoming NomCom Chair (if one has been = selected) or the Outgoing NomCom Chair (if the search for an Incoming NomCom = Chair is still underway) may request the secretariat to perform these tasks, with appropriate = notification to the=20 community.
For , in section 4,=20 "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. =09 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. At the NomCom Chair's request, the secretariat may perform other = clerical support tasks, as long as the task being performed does not require = NomCom Chair judgement, in the NomCom Chair's opinion, and as long as=20 the community is appropriately notified that this request is being made. This request may come from the = Incoming NomCom Chair (if one has been selected for this NomCom cycle) or the = Outgoing NomCom Chair (if the search for an Incoming NomCom Chair is still = underway). =09 Note: This text no longer specifies the list of bodies that NomCom = reviews, rather than adding IAOC to the list of bodies in the text, so that this text need not = change further when=20 NomCom review responsibilities change.
This specification describes issues with the current IETF Nominating = Committee process=20 () and proposes an update to avoid a serial = delay. No security considerations apply.
No IANA actions are requested in this specification.
=20
The editor thanks the following folks who have provided useful = observations and=20 guidance on previous versions of this draft: Scott Bradner (who = suggested that the IETF Secretariat have this responsibility), Brian Carpenter,=20 Jim Galvin, Joel Halpern, Danny McPherson. The editor also thanks IETF plenary participants who provided useful = feedback on previous versions of this draft.
=20 &RFC3777; &RFC5078; ------=_NextPart_000_10F8_01C9CE5E.59580C40 Content-Type: text/plain; format=flowed; name="draft-dawkins-nomcom-dont-wait-02.txt"; reply-type=response Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-dawkins-nomcom-dont-wait-02.txt" =0A= =0A= =0A= Network Working Group S. Dawkins, Ed.=0A= Internet-Draft Huawei (USA)=0A= Updates: 3777 (if approved) May 6, 2009=0A= Intended status: BCP=0A= Expires: November 7, 2009=0A= =0A= =0A= Nominating Committee Process: Earlier Announcement of Open Positions and=0A= Solicitation of Volunteers=0A= draft-dawkins-nomcom-dont-wait-02=0A= =0A= Status of this Memo=0A= =0A= This Internet-Draft is submitted to IETF in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on November 7, 2009.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2009 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents in effect on the date of=0A= publication of this document (http://trustee.ietf.org/license-info).=0A= Please review these documents carefully, as they describe your rights=0A= and restrictions with respect to this document.=0A= =0A= Abstract=0A= =0A= This document updates RFC 3777, Section 4, Bullet 13 to allow=0A= =0A= =0A= =0A= Dawkins Expires November 7, 2009 [Page 1]=0A= =0C=0A= Internet-Draft NomCom Issues May 2009=0A= =0A= =0A= announcement of open positions and solicitation of volunteers to be=0A= issued before a Nominating and Recall Committee Chair has been named=0A= by the Internet Society President.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. Background of this document . . . . . . . . . . . . . . . . . . 3=0A= 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 4. Updated text from RFC 3777 . . . . . . . . . . . . . . . . . . 4=0A= 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5=0A= 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5=0A= 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6=0A= 8.2. Informative References . . . . . . . . . . . . . . . . . . 6=0A= Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Dawkins Expires November 7, 2009 [Page 2]=0A= =0C=0A= Internet-Draft NomCom Issues May 2009=0A= =0A= =0A= 1. Introduction=0A= =0A= The Internet Engineering Steering Group (IESG), the Internet=0A= Architecture Board (IAB), and at-large IETF representatives to the=0A= IETF Administrative Oversight Committee (IAOC) are selected by a=0A= "Nominating and Recall Committee" (universally abbreviated as=0A= "NomCom"). [RFC3777] defines how the NomCom is selected, and the=0A= processes it follows as it selects candidates for these positions.=0A= =0A= This document describes an issue with [RFC3777] that causes an=0A= avoidable delay in the NomCom process, and specifies a normative=0A= update to resolve the issue.=0A= =0A= =0A= 2. Background of this document=0A= =0A= [RFC3777] is the latest in a series of revisions to the NomCom=0A= process. [RFC3777] has been updated once since 2004, but this update=0A= ([RFC5078] did not change normative text (it replaced a sample=0A= timeline).=0A= =0A= [RFC5078] identified a serial delay in the process described in=0A= [RFC3777], in section 4, "Nominating Committee Selection", bullet 13,=0A= which states:=0A= =0A= The Chair obtains the list of IESG and IAB positions to be=0A= reviewed and announces it along with a solicitation for names of=0A= volunteers from the IETF community willing to serve on the=0A= nominating committee.=0A= =0A= The solicitation must permit the community at least 30 days during=0A= which they may choose to volunteer to be selected for the=0A= nominating committee.=0A= =0A= The list of open positions is published with the solicitation to=0A= facilitate community members choosing between volunteering for an=0A= open position and volunteering for the nominating committee.=0A= =0A= The result is that the Incoming NomCom Chair is the only person who=0A= can announce the list of open positions and solicitation for names of=0A= volunteers, a process that requires 30 days for public solicitation.=0A= =0A= Since this is the first step in organizing the NomCom committee,=0A= delays in selecting the Incoming NomCom Chair translate directly into=0A= delays in issuing the solicitation and organizing the NomCom.=0A= =0A= This proved problematic in practice in 2008-2009, when Joel Halpern=0A= was named NomCom Chair less than 30 days prior to the Second IETF=0A= =0A= =0A= =0A= Dawkins Expires November 7, 2009 [Page 3]=0A= =0C=0A= Internet-Draft NomCom Issues May 2009=0A= =0A= =0A= meeting. If the 30-day solicitation had already taken place, the=0A= Nomcom could have conducted face-to-face interviews at the Second=0A= IETF meeting, but since the required 30-day solicitation didn't start=0A= until Joel was named, Joel was unable to assemble his NomCom before=0A= the Second IETF meeting, and the NomCom had to carry out these=0A= interviews using e-mail and conference calls.=0A= =0A= It is desirable to allow the solicitation and announcement to take=0A= place in a timely manner so that when an Incoming NomCom Chair IS=0A= named, the NomCom Chair can immediately begin executing the NomCom=0A= process.=0A= =0A= =0A= 3. Discussion=0A= =0A= This document proposes that the IETF Secretariat will issue the=0A= announcement of open positions and the solicitation for names of=0A= volunteers on behalf of the Incoming NomCom Chair who will be named=0A= by the ISOC President. This allows the search for the Incoming=0A= NomCom Chair and volunteers to proceed in parallel.=0A= =0A= This process change covers only the the announcement of open=0A= positions and solicitation for names of volunteers. The goal of this=0A= process change is *not* to allow the NomCom process to move to=0A= completion without an Incoming NomCom Chair, it is only to ensure=0A= that the Incoming NomCom Chair can begin executing the NomCom process=0A= without an avoidable delay, and can use face-to-face time at the=0A= Second IETF meeting effectively for this purpose.=0A= =0A= During discussions in the IETF 74 timeframe, it was suggested that we=0A= also allow the secretariat to perform other clerical tasks that=0A= aren't called out specifically in the NomCom process, but which=0A= clearly do not require NomCom chair judgement. This document does=0A= not provide guidance about specific clerical tasks that would be=0A= appropriate for the secretariat to carry out. Instead, either the=0A= Incoming NomCom Chair (if one has been selected) or the Outgoing=0A= NomCom Chair (if the search for an Incoming NomCom Chair is still=0A= underway) may request the secretariat to perform these tasks, with=0A= appropriate notification to the community.=0A= =0A= =0A= 4. Updated text from RFC 3777=0A= =0A= For [RFC3777], in section 4, "Nominating Committee Selection", bullet=0A= 13, which states:=0A= =0A= =0A= =0A= =0A= =0A= =0A= Dawkins Expires November 7, 2009 [Page 4]=0A= =0C=0A= Internet-Draft NomCom Issues May 2009=0A= =0A= =0A= The Chair obtains the list of IESG and IAB positions to be=0A= reviewed and announces it along with a solicitation for names of=0A= volunteers from the IETF community willing to serve on the=0A= nominating committee.=0A= =0A= this text is replaced with the following text:=0A= =0A= The IETF Secretariat obtains the list of positions to be reviewed=0A= and announces it along with a solicitation for names of volunteers=0A= from the IETF community willing to serve on the nominating=0A= committee.=0A= =0A= At the NomCom Chair's request, the secretariat may perform other=0A= clerical support tasks, as long as the task being performed does=0A= not require NomCom Chair judgement, in the NomCom Chair's opinion,=0A= and as long as the community is appropriately notified that this=0A= request is being made. This request may come from the Incoming=0A= NomCom Chair (if one has been selected for this NomCom cycle) or=0A= the Outgoing NomCom Chair (if the search for an Incoming NomCom=0A= Chair is still underway).=0A= =0A= Note: This text no longer specifies the list of bodies that NomCom=0A= reviews, rather than adding IAOC to the list of bodies in the text,=0A= so that this text need not change further when NomCom review=0A= responsibilities change.=0A= =0A= =0A= 5. Security Considerations=0A= =0A= This specification describes issues with the current IETF Nominating=0A= Committee process ([RFC3777]) and proposes an update to avoid a=0A= serial delay. No security considerations apply.=0A= =0A= =0A= 6. IANA Considerations=0A= =0A= No IANA actions are requested in this specification.=0A= =0A= =0A= 7. Acknowledgements=0A= =0A= The editor thanks the following folks who have provided useful=0A= observations and guidance on previous versions of this draft: Scott=0A= Bradner (who suggested that the IETF Secretariat have this=0A= responsibility), Brian Carpenter, Jim Galvin, Joel Halpern, Danny=0A= McPherson.=0A= =0A= The editor also thanks IETF plenary participants who provided useful=0A= =0A= =0A= =0A= Dawkins Expires November 7, 2009 [Page 5]=0A= =0C=0A= Internet-Draft NomCom Issues May 2009=0A= =0A= =0A= feedback on previous versions of this draft.=0A= =0A= =0A= 8. References=0A= =0A= 8.1. Normative References=0A= =0A= [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and=0A= Recall Process: Operation of the Nominating and Recall=0A= Committees", BCP 10, RFC 3777, June 2004.=0A= =0A= 8.2. Informative References=0A= =0A= [RFC5078] Dawkins, S., "IAB and IESG Selection, Confirmation, and=0A= Recall Process: Revision of the Nominating and Recall=0A= Committees Timeline", RFC 5078, October 2007.=0A= =0A= =0A= Author's Address=0A= =0A= Spencer Dawkins (editor)=0A= Huawei Technologies (USA)=0A= =0A= Phone: +1 214 755 3870=0A= Email: spencer@wonderhamster.org=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Dawkins Expires November 7, 2009 [Page 6]=0A= =0C=0A= =0A= ------=_NextPart_000_10F8_01C9CE5E.59580C40-- From spencer@wonderhamster.org Wed May 6 13:58: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 2E5D53A6DAE for ; Wed, 6 May 2009 13:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 WgJ-Ap10sDng for ; Wed, 6 May 2009 13:58:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 54EF23A6A9B for ; Wed, 6 May 2009 13:58:39 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1M1oDj2nyt-000fu1; Wed, 06 May 2009 17:00:06 -0400 Message-ID: <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> From: "Spencer Dawkins" To: "Danny McPherson" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> Date: Wed, 6 May 2009 15:59:44 -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: V01U2FsdGVkX19rvO/eSEaURN5FfZ/X9iaJyupLY7QUWs6K3ku DJAxbtfOCdoJboKXb0/+AFjPd3j84HcYEIuQaTpJTt8nL0AgLu ginhFDXbBFvNtPmqqqiY8mO7CHKSO0ZAaXmACfDoAk= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 06 May 2009 20:58:40 -0000 Hi, Danny, > Spencer et al., > It seems to me we've reached [near] consensus on > > > and I'd _really like to see this I-D pushed to IETF LC and > recommendations instituted before the next NomCom cycle - > which is approaching fast. > > Were there any outstanding actions that need to be updated or > can we ask to progress? I believe the required updates for this draft are - allow padding if NomCom is considering only one or two candidates for a specific position (this was requested at the plenary, and if a NomCom can only find one or two willing candidates, I'm thinking the choices are (1) let them pad, or (2) tell them if we can only find one or two people who are willing to serve in a given position, we need to rethink the position, not just add a couple of ringers - and I would be OK with either path forward) - make it clear that all feedback about announced candidates goes to NomCom for confidential consideration (we aren't looking for "I Like Bob" posts on the IETF discussion list) - remove Spencer's Personal Opinions in preparation for publication. What else am I missing? Thanks, Spencer From jmh@joelhalpern.com Wed May 6 14:18: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 A5CAD3A6AF4 for ; Wed, 6 May 2009 14:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 r-Qjz4N44auM for ; Wed, 6 May 2009 14:18:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E39313A6E9A for ; Wed, 6 May 2009 14:18:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B0BCD4302CC for ; Wed, 6 May 2009 14:20:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id EA74E4302C2 for ; Wed, 6 May 2009 14:20:25 -0700 (PDT) Message-ID: <4A01FF14.1000802@joelhalpern.com> Date: Wed, 06 May 2009 17:20:20 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 CC: NomComDiscussion References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> In-Reply-To: <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 06 May 2009 21:18:59 -0000 As long as the wording is clear that it is "allow" rather than "require" on your first point, I can live with that. Joel Spencer Dawkins wrote: > Hi, Danny, > >> Spencer et al., >> It seems to me we've reached [near] consensus on >> > > >> and I'd _really like to see this I-D pushed to IETF LC and >> recommendations instituted before the next NomCom cycle - >> which is approaching fast. >> >> Were there any outstanding actions that need to be updated or >> can we ask to progress? > > I believe the required updates for this draft are > > - allow padding if NomCom is considering only one or two candidates for > a specific position (this was requested at the plenary, and if a NomCom > can only find one or two willing candidates, I'm thinking the choices > are (1) let them pad, or (2) tell them if we can only find one or two > people who are willing to serve in a given position, we need to rethink > the position, not just add a couple of ringers - and I would be OK with > either path forward) > > - make it clear that all feedback about announced candidates goes to > NomCom for confidential consideration (we aren't looking for "I Like > Bob" posts on the IETF discussion list) > > - remove Spencer's Personal Opinions in preparation for publication. > > What else am I missing? > > Thanks, > > Spencer > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From spencer@wonderhamster.org Wed May 6 14:28: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 E3CE33A6BB0 for ; Wed, 6 May 2009 14:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, 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 x95qc46+--EY for ; Wed, 6 May 2009 14:28:09 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 00EA828C12F for ; Wed, 6 May 2009 14:28:09 -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-1M1ogH03qy-000d64; Wed, 06 May 2009 17:29:35 -0400 Message-ID: <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> From: "Spencer Dawkins" To: "Joel M. Halpern" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> Date: Wed, 6 May 2009 16:29:13 -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+Uuibkhikz4bPJsy0Dz9NxzQjRXx5TPEDKb2a vgAJQuIVfDDbLZwKbCGibUgKRzGmiRngysVG0VOgU1hLx0T4Yv HbuBcA5eM0UacH4+t+iM9F7nKjIoNo5lGubFw8JRc4= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 06 May 2009 21:28:10 -0000 Hi, Joel, Exactly. The text in my working draft looks like this: The list of nominees published should not contain the names of nominees who have not indicated a willingness to serve in a position under review, unless the NomCom is considering only one or two willing nominees for a position. I'm trying to be very restrictive here (that's my personal viewpoint) - think this is the right tone, or can other people suggest text that would be more appropriate? Thanks, Spencer > As long as the wording is clear that it is "allow" rather than "require" > on your first point, I can live with that. > > Joel > > Spencer Dawkins wrote: >> Hi, Danny, >> >>> Spencer et al., >>> It seems to me we've reached [near] consensus on >>> >> > >>> and I'd _really like to see this I-D pushed to IETF LC and >>> recommendations instituted before the next NomCom cycle - >>> which is approaching fast. >>> >>> Were there any outstanding actions that need to be updated or >>> can we ask to progress? >> >> I believe the required updates for this draft are >> >> - allow padding if NomCom is considering only one or two candidates for a >> specific position (this was requested at the plenary, and if a NomCom can >> only find one or two willing candidates, I'm thinking the choices are (1) >> let them pad, or (2) tell them if we can only find one or two people who >> are willing to serve in a given position, we need to rethink the >> position, not just add a couple of ringers - and I would be OK with >> either path forward) >> >> - make it clear that all feedback about announced candidates goes to >> NomCom for confidential consideration (we aren't looking for "I Like Bob" >> posts on the IETF discussion list) >> >> - remove Spencer's Personal Opinions in preparation for publication. >> >> What else am I missing? >> >> Thanks, >> >> Spencer >> >> _______________________________________________ >> 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 fred@cisco.com Wed May 6 14:42: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 735A93A6CC4 for ; Wed, 6 May 2009 14:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.473 X-Spam-Level: X-Spam-Status: No, score=-106.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 BMVWWoSLDY5E for ; Wed, 6 May 2009 14:42:43 -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 72B0A3A6C21 for ; Wed, 6 May 2009 14:42:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,304,1238976000"; d="scan'208";a="181909773" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 06 May 2009 21:44:05 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n46Li52k021915; Wed, 6 May 2009 14:44:05 -0700 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n46Li5lb025010; Wed, 6 May 2009 21:44:05 GMT From: Fred Baker To: "Spencer Dawkins" In-Reply-To: <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> X-Priority: 3 References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> Message-Id: <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.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, 6 May 2009 14:44:02 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3091; t=1241646245; x=1242510245; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[ietf-nomcom]=20announcing=20list=20of= 20willing=20candidates |Sender:=20; bh=5uy9mgdwz6o8QYduHrswAiOVLfERRJ892B5OCaVySWA=; b=aIWhusVY/6G5QBGqbIJl8FLPkfZ9kYAODUUqXEuDxr4lnT2Rl6KH1LRi94 HtIFHfpv8Gd543hrJ0ho0DyzsFsTyd26gM1dSOW0ikxwdT/jdWuAaLEA4Q++ 5Bq8oSVZPK; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 06 May 2009 21:42:44 -0000 That seems like a reasonable tone. I do question the "unless" in the particular case: if a person has withdrawn their name from candidacy, they're not candidates, even if there is no other candidate. I would actually state it positively, though. The list of nominees published should contain only the names of nominees who have indicated a willingness to serve in a position under review. On May 6, 2009, at 2:29 PM, Spencer Dawkins wrote: > Hi, Joel, > > Exactly. The text in my working draft looks like this: > > The list of nominees published should not contain the names of > nominees who > have not indicated a willingness to serve in a position under > review, unless the NomCom is considering only one or two > willing nominees for a position. > > > > I'm trying to be very restrictive here (that's my personal > viewpoint) - think this is the right tone, or can other people > suggest text that would be more appropriate? > > Thanks, > > Spencer > > >> As long as the wording is clear that it is "allow" rather than >> "require" on your first point, I can live with that. >> >> Joel >> >> Spencer Dawkins wrote: >>> Hi, Danny, >>> >>>> Spencer et al., >>>> It seems to me we've reached [near] consensus on >>>> >>> > >>>> and I'd _really like to see this I-D pushed to IETF LC and >>>> recommendations instituted before the next NomCom cycle - >>>> which is approaching fast. >>>> >>>> Were there any outstanding actions that need to be updated or >>>> can we ask to progress? >>> >>> I believe the required updates for this draft are >>> >>> - allow padding if NomCom is considering only one or two >>> candidates for a specific position (this was requested at the >>> plenary, and if a NomCom can only find one or two willing >>> candidates, I'm thinking the choices are (1) let them pad, or (2) >>> tell them if we can only find one or two people who are willing to >>> serve in a given position, we need to rethink the position, not >>> just add a couple of ringers - and I would be OK with either path >>> forward) >>> >>> - make it clear that all feedback about announced candidates goes >>> to NomCom for confidential consideration (we aren't looking for "I >>> Like Bob" posts on the IETF discussion list) >>> >>> - remove Spencer's Personal Opinions in preparation for publication. >>> >>> What else am I missing? >>> >>> Thanks, >>> >>> Spencer >>> >>> _______________________________________________ >>> 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 spencer@wonderhamster.org Wed May 6 14:58: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 879EB3A6C6E for ; Wed, 6 May 2009 14:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 SlacICpZYjsU for ; Wed, 6 May 2009 14:58:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 749233A6B3B for ; Wed, 6 May 2009 14:58:39 -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-1M1p9n0vH1-000cpn; Wed, 06 May 2009 18:00:06 -0400 Message-ID: From: "Spencer Dawkins" To: "Fred Baker" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> Date: Wed, 6 May 2009 16:59:42 -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: V01U2FsdGVkX18Y/ZszeCiFVyfH/G/qwT/G27IiI/3azzvZ8qn QSldh5FDk2gkvhcOle11lHho1MIGmJ4rVXpiL3iPauHtLYteHX LWFSI/5oq86AkryeilI9KnhAlHqCvITkdAj0OZ3nAg= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 06 May 2009 21:58:40 -0000 Hi, Fred, This paragraph was intended to cover padding - "don't do it unless you have only one or two willing nominees". In that case, the additional nominees aren't willing, but their names would still be published (with permission, of course). Is this clearer? The list of nominees published should not contain the names of nominees who are unwilling to serve in a position under review, unless the NomCom is considering only one or two willing nominees for a position and wishes to include "padding" in the published list of nominees, with permission from these unwilling nominees. To all - I'm struggling a little bit with "one or two" - if we have two willing candidates, do we NEED to add padding? I'd like to make this "considering only one willing nominee", but don't want to do that without asking the mailing list. Thanks, Spencer > That seems like a reasonable tone. I do question the "unless" in the > particular case: if a person has withdrawn their name from candidacy, > they're not candidates, even if there is no other candidate. > > I would actually state it positively, though. > > The list of nominees published should contain only the names of > nominees who have indicated a willingness to serve in a position under > review. > > On May 6, 2009, at 2:29 PM, Spencer Dawkins wrote: > >> Hi, Joel, >> >> Exactly. The text in my working draft looks like this: >> >> The list of nominees published should not contain the names of >> nominees who >> have not indicated a willingness to serve in a position under >> review, unless the NomCom is considering only one or two >> willing nominees for a position. >> >> >> >> I'm trying to be very restrictive here (that's my personal viewpoint) - >> think this is the right tone, or can other people suggest text that >> would be more appropriate? >> >> Thanks, >> >> Spencer >> >> >>> As long as the wording is clear that it is "allow" rather than >>> "require" on your first point, I can live with that. >>> >>> Joel >>> >>> Spencer Dawkins wrote: >>>> Hi, Danny, >>>> >>>>> Spencer et al., >>>>> It seems to me we've reached [near] consensus on >>>>> >>>> > >>>>> and I'd _really like to see this I-D pushed to IETF LC and >>>>> recommendations instituted before the next NomCom cycle - >>>>> which is approaching fast. >>>>> >>>>> Were there any outstanding actions that need to be updated or >>>>> can we ask to progress? >>>> >>>> I believe the required updates for this draft are >>>> >>>> - allow padding if NomCom is considering only one or two candidates >>>> for a specific position (this was requested at the plenary, and if a >>>> NomCom can only find one or two willing candidates, I'm thinking the >>>> choices are (1) let them pad, or (2) tell them if we can only find one >>>> or two people who are willing to serve in a given position, we need to >>>> rethink the position, not just add a couple of ringers - and I would >>>> be OK with either path forward) >>>> >>>> - make it clear that all feedback about announced candidates goes to >>>> NomCom for confidential consideration (we aren't looking for "I Like >>>> Bob" posts on the IETF discussion list) >>>> >>>> - remove Spencer's Personal Opinions in preparation for publication. >>>> >>>> What else am I missing? >>>> >>>> Thanks, >>>> >>>> Spencer >>>> >>>> _______________________________________________ >>>> 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 fred@cisco.com Wed May 6 15:12:05 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 1CA1E3A68B9 for ; Wed, 6 May 2009 15:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 bBI4gZEn1jtF for ; Wed, 6 May 2009 15:12:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 064C23A6A9B for ; Wed, 6 May 2009 15:12:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,305,1238976000"; d="scan'208";a="299762305" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 May 2009 22:13:31 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n46MDVGN011116; Wed, 6 May 2009 15:13:31 -0700 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n46MDVFj005324; Wed, 6 May 2009 22:13:31 GMT From: Fred Baker To: "Spencer Dawkins" In-Reply-To: X-Priority: 3 References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> Message-Id: <675982CA-8EED-470C-888D-DB876816D256@cisco.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, 6 May 2009 15:13:31 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4698; t=1241648011; x=1242512011; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[ietf-nomcom]=20announcing=20list=20of= 20willing=20candidates |Sender:=20; bh=ZTGRL6FSVSHPblk6Q1kE3ZDIG5SZOYv3V2RN2G6q1Ws=; b=OHLl/56428bojl0nh86PbZMLUQkkQ8kItRFmmVajIF2bap+vbDQHX+9ezZ LqTMqe5SAES9JgRQ0bVwTPatQu5vRXR2IT8Aspw0PsyZLzyWGQ01oxl5QeBp yetmyjY2Ei; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 06 May 2009 22:12:05 -0000 How about: The list of nominees published should not contain the names of nominees who are unwilling to serve in a position under review, unless the NomCom wishes to include "padding" in the published list of nominees, with permission from these unwilling nominees. btw, why the blank line? On May 6, 2009, at 2:59 PM, Spencer Dawkins wrote: > Hi, Fred, > > This paragraph was intended to cover padding - "don't do it unless > you have only one or two willing nominees". In that case, the > additional nominees aren't willing, but their names would still be > published (with permission, of course). > > Is this clearer? > > The list of nominees published should not contain the names of > nominees who > are unwilling to serve in a position under > review, unless the NomCom is considering only one or two > willing nominees for a position and wishes to include "padding" in > the published > list of nominees, with permission from these unwilling nominees. > > > > To all - I'm struggling a little bit with "one or two" - if we have > two willing candidates, do we NEED to add padding? I'd like to make > this "considering only one willing nominee", but don't want to do > that without asking the mailing list. > > Thanks, > > Spencer > > >> That seems like a reasonable tone. I do question the "unless" in >> the particular case: if a person has withdrawn their name from >> candidacy, they're not candidates, even if there is no other >> candidate. >> >> I would actually state it positively, though. >> >> The list of nominees published should contain only the names of >> nominees who have indicated a willingness to serve in a position >> under review. >> >> On May 6, 2009, at 2:29 PM, Spencer Dawkins wrote: >> >>> Hi, Joel, >>> >>> Exactly. The text in my working draft looks like this: >>> >>> The list of nominees published should not contain the names of >>> nominees who >>> have not indicated a willingness to serve in a position under >>> review, unless the NomCom is considering only one or two >>> willing nominees for a position. >>> >>> >>> >>> I'm trying to be very restrictive here (that's my personal >>> viewpoint) - think this is the right tone, or can other people >>> suggest text that would be more appropriate? >>> >>> Thanks, >>> >>> Spencer >>> >>> >>>> As long as the wording is clear that it is "allow" rather than >>>> "require" on your first point, I can live with that. >>>> >>>> Joel >>>> >>>> Spencer Dawkins wrote: >>>>> Hi, Danny, >>>>> >>>>>> Spencer et al., >>>>>> It seems to me we've reached [near] consensus on >>>>>> >>>>> > >>>>>> and I'd _really like to see this I-D pushed to IETF LC and >>>>>> recommendations instituted before the next NomCom cycle - >>>>>> which is approaching fast. >>>>>> >>>>>> Were there any outstanding actions that need to be updated or >>>>>> can we ask to progress? >>>>> >>>>> I believe the required updates for this draft are >>>>> >>>>> - allow padding if NomCom is considering only one or two >>>>> candidates for a specific position (this was requested at the >>>>> plenary, and if a NomCom can only find one or two willing >>>>> candidates, I'm thinking the choices are (1) let them pad, or >>>>> (2) tell them if we can only find one or two people who are >>>>> willing to serve in a given position, we need to rethink the >>>>> position, not just add a couple of ringers - and I would be OK >>>>> with either path forward) >>>>> >>>>> - make it clear that all feedback about announced candidates >>>>> goes to NomCom for confidential consideration (we aren't >>>>> looking for "I Like Bob" posts on the IETF discussion list) >>>>> >>>>> - remove Spencer's Personal Opinions in preparation for >>>>> publication. >>>>> >>>>> What else am I missing? >>>>> >>>>> Thanks, >>>>> >>>>> Spencer >>>>> >>>>> _______________________________________________ >>>>> 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 spencer@wonderhamster.org Wed May 6 15:34: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 B32B93A6A65 for ; Wed, 6 May 2009 15:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.406, 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 tY7zR683L-rp for ; Wed, 6 May 2009 15:34:19 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id A61E13A6A41 for ; Wed, 6 May 2009 15:34:19 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1M1piH1szH-000fzf; Wed, 06 May 2009 18:35:44 -0400 Message-ID: <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> From: "Spencer Dawkins" To: "Fred Baker" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> Date: Wed, 6 May 2009 17:35: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/LT4+jKKStS9lTEMhK1PZpcNiMbskTHaeLrgJ N6gH7UyF2a+iIfjDmIRRj7Q4CrHOsP6RHoMH3x0tlcZ3A2Oe85 f7clBzRYB0a9Ca5gLcvLSlzrHCeB8k1uANYJV3Br/U= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 06 May 2009 22:34:20 -0000 Hi, Fred, > How about: > > The list of nominees published should not contain the names of > nominees who > are unwilling to serve in a position under > review, unless the NomCom wishes to include "padding" in the published > list of nominees, with permission from these unwilling nominees. This seems to be less restrictive - basically saying "NomCom shouldn't use padding unless they want to". I was taking the hum at IETF 74 plenary as evidence that people wanted to say "don't use padding" - but one of the current NomCom participants asked, "but what if we've only got one or two willing nominees?", so I didn't want to exclude padding in that case. Modulo checking that evidence on the mailing list, of course. How are other people seeing this? Thanks, Spencer > > > > btw, why the blank line? > > On May 6, 2009, at 2:59 PM, Spencer Dawkins wrote: > >> Hi, Fred, >> >> This paragraph was intended to cover padding - "don't do it unless you >> have only one or two willing nominees". In that case, the additional >> nominees aren't willing, but their names would still be published (with >> permission, of course). >> >> Is this clearer? >> >> The list of nominees published should not contain the names of >> nominees who >> are unwilling to serve in a position under >> review, unless the NomCom is considering only one or two >> willing nominees for a position and wishes to include "padding" in the >> published >> list of nominees, with permission from these unwilling nominees. >> >> >> >> To all - I'm struggling a little bit with "one or two" - if we have two >> willing candidates, do we NEED to add padding? I'd like to make this >> "considering only one willing nominee", but don't want to do that >> without asking the mailing list. >> >> Thanks, >> >> Spencer >> >> >>> That seems like a reasonable tone. I do question the "unless" in the >>> particular case: if a person has withdrawn their name from candidacy, >>> they're not candidates, even if there is no other candidate. >>> >>> I would actually state it positively, though. >>> >>> The list of nominees published should contain only the names of >>> nominees who have indicated a willingness to serve in a position under >>> review. >>> >>> On May 6, 2009, at 2:29 PM, Spencer Dawkins wrote: >>> >>>> Hi, Joel, >>>> >>>> Exactly. The text in my working draft looks like this: >>>> >>>> The list of nominees published should not contain the names of >>>> nominees who >>>> have not indicated a willingness to serve in a position under >>>> review, unless the NomCom is considering only one or two >>>> willing nominees for a position. >>>> >>>> >>>> >>>> I'm trying to be very restrictive here (that's my personal >>>> viewpoint) - think this is the right tone, or can other people >>>> suggest text that would be more appropriate? >>>> >>>> Thanks, >>>> >>>> Spencer >>>> >>>> >>>>> As long as the wording is clear that it is "allow" rather than >>>>> "require" on your first point, I can live with that. >>>>> >>>>> Joel >>>>> >>>>> Spencer Dawkins wrote: >>>>>> Hi, Danny, >>>>>> >>>>>>> Spencer et al., >>>>>>> It seems to me we've reached [near] consensus on >>>>>>> >>>>>> > >>>>>>> and I'd _really like to see this I-D pushed to IETF LC and >>>>>>> recommendations instituted before the next NomCom cycle - >>>>>>> which is approaching fast. >>>>>>> >>>>>>> Were there any outstanding actions that need to be updated or >>>>>>> can we ask to progress? >>>>>> >>>>>> I believe the required updates for this draft are >>>>>> >>>>>> - allow padding if NomCom is considering only one or two candidates >>>>>> for a specific position (this was requested at the plenary, and if >>>>>> a NomCom can only find one or two willing candidates, I'm thinking >>>>>> the choices are (1) let them pad, or (2) tell them if we can only >>>>>> find one or two people who are willing to serve in a given >>>>>> position, we need to rethink the position, not just add a couple of >>>>>> ringers - and I would be OK with either path forward) >>>>>> >>>>>> - make it clear that all feedback about announced candidates goes >>>>>> to NomCom for confidential consideration (we aren't looking for "I >>>>>> Like Bob" posts on the IETF discussion list) >>>>>> >>>>>> - remove Spencer's Personal Opinions in preparation for publication. >>>>>> >>>>>> What else am I missing? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Spencer >>>>>> >>>>>> _______________________________________________ >>>>>> 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 bertietf@bwijnen.net Wed May 6 23:51:46 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 13B573A68DA for ; Wed, 6 May 2009 23:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.127 X-Spam-Level: X-Spam-Status: No, score=-0.127 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=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 MTC2DU7TXJKw for ; Wed, 6 May 2009 23:51:44 -0700 (PDT) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 9DFE23A6FD5 for ; Wed, 6 May 2009 23:51:25 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1M1xTO-0000dv-Hq; Thu, 07 May 2009 08:52:50 +0200 Message-ID: <765544F852C2434E8C21B9A3FFF91495@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Spencer Dawkins" , "Fred Baker" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com><4A01FF14.1000802@joelhalpern.com><68203580453A41F9BE4A8E17676A40DD@china.huawei.com><52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com><675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> In-Reply-To: <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> Date: Thu, 7 May 2009 08:52:29 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_177C_01C9CEF1.26D7B200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 06:51:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_177C_01C9CEF1.26D7B200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I do not like the padding at all. So certainly it should be "allow the nomcom to do so in rare cases where there is only one (max 2) willing nominees). Maybe too big a change.... but how about allowing new nominations if there is only one (willing) nominee? In other words, if those who = need to comment believe that the one nominee is perfect, then fine. If not, = they can/should find other volunteers that can be nominated. Of course this = should not happen too late in the process. Bert ----- Original Message -----=20 From: Spencer Dawkins=20 To: Fred Baker=20 Cc: NomComDiscussion=20 Sent: Thursday, May 07, 2009 12:35 AM Subject: Re: [ietf-nomcom] announcing list of willing candidates Hi, Fred, > How about: > > The list of nominees published should not contain the names of=20 > nominees who > are unwilling to serve in a position under > review, unless the NomCom wishes to include "padding" in the = published > list of nominees, with permission from these unwilling nominees. This seems to be less restrictive - basically saying "NomCom shouldn't = use=20 padding unless they want to". I was taking the hum at IETF 74 plenary as evidence that people wanted = to=20 say "don't use padding" - but one of the current NomCom participants = asked,=20 "but what if we've only got one or two willing nominees?", so I didn't = want=20 to exclude padding in that case. Modulo checking that evidence on the mailing list, of course. How are other people seeing this? Thanks, Spencer > > > > btw, why the blank line? > > On May 6, 2009, at 2:59 PM, Spencer Dawkins wrote: > >> Hi, Fred, >> >> This paragraph was intended to cover padding - "don't do it unless = you=20 >> have only one or two willing nominees". In that case, the = additional=20 >> nominees aren't willing, but their names would still be published = (with=20 >> permission, of course). >> >> Is this clearer? >> >> The list of nominees published should not contain the names of=20 >> nominees who >> are unwilling to serve in a position under >> review, unless the NomCom is considering only one or two >> willing nominees for a position and wishes to include "padding" in = the=20 >> published >> list of nominees, with permission from these unwilling nominees. >> >> >> >> To all - I'm struggling a little bit with "one or two" - if we have = two=20 >> willing candidates, do we NEED to add padding? I'd like to make = this=20 >> "considering only one willing nominee", but don't want to do that=20 >> without asking the mailing list. >> >> Thanks, >> >> Spencer >> >> >>> That seems like a reasonable tone. I do question the "unless" in = the=20 >>> particular case: if a person has withdrawn their name from = candidacy,=20 >>> they're not candidates, even if there is no other candidate. >>> >>> I would actually state it positively, though. >>> >>> The list of nominees published should contain only the names of = >>> nominees who have indicated a willingness to serve in a position = under=20 >>> review. >>> >>> On May 6, 2009, at 2:29 PM, Spencer Dawkins wrote: >>> >>>> Hi, Joel, >>>> >>>> Exactly. The text in my working draft looks like this: >>>> >>>> The list of nominees published should not contain the names of = >>>> nominees who >>>> have not indicated a willingness to serve in a position under >>>> review, unless the NomCom is considering only one or two >>>> willing nominees for a position. >>>> >>>> >>>> >>>> I'm trying to be very restrictive here (that's my personal=20 >>>> viewpoint) - think this is the right tone, or can other people=20 >>>> suggest text that would be more appropriate? >>>> >>>> Thanks, >>>> >>>> Spencer >>>> >>>> >>>>> As long as the wording is clear that it is "allow" rather than=20 >>>>> "require" on your first point, I can live with that. >>>>> >>>>> Joel >>>>> >>>>> Spencer Dawkins wrote: >>>>>> Hi, Danny, >>>>>> >>>>>>> Spencer et al., >>>>>>> It seems to me we've reached [near] consensus on >>>>>>> = >>>>>> > >>>>>>> and I'd _really like to see this I-D pushed to IETF LC and >>>>>>> recommendations instituted before the next NomCom cycle - >>>>>>> which is approaching fast. >>>>>>> >>>>>>> Were there any outstanding actions that need to be updated or >>>>>>> can we ask to progress? >>>>>> >>>>>> I believe the required updates for this draft are >>>>>> >>>>>> - allow padding if NomCom is considering only one or two = candidates=20 >>>>>> for a specific position (this was requested at the plenary, = and if=20 >>>>>> a NomCom can only find one or two willing candidates, I'm = thinking=20 >>>>>> the choices are (1) let them pad, or (2) tell them if we can = only=20 >>>>>> find one or two people who are willing to serve in a given=20 >>>>>> position, we need to rethink the position, not just add a = couple of=20 >>>>>> ringers - and I would be OK with either path forward) >>>>>> >>>>>> - make it clear that all feedback about announced candidates = goes=20 >>>>>> to NomCom for confidential consideration (we aren't looking = for "I=20 >>>>>> Like Bob" posts on the IETF discussion list) >>>>>> >>>>>> - remove Spencer's Personal Opinions in preparation for = publication. >>>>>> >>>>>> What else am I missing? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Spencer >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >> >> > >=20 _______________________________________________ ietf-nomcom mailing list ietf-nomcom@ietf.org https://www.ietf.org/mailman/listinfo/ietf-nomcom ------=_NextPart_000_177C_01C9CEF1.26D7B200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I do not like the padding at all.
So certainly it should be "allow the nomcom to do so = in=20 rare
cases where there is only one (max 2) willing=20 nominees).
 
Maybe too big a change.... but how about = allowing new=20 nominations
if there is only one (willing) nominee? In other = words, if=20 those who need
to comment believe that the one nominee is perfect, = then fine.=20 If not, they
can/should find other volunteers that can be = nominated. Of=20 course this should
not happen too late in the process.
 
Bert
----- Original Message -----
From:=20 Spencer Dawkins
Sent: Thursday, May 07, 2009 = 12:35=20 AM
Subject: Re: [ietf-nomcom] = announcing=20 list of willing candidates

Hi, Fred,


> How about:
>
>=20 <t>The list of nominees published should not contain the names = of=20
> nominees who
>  are unwilling to serve in a = position=20 under
>  review, unless the NomCom wishes to include = "padding" in=20 the published
>  list of nominees, with permission from = these=20 unwilling nominees.

This seems to be less restrictive - = basically=20 saying "NomCom shouldn't use
padding unless they want = to".

I was=20 taking the hum at IETF 74 plenary as evidence that people wanted to =
say=20 "don't use padding" - but one of the current NomCom participants = asked,=20
"but what if we've only got one or two willing nominees?", so I = didn't=20 want
to exclude padding in that case.

Modulo checking that = evidence=20 on the mailing list, of course.

How are other people seeing=20 this?

Thanks,

Spencer

>  <vspace=20 blankLines=3D'1' />
> </t>
>
> btw, why the = blank=20 line?
>
> On May 6, 2009, at 2:59 PM, Spencer Dawkins=20 wrote:
>
>> Hi, Fred,
>>
>> This = paragraph=20 was intended to cover padding - "don't do it unless  you =
>>=20 have only one or two willing nominees". In that case, the  = additional=20
>> nominees aren't willing, but their names would still = be =20 published (with
>> permission, of = course).
>>
>>=20 Is this clearer?
>>
>> <t>The list of nominees = published should not contain the names of
>> nominees=20 who
>>  are unwilling to serve in a position=20 under
>>  review, unless the NomCom is considering only = one or=20 two
>>  willing nominees for a position and wishes to = include=20 "padding" in  the
>> published
>>  list = of=20 nominees, with permission from these unwilling = nominees.
>> =20 <vspace blankLines=3D'1' />
>> = </t>
>>
>>=20 To all - I'm struggling a little bit with "one or two" - if we = have  two=20
>> willing candidates, do we NEED to add padding? I'd like = to=20 make  this
>> "considering only one willing nominee", = but don't=20 want to do  that
>> without asking the mailing=20 list.
>>
>> Thanks,
>>
>>=20 Spencer
>>
>>
>>> That seems like a = reasonable=20 tone. I do question the "unless" in  the
>>> = particular=20 case: if a person has withdrawn their name from  candidacy,=20
>>> they're not candidates, even if there is no = other =20 candidate.
>>>
>>> I would actually state it=20 positively, though.
>>>
>>> <t>The list = of=20 nominees published should contain only the names of
>>> = nominees=20 who have indicated a willingness to serve in a position  under=20
>>> review.</t>
>>>
>>> On = May 6,=20 2009, at 2:29 PM, Spencer Dawkins = wrote:
>>>
>>>>=20 Hi, Joel,
>>>>
>>>> Exactly. The text in = my=20 working draft looks like this:
>>>>
>>>> = <t>The list of nominees published should not contain the names = of=20
>>>> nominees who
>>>> have not = indicated a=20 willingness to serve in a position under
>>>> review, = unless=20 the NomCom is considering only one or two
>>>> willing = nominees=20 for a position.
>>>> <vspace blankLines=3D'1'=20 />
>>>> = </t>
>>>>
>>>>=20 I'm trying to be very restrictive here (that's my personal=20
>>>>   viewpoint) - think this is the right = tone, or=20 can other people
>>>> suggest text that would be more=20 appropriate?
>>>>
>>>>=20 Thanks,
>>>>
>>>>=20 = Spencer
>>>>
>>>>
>>>>> = As=20 long as the wording is clear that it is "allow" rather than=20
>>>>> "require" on your first point, I can live = with=20 that.
>>>>>
>>>>>=20 Joel
>>>>>
>>>>> Spencer Dawkins=20 wrote:
>>>>>> Hi,=20 Danny,
>>>>>>
>>>>>>> = Spencer et=20 al.,
>>>>>>> It seems to me we've reached = [near]=20 consensus on
>>>>>>> <http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-openlis= t-01.txt
>>>>>>>=20 >
>>>>>>> and I'd _really like to see this = I-D=20 pushed to IETF LC and
>>>>>>> recommendations=20 instituted before the next NomCom cycle = -
>>>>>>>=20 which is approaching=20 fast.
>>>>>>>
>>>>>>> = Were=20 there any outstanding actions that need to be updated=20 or
>>>>>>> can we ask to=20 progress?
>>>>>>
>>>>>> I = believe=20 the required updates for this draft=20 are
>>>>>>
>>>>>> - allow = padding if=20 NomCom is considering only one or two   candidates=20
>>>>>> for a specific position (this was = requested at=20 the   plenary, and if
>>>>>> a NomCom = can only=20 find one or two willing   candidates, I'm thinking=20
>>>>>> the choices are (1) let them pad, = or =20 (2)  tell them if we can only
>>>>>> find = one or=20 two people who are  willing to  serve in a given=20
>>>>>> position, we need to rethink the  = position,=20 not  just add a couple of
>>>>>> ringers - = and I=20 would be OK  with either path =20 forward)
>>>>>>
>>>>>> - = make it=20 clear that all feedback about announced candidates  goes=20
>>>>>> to NomCom for confidential consideration = (we=20 aren't  looking for "I
>>>>>> Like Bob" = posts on=20 the IETF discussion=20 list)
>>>>>>
>>>>>> - remove = Spencer's Personal Opinions in preparation for =20 publication.
>>>>>>
>>>>>> = What else=20 am I missing?
>>>>>>
>>>>>>=20 Thanks,
>>>>>>
>>>>>>=20 Spencer
>>>>>>
>>>>>>=20 = _______________________________________________
>>>>>&g= t;=20 ietf-nomcom mailing list
>>>>>> ietf-nomcom@ietf.org
>>= >>>>=20 https://www.ie= tf.org/mailman/listinfo/ietf-nomcom
>>>>>>
&g= t;>>>>=20 = _______________________________________________
>>>>>=20 ietf-nomcom mailing list
>>>>> ietf-nomcom@ietf.org
>>= >>>=20 https://www.ie= tf.org/mailman/listinfo/ietf-nomcom
>>>>
>>&g= t;>
>>>>=20 _______________________________________________
>>>>=20 ietf-nomcom mailing list
>>>> ietf-nomcom@ietf.org
>>= >>=20 https://www.ie= tf.org/mailman/listinfo/ietf-nomcom
>>>
>>
&g= t;>
>
>=20 =


_______________________________________________
ietf-nomco= m=20 mailing list
ietf-nomcom@ietf.org
https://www.ie= tf.org/mailman/listinfo/ietf-nomcom
------=_NextPart_000_177C_01C9CEF1.26D7B200-- From lars.eggert@nokia.com Thu May 7 00:53: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 3D9BE3A6898 for ; Thu, 7 May 2009 00:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 qVNaNiWfov9S for ; Thu, 7 May 2009 00:53:08 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 2FE163A677D for ; Thu, 7 May 2009 00:53:08 -0700 (PDT) Received: from [10.180.88.11] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n477sSdH063605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 May 2009 10:54:28 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Spencer Dawkins In-Reply-To: <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> Content-Type: multipart/signed; boundary=Apple-Mail-58--764825780; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 7 May 2009 10:54:22 +0300 References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Thu, 07 May 2009 10:54:28 +0300 (EEST) Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 07:53:10 -0000 --Apple-Mail-58--764825780 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-5-7, at 1:35, Spencer Dawkins wrote: > I was taking the hum at IETF 74 plenary as evidence that people > wanted to > say "don't use padding" I saw consensus for "don't use padding". > - but one of the current NomCom participants asked, > "but what if we've only got one or two willing nominees?", so I > didn't want > to exclude padding in that case. I didn't see consensus for allowing padding in this special case - my take-away was that there was consensus to not use padding then either. Lars --Apple-Mail-58--764825780 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA1MDcwNzU0MjNaMCMGCSqGSIb3DQEJBDEWBBSgsd+/bo5OUObi jw6EbaQJG0kW6zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAAjPXLif84uw5VnBBBG0uMdl5fOPpzqF5pRhxebjvREL8OolWuYsR IjqMtvakWa99Ip9wC6cbCR0HF+QwtQZqxeJOyNsN5F5AB8VI5YAJt/bGt1wR6gT81hb5RZRsVafi Lg1bfWbCs743GilKZTEScqdLlKqTAOV4j1yB85XXoz0W2YBNIkkAFiXEZNtiYt2VCUYoR/K/uatH WC0N8/zhH+XMerkViMybXTKn+QI8lF1k2mPQypFX5jHeUd0X3PZBp+2qC7zU1xs3Rs7xEmQVbvhi YcYtXPBOe9pWXXaV8Wc+Y3D8YwN9IgRHhltomqZnhjsWvMb53qlGie/X583lfwAAAAAAAA== --Apple-Mail-58--764825780-- From spencer@wonderhamster.org Thu May 7 05:28:17 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 71B0F28C11A for ; Thu, 7 May 2009 05:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.397, 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 AT3VN+EiLzec for ; Thu, 7 May 2009 05:28:16 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 948BA3A6BE8 for ; Thu, 7 May 2009 05:28:16 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1M22ix1air-000ft5; Thu, 07 May 2009 08:29:18 -0400 Message-ID: From: "Spencer Dawkins" To: "Lars Eggert" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> Date: Thu, 7 May 2009 07:28:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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/SBrY78PQfha1TxvpaM+PuThzekkq1pAey02e TulLAJrlybgakUzZgF13MI6xJfQe3sia9TpMVHTDVAOzFBgwyZ jeIj5ddMaRGDrugm3VlrRztsB4xGnRxjufyRvLG+qg= Cc: NomComDiscussion Subject: [ietf-nomcom] Sense-of-the-mailing-list call for padding on small nominee lists - MUST NOT or SHOULD NOT? 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, 07 May 2009 12:28:17 -0000 >> - but one of the current NomCom participants asked, >> "but what if we've only got one or two willing nominees?", so I didn't >> want >> to exclude padding in that case. > > I didn't see consensus for allowing padding in this special case - my > take-away was that there was consensus to not use padding then either. > > Lars OK, I went back and looked at http://www.ietf.org/proceedings/09mar/plenaryw.html, which says "Russ asks who believes we should open an unpadded willing-to-serve nominee list? very many hums Russ asks who is opposed? few hums Russ asks who believes that we need to do anything that describes what is acceptable nominee behaviour. many hums Russ asks who doesn't believe this is necessary? a few more hums" So it doesn't look like Russ took a hum on the special case, and even if he had, we should be verifying on a mailing list - could people who think we should allow padding of nominee lists with only one or two willing nominees say so now? I'll remove the special-case text and hold off submitting for a couple of days, to see what pops up on the mailing list - so the working copy of this draft now looks like The list of nominees for a position under review should not contain the names of nominees who are unwilling to serve in that position (so-called "padding"). Thanks, Spencer From sob@harvard.edu Thu May 7 05:31:46 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 DEE973A6DE3 for ; Thu, 7 May 2009 05:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 J+a9DL8W4trt for ; Thu, 7 May 2009 05:31:46 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 216203A6B04 for ; Thu, 7 May 2009 05:31:08 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 6C69316BD307; Thu, 7 May 2009 08:32:33 -0400 (EDT) To: lars.eggert@nokia.com, spencer@wonderhamster.org In-Reply-To: Message-Id: <20090507123233.6C69316BD307@newdev.eecs.harvard.edu> Date: Thu, 7 May 2009 08:32:33 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding on small nominee lists - MUST NOT or SHOULD NOT? 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, 07 May 2009 12:31:47 -0000 > could people who think we > should allow padding of nominee lists with only one or two willing nominees > say so now? I'd rather leave the nomcom with flexibility Scott From sob@harvard.edu Thu May 7 05:32:00 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 C2A6D3A6FF5 for ; Thu, 7 May 2009 05:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 uDuYW0-O0TRi for ; Thu, 7 May 2009 05:32:00 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 3D3E13A6FEF for ; Thu, 7 May 2009 05:31:50 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 3096216BD31F; Thu, 7 May 2009 08:33:18 -0400 (EDT) To: lars.eggert@nokia.com, spencer@wonderhamster.org In-Reply-To: Message-Id: <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> Date: Thu, 7 May 2009 08:33:18 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding on small nominee lists - MUST NOT or SHOULD NOT? 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, 07 May 2009 12:32:00 -0000 maybe "do not need to pad..." Scott From spencer@wonderhamster.org Thu May 7 05:38: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 B325C3A6886 for ; Thu, 7 May 2009 05:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 bAogCcAwshvc for ; Thu, 7 May 2009 05:38:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id D4D5C3A67D9 for ; Thu, 7 May 2009 05:38:40 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1M22tI1cyz-000fsi; Thu, 07 May 2009 08:39:59 -0400 Message-ID: From: "Spencer Dawkins" To: "Lars Eggert" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> Date: Thu, 7 May 2009 07:39:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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/lHhnVj9pfShO9DlHuuJJbkUv2Gt2p2AOJEVm SHVWCMqP6Jsi51pJMQWLtKQ1Fnc8V0Sz+ZmRmGBE1keyyPmjN3 7NrrrsjxoZPULConmwI7Kfj4Wk+n3Z4BXfIo/+nreQ= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 12:38:41 -0000 Hi, Lars, >> - but one of the current NomCom participants asked, >> "but what if we've only got one or two willing nominees?", so I didn't >> want >> to exclude padding in that case. > > I didn't see consensus for allowing padding in this special case - my > take-away was that there was consensus to not use padding then either. OK, let's go there. ("I've never served on a NomCom, but ..." - and not trying to reflect consensus yet, because this is a question I haven't seen discussed lately) What do we want NomCom to do if there is only one willing nominee? I'm assuming that choices would include (singly or in combination): - asking for feedback on a padded list (what we are saying we DON'T want to keep doing), - asking for feedback on one willing nominee with no padding (boy, it would reek to be that person and not get selected, but I guess it's not much worse than reopening the call for nominations after lots of people have seen the short list, which we do today), - looking at the single nominee without a call for feedback from the community, - reopening the call for nominations with a higher level of "enhanced recruiting techniques" (sorry for the GITMO reference), or - telling someone (who?) that there isn't enough community support for this position to allow NomCom to fill the position using the normal NomCom process, and we need to look at whether the position needs to be redefined or even eliminated. Are there other choices that I'm missing? What SHOULD happen? Can we provide helpful guidance in this document? Thanks, Spencer From narten@us.ibm.com Thu May 7 05:43:49 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 614AC3A6926 for ; Thu, 7 May 2009 05:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.803 X-Spam-Level: X-Spam-Status: No, score=-5.803 tagged_above=-999 required=5 tests=[AWL=0.796, 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 2RuJa6ktDIgt for ; Thu, 7 May 2009 05:43:48 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 817983A67D9 for ; Thu, 7 May 2009 05:43:48 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n47CfQBl003628 for ; Thu, 7 May 2009 08:41:26 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n47Cj6Ae141052 for ; Thu, 7 May 2009 08:45:06 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n47Cj5B0020877 for ; Thu, 7 May 2009 08:45:06 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-21.mts.ibm.com [9.49.155.21]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n47Cj4l2020736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 08:45:05 -0400 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 n47Cj2o0026140; Thu, 7 May 2009 08:45:03 -0400 Message-Id: <200905071245.n47Cj2o0026140@cichlid.raleigh.ibm.com> To: "Bert Wijnen \(IETF\)" In-reply-to: <765544F852C2434E8C21B9A3FFF91495@BertLaptop> References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com><4A01FF14.1000802@joelhalpern.com><68203580453A41F9BE4A8E17676A40DD@china.huawei.com><52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com><675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <765544F852C2434E8C21B9A3FFF91495@BertLaptop> Comments: In-reply-to "Bert Wijnen \(IETF\)" message dated "Thu, 07 May 2009 08:52:29 +0200." Date: Thu, 07 May 2009 08:45:02 -0400 From: Thomas Narten Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 12:43:49 -0000 > I do not like the padding at all. Agreed. What I'd like to see in the document is a short explanation of why padding is to be avoided and why it is considered a Bad Thing. Without that background, we just have a process rule that misses the underlying issue. I.e., the rule about padding the list really ought to be "SHOULD NOT", with an explanation of why. For me, the issue with padding is that it wastes the community's time and is a disincentive to comment on the names. That does not help in the selection of the best candidates. But I could imagine some scenarios where it is deemed necessary, in which case a process rule that says MUST NOT seems a bad thing to have on the books. Thomas From narten@us.ibm.com Thu May 7 05:47:05 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 6E3383A6EA7 for ; Thu, 7 May 2009 05:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.85 X-Spam-Level: X-Spam-Status: No, score=-5.85 tagged_above=-999 required=5 tests=[AWL=0.749, 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 k5nPnZtTsA5B for ; Thu, 7 May 2009 05:47:04 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 7B1953A6DE3 for ; Thu, 7 May 2009 05:47:04 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n47ChXDc030973 for ; Thu, 7 May 2009 08:43:33 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n47CmVQ4149218 for ; Thu, 7 May 2009 08:48:31 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n47CmVgP021637 for ; Thu, 7 May 2009 08:48:31 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-21.mts.ibm.com [9.49.155.21]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n47CmURE021559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 08:48:31 -0400 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 n47CmSYc026256; Thu, 7 May 2009 08:48:29 -0400 Message-Id: <200905071248.n47CmSYc026256@cichlid.raleigh.ibm.com> To: "Spencer Dawkins" In-reply-to: References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> Comments: In-reply-to "Spencer Dawkins" message dated "Thu, 07 May 2009 07:39:35 -0500." Date: Thu, 07 May 2009 08:48:28 -0400 From: Thomas Narten Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 12:47:05 -0000 "Spencer Dawkins" writes: > - asking for feedback on one willing nominee with no padding (boy, it would > reek to be that person and not get selected, but I guess it's not much worse > than reopening the call for nominations after lots of people have seen the > short list, which we do today), The nomcom absolutely has to have the ability to do this. I would expect the nomcom to run into "we need more feedback on person X in particular" (for whatever reason). Surely the nomcom should be able to do that? Thomas From bernie@ietf.hoeneisen.ch Thu May 7 06:05: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 0B5533A6EFB for ; Thu, 7 May 2009 06:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 hLqsLDg8JNTK for ; Thu, 7 May 2009 06:05:00 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 34DC13A6DE3 for ; Thu, 7 May 2009 06:05:00 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1M23If-000192-E1; Thu, 07 May 2009 15:06:09 +0200 Date: Thu, 7 May 2009 15:06:09 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Thomas Narten In-Reply-To: <200905071245.n47Cj2o0026140@cichlid.raleigh.ibm.com> Message-ID: References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com><4A01FF14.1000802@joelhalpern.com><68203580453A41F9BE4A8E17676A40DD@china.huawei.com><52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com><675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <765544F852C2434E8C21B9A3FFF91495@BertLaptop> <200905071245.n47Cj2o0026140@cichlid.raleigh.ibm.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: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 13:05:01 -0000 +1 (I also hate padding, but...) On Thu, 7 May 2009, Thomas Narten wrote: >> I do not like the padding at all. > > Agreed. > > What I'd like to see in the document is a short explanation of why > padding is to be avoided and why it is considered a Bad Thing. Without > that background, we just have a process rule that misses the > underlying issue. I.e., the rule about padding the list really ought > to be "SHOULD NOT", with an explanation of why. > > For me, the issue with padding is that it wastes the community's time > and is a disincentive to comment on the names. That does not help in > the selection of the best candidates. > > But I could imagine some scenarios where it is deemed necessary, in > which case a process rule that says MUST NOT seems a bad thing to have > on the books. > > Thomas > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From jmh@joelhalpern.com Thu May 7 06:06:38 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 8B7953A6C1F for ; Thu, 7 May 2009 06:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 9esjDzeRHB8O for ; Thu, 7 May 2009 06:06:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EFCD63A6AE4 for ; Thu, 7 May 2009 06:05:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C23AE4300C5; Thu, 7 May 2009 06:07:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id F05454300C1; Thu, 7 May 2009 06:07:18 -0700 (PDT) Message-ID: <4A02DD01.3040009@joelhalpern.com> Date: Thu, 07 May 2009 09:07:13 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Spencer Dawkins References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 13:06:38 -0000 I suggest not writing any text specifically for this case. I do not think padding would actually help this at all. And what else "should" happen probably depends upon the exact case. The nomcom can appoint the one person, find some other nominees, or not appoint. Nothing new needs to be said to allow any of those options. (And maybe they will come up with a new option, depending upon the exact circumstances.) Yours, Joel Spencer Dawkins wrote: > What do we want NomCom to do if there is only one willing nominee? I'm > assuming that choices would include (singly or in combination): > > - asking for feedback on a padded list (what we are saying we DON'T want > to keep doing), > > - asking for feedback on one willing nominee with no padding (boy, it > would reek to be that person and not get selected, but I guess it's not > much worse than reopening the call for nominations after lots of people > have seen the short list, which we do today), > > - looking at the single nominee without a call for feedback from the > community, > > - reopening the call for nominations with a higher level of "enhanced > recruiting techniques" (sorry for the GITMO reference), or > > - telling someone (who?) that there isn't enough community support for > this position to allow NomCom to fill the position using the normal > NomCom process, and we need to look at whether the position needs to be > redefined or even eliminated. > > Are there other choices that I'm missing? > > What SHOULD happen? Can we provide helpful guidance in this document? > > Thanks, > > Spencer > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From spencer@wonderhamster.org Thu May 7 07:04:48 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 4AA363A7048 for ; Thu, 7 May 2009 07:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 5CQvVwd07mJs for ; Thu, 7 May 2009 07:04:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 4FED23A703E for ; Thu, 7 May 2009 07:04:47 -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-1M24El0fEM-000gAe; Thu, 07 May 2009 10:06:14 -0400 Message-ID: From: "Spencer Dawkins" To: "Joel M. Halpern" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> Date: Thu, 7 May 2009 09:05:49 -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/W9NnZezB8w09QN/wMIPIJ+Ao767u76JL60on 61fR2TrK2C2eaAyOdhvubdMAlyzg3Gasm94Zcys20Jkw5pnXBc pACOvFU54o60KhdA55kPjobQoYK7NF8g8pcrm6A1fA= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 14:04:48 -0000 Hi, Joel, >I suggest not writing any text specifically for this case. > I do not think padding would actually help this at all. > And what else "should" happen probably depends upon the exact case. The > nomcom can appoint the one person, find some other nominees, or not > appoint. Nothing new needs to be said to allow any of those options. I agree on your first two cases, but ... is it obvious that a NomCom can forward an incomplete slate because no willing nominee is a suitable candidate? I'm remembering much wailing about a recent attempt to get a confirming body to confirm a partial slate, and we haven't made normative changes to 3777 since then. Thanks, Spencer From fred@cisco.com Thu May 7 07:41:48 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 923753A702F for ; Thu, 7 May 2009 07:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 hQmrmK6nt8D6 for ; Thu, 7 May 2009 07:41:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2DA0A3A7032 for ; Thu, 7 May 2009 07:41:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,310,1238976000"; d="scan'208";a="300214460" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 May 2009 14:43:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n47Eh6PN015286; Thu, 7 May 2009 07:43:06 -0700 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n47Eh6Vf025011; Thu, 7 May 2009 14:43:06 GMT From: Fred Baker To: Spencer Dawkins In-Reply-To: X-Priority: 3 References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> Message-Id: <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.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: Thu, 7 May 2009 07:43:03 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1275; t=1241707386; x=1242571386; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[ietf-nomcom]=20announcing=20list=20of= 20willing=20candidates |Sender:=20; bh=zfHDj1f+4sxxfNESXPbml+B/HLEqqRDorh0WJfr7T4A=; b=c/qf/V+KvhWj2frn6j/E3Zv7mlMMiu+uBMc5IFEVXhFfXDi2DJ1+VXGMnb +H1yg1kPAACN7+Hkw+BwbOHOakWjQ72WzkkyuerCwNAG5iQ0pGeUBRQB9lGu 2+r1KNZeM+; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 14:41:48 -0000 The reason that a nomcom must send a complete slate is to protect the confidentiality of those it has names of and doesn't have consensus to select. How does that fit with the idea of posting a single name and then not choosing it? Not arguing for padding, but concerned that there is a mismatch here. On May 7, 2009, at 7:05 AM, Spencer Dawkins wrote: > Hi, Joel, > > >> I suggest not writing any text specifically for this case. >> I do not think padding would actually help this at all. >> And what else "should" happen probably depends upon the exact >> case. The nomcom can appoint the one person, find some other >> nominees, or not appoint. Nothing new needs to be said to allow >> any of those options. > > I agree on your first two cases, but ... is it obvious that a NomCom > can forward an incomplete slate because no willing nominee is a > suitable candidate? I'm remembering much wailing about a recent > attempt to get a confirming body to confirm a partial slate, and we > haven't made normative changes to 3777 since then. > > Thanks, > > Spencer > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom From jmh@joelhalpern.com Thu May 7 07:51: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 E1EB628C2A8 for ; Thu, 7 May 2009 07:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 J1tg34cej2Vt for ; Thu, 7 May 2009 07:51:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 59D8D3A7106 for ; Thu, 7 May 2009 07:50:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 126514300FD for ; Thu, 7 May 2009 07:52:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 82DED4300F5 for ; Thu, 7 May 2009 07:52:16 -0700 (PDT) Message-ID: <4A02F59A.3030205@joelhalpern.com> Date: Thu, 07 May 2009 10:52:10 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NomComDiscussion References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 14:51:57 -0000 It is clear that incomplete appointments can happen (easiest way: a full slate gets selected, confirmed, verified, and announced. Then one person steps down.) Normally, confirming bodies do not like to confirm partial slates, but it does happen. Presumably, if the nomcom chooses not to appoint, they have some plan of action. Whether their plan is to explicitly leave the seat vacant, or to fill it by some longer procedure, this will need to be communicated to the confirming body. And is likely to provoke discussion. That's between those bodies. My point is NOT that leaving it vacant is a good idea. But rather that I see no reason to add any text attempting to pre-guess (pre-judge?) the correct response to a difficult situation. Joel Spencer Dawkins wrote: > Hi, Joel, > > >> I suggest not writing any text specifically for this case. >> I do not think padding would actually help this at all. >> And what else "should" happen probably depends upon the exact case. >> The nomcom can appoint the one person, find some other nominees, or >> not appoint. Nothing new needs to be said to allow any of those options. > > I agree on your first two cases, but ... is it obvious that a NomCom can > forward an incomplete slate because no willing nominee is a suitable > candidate? I'm remembering much wailing about a recent attempt to get a > confirming body to confirm a partial slate, and we haven't made > normative changes to 3777 since then. > > Thanks, > > Spencer > > From fred@cisco.com Thu May 7 07:57:08 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 329DC3A6B77 for ; Thu, 7 May 2009 07:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Fke6nMfmbbAg for ; Thu, 7 May 2009 07:57:07 -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 651963A68D0 for ; Thu, 7 May 2009 07:57:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,310,1238976000"; d="scan'208";a="162987906" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 07 May 2009 14:58:35 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n47EwZmx015617; Thu, 7 May 2009 07:58:35 -0700 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n47EwZUK027957; Thu, 7 May 2009 14:58:35 GMT Message-Id: From: Fred Baker To: "Joel M. Halpern" In-Reply-To: <4A02F59A.3030205@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: Thu, 7 May 2009 07:58:35 -0700 References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <4A02F59A.3030205@joelhalpern.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2005; t=1241708315; x=1242572315; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[ietf-nomcom]=20announcing=20list=20of= 20willing=20candidates |Sender:=20; bh=purv0QLm3687O40q7tErNbUmPx7gXE6KaOvqRT5w6Pk=; b=cXm9DCZ8WG8JwiAz9ISPElO8qZRmdutwJ5Wg6dri/l4mYMES69gEBxyeiz 9gsZgwslWzoji6f3M02/IHiodXwXKDANRlp/Ty8GVPbX3idlcZBzm4PGknHt fJuXupqTsu; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 14:57:08 -0000 this has resulted in the confirming bodies responding "you did not send a complete list" and stonewalling. The nomcom would need a way to tell the community that the IAB is feeling its oats again. On May 7, 2009, at 7:52 AM, Joel M. Halpern wrote: > It is clear that incomplete appointments can happen (easiest way: a > full slate gets selected, confirmed, verified, and announced. Then > one person steps down.) > Normally, confirming bodies do not like to confirm partial slates, > but it does happen. > > Presumably, if the nomcom chooses not to appoint, they have some > plan of action. Whether their plan is to explicitly leave the seat > vacant, or to fill it by some longer procedure, this will need to be > communicated to the confirming body. And is likely to provoke > discussion. That's between those bodies. > > My point is NOT that leaving it vacant is a good idea. But rather > that I see no reason to add any text attempting to pre-guess (pre- > judge?) the correct response to a difficult situation. > > Joel > > Spencer Dawkins wrote: >> Hi, Joel, >>> I suggest not writing any text specifically for this case. >>> I do not think padding would actually help this at all. >>> And what else "should" happen probably depends upon the exact >>> case. The nomcom can appoint the one person, find some other >>> nominees, or not appoint. Nothing new needs to be said to allow >>> any of those options. >> I agree on your first two cases, but ... is it obvious that a >> NomCom can forward an incomplete slate because no willing nominee >> is a suitable candidate? I'm remembering much wailing about a >> recent attempt to get a confirming body to confirm a partial slate, >> and we haven't made normative changes to 3777 since then. >> Thanks, >> Spencer > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom From jmh@joelhalpern.com Thu May 7 08:16: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 01D5F3A700B for ; Thu, 7 May 2009 08:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 KHPMCk+QKe8E for ; Thu, 7 May 2009 08:16:39 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id BFE613A7021 for ; Thu, 7 May 2009 08:16:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1C69A4301C7 for ; Thu, 7 May 2009 08:17:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 8CFEB4300FD for ; Thu, 7 May 2009 08:17:46 -0700 (PDT) Message-ID: <4A02FB94.5060106@joelhalpern.com> Date: Thu, 07 May 2009 11:17:40 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NomComDiscussion References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <4A02F59A.3030205@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 15:16:40 -0000 That (a clash of wills between the nomcom and the confirming body) demonstrably can occur anyway. There are ways to reduce the odds of such. Those ways do not include trying to write text to cover all the weird things reality can do to us. I presume that the nomcom takes its responsibilities seriously. I presume that they are trying to do what is best for the community. Thus, if they have only one nominee, and that nominee is someone they are unhappy with, I don't think it takes extra text to tell them "go try and find someone better." Similarly, if they have tried, and they have concluded that they can not, and they concluded that they can not appoint the one nominee, then I do not think that writing special rules is either necessary or useful. The philosophy of this document historically was to leave things up to the judgment of the nominating committee and the nominating committee chair. I also presume that having observed history, if the nomcom decides to do something radical they will try to figure out how to work with the confirming body on that, rather than just throwing it over the wall and saying "live with it." But since it is very situational, I would hesitate to even write advice for the chair in that situation, much less rules. Joel Fred Baker wrote: > this has resulted in the confirming bodies responding "you did not send > a complete list" and stonewalling. The nomcom would need a way to tell > the community that the IAB is feeling its oats again. > From fred@cisco.com Thu May 7 08:42:22 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 CEFD13A6C5F for ; Thu, 7 May 2009 08:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.456 X-Spam-Level: X-Spam-Status: No, score=-106.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 BUXe6S4LuDeJ for ; Thu, 7 May 2009 08:42:21 -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 D6C0828C2A0 for ; Thu, 7 May 2009 08:42:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,311,1238976000"; d="scan'208";a="43682548" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 May 2009 15:43:38 +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 n47FhcLR021167; Thu, 7 May 2009 11:43:38 -0400 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n47FhbYI025323; Thu, 7 May 2009 15:43:38 GMT Message-Id: From: Fred Baker To: "Joel M. Halpern" In-Reply-To: <4A02FB94.5060106@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: Thu, 7 May 2009 08:43:32 -0700 References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <4A02F59A.3030205@joelhalpern.com> <4A02FB94.5060106@joelhalpern.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2695; t=1241711018; x=1242575018; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[ietf-nomcom]=20announcing=20list=20of= 20willing=20candidates |Sender:=20 |To:=20=22Joel=20M.=20Halpern=22=20; bh=cYs19E3hslz7kc+fK5v4tD8myabbqzkKKiXx69n6wI8=; b=L1BhrW5dDpzIIG8WlgiPfOwxixTZ3/BsI3aRXMkqFOLhkKH76EPEsBxrf3 g8rn2McmK1DOFKYQmbXCnxpSPas7svu+qQbJhK7HTte2c+7J0dDxfmhbqvqb OmxkFtqW/H; Authentication-Results: rtp-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 15:42:22 -0000 I agree with your characterization here. Unfortunately, the nomcom has found itself saying not "live with it" but "the rules don't allow us to be more explicit" - trying to do a good job and play by the rules has created some tough scenarios. I think part of this relates to "bad events make bad law" - most of the rules here (including "don't send partial lists", which comes from an event that happened on my watch as nomcom chair) relate to "let's not have <> happen, which happened in <>". I actually think better rules in general would not preclude a behavior but would describe preferred behavior. Coming back to Spencer's initial question, I think we are arriving at The list of nominees published should contain only the names of nominees who are willing to serve in a position under review. Is that correct? On May 7, 2009, at 8:17 AM, Joel M. Halpern wrote: > That (a clash of wills between the nomcom and the confirming body) > demonstrably can occur anyway. > There are ways to reduce the odds of such. > Those ways do not include trying to write text to cover all the > weird things reality can do to us. > > I presume that the nomcom takes its responsibilities seriously. I > presume that they are trying to do what is best for the community. > Thus, if they have only one nominee, and that nominee is someone > they are unhappy with, I don't think it takes extra text to tell > them "go try and find someone better." > Similarly, if they have tried, and they have concluded that they can > not, and they concluded that they can not appoint the one nominee, > then I do not think that writing special rules is either necessary > or useful. > > The philosophy of this document historically was to leave things up > to the judgment of the nominating committee and the nominating > committee chair. > > I also presume that having observed history, if the nomcom decides > to do something radical they will try to figure out how to work with > the confirming body on that, rather than just throwing it over the > wall and saying "live with it." But since it is very situational, I > would hesitate to even write advice for the chair in that situation, > much less rules. > > Joel > > Fred Baker wrote: >> this has resulted in the confirming bodies responding "you did not >> send a complete list" and stonewalling. The nomcom would need a way >> to tell the community that the IAB is feeling its oats again. > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom From russ@cisco.com Thu May 7 06:28: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 E178A3A6A2A for ; Thu, 7 May 2009 06:28:09 -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 lJSj+1m6fNZT for ; Thu, 7 May 2009 06:28:08 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E1CA43A693D for ; Thu, 7 May 2009 06:28:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,310,1238976000"; d="scan'208";a="75043719" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 07 May 2009 13:18: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 n47DINOP010937; Thu, 7 May 2009 09:18:23 -0400 Received: from [127.0.0.1] (rtp-vpn4-377.cisco.com [10.82.209.121]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n47DIMlH026503; Thu, 7 May 2009 13:18:22 GMT Message-ID: <4A02DF98.6000704@cisco.com> Date: Thu, 07 May 2009 09:18:16 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> In-Reply-To: <4A02DD01.3040009@joelhalpern.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1089; t=1241702303; x=1242566303; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=russ@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[ietf-nomcom]=20announcing=20list=20of= 20willing=20candidates |Sender:=20 |To:=20=22Joel=20M.=20Halpern=22=20; bh=kKQkxdY5noDgbl1p4uy46UaUJvKqNlzAdxWPnohy4kY=; b=MC+LFoBL/VrF1VMeEoD+GTIztaHsQlZRsHwTnMnC36CrddOX90GMCQ4/Hf JM4H8qBcJ6vL39XIp7Q0LNtJcieB54KQSe2Ka+g3fxsZHfq+6S6uCyra/eB+ doyfSdJTJI; Authentication-Results: rtp-dkim-2; header.From=russ@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Mailman-Approved-At: Thu, 07 May 2009 08:45:42 -0700 Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 13:51:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I suggest not writing any text specifically for this case. > I do not think padding would actually help this at all. > And what else "should" happen probably depends upon the exact case. The > nomcom can appoint the one person, find some other nominees, or not > appoint. Nothing new needs to be said to allow any of those options. > (And maybe they will come up with a new option, depending upon the exact > circumstances.) Agreed. It's best to find some other solution than padding. :-) Russ - -- riw@cisco.com :: CCIE :: CCDE :: <>< Grace Alone Extremism is a mental disorder in which a person actually believes jumping off a fifty story building will kill you. We all know from watching cartoons there is a high probability your shirt will be caught on a flag pole. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoC35gACgkQER27sUhU9OSlJACfdzAAiACMOLgeQHmpoKITg7Sq IG4An3smzj/0tHQ6MtksVZmU1K92/Z6r =hgfR -----END PGP SIGNATURE----- From jmh@joelhalpern.com Thu May 7 09:11:42 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 138463A6E3E for ; Thu, 7 May 2009 09:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 DRnS8Ham3C7X for ; Thu, 7 May 2009 09:11:41 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DDF6428C2A5 for ; Thu, 7 May 2009 09:11:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0547C43023D for ; Thu, 7 May 2009 09:13:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 8814E4301FF for ; Thu, 7 May 2009 09:13:01 -0700 (PDT) Message-ID: <4A030887.7060604@joelhalpern.com> Date: Thu, 07 May 2009 12:12:55 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NomComDiscussion References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <4A02F59A.3030205@joelhalpern.com> <4A02FB94.5060106@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 16:11:42 -0000 That works for me. Joel Fred Baker wrote: ... > > Coming back to Spencer's initial question, I think we are arriving at > > The list of nominees published should contain only the names of > nominees who are willing to serve in a position under review. > > Is that correct? From rcallon@juniper.net Thu May 7 09:18:05 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 C7A6A3A7040 for ; Thu, 7 May 2009 09:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 3D6JFNAZ9PiH for ; Thu, 7 May 2009 09:18:04 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id CB57928C1AC for ; Thu, 7 May 2009 09:16:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob59.postini.com ([64.18.6.12]) with SMTP ID DSNKSgMJriMRtiGdp4AR4gjxfD094eFZhntq@postini.com; Thu, 07 May 2009 09:17:52 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 7 May 2009 09:10:50 -0700 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 09:10:50 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 09:10:50 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 12:10:45 -0400 Message-ID: <3525C9833C09ED418C6FD6CD9514668C064D7BBA@emailwf1.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-nomcom] announcing list of willing candidates Thread-Index: AcnPKqRzQ2yX19/XTvOXmMQcqWeLLAAAy6TA References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com><4A02F59A.3030205@joelhalpern.com><4A02FB94.5060106@joelhalpern.com> From: Ross Callon To: "Fred Baker" , "Joel M. Halpern" X-OriginalArrivalTime: 07 May 2009 16:10:50.0137 (UTC) FILETIME=[637D4890:01C9CF2E] Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 16:18:05 -0000 > Coming back to Spencer's initial question, I think we are arriving at > > The list of nominees published should contain only the names of =20 > nominees who are willing to serve in a position under review. This looks right to me.=20 Ross ---------------------------------------------------- On May 7, 2009, at 8:17 AM, Joel M. Halpern wrote: > That (a clash of wills between the nomcom and the confirming body) =20 > demonstrably can occur anyway. > There are ways to reduce the odds of such. > Those ways do not include trying to write text to cover all the =20 > weird things reality can do to us. > > I presume that the nomcom takes its responsibilities seriously. I =20 > presume that they are trying to do what is best for the community. > Thus, if they have only one nominee, and that nominee is someone =20 > they are unhappy with, I don't think it takes extra text to tell =20 > them "go try and find someone better." > Similarly, if they have tried, and they have concluded that they can =20 > not, and they concluded that they can not appoint the one nominee, =20 > then I do not think that writing special rules is either necessary =20 > or useful. > > The philosophy of this document historically was to leave things up =20 > to the judgment of the nominating committee and the nominating =20 > committee chair. > > I also presume that having observed history, if the nomcom decides =20 > to do something radical they will try to figure out how to work with =20 > the confirming body on that, rather than just throwing it over the =20 > wall and saying "live with it." But since it is very situational, I =20 > would hesitate to even write advice for the chair in that situation, =20 > much less rules. > > Joel > > Fred Baker wrote: >> this has resulted in the confirming bodies responding "you did not =20 >> send a complete list" and stonewalling. The nomcom would need a way =20 >> to tell the community that the IAB is feeling its oats again. > _______________________________________________ > 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 Thu May 7 09:49:25 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 1451628C2A5 for ; Thu, 7 May 2009 09:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] 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 XKUEtHC-WovI for ; Thu, 7 May 2009 09:49:24 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 525C23A6B10 for ; Thu, 7 May 2009 09:49:08 -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-1M26ni2B52-000g1N; Thu, 07 May 2009 12:50:30 -0400 Message-ID: From: "Spencer Dawkins" To: "Thomas Narten" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <200905071248.n47CmSYc026256@cichlid.raleigh.ibm.com> Date: Thu, 7 May 2009 11:50:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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+OdEcBj6wyU4CY8WrAoNF75J08zzPFQLVrYdV lRAtRD+nHwFXde1BnzR/Kf7k2t5u9Q39NuwBDNc6Vepq6gLyWS zI3cTQoUZrxLB/trMN1KzpNrCw1MDsKs6rm5etsDks= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 16:49:25 -0000 Hi, Thomas, >> - asking for feedback on one willing nominee with no padding (boy, it >> would >> reek to be that person and not get selected, but I guess it's not much >> worse >> than reopening the call for nominations after lots of people have seen >> the >> short list, which we do today), > > The nomcom absolutely has to have the ability to do this. I would > expect the nomcom to run into "we need more feedback on person X in > particular" (for whatever reason). Surely the nomcom should be able to > do that? I agree, and I'm OK with adding text that makes this explicitly OK. Perhaps The NomCom may publish requests for additional feedback on specific willing nominees, if the NomCom finds this useful. Thanks, Spencer From spencer@wonderhamster.org Thu May 7 09:59:11 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 6ABC93A6C9E for ; Thu, 7 May 2009 09:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, 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 UHco80Rz3p-Y for ; Thu, 7 May 2009 09:59:10 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 666663A6B37 for ; Thu, 7 May 2009 09:59:10 -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-1M26xQ0Hsp-000cmX; Thu, 07 May 2009 13:00:31 -0400 Message-ID: From: "Spencer Dawkins" To: "Fred Baker" , "Joel M. Halpern" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com><4A02F59A.3030205@joelhalpern.com><4A02FB94.5060106@joelhalpern.com> Date: Thu, 7 May 2009 12:00:05 -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/CJvSx6aX6KxeZ0Z12mXTWUvQILmK+/A/185o s1virsfCYaY+wEqx+8z3gfgtPNmBDLth1u/HNEpj0tF2n/Rdqj 58iXZlAFUdKfFkFylleAAS9yKa2ZgPyhjfoio5Uy3E= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 16:59:11 -0000 Fred, Joel, I am OK with where this sub-thread is ending up, except for one point - we've already tripped over the "can't confirm an incomplete slate" tripwire (as Fred pointed out), and this ended up with our first-ever NomCom process appeal. NOT IN THIS DOCUMENT, I would like to say that NomComs are allowed to forward incomplete slates, if that's the best option in the NomCom's judgement, and that confirming bodies are allowed to confirm incomplete slates, just so we don't have the same situation in the future. But that's kind of off-topic for this draft, so I'd suggest using a different draft to propose it. Thanks for your feedback here. Spencer >I agree with your characterization here. Unfortunately, the nomcom has >found itself saying not "live with it" but "the rules don't allow us to be >more explicit" - trying to do a good job and play by the rules has created >some tough scenarios. > > I think part of this relates to "bad events make bad law" - most of the > rules here (including "don't send partial lists", which comes from an > event that happened on my watch as nomcom chair) relate to "let's not > have <> happen, which happened in <>". I actually think better rules in > general would not preclude a behavior but would describe preferred > behavior. > > Coming back to Spencer's initial question, I think we are arriving at > > The list of nominees published should contain only the names of > nominees who are willing to serve in a position under review. > > Is that correct? > > On May 7, 2009, at 8:17 AM, Joel M. Halpern wrote: > >> That (a clash of wills between the nomcom and the confirming body) >> demonstrably can occur anyway. >> There are ways to reduce the odds of such. >> Those ways do not include trying to write text to cover all the weird >> things reality can do to us. >> >> I presume that the nomcom takes its responsibilities seriously. I >> presume that they are trying to do what is best for the community. >> Thus, if they have only one nominee, and that nominee is someone they >> are unhappy with, I don't think it takes extra text to tell them "go try >> and find someone better." >> Similarly, if they have tried, and they have concluded that they can >> not, and they concluded that they can not appoint the one nominee, then >> I do not think that writing special rules is either necessary or useful. >> >> The philosophy of this document historically was to leave things up to >> the judgment of the nominating committee and the nominating committee >> chair. >> >> I also presume that having observed history, if the nomcom decides to do >> something radical they will try to figure out how to work with the >> confirming body on that, rather than just throwing it over the wall and >> saying "live with it." But since it is very situational, I would >> hesitate to even write advice for the chair in that situation, much less >> rules. >> >> Joel >> >> Fred Baker wrote: >>> this has resulted in the confirming bodies responding "you did not send >>> a complete list" and stonewalling. The nomcom would need a way to tell >>> the community that the IAB is feeling its oats again. From narten@us.ibm.com Thu May 7 10:10:34 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 1EDCC28C174 for ; Thu, 7 May 2009 10:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.891 X-Spam-Level: X-Spam-Status: No, score=-5.891 tagged_above=-999 required=5 tests=[AWL=0.708, 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 Z0UoSLcWvaqo for ; Thu, 7 May 2009 10:10:33 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id 414D43A6E3E for ; Thu, 7 May 2009 10:10:33 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n47H8EkM002675 for ; Thu, 7 May 2009 11:08:14 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n47HAT6d258846 for ; Thu, 7 May 2009 11:10:32 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n47HARBc012877 for ; Thu, 7 May 2009 11:10:27 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-21.mts.ibm.com [9.49.155.21]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n47HAPGq012540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 11:10:27 -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 n47HAMlf027713; Thu, 7 May 2009 13:10:22 -0400 Message-Id: <200905071710.n47HAMlf027713@cichlid.raleigh.ibm.com> To: "Spencer Dawkins" In-reply-to: References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <200905071248.n47CmSYc026256@cichlid.raleigh.ibm.com> Comments: In-reply-to "Spencer Dawkins" message dated "Thu, 07 May 2009 11:50:04 -0500." Date: Thu, 07 May 2009 13:10:22 -0400 From: Thomas Narten Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 17:10:34 -0000 "Spencer Dawkins" writes: > Hi, Thomas, > >> - asking for feedback on one willing nominee with no padding (boy, it > >> would > >> reek to be that person and not get selected, but I guess it's not much > >> worse > >> than reopening the call for nominations after lots of people have seen > >> the > >> short list, which we do today), > > > > The nomcom absolutely has to have the ability to do this. I would > > expect the nomcom to run into "we need more feedback on person X in > > particular" (for whatever reason). Surely the nomcom should be able to > > do that? > I agree, and I'm OK with adding text that makes this explicitly OK. Perhaps > The NomCom may publish requests for additional feedback on specific > willing nominees, if the NomCom finds this useful. > I'm actually generally unhappy with this approach. To channel another frequent voice, can we please stay away from making specific rules that say "you can do this" or "you can't do that" designed to deal with relatively narrow/specific situations? Such rules are not good for dealing with future situations we haven't run into yet. We should state what the principle is (and why the principle is important), and leave judgement to the nomcom on the details of how to apply the principle to specific situations. We seem to coninually get into situations where the nomcom seems to want to do X (because that makes sense and would seem to be in the spirit of what was intended), but doesn't think the rules allow that, because there is no specific rule that says exactly that, or existing rules are interpreted in a narrow way to mean doing so would be a process violation. We'd be much better off (generally) if the principle were made clear. In this case, the principle would seem to be that padding the list is a bad idea because it wastes people's time. But that doesn't mean that padding the list should be a process violation either. Thomas From spencer@wonderhamster.org Thu May 7 11:48:36 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 38E443A6EA6 for ; Thu, 7 May 2009 11:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] 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 74DOgennLCGC for ; Thu, 7 May 2009 11:48:35 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 6C3B43A68EA for ; Thu, 7 May 2009 11:48:32 -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-1M28eo2A8F-000g7C; Thu, 07 May 2009 14:49:26 -0400 Message-ID: From: "Spencer Dawkins" To: "Thomas Narten" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <200905071248.n47CmSYc026256@cichlid.raleigh.ibm.com> <200905071710.n47HAMlf027713@cichlid.raleigh.ibm.com> Date: Thu, 7 May 2009 13:48:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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: V01U2FsdGVkX18SWCpRcXAATj4Vsa81W9LHjl7eulBLV9H32hb pl0LR6bSge0XamPG+Ei2rI7Nz8e5fZIk5lYhyduMallhWArzI5 0bWjfBM++kbWq7hjAKFBParMNmXkg5bnBtc5sTnDM8= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 18:48:36 -0000 Hi, Thomas, > We should state what the principle is (and why the principle is > important), and leave judgement to the nomcom on the details of how to > apply the principle to specific situations. > > We seem to coninually get into situations where the nomcom seems to > want to do X (because that makes sense and would seem to be in the > spirit of what was intended), but doesn't think the rules allow that, > because there is no specific rule that says exactly that, or existing > rules are interpreted in a narrow way to mean doing so would be a > process violation. We'd be much better off (generally) if the > principle were made clear. > > In this case, the principle would seem to be that padding the list is > a bad idea because it wastes people's time. But that doesn't mean that > padding the list should be a process violation either. Hi, Thomas, OK. The draft currently says In an attempt to maintain the required level of confidentiality, past NomComs have also included "ringers" on the short list - nominees who have notified NomCom that they are NOT willing to serve. Since anyone who sees the short list does not know who the ringers are, consciencious IETF participants also provide feedback on nominees who have already declined. This is a waste of precious IETF-participant cycles, and Joel Halpern (2008-2009 NomCom Chair) reports that "the ringer pool leaks like a sieve" - it's also ineffective. Think that's sufficient? Thanks, Spencer From Andrew.Lange@alcatel-lucent.com Thu May 7 12:37: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 BD8123A6FE1 for ; Thu, 7 May 2009 12:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 ZqleDTNMKeDs for ; Thu, 7 May 2009 12:37:26 -0700 (PDT) Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 8675F3A6B69 for ; Thu, 7 May 2009 12:37:25 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id n47Jcfg4006111; Thu, 7 May 2009 14:38:53 -0500 Received: from neo-6.ind.alcatel.com ([172.22.216.4]) by usdalsbhs01.ad3.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 14:38:51 -0500 Message-Id: From: Andrew Lange To: "Spencer Dawkins" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-4--722559638 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 7 May 2009 12:38:48 -0700 References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com><51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net><874B0EA5B7474E40BC4771582E20F135@china.huawei.com><4A01FF14.1000802@joelhalpern.com><68203580453A41F9BE4A8E17676A40DD@china.huawei.com><52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com><675982CA-8EED-470C-888D-DB876816D256@cisco.com><5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com><200905071248.n47CmSYc026256@cichlid.raleigh.ibm.com><200905071710.n47HAMlf027713@cichlid.raleigh.ibm.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 07 May 2009 19:38:51.0689 (UTC) FILETIME=[7312F990:01C9CF4B] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 19:37:27 -0000 --Apple-Mail-4--722559638 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Spencer, I'd just like to affirm and agree with what I'm seeing as the consensus here: Ringers/padding is not desired, it should be a SHOULD NOT at least, and strongly discouraged, but don't tie nomcom's hands in case some odd situation comes up that requires padding (I cannot see what this would, be, but then again it is the odd case.) Andrew On May 7, 2009, at 11:48 AM, Spencer Dawkins wrote: > Hi, Thomas, > > > We should state what the principle is (and why the principle is > > important), and leave judgement to the nomcom on the details of > how to > > apply the principle to specific situations. > > > > We seem to coninually get into situations where the nomcom seems to > > want to do X (because that makes sense and would seem to be in the > > spirit of what was intended), but doesn't think the rules allow > that, > > because there is no specific rule that says exactly that, or > existing > > rules are interpreted in a narrow way to mean doing so would be a > > process violation. We'd be much better off (generally) if the > > principle were made clear. > > > > In this case, the principle would seem to be that padding the list > is > > a bad idea because it wastes people's time. But that doesn't mean > that > > padding the list should be a process violation either. > > Hi, Thomas, > > OK. The draft currently says > > In an attempt to maintain the required level of confidentiality, > past NomComs have also included > "ringers" on the short list - nominees who have notified > NomCom that they are NOT willing > to serve. Since anyone who sees the short list does not > know who the ringers are, > consciencious IETF participants also provide feedback on > nominees who have already > declined. This is a waste of precious IETF-participant cycles, > and Joel Halpern (2008-2009 > NomCom Chair) reports that "the ringer pool leaks like a sieve" > - it's also ineffective. > > > Think that's sufficient? > > Thanks, > > Spencer > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > --Apple-Mail-4--722559638 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Spencer,

I'd = just like to affirm and agree with what I'm seeing as the consensus = here:  Ringers/padding is not desired, it should be a SHOULD NOT at = least, and strongly discouraged, but don't tie nomcom's hands in case = some odd situation comes up that requires padding (I cannot see what = this would, be, but then again it is the odd = case.)

Andrew

On May 7, = 2009, at 11:48 AM, Spencer Dawkins wrote:

=

Hi, = Thomas,

> We should state what the principle is (and why the = principle is
> important), and leave judgement to the nomcom on = the details of how to
> apply the principle to specific = situations.
>
> We seem to coninually get into situations = where the nomcom seems to
> want to do X (because that makes = sense and would seem to be in the
> spirit of what was intended), = but doesn't think the rules allow that,
> because there is no = specific rule that says exactly that, or existing
> rules are = interpreted in a narrow way to mean doing so would be a
> process = violation. We'd be much better off (generally) if the
> principle = were made clear.
>
> In this case, the principle would = seem to be that padding the list is
> a bad idea because it = wastes people's time. But that doesn't mean that
> padding the = list should be a process violation either.

Hi, Thomas,

= OK. The draft currently says

 <t>In an attempt to = maintain the required level of confidentiality,
  past NomComs = have also included
  "ringers" on the short list - nominees who = have notified
  NomCom that they are NOT willing
  to = serve. Since anyone who sees the short list does not
  know who = the ringers are,
  consciencious IETF participants also provide = feedback on
  nominees who have already
  declined. = This is a waste of precious IETF-participant cycles,
  and Joel = Halpern (2008-2009
  NomCom Chair) reports that "the ringer = pool leaks like a sieve"
  - it's also ineffective.
=  </t>

Think that's sufficient?

Thanks,
=
Spencer

= _______________________________________________
ietf-nomcom mailing = list
ietf-nomcom@ietf.org
https://www.iet= f.org/mailman/listinfo/ietf-nomcom

=

= --Apple-Mail-4--722559638-- From Andrew.Lange@alcatel-lucent.com Thu May 7 12:43: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 BF1B93A69B2 for ; Thu, 7 May 2009 12:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 g9Zapb-eKrHG for ; Thu, 7 May 2009 12:43:31 -0700 (PDT) Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 5466B3A6AE0 for ; Thu, 7 May 2009 12:43:29 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id n47Jivm3007927; Thu, 7 May 2009 14:44:57 -0500 Received: from neo-6.ind.alcatel.com ([172.22.216.4]) by usdalsbhs01.ad3.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 14:44:56 -0500 Message-Id: From: Andrew Lange To: "Spencer Dawkins" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-5--722194476 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 7 May 2009 12:44:54 -0700 References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com><4A02F59A.3030205@joelhalpern.com><4A02FB94.5060106@joelhalpern.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 07 May 2009 19:44:57.0767 (UTC) FILETIME=[4D460B70:01C9CF4C] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Cc: NomComDiscussion Discussion Subject: [ietf-nomcom] Tangent: Confirming Bodies and Partial Slates 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, 07 May 2009 19:43:32 -0000 --Apple-Mail-5--722194476 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I split the thread, since this is not something that we're talking about for this document. But I'd be willing go to further than "may confirm": To make the confirmation process easier on the confirming body, NomCom should make every reasonable attempt to forward a complete slate of candidates. However, since conditions do arise where is it not in the best interests of the internet or the IETF to hold up the entire slate until a particularly difficult position is filled, the NomCom MAY forward an incomplete slate to the confirming body. The confirming body MUST vote on the partial slate presented, and MAY NOT hold up the process simply because they want an entire slate. If the confirming body has specific needs, beyond "slate completeness" they are encouraged to share that with the NomCom. Andrew On May 7, 2009, at 10:00 AM, Spencer Dawkins wrote: > Fred, Joel, > > I am OK with where this sub-thread is ending up, except for one > point - > we've already tripped over the "can't confirm an incomplete slate" > tripwire > (as Fred pointed out), and this ended up with our first-ever NomCom > process > appeal. > > NOT IN THIS DOCUMENT, I would like to say that NomComs are allowed to > forward incomplete slates, if that's the best option in the NomCom's > judgement, and that confirming bodies are allowed to confirm > incomplete > slates, just so we don't have the same situation in the future. > > But that's kind of off-topic for this draft, so I'd suggest using a > different draft to propose it. > > Thanks for your feedback here. > > Spencer > > > >I agree with your characterization here. Unfortunately, the nomcom > has > >found itself saying not "live with it" but "the rules don't allow > us to be > >more explicit" - trying to do a good job and play by the rules has > created > >some tough scenarios. > > > > I think part of this relates to "bad events make bad law" - most > of the > > rules here (including "don't send partial lists", which comes > from an > > event that happened on my watch as nomcom chair) relate to "let's > not > > have <> happen, which happened in <>". I actually think better > rules in > > general would not preclude a behavior but would describe preferred > > behavior. > > > > Coming back to Spencer's initial question, I think we are arriving > at > > > > The list of nominees published should contain only the names of > > nominees who are willing to serve in a position under review. > > > > Is that correct? > > > > On May 7, 2009, at 8:17 AM, Joel M. Halpern wrote: > > > >> That (a clash of wills between the nomcom and the confirming body) > >> demonstrably can occur anyway. > >> There are ways to reduce the odds of such. > >> Those ways do not include trying to write text to cover all the > weird > >> things reality can do to us. > >> > >> I presume that the nomcom takes its responsibilities seriously. I > >> presume that they are trying to do what is best for the community. > >> Thus, if they have only one nominee, and that nominee is someone > they > >> are unhappy with, I don't think it takes extra text to tell them > "go try > >> and find someone better." > >> Similarly, if they have tried, and they have concluded that they > can > >> not, and they concluded that they can not appoint the one > nominee, then > >> I do not think that writing special rules is either necessary or > useful. > >> > >> The philosophy of this document historically was to leave things > up to > >> the judgment of the nominating committee and the nominating > committee > >> chair. > >> > >> I also presume that having observed history, if the nomcom > decides to do > >> something radical they will try to figure out how to work with the > >> confirming body on that, rather than just throwing it over the > wall and > >> saying "live with it." But since it is very situational, I would > >> hesitate to even write advice for the chair in that situation, > much less > >> rules. > >> > >> Joel > >> > >> Fred Baker wrote: > >>> this has resulted in the confirming bodies responding "you did > not send > >>> a complete list" and stonewalling. The nomcom would need a way > to tell > >>> the community that the IAB is feeling its oats again. > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > --Apple-Mail-5--722194476 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I split the thread, since this = is not something that we're talking about for this = document. 

But I'd be willing go to further than = "may confirm":

To make the confirmation process = easier on the confirming body, NomCom should make every reasonable = attempt to forward a complete slate of candidates. However, since = conditions do arise where is it not in the best interests of the = internet or the IETF to hold up the entire slate until a particularly = difficult position is filled, the NomCom MAY forward an incomplete slate = to the confirming body.   The confirming body MUST vote on the = partial slate presented, and MAY NOT hold up the process simply because = they want an entire slate.  If the confirming body has specific = needs, beyond "slate completeness" they are encouraged to share that = with the = NomCom.

Andrew


=
On May 7, 2009, at 10:00 AM, Spencer Dawkins wrote:

=

Fred, = Joel,

I am OK with where this sub-thread is ending up, except = for one point -
we've already tripped over the "can't confirm an = incomplete slate" tripwire
(as Fred pointed out), and this ended up = with our first-ever NomCom process
appeal.

NOT IN THIS = DOCUMENT, I would like to say that NomComs are allowed to
forward = incomplete slates, if that's the best option in the NomCom's
= judgement, and that confirming bodies are allowed to confirm = incomplete
slates, just so we don't have the same situation in the = future.

But that's kind of off-topic for this draft, so I'd = suggest using a
different draft to propose it.

Thanks for = your feedback here.

Spencer


>I agree with your = characterization here. Unfortunately, the nomcom has
>found = itself saying not "live with it" but "the rules don't allow us  to = be
>more explicit" - trying to do a good job and play by the = rules  has created
>some tough scenarios.
>
> = I think part of this relates to "bad events make bad law" - most = of  the
> rules here (including "don't send partial lists", = which comes from  an
> event that happened on my watch as = nomcom chair) relate to "let's  not
> have <> happen, = which happened in <>". I actually think better  rules in
= > general would not preclude a behavior but would describe  = preferred
> behavior.
>
> Coming back to Spencer's = initial question, I think we are arriving at
>
> = <t>The list of nominees published should contain only the names = of
> nominees who are willing to serve in a position under = review.</t>
>
> Is that correct?
>
> = On May 7, 2009, at 8:17 AM, Joel M. Halpern wrote:
>
>> = That (a clash of wills between the nomcom and the confirming body)
= >> demonstrably can occur anyway.
>> There are ways to = reduce the odds of such.
>> Those ways do not include trying = to write text to cover all the  weird
>> things reality = can do to us.
>>
>> I presume that the nomcom takes = its responsibilities seriously.  I
>> presume that they = are trying to do what is best for the community.
>> Thus, if = they have only one nominee, and that nominee is someone  they
= >> are unhappy with, I don't think it takes extra text to = tell  them "go try
>> and find someone better."
= >> Similarly, if they have tried, and they have concluded that = they can
>> not, and they concluded that they can not appoint = the one nominee,  then
>> I do not think that writing = special rules is either necessary  or useful.
>>
= >> The philosophy of this document historically was to leave = things up  to
>> the judgment of the nominating committee = and the nominating  committee
>> chair.
>>
= >> I also presume that having observed history, if the nomcom = decides  to do
>> something radical they will try to = figure out how to work with  the
>> confirming body on = that, rather than just throwing it over the  wall and
>> = saying "live with it."  But since it is very situational, I  = would
>> hesitate to even write advice for the chair in that = situation,  much less
>> rules.
>>
>> = Joel
>>
>> Fred Baker wrote:
>>> this = has resulted in the confirming bodies responding "you did not  = send
>>> a complete list" and stonewalling. The nomcom = would need a way  to tell
>>> the community that the = IAB is feeling its oats again.


= _______________________________________________
ietf-nomcom mailing = list
ietf-nomcom@ietf.org
https://www.iet= f.org/mailman/listinfo/ietf-nomcom

=

= --Apple-Mail-5--722194476-- From huitema@windows.microsoft.com Thu May 7 14:11: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 F2DDB3A6CC7 for ; Thu, 7 May 2009 14:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 CR9WkkrjSqlv for ; Thu, 7 May 2009 14:11:43 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 342793A6C5D for ; Thu, 7 May 2009 14:11:43 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 7 May 2009 14:13:11 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.2.99.4; Thu, 7 May 2009 14:12:51 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Thu, 7 May 2009 14:12:50 -0700 From: Christian Huitema To: Fred Baker , Spencer Dawkins Date: Thu, 7 May 2009 14:12:49 -0700 Thread-Topic: [ietf-nomcom] announcing list of willing candidates Thread-Index: AcnPIlA9QU+i7XmLT5uXMK6danJ8JgANdkSA Message-ID: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> In-Reply-To: <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 07 May 2009 21:11:44 -0000 > The reason that a nomcom must send a complete slate is to protect the > confidentiality of those it has names of and doesn't have consensus to > select. How does that fit with the idea of posting a single name and > then not choosing it? It is a difficult problem. In difficult cases, it is good to rely on simple= guidelines, such as, for example, "YOU SHALL NOT LIE." And padding is just= that, a lie. Maybe a white lie, maybe a well intentioned lie, a lie nevert= heless. If there are not enough name on the list, and the nomcom does not f= eel comfortable releasing them, then it should have an option, such as not = writing any name, or writing a place holder such as "not enough candidates = at this point." -- Christian Huitema From rcallon@juniper.net Thu May 7 19:53:46 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 398D53A68AF for ; Thu, 7 May 2009 19:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 T32SjApEkuvI for ; Thu, 7 May 2009 19:53:45 -0700 (PDT) Received: from chip3og62.obsmtp.com (chip3og62.obsmtp.com [64.18.14.201]) by core3.amsl.com (Postfix) with ESMTP id B962C3A6819 for ; Thu, 7 May 2009 19:53:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob62.postini.com ([64.18.6.12]) with SMTP ID DSNKSgOfCt53RjBlGcmDUTSibh9HDW1PyM0B@postini.com; Thu, 07 May 2009 19:55:14 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 7 May 2009 19:53:15 -0700 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 19:53:15 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 19:53:14 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2009 22:53:12 -0400 Message-ID: <3525C9833C09ED418C6FD6CD9514668C064D7DF3@emailwf1.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-nomcom] announcing list of willing candidates Thread-Index: AcnPRKVJpdc0Bc4/RcmWboBmLVALcgAIjqbA References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com><51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net><874B0EA5B7474E40BC4771582E20F135@china.huawei.com><4A01FF14.1000802@joelhalpern.com><68203580453A41F9BE4A8E17676A40DD@china.huawei.com><52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com><675982CA-8EED-470C-888D-DB876816D256@cisco.com><5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com><200905071248.n47CmSYc026256@cichlid.raleigh.ibm.com><200905071710.n47HAMlf027713@cichlid.raleigh.ibm.com> From: Ross Callon To: "Spencer Dawkins" , "Thomas Narten" X-OriginalArrivalTime: 08 May 2009 02:53:14.0804 (UTC) FILETIME=[21E6B740:01C9CF88] Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 08 May 2009 02:53:46 -0000 > ...This is a waste of precious IETF-participant cycles,=20 > and Joel Halpern (2008-2009 NomCom Chair) reports that=20 > "the ringer pool leaks like a sieve" - it's also ineffective. > > Think that's sufficient? While I agree with Joel's statement, I would be inclined to make this a bit less colloquial in the writeup, and change this to something like: > ...This is a waste of precious IETF-participant cycles,=20 > and there are widespread reports that strict confidentiality=20 > is not successfully maintained in terms of which candidates=20 > are "real", and which are included as "padding" (aka "ringers").=20 Ross From bernie@ietf.hoeneisen.ch Fri May 8 02:24: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 5814928C0FD for ; Fri, 8 May 2009 02:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 zTxldZIO6DIN for ; Fri, 8 May 2009 02:24:36 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 7D0043A6CFF for ; Fri, 8 May 2009 02:24:36 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1M2MKz-0002Nv-7p; Fri, 08 May 2009 11:25:49 +0200 Date: Fri, 8 May 2009 11:25:49 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Ross Callon In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C064D7DF3@emailwf1.jnpr.net> Message-ID: References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com><51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net><874B0EA5B7474E40BC4771582E20F135@china.huawei.com><4A01FF14.1000802@joelhalpern.com><68203580453A41F9BE4A8E17676A40DD@china.huawei.com><52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com><675982CA-8EED-470C-888D-DB876816D256@cisco.com><5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com><200905071248.n47CmSYc026256@cichlid.raleigh.ibm.com><200905071710.n47HAMlf027713@cichlid.raleigh.ibm.com> <3525C9833C09ED418C6FD6CD9514668C064D7DF3@emailwf1.jnpr.net> 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: Thomas Narten , NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 08 May 2009 09:24:37 -0000 On Thu, 7 May 2009, Ross Callon wrote: >> ...This is a waste of precious IETF-participant cycles, >> and there are widespread reports that strict confidentiality >> is not successfully maintained in terms of which candidates >> are "real", and which are included as "padding" (aka "ringers"). Great, we are making progress on the text! One small correction: s/candidates/nominees/ (Terminology: nominiee vs. candidate) cheers, Bernie From barryleiba.mailing.lists@gmail.com Fri May 8 07:57:22 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 2352F3A70B7 for ; Fri, 8 May 2009 07:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.159, 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 D2L0ilhHpB8B for ; Fri, 8 May 2009 07:57:21 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 322CA3A686C for ; Fri, 8 May 2009 07:57:21 -0700 (PDT) Received: by fxm2 with SMTP id 2so1444002fxm.37 for ; Fri, 08 May 2009 07:58:34 -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=Gxon83y0f1YElxYV8dhk/pnqT+KDNaIqFRPKsbb5Eg0=; b=GT7wE7m4Czo0VXEOTMrj2yH3T5dW2MHLo+i4rzt+0zdswQAMmGLwa57pkmXcpqI6y0 cPjNpXPSAkmvxPqz0ssISt5WDsAncb0LYFQpSsTLPA99Fq+K0HwZuQ8Wdj0kADEkbu0Z bSXVTO5JqvWSkc5NYhchyStYTczfFfV/xFUm0= 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=rgCgruwl1iicpSg2IRkzDQCUNOv0kA1boUxWyl1lP4YxtxsnIlg3htA0/o4x8jH6+j EPSd/AVLhw8YTZ85ojrwA8LZHGVYpoULGd0UzjgSSaNd+dQ7Ci1m47WhcHLUMkTPERyr /N88X5iZVUhRdVedc5YGoEf0hNS0RDiPCTmoQ= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.223.119.84 with SMTP id y20mr2212910faq.14.1241794714730; Fri, 08 May 2009 07:58:34 -0700 (PDT) In-Reply-To: <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> References: <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> Date: Fri, 8 May 2009 10:58:34 -0400 X-Google-Sender-Auth: 0081c41f5c2ca6a9 Message-ID: <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> From: Barry Leiba To: "Scott O. Bradner" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding on small nominee lists - MUST NOT or SHOULD NOT? 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, 08 May 2009 14:57:22 -0000 > maybe "do not need to pad..." I think there's value to the community in knowing that the list is short. And I think that the less padding that goes on, the more we'll all expect that the lists aren't padded, so the more misleading the odd padded list will be. Where's the value? I'd go for never padding, ever. Barry From kre@munnari.OZ.AU Fri May 8 10:10:29 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 8749D3A6B4A for ; Fri, 8 May 2009 10:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 WM1qk128FqhV for ; Fri, 8 May 2009 10:10:28 -0700 (PDT) Received: from jade.coe.psu.ac.th (unknown [202.28.99.196]) by core3.amsl.com (Postfix) with ESMTP id A3E743A6967 for ; Fri, 8 May 2009 10:10:27 -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 n48H9OTV000832; Sat, 9 May 2009 00:09:41 +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 n48H7hkQ009001; Sat, 9 May 2009 00:08:10 +0700 (ICT) From: Robert Elz To: Christian Huitema In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 May 2009 00:07:43 +0700 Message-ID: <11211.1241802463@epsilon.noi.kre.to> Sender: kre@munnari.OZ.AU Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 08 May 2009 17:10:29 -0000 Date: Thu, 7 May 2009 14:12:49 -0700 From: Christian Huitema Message-ID: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> | It is a difficult problem. In difficult cases, it is good to rely | on simple guidelines, such as, for example, "YOU SHALL NOT LIE." That's good, but causes other problems. I will phrase the following in terms of the nomcom soliciting opinions about nominees for particular positions, as I still don't think the nominee list should be published at all, and I refuse to say anything that might be construed as a change of opinion on that... Consider where the nomcom has 3 nominees for a position (say internet AD). Call them A B and C. The nomcom asks for opinions about those 3 nominees. It happens C is also nominated for another position, say security AD. Somewhere during the deliberations, it becomes pretty clear that C is going to be appointed security AD. At this point, if the nomcom asks "which of A B and C would be a good internet AD?" wouldn't that be just as much a lie as adding a ringer, even though C is still (technically) a nominee for internet AD? And wouldn't asking that question be wasting the community's time almost as much as adding ringers? Because of that, I would suggest that the doc make clear that the nomcom isn't required to include the complete list of nominees in any question it asks, in the case above (before C is selected as security AD), it could ask WG chair X: "What do you think of A and B as internet AD?", and ask WG chair Y: "What do you think of B and C as internet AD?", and ask WG chair Z: "What do you think of A and C as internet AD?" One might imagine X replying, "B would be good, I don't think much of A", and Y replying "C would be OK, probably better at security though, but B is better for internet AD, great to see you're not considering that moron A", and Z replying "C is OK I guess, A is an idiot, why the hell aren't you considering B?". With this, the changing list of nominees, as some are rendered unavailable - either because they're appointed (earmarked anyway) elsewhere, or because they're simply struck off the list as inappropriate, never becomes obvious, no-one ever knows that a name is no longer on the list, as no-one is even really expecting to see the complete list of nominees. Also, while I am here ... The issue of what to do with an incomplete slate because there was only one nominee and the nomcom doesn't want to appoint that person is just too silly to consider - not because it couldn't happen, but because it is just a special case of "there is no candidate for this position". What is the nomcom supposed to do if no-one volunteers for a position, and no-one can be coerced into it? If forwarding an incomplete slate of candidates is not permitted, the whole process deadlocks, and that's just absurd. On dealing with this question spencer@wonderhamster.org said: (as one of the possible solutions) ... | - reopening the call for nominations with a higher level of "enhanced | recruiting techniques" (sorry for the GITMO reference), or which exposes an erroneous (or should be erroneous) mindset - it looks to me as if too many people are still looking at the nomcom process as something akin to a parliamentary (congressional if you like) election. For those things, they have, for good reason, deadlines on nominations - put in your nomination one minute after the deadline, and you're excluded. That's not relevant here, not even close - the question of "reopening the call for nominations" should never arise, as nominations should never be closed until the position is filled - which happens at the time the annoouncement is sent to ietf-announce (well after confirmation). At any time before then, it should be possible to send in a new nomination. Of course, once the nomcom has selected its candidate, there's no requirement that it ever go back and re-open the issue, unless it decides that is what it wants to do, so very late nominations stand a good chance of being futile - but that's no reason to have a rule forbidding such things, or for ever giving the impression that any particular deadline must be met for a nomination to be legitimate. kre From agmalis@gmail.com Fri May 8 10:14:54 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 121263A6C32 for ; Fri, 8 May 2009 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 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 KrKNVlNGyvjB for ; Fri, 8 May 2009 10:14:53 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id EF6FE3A6B63 for ; Fri, 8 May 2009 10:14:52 -0700 (PDT) Received: by bwz22 with SMTP id 22so1486175bwz.37 for ; Fri, 08 May 2009 10:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=w1vthWD1kLCXkfpzsauhKdQxoFIfme0kQUxyOzWH54w=; b=V1EuiS2pbPRd5L5uRvDb7S/L3OG7bVSSfrDcDi+2iGBv14z28dJRFgvKCmWLPlgWUN 5LQ/NA3H+9wiy8CxnGDZvAWtXq4M9ovQloaJ5kBcN9sVrJfRRgKRbzgNfzbpv6yHZevh ydLiYJrNc8Ye1PfN0mHApUsOLDnmLPsoDN7l0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Tu7nWC7yK5RKjp0gWpo2mi7wSResHtq77g0dezUMIk7iu2R+QIl4vLWqSawWaeXIDV sb10Sb0KCYpk54vYJc4JuFQTdfT/Do0nFfT4A3qCrKhibpeMcY0DRjHZzOdr7dwTvLAo GBDrboMwCrdcK67PRVtAmP5efcwaSkSuyGxQY= MIME-Version: 1.0 Received: by 10.223.104.140 with SMTP id p12mr2334307fao.7.1241802979184; Fri, 08 May 2009 10:16:19 -0700 (PDT) In-Reply-To: <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> References: <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> From: "Andrew G. Malis" Date: Fri, 8 May 2009 13:15:59 -0400 Message-ID: <8c99930d0905081015j101235dbx5e0974016a19bc96@mail.gmail.com> To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding on small nominee lists - MUST NOT or SHOULD NOT? 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, 08 May 2009 17:14:54 -0000 +1, emphatically! On Fri, May 8, 2009 at 10:58 AM, Barry Leiba wrot= e: >> maybe "do not need to pad..." > > I think there's value to the community in knowing that the list is > short. =A0And I think that the less padding that goes on, the more we'll > all expect that the lists aren't padded, so the more misleading the > odd padded list will be. > > Where's the value? > > I'd go for never padding, ever. > > Barry > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From jwkckid1@ix.netcom.com Fri May 8 11:05: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 5C6A43A6D3E for ; Fri, 8 May 2009 11:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_40=-0.185] 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 Zp2sETXZuUZC for ; Fri, 8 May 2009 11:05:02 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 338CD3A6D2F for ; Fri, 8 May 2009 11:05:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=igASMI/eWJudIu/5Elu/paq17VweLxJoMI9RacbHevN2mmICVN1BzSyThD8jrq8K; 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.201] (helo=ix.netcom.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M2USr-0003I2-VD; Fri, 08 May 2009 14:06:30 -0400 Message-ID: <4A04748D.9B76163A@ix.netcom.com> Date: Fri, 08 May 2009 11:06:05 -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: Barry Leiba References: <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606885bd7d2c83603f2a972163cfcb43d303b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.102.201 Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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, 08 May 2009 18:05:03 -0000 Barry and all, FWIW, I can't see the need for a "List" of candidates in the first place. Why not just allow for self nomination or nomination by others? Barry Leiba wrote: > > maybe "do not need to pad..." > > I think there's value to the community in knowing that the list is > short. And I think that the less padding that goes on, the more we'll > all expect that the lists aren't padded, so the more misleading the > odd padded list will be. > > Where's the value? > > I'd go for never padding, ever. > > Barry > _______________________________________________ > 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 barryleiba@gmail.com Fri May 8 11:09: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 A521B3A6D3E for ; Fri, 8 May 2009 11:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 rm14Dhr5RAW7 for ; Fri, 8 May 2009 11:09:09 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id A9B2E3A6D15 for ; Fri, 8 May 2009 11:09:08 -0700 (PDT) Received: by ewy24 with SMTP id 24so2007350ewy.37 for ; Fri, 08 May 2009 11:10:33 -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=BZYGVvyPlVHpfjRjdpaSTkYOaHEYZR/aq3H+TzTn7co=; b=FMp+vuT6DdtGFA9qbNn4m/D2oTdYYn3P+UblE1SyS6Yhb4qVUlDWRt5EPmg9gj/pyE AdOutsY9aM59Vfq4h9cq6Y/C8rUHrh5HSkhaIExB242P1BoSPYfxV0nQO1arkgBOTild JI6ICVYYHnglbh8Gc7SdbCRq0R1DN8+Ly3G7w= 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=Wl3g5PcYRt0xPLrKOmUr6w8wDSc8aeR8GFkSxF5PNxNFbx24Xid1LJRQz612AGZ3No RpLIyATC+GUeWK0DQqanZAjA2ChXwcOl/mgEz96tnuK0GENm0QisGYcMkc4sskTqgTMK FPq421i4WMN/kqPcgIsc3lBvja0+597+kI9ak= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.210.37.11 with SMTP id k11mr1791034ebk.9.1241806232324; Fri, 08 May 2009 11:10:32 -0700 (PDT) In-Reply-To: <4A04748D.9B76163A@ix.netcom.com> References: <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> <4A04748D.9B76163A@ix.netcom.com> Date: Fri, 8 May 2009 14:10:32 -0400 X-Google-Sender-Auth: 5b4f5fb9cec06ab8 Message-ID: <9abf48a60905081110w186a852lb3832e64e3ec19ff@mail.gmail.com> From: Barry Leiba To: "Jeffrey A. Williams" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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, 08 May 2009 18:09:09 -0000 On Fri, May 8, 2009 at 2:06 PM, Jeffrey A. Williams wrote: > =A0FWIW, I can't see the need for a "List" of candidates in the first > place. =A0Why not just allow for self nomination or nomination by > others? That's what we have. But at some point, the time for nominations is over, and we have a list of nominees for the NomCom to work with (and for the community to comment on). Sometimes, when that time comes, few people have been nominated, whether by themselves or by others. That's what we're addressing here. Do you not understand that, or do I misunderstand your comment? Barry From spencer@wonderhamster.org Fri May 8 11:28:46 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 7A1173A6D15 for ; Fri, 8 May 2009 11:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, 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 AFu9y26NoOiJ for ; Fri, 8 May 2009 11:28:45 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 9BE9E3A67DA for ; Fri, 8 May 2009 11:28:45 -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-1M2Qmj0kpJ-000crB; Fri, 08 May 2009 10:10:50 -0400 Message-ID: <2DA631E0A3C448C4B08554CD0D1B5B45@china.huawei.com> From: "Spencer Dawkins" To: "Bernie Hoeneisen" , "Ross Callon" References: <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com><51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net><874B0EA5B7474E40BC4771582E20F135@china.huawei.com><4A01FF14.1000802@joelhalpern.com><68203580453A41F9BE4A8E17676A40DD@china.huawei.com><52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com><675982CA-8EED-470C-888D-DB876816D256@cisco.com><5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com><200905071248.n47CmSYc026256@cichlid.raleigh.ibm.com><200905071710.n47HAMlf027713@cichlid.raleigh.ibm.com> <3525C9833C09ED418C6FD6CD9514668C064D7DF3@emailwf1.jnpr.net> Date: Fri, 8 May 2009 09:10:19 -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/ieacuQpDMUA5p4F/iUB3gCh36LdBI//sqGAA 7NtUV+rD0cIcIRTFoKGZL86HKrjntew562Ill/FzV8WbcPnZby AOq3d445LLix/qmwPMpy/GyNZU6eUApkrjt+bpGfMI= Cc: Thomas Narten , NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 08 May 2009 18:28:46 -0000 Hi, Bernie, ... no one gets this right the first time ;-) ... Thanks, Spencer > On Thu, 7 May 2009, Ross Callon wrote: > >>> ...This is a waste of precious IETF-participant cycles, >>> and there are widespread reports that strict confidentiality >>> is not successfully maintained in terms of which candidates >>> are "real", and which are included as "padding" (aka "ringers"). > > Great, we are making progress on the text! > > One small correction: s/candidates/nominees/ > (Terminology: nominiee vs. candidate) > > cheers, > Bernie > From jwkckid1@ix.netcom.com Fri May 8 12:30: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 8890828C205 for ; Fri, 8 May 2009 12:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=1.829, 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 keZNy+79LJRD for ; Fri, 8 May 2009 12:30:12 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 650D128C1EA for ; Fri, 8 May 2009 12:30:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=swIwHLYmTifCxJOvEaWeTPXUAg5doP7hqhc79VC84mxVH3D2Spo3fIspp7zH4sDH; 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.201] (helo=ix.netcom.com) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M2VnI-0001fA-6n; Fri, 08 May 2009 15:31:40 -0400 Message-ID: <4A048883.6FE30E0@ix.netcom.com> Date: Fri, 08 May 2009 12:31:15 -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: Barry Leiba References: <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> <4A04748D.9B76163A@ix.netcom.com> <9abf48a60905081110w186a852lb3832e64e3ec19ff@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688cf76817fdc49ce85fab3e29531a8c1e1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.102.201 Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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, 08 May 2009 19:30:13 -0000 Barry and all, I understood your comment/ remark. Yet I've seen no one yet nominated or self nominate. Hence my original response. So you must have misunderstood my comment. Sorry about that. Do you understand now? Barry Leiba wrote: > On Fri, May 8, 2009 at 2:06 PM, Jeffrey A. Williams > wrote: > > FWIW, I can't see the need for a "List" of candidates in the first > > place. Why not just allow for self nomination or nomination by > > others? > > That's what we have. But at some point, the time for nominations is > over, and we have a list of nominees for the NomCom to work with (and > for the community to comment on). Sometimes, when that time comes, > few people have been nominated, whether by themselves or by others. > That's what we're addressing here. > > Do you not understand that, or do I misunderstand your comment? > > Barry 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 john-ietf@jck.com Fri May 8 15:11: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 19F973A6B55 for ; Fri, 8 May 2009 15:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 w779X+wlX5wX for ; Fri, 8 May 2009 15:11:40 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id CAA583A6B63 for ; Fri, 8 May 2009 15:11:39 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1M2YJX-000KeW-1z; Fri, 08 May 2009 18:13:07 -0400 Date: Fri, 08 May 2009 18:13:06 -0400 From: John C Klensin To: Barry Leiba Message-ID: In-Reply-To: <9abf48a60905081110w186a852lb3832e64e3ec19ff@mail.gmail.com> References: <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> <4A04748D.9B76163A@ix.netcom.com> <9abf48a60905081110w186a852lb3832e64e3ec19ff@mail.gmail.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: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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, 08 May 2009 22:11:41 -0000 --On Friday, May 08, 2009 14:10 -0400 Barry Leiba wrote: >... > But at some point, the time for nominations is > over, and we have a list of nominees for the NomCom to work > with (and for the community to comment on). Sometimes, when > that time comes, few people have been nominated, whether by > themselves or by others. That's what we're addressing here. >... Barry, What we have, unless _I_ misunderstand things, is a date on which initial nominations are closed. That date exists for the convenience of both the community and the Nomcom. But the Nomcom is free, at almost any time up to when it makes its decision, to decide it needs more nominees or that someone not yet nominated would be ideal for the job. If it makes that decision, it is free to go out and start arm-twisting (or whatever else it takes). Indeed, if it isn't satisfied with the nominees it has, I believe that it is obligated to do that. While I've got misgivings about the present proposal, I can live with it, but not if it contains provisions that can be interpreted as any of... -- preventing the Nomcom from doing active and selective recruiting (or makes the Nomcom passive wrt what nominations are considered, which amounts to the same thing) -- preventing the Nomcom from going recruiting after nominations have formally closed and it has started to consider candidates -- preventing the Nomcom from considering (or even selecting) a nominee/ potential candidate whose name had not been exposed to the community on one or more short (or not-so-short) lists. In essence, no matter what one thinks about the desirability of giving the community more information so that the Nomcom gets more and better information, if the mechanism for doing so has the side-effect of reducing the Nomcom's flexibility and/or sense of responsibility, it is probably a bad idea. Just IMO, john From john-ietf@jck.com Fri May 8 15:18: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 AE1F73A6918 for ; Fri, 8 May 2009 15:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 rS-dKVcqdPLx for ; Fri, 8 May 2009 15:18:27 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 399753A6830 for ; Fri, 8 May 2009 15:18:27 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1M2YQ4-000KyK-E6; Fri, 08 May 2009 18:19:52 -0400 Date: Fri, 08 May 2009 18:19:51 -0400 From: John C Klensin To: Robert Elz , Christian Huitema Message-ID: In-Reply-To: <11211.1241802463@epsilon.noi.kre.to> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> 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] announcing list of willing candidates 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, 08 May 2009 22:18:28 -0000 +1 I think there are a series of important principles here, including the implied ability of the Nomcom to decide to not fill some positions, and that no decision that is made about exposing names should --accidentally or deliberately-- be permitted to violate those principles. john --On Saturday, May 09, 2009 00:07 +0700 Robert Elz wrote: > Date: Thu, 7 May 2009 14:12:49 -0700 > From: Christian Huitema > Message-ID: > <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wing > roup.windeploy.ntdev.microsoft.com> > > | It is a difficult problem. In difficult cases, it is good > to rely | on simple guidelines, such as, for example, "YOU > SHALL NOT LIE." > > That's good, but causes other problems. > > I will phrase the following in terms of the nomcom soliciting > opinions about nominees for particular positions, as I still > don't think the nominee list should be published at all, and I > refuse to say anything that might be construed as a change of > opinion on that... > > Consider where the nomcom has 3 nominees for a position (say > internet AD). Call them A B and C. The nomcom asks for > opinions about those 3 nominees. It happens C is also > nominated for another position, say security AD. Somewhere > during the deliberations, it becomes pretty clear that C is > going to be appointed security AD. At this point, if the > nomcom asks "which of A B and C would be a good internet AD?" > wouldn't that be just as much a lie as adding a ringer, even > though C is still (technically) a nominee for internet AD? > > And wouldn't asking that question be wasting the community's > time almost as much as adding ringers? > > Because of that, I would suggest that the doc make clear that > the nomcom isn't required to include the complete list of > nominees in any question it asks, in the case above (before C > is selected as security AD), it could ask WG chair X: "What do > you think of A and B as internet AD?", and ask WG chair Y: > "What do you think of B and C as internet AD?", and ask WG > chair Z: "What do you think of A and C as internet AD?" > > One might imagine X replying, "B would be good, I don't think > much of A", and Y replying "C would be OK, probably better at > security though, but B is better for internet AD, great to see > you're not considering that moron A", and Z replying "C is OK > I guess, A is an idiot, why the hell aren't you considering > B?". > > With this, the changing list of nominees, as some are rendered > unavailable - either because they're appointed (earmarked > anyway) elsewhere, or because they're simply struck off the > list as inappropriate, never becomes obvious, no-one ever > knows that a name is no longer on the list, as no-one is even > really expecting to see the complete list of nominees. > > Also, while I am here ... > > The issue of what to do with an incomplete slate because there > was only one nominee and the nomcom doesn't want to appoint > that person is just too silly to consider - not because it > couldn't happen, but because it is just a special case of > "there is no candidate for this position". > > What is the nomcom supposed to do if no-one volunteers for a > position, and no-one can be coerced into it? If forwarding > an incomplete slate of candidates is not permitted, the whole > process deadlocks, and that's just absurd. > > On dealing with this question spencer@wonderhamster.org said: > (as one of the possible solutions) ... > > | - reopening the call for nominations with a higher level > of "enhanced | recruiting techniques" (sorry for the GITMO > reference), or > > which exposes an erroneous (or should be erroneous) mindset - > it looks to me as if too many people are still looking at the > nomcom process as something akin to a parliamentary > (congressional if you like) election. For those things, they > have, for good reason, deadlines on nominations - put in your > nomination one minute after the deadline, and you're excluded. > > That's not relevant here, not even close - the question of > "reopening the call for nominations" should never arise, as > nominations should never be closed until the position is > filled - which happens at the time the annoouncement is sent > to ietf-announce (well after confirmation). > > At any time before then, it should be possible to send in a > new nomination. > > Of course, once the nomcom has selected its candidate, there's > no requirement that it ever go back and re-open the issue, > unless it decides that is what it wants to do, so very late > nominations stand a good chance of being futile - but that's > no reason to have a rule forbidding such things, or for ever > giving the impression that any particular deadline must be met > for a nomination to be legitimate. > > kre > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom From sm@resistor.net Sat May 9 04:09:49 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 A0BC03A6CFF for ; Sat, 9 May 2009 04:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 2eUg6oU7Ldal for ; Sat, 9 May 2009 04:09:48 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 4F4D53A6809 for ; Sat, 9 May 2009 04:09:48 -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 n49BB4Gg020828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 May 2009 04:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1241867475; x=1241953875; bh=cmSrEe20dTmhCWRA2WJeeQTFNE2gs+x5pS8P+em3Ml4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=uHm9/vXBzsaEGOjayJkHNK+LVa01E1mVN8AiFXK/rg+8NKjkdFHq/V4apy0292mmd dYJC7dR343Riffc9YOS0jzgswR3XUTmGgrxNU89X0KUwK1ZtUu1vW32RQvzRAvN0en IskemYp8kvymHQFTyNR2y5z9zWswq8GdYlJ0Lm3I= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=xXdeRlVFkYoYT1n4k2XH77N0SGrqPYJB64i1Q4lZ8HijZ5Trt4wMqsuTzFqxBe63r NlOCAUhaw0QK91bxqgQdS92Ivl4riQErXm6gDgyrG/+8DlaVGYghndPSv7uevFh1Py8 to8tcWAvtWg0VOXI+k+7q1JkQ70dbnZdxX2pCBA= Message-Id: <6.2.5.6.2.20090508212200.031d3d80@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 09 May 2009 04:10:41 -0700 To: Robert Elz , John C Klensin From: SM In-Reply-To: <11211.1241802463@epsilon.noi.kre.to> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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: Sat, 09 May 2009 11:09:49 -0000 At 10:07 08-05-2009, Robert Elz wrote: >which exposes an erroneous (or should be erroneous) mindset - it looks >to me as if too many people are still looking at the nomcom process as >something akin to a parliamentary (congressional if you like) election. >For those things, they have, for good reason, deadlines on nominations - >put in your nomination one minute after the deadline, and you're >excluded. NomCom is an undemocratic process used to choose the "best person for the job". It is not about choosing someone representative of the IETF community. The community can nominate a candidate. At the individual level, a person can nominate himself/herself. The end results is a list. It is not "the" list of all candidates. There is nothing forbidding NomCom from finding someone who is not on the original list. The list is not a list of all possible nominees. It should be seen more as a list of people on which NomCom is seeking feedback for the selection. That's why the list is being published. There has been a practice to create a hypothetical situation (padding the list) to get around the "rule on confidentiality". I don't see the purpose of tweaking the rules to say what is not confidential. Quoting Section 3 of RFC 3777: "All deliberations and supporting information that relates to specific nominees, candidates, and confirmed candidates are confidential. The nominating committee and confirming body members will be exposed to confidential information as a result of their deliberations, their interactions with those they consult, and from those who provide requested supporting information. All members and all other participants are expected to handle this information in a manner consistent with its sensitivity." That clearly spells out that it is the deliberations and "supporting information" that are confidential. Anything else should not be viewed as confidential. The second paragraph I quoted provides NomCom with the discretion on how to handle sensitive information and gives it some leeway in collecting feedback about the candidates. It does not say that the information is confidential. I note that the model is not about evaluating a candidate on the basis of their application only. The model also doesn't require NomCom to justify their selection (why candidate X was selected instead of candidate Y). The following was from a different thread. At 15:13 08-05-2009, John C Klensin wrote: >What we have, unless _I_ misunderstand things, is a date on >which initial nominations are closed. That date exists for the >convenience of both the community and the Nomcom. But the >Nomcom is free, at almost any time up to when it makes its >decision, to decide it needs more nominees or that someone not >yet nominated would be ideal for the job. If it makes that >decision, it is free to go out and start arm-twisting (or >whatever else it takes). Indeed, if it isn't satisfied with the >nominees it has, I believe that it is obligated to do that. There is a period set for the IETF community to nominate people. NomCom can add other candidates after the period. I would rather view that as the discretion NomCom is given so that it can fulfill its principal functions instead of an obligation (must do it). >While I've got misgivings about the present proposal, I can live >with it, but not if it contains provisions that can be >interpreted as any of... draft-dawkins-nomcom-openlist-02 proposes to allow NomCom to disclose the list of nominees. It then goes into specifying that the published list is intended to be a complete list. By doing so, NomCom may find itself with less discretion in picking nominees. It is better for NomCom to be able to provide the community with a list of nominees on which it solicits feedback with the option to update the list. > -- preventing the Nomcom from doing active and selective > recruiting (or makes the Nomcom passive wrt what > nominations are considered, which amounts to the same > thing) > > -- preventing the Nomcom from going recruiting after > nominations have formally closed and it has started to > consider candidates > > -- preventing the Nomcom from considering (or even > selecting) a nominee/ potential candidate whose name had > not been exposed to the community on one or more short > (or not-so-short) lists. Setting a deadline for the publication may hamper NomCom's ability to do the above. I prefer to see a list that is considered as "work in progress". Leave it to NomCom to determine when to publish their "request for feedback" and how often they want to update that. One concern about having an open list is that it would lead to "lobbying". I guess that it is already being done subtly under the guise of feedback. If people want to provide "statements of support", there aren't any rules to stop them from doing it. If the IETF community views that as "undesirable" behavior, it can frown on such a practice. Bear in mind that NomCom is the "electing body" and it takes its responsibility seriously. I'll purport that it is up to the members of the I* bodies to ensure that there is a possible replacement. Otherwise, they will leave a legacy similar to Louis XV. Regards, -sm From john-ietf@jck.com Sat May 9 07:56: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 210D03A6CAC for ; Sat, 9 May 2009 07:56: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=[AWL=0.001, 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 AK4ORihd3QMO for ; Sat, 9 May 2009 07:56:09 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 911B33A6E5E for ; Sat, 9 May 2009 07:55:48 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1M2nzE-000IEx-BC; Sat, 09 May 2009 10:57:12 -0400 Date: Sat, 09 May 2009 10:57:11 -0400 From: John C Klensin To: SM Message-ID: In-Reply-To: <6.2.5.6.2.20090508212200.031d3d80@resistor.net> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3d80@resistor.net> 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 , Robert Elz Subject: Re: [ietf-nomcom] announcing list of willing candidates 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: Sat, 09 May 2009 14:56:10 -0000 --On Saturday, May 09, 2009 04:10 -0700 SM wrote: >... > The list is not a list of all possible nominees. It should be > seen more as a list of people on which NomCom is seeking > feedback for the selection. That's why the list is being > published. There has been a practice to create a hypothetical > situation (padding the list) to get around the "rule on > confidentiality". I don't see the purpose of tweaking the > rules to say what is not confidential. >... While I had not thought about it that way, I think the notion of clarifying just how much discretion the Nomcom has is a better idea than trying to make a new set of rules. The Nomcom should be (and is) clearly barred from exposing the content of its own deliberations about specific candidates, comparisons among candidates, and information submitted with a clear expectation of confidentiality are not exposed, but little else. If the community wants to clarify the current rules to make it clear that the Nomcom can expose _a_ list of nominees at a point of the Nomcom's choosing, that is probably ok (I share kre's belief that it is probably a bad idea, but we appear to be in the minority). But let's not move beyond that into trying to tie the Nomcom up in specifics that would constrain its discretion and ability to do its job. > There is a period set for the IETF community to nominate > people. NomCom can add other candidates after the period. I > would rather view that as the discretion NomCom is given so > that it can fulfill its principal functions instead of an > obligation (must do it). The "obligation" comment was based on the following reasoning. The Nomcom has something of an obligation to place candidates into roles for which those candidates are optimal choices (possibly not the only optimal choices, of course). Now suppose that, after evaluation of all nominees who came through the "normal" and early nomination process, the Nomcom has a choice between" (a) A "least-bad" candidate with whom the Nomcom is not satisfied and may not be satisfied that the candidate can and will do the job well. (b) Not filling the position, leaving the relevant body with the necessity to cope with being short-handed. (c) Mounting an aggressive search and recruitment campaign. >From my point of view, the first choice is unacceptable (even though I suspect it has been used in the past). And I would hope that the Nomcom would feel obligated to try the third before selecting the second. Also from my point of view, the second is not an obviously bad choice: it might force the relevant body to reconsider and adjust its own scope, workload, etc. and the requirement for that is, IMO, an appropriate message for a Nomcom to send. > draft-dawkins-nomcom-openlist-02 proposes to allow NomCom to > disclose the list of nominees. It then goes into specifying > that the published list is intended to be a complete list. By > doing so, NomCom may find itself with less discretion in > picking nominees. >... Exactly. john From barryleiba.mailing.lists@gmail.com Sat May 9 14:02: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 835253A6B5C for ; Sat, 9 May 2009 14:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=-0.153, 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 ZcvPXDQJUuRB for ; Sat, 9 May 2009 14:02:02 -0700 (PDT) Received: from mail-bw0-f174.google.com (mail-bw0-f174.google.com [209.85.218.174]) by core3.amsl.com (Postfix) with ESMTP id 731CA3A67D0 for ; Sat, 9 May 2009 14:02:02 -0700 (PDT) Received: by bwz22 with SMTP id 22so1960476bwz.37 for ; Sat, 09 May 2009 14:03:29 -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=zrCQvFtOLUn/KIaGDbFP9hbMRTW6GERa++FlNVUexiU=; b=sC3jaRM+tamhJhBYwNsXFSTU7vUIGvBI/qMGopmpwGAT6PqX/PhI94CyoKsqKF4jDO k9sAIQjTyN4MwdPV7gNtWL0lTKb5IaCSIWAKLIDaHjBq/XeLpY/reEkl48cQFNr9lm3R 1AQdE8rw6JSIR4PKvvNYymSC2CT2ctp9qxelY= 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=jGv7w1Cm2D6+DdKiK2uas40zjKUivQakpuY2VP+Av0ffsto4YYn6XzXVFhn8RzIU5V Qeddb93y3YD0pMXhfg+f/XWwNhm0MKFkhavIiZhay6LHxDKkQRKXQK/8Wn15TJlbQGFS akAxJJ82xhQe2aUCYdFjgof0aJ4bj9cL9tdDM= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.223.126.1 with SMTP id a1mr2969373fas.52.1241903008849; Sat, 09 May 2009 14:03:28 -0700 (PDT) In-Reply-To: References: <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> <4A04748D.9B76163A@ix.netcom.com> <9abf48a60905081110w186a852lb3832e64e3ec19ff@mail.gmail.com> Date: Sat, 9 May 2009 17:03:27 -0400 X-Google-Sender-Auth: 0c492d74084d6a80 Message-ID: <6c9fcc2a0905091403wb2b9b53y67387872bd793475@mail.gmail.com> From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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: Sat, 09 May 2009 21:02:03 -0000 On Fri, May 8, 2009 at 6:13 PM, John C Klensin wrote: > What we have, unless _I_ misunderstand things, is a date on > which initial nominations are closed. =A0That date exists for the > convenience of both the community and the Nomcom. =A0But the > Nomcom is free, at almost any time up to when it makes its > decision, to decide it needs more nominees or that someone not > yet nominated would be ideal for the job. =A0If it makes that > decision, it is free to go out and start arm-twisting (or > whatever else it takes). In other words, while we have a date by which nominations are expected, nominations are never really closed. I fully agree. My only concern with actually saying that is that I'd worry that it'd prompt people to ignore the deadlines completely. Though, on thinking about it, I don't imagine it'd be a real problem. The NomCom is free to give little notice to "late" nominations if it wants to, and it's in everyone's best interest for it to pick a stellar candidate even if her nomination was "late". Barry From john-ietf@jck.com Sat May 9 15:53:29 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 266A23A6826 for ; Sat, 9 May 2009 15:53:29 -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=[AWL=0.000, 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 dFLK9cLiOl1s for ; Sat, 9 May 2009 15:53:28 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 4148D3A67D4 for ; Sat, 9 May 2009 15:53:28 -0700 (PDT) Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1M2vRY-0003Gd-DH; Sat, 09 May 2009 18:54:56 -0400 Date: Sat, 09 May 2009 18:54:55 -0400 From: John C Klensin To: Barry Leiba Message-ID: <30F4F99D7834055BBFB7674E@[192.168.1.110]> In-Reply-To: <6c9fcc2a0905091403wb2b9b53y67387872bd793475@mail.gmail.com> References: <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> <4A04748D.9B76163A@ix.netcom.com> <9abf48a60905081110w186a852lb3832e64e3ec19ff@mail.gmail.com> <6c9fcc2a0905091403wb2b9b53y67387872bd793475@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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: Sat, 09 May 2009 22:53:29 -0000 --On Saturday, May 09, 2009 5:03 PM -0400 Barry Leiba wrote: > In other words, while we have a date by which nominations are > expected, nominations are never really closed. I fully agree. > > My only concern with actually saying that is that I'd worry > that it'd prompt people to ignore the deadlines completely. > Though, on thinking about it, I don't imagine it'd be a real > problem. The NomCom is free to give little notice to "late" > nominations if it wants to, and it's in everyone's best > interest for it to pick a stellar candidate even if her > nomination was "late". Exactly. If we need to be explicit, it should include the observation that the Nomcom may, at its discretion, completely ignore anything that comes in after the deadline. john From kre@munnari.OZ.AU Sat May 9 21:57: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 B92523A6C09 for ; Sat, 9 May 2009 21:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 Vld4rTfGTM7a for ; Sat, 9 May 2009 21:57:17 -0700 (PDT) Received: from jade.coe.psu.ac.th (unknown [202.28.99.196]) by core3.amsl.com (Postfix) with ESMTP id 13B0F3A6BB0 for ; Sat, 9 May 2009 21:57:16 -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 n4A4uX3P010228; Sun, 10 May 2009 11:56:50 +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 n4A4teA3016983; Sun, 10 May 2009 11:55:54 +0700 (ICT) From: Robert Elz To: John C Klensin In-Reply-To: <30F4F99D7834055BBFB7674E@[192.168.1.110]> References: <30F4F99D7834055BBFB7674E@[192.168.1.110]> <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> <4A04748D.9B76163A@ix.netcom.com> <9abf48a60905081110w186a852lb3832e64e3ec19ff@mail.gmail.com> <6c9fcc2a0905091403wb2b9b53y67387872bd793475@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 May 2009 11:55:40 +0700 Message-ID: <19058.1241931340@epsilon.noi.kre.to> Sender: kre@munnari.OZ.AU Cc: Barry Leiba , ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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, 10 May 2009 04:57:18 -0000 Date: Sat, 09 May 2009 18:54:55 -0400 From: John C Klensin Message-ID: <30F4F99D7834055BBFB7674E@[192.168.1.110]> | Exactly. If we need to be explicit, it should include the | observation that the Nomcom may, at its discretion, completely | ignore anything that comes in after the deadline. No, that's entirely the wrong message - there is, and should be, no deadline - the date on the call for nominations should be the date after which the nomcom will start actively considering what has been submitted to it - and so, the later after that a nomination is made, the less likely it is to be given much weight (all depending upon circumstances, if the position is already essentially filled, only an outstanding nomination would even be examined, I assume, whereas if a position has no current viable takers, almost any nomination, any time, would get serious thought.) There's no reason to tell the nomcom they have discretion to ignore anything after some mythical deadline - they have the discretion to ignore anything, anytime, for any reason. [The rest or this message isn't addressed to John K, the "you" below is the plural you for the whole IETF.] Once again, the nomcom is selected to appoint the I* (and whoever), they're not selected to decide who the community wants to be on the I*. The nomcom appoints who the nomcom think will do the best job for the IETF as a whole, not what any of the rest of us think. Of course, no-one expects the nomcom members to know everything there is to know about every nominee, so they're free to ask for advice from the community, or any part of it (confidentially) - they're free to ask, they're not, and shouldn't be, required to ask. This is (one of) the reasons I'm not in favour of publishing lists of nominees - it is giving the impression that the nomcom is supposed to be soliciting opinions from everyone, and acting upon them - I have seen opinions expressed that that's exactly why this change is being made, to make sure everyone has the chance to express their opinion, as if everyone's opinion is required, or even matters - neither is or should be true. I truly wish that everyone would let go of the election model from their mindsets. Instead imagine that your company (or some company you know of) has just lost its CFO (retired, died, promoted, imprisoned, .. whatever) and needs a new one. The board appoint a committee to find a replacement CFO. Imagine the way they go about that task - many of you probably have some experience of something like this at some stage or other. That committee is exactly the model the nomcom should be following - seeking the best possible available person to fill the open job. Once you start seeing it that way, instead of as some kind of election, the way it is expected to work alters dramatically. kre From john-ietf@jck.com Sun May 10 03:09:38 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 A69B63A67B5 for ; Sun, 10 May 2009 03:09:38 -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=[AWL=0.000, 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 mxY02aMWNwjO for ; Sun, 10 May 2009 03:09:37 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 3FDB93A67B1 for ; Sun, 10 May 2009 03:09:37 -0700 (PDT) Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1M35zo-000Gfg-8k; Sun, 10 May 2009 06:11:00 -0400 Date: Sun, 10 May 2009 06:10:58 -0400 From: John C Klensin To: Robert Elz Message-ID: In-Reply-To: <19058.1241931340@epsilon.noi.kre.to> References: <30F4F99D7834055BBFB7674E@[192.168.1.110]> <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> <4A04748D.9B76163A@ix.netcom.com> <9abf48a60905081110w186a852lb3832e64e3ec19ff@mail.gmail.com> <6c9fcc2a0905091403wb2b9b53y67387872bd793475@mail.gmail.com> <19058.1241931340@epsilon.noi.kre.to> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Barry Leiba , ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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, 10 May 2009 10:09:38 -0000 --On Sunday, May 10, 2009 11:55 AM +0700 Robert Elz wrote: > Date: Sat, 09 May 2009 18:54:55 -0400 > From: John C Klensin > Message-ID: <30F4F99D7834055BBFB7674E@[192.168.1.110]> > > | Exactly. If we need to be explicit, it should include the > | observation that the Nomcom may, at its discretion, > completely | ignore anything that comes in after the > deadline. > > No, that's entirely the wrong message - there is, and should > be, no deadline - the date on the call for nominations should > be the date after which the nomcom will start actively > considering what has been submitted to it - and so, the later > after that a nomination is made, the less likely it is to be > given much weight (all depending upon circumstances, if the > position is already essentially filled, only an outstanding > nomination would even be examined, I assume, whereas if a > position has no current viable takers, almost any nomination, > any time, would get serious thought.) Actually, I think we agree. I might have better expressed what I was trying to say with: If folks insist in thinking about the nominal "close of nominations" date as a "deadline" or "cutoff", or of setting a date after which a snapshot of names being considered will be posted, then it is worth reinforcing the principle that the Nomcom is free to either give careful consideration to names received after that date or to ignore them, at its discretion. I believe that thinking about things in terms of deadlines or cutoffs is a bad idea, but can probably live with it. The general principles here apply to other things as well. For example, a Nomcom that decides to use questionnaires is not required to insist that every nominee fill them out, nor to reject a nominee who declines to do so -- its obligation is to take responsibility for finding the best candidates, not to pretend that it can substitute mechanical following of rules, rituals, or scoring formulae for that responsibility. I also agree that this is a nomination/selection committee, not an election, and that election models do not serve us well. And, while it may not seem relevant at first glance, if we have really managed to get to the point at which Nomcom members have so little knowledge of the community that their only option is to collect and tabulate long questionnaires and to try to consult everyone who has an opinion, we need to think about finding an entirely different model, not trying to make small clarifications or adjustments to the confidentiality rules. > This is (one of) the reasons I'm not in favour of publishing > lists of nominees - it is giving the impression that the > nomcom is supposed to be soliciting opinions from everyone, > and acting upon them - I have seen opinions expressed that > that's exactly why this change is being made, to make sure > everyone has the chance to express their opinion, as if > everyone's opinion is required, or even matters - neither is > or should be true. It has another bad consequence, which is that, if there are people who are sensitive about publication of their names, they have an incentive to delay informing the Nomcom of their willingness to serve until after names are posted (or until the likely posting cutoff has passed). Because one would hope that a clearly-superior option would be considered whenever (and however) it came onto the table, unnecessarily late submission of "nominations" risks wasting Nomcom time, which is not desirable. john From jmh@joelhalpern.com Sun May 10 07:33: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 D56243A6B60 for ; Sun, 10 May 2009 07:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_40=-0.185, 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 UNw+gq5mnY3U for ; Sun, 10 May 2009 07:33:03 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 03FA93A680D for ; Sun, 10 May 2009 07:33:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 64D04430131 for ; Sun, 10 May 2009 07:34:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id B6972430126 for ; Sun, 10 May 2009 07:34:32 -0700 (PDT) Message-ID: <4A06E5F3.9040406@joelhalpern.com> Date: Sun, 10 May 2009 10:34:27 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ietf-nomcom@ietf.org References: <30F4F99D7834055BBFB7674E@[192.168.1.110]> <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> <4A04748D.9B76163A@ix.netcom.com> <9abf48a60905081110w186a852lb3832e64e3ec19ff@mail.gmail.com> <6c9fcc2a0905091403wb2b9b53y67387872bd793475@mail.gmail.com> <19058.1241931340@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] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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, 10 May 2009 14:33:03 -0000 If all the nomcom could do was "collect and tabulate long questionnaires and try to consult everyone who has an opinion" we would indeed have a serious problem. However, there is a long distance between that and the nomcom having enough information in and of itself to judge the nominees and select the candidates. The nomcom needs input to do its job. It may have been the case when the procedure was originally envisioned that the job could be done without questionnaires, and wihtout extensive input collection. But nobody can know the necessary parts of the community well enough now. So input collection is necessary. Not for tabulation. But for gaining understanding. (Which is why I sent my earlier note about what I observed to be useful input, and included that information in my report I-D. Even though that has no direct effect on the rules.) But, the current procedure means that the nomcom gets a limited set of input. It also means that the nomcom makes those providing the input do extra work if they are doing their part well. Letting the community as a whole see the list of folks who have been nominated (without any indication of whether they nominated themselves, were nominated by others, whatever), and allowing community members to see and comment on those names, helps the nomcom get better input. Yes, it also means that the nomcom probably has to pay a little more attention to electioneering, so as to extract the information about the nominees skills and abilities, rather than about their social connectness. But that is already part of the nomcom's job. No, this is not an election. RFC 3777 does state that there shall be schedules and deadlines. My read of the purpose of the specific deadline for nomination is that it serves to tell the community that if they want someone seriously considered they should make sure the name gets in before the deadline. That is not a promise by the committee to seriously consider such a person, but a warning that after the deadline, the odds go up that the nomcom will decide for its won reasons to ignore the input. (For example, if someone provides a nomination after the nomcom has selected a candidate but not had that person confirmed, the nomcom is far more likely to do a cursory ~is this new person really much better~, decide "no", and go on with the process.) I agree that the wording has to be clear that the nomcom is free to add people to the pool at any time, for any reason, on any basis it decides. My own take on how to handle that is to simply state that if individuals are added as nominees later, their names are added to the public list. This makes it clear that names can be added later, and indicates how that interacts with the publication process. There should be no requirement for how long a name must be in the pool before the nomcom submits it for confirmation (and that process is not public.) Yours, Joel M. Halpern John C Klensin wrote: ... > I also agree that this is a nomination/selection committee, not an > election, and that election models do not serve us well. And, while it > may not seem relevant at first glance, if we have really managed to get > to the point at which Nomcom members have so little knowledge of the > community that their only option is to collect and tabulate long > questionnaires and to try to consult everyone who has an opinion, we > need to think about finding an entirely different model, not trying to > make small clarifications or adjustments to the confidentiality rules. From sob@harvard.edu Sun May 10 07:37:53 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 36F4C3A6C11 for ; Sun, 10 May 2009 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_20=-0.74] 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 oVdrEAnNweSM for ; Sun, 10 May 2009 07:37:52 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 760BC3A6B07 for ; Sun, 10 May 2009 07:37:52 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 6FFE716D7C2F; Sun, 10 May 2009 10:39:21 -0400 (EDT) To: ietf-nomcom@ietf.org Message-Id: <20090510143921.6FFE716D7C2F@newdev.eecs.harvard.edu> Date: Sun, 10 May 2009 10:39:21 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 10 May 2009 14:37:53 -0000 John sed: > the implied ability of the Nomcom to decide to not fill some positions the one time I know that a nomcom did that the IESG tolld them that was not acceptable & that they should go fill the seats they had been told to fill Scott From sm@resistor.net Sun May 10 07:57:02 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 3E3A93A6869 for ; Sun, 10 May 2009 07:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=-0.735, 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 QK61YQGjUW8d for ; Sun, 10 May 2009 07:57:01 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 310083A6B60 for ; Sun, 10 May 2009 07:57:01 -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 n4AEwEkO015252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2009 07:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1241967509; x=1242053909; bh=T2sYo8Krq1kRIM9LMaZeMxlODokxAnpoP3tyt4bNr7k=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=dq9eEIH/CkT42F4VrFmUa1Pb2iFm+7q+FLeTygr0GnnQMTAkkHg+h0hs+HN+RZCIu 7eeUx7XLPEi1pdvUgRCamKSfS7mgael04FhAxqCtH+Ho6oBvwETQcQ9ZTAyqPq466V vohZ1dbUVxae7uT6AVm1Xpg4iop9JoDuqDMn15uU= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=YhW8XmB27xa2duO/n0GO6JYDB/AwqUiC9zmTtmIosYDCa23Df81sE5EtZOgkCe8h2 MuzClVOI0i0qFKRSnxV0sV8Hpzy7KzjoiNuSduqCDV1IdT4FI8akCiAeyJtlMAnu5zT azD6j6cL7KsTVeXoRxRWpYpxqvoYvicopuVnH2Y= Message-Id: <6.2.5.6.2.20090509222301.02f3bd60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 10 May 2009 05:03:08 -0700 To: John C Klensin From: SM In-Reply-To: References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3d80@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: NomComDiscussion , Robert Elz Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 10 May 2009 14:57:02 -0000 At 07:57 09-05-2009, John C Klensin wrote: >The "obligation" comment was based on the following reasoning. >The Nomcom has something of an obligation to place candidates >into roles for which those candidates are optimal choices >(possibly not the only optimal choices, of course). Now suppose My previous comment about the list oversimplified the matter. It does not address the question of making the optimal choices. kre discussed about that in his message. We have been talking about announcing a list of willing candidates. It's more than one list as it's various roles in the different bodies that are being filled. There can be permutations to reach the optimal choice. >that, after evaluation of all nominees who came through the >"normal" and early nomination process, the Nomcom has a choice >between" > > (a) A "least-bad" candidate with whom the Nomcom is not > satisfied and may not be satisfied that the candidate > can and will do the job well. > > (b) Not filling the position, leaving the relevant body > with the necessity to cope with being short-handed. > > (c) Mounting an aggressive search and recruitment > campaign. > > >From my point of view, the first choice is unacceptable (even >though I suspect it has been used in the past). And I would >hope that the Nomcom would feel obligated to try the third >before selecting the second. Also from my point of view, the >second is not an obviously bad choice: it might force the >relevant body to reconsider and adjust its own scope, workload, >etc. and the requirement for that is, IMO, an appropriate >message for a Nomcom to send. I find the first choice unacceptable as well. One of the problems with a static list is that we can end up with such a choice. I am not so keen about the second choice. However, I won't label it as bad as there are circumstances where NomCom might want to send a message to the confirming body. In a previous iteration of BCP 10, it was clearly spelled out that the principal function of the nominating committee is to recruit and nominate candidates (option three). For that to be possible, NomCom should not be constrained with a list of (willing) nominees. Regards, -sm From jmh@joelhalpern.com Sun May 10 08:06: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 8A5523A68B0 for ; Sun, 10 May 2009 08:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_20=-0.74, J_CHICKENPOX_71=0.6, 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 ES3BsYi-g9Fm for ; Sun, 10 May 2009 08:06:09 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 351AE3A6CCD for ; Sun, 10 May 2009 08:06:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 96E3F43014B for ; Sun, 10 May 2009 08:07:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 0E1A3430147 for ; Sun, 10 May 2009 08:07:32 -0700 (PDT) Message-ID: <4A06EDAF.6090405@joelhalpern.com> Date: Sun, 10 May 2009 11:07:27 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ietf-nomcom@ietf.org References: <20090510143921.6FFE716D7C2F@newdev.eecs.harvard.edu> In-Reply-To: <20090510143921.6FFE716D7C2F@newdev.eecs.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 10 May 2009 15:06:10 -0000 I strongly suspect that the problem here (of not getting all slates filled) is not a rules problem. There is no question that the nomcom should fill the positions it is tasked to fill. That is what it is chartered and selected to do. Equally, if there is a real problem, then the nomcom and the confirming body need to communicate about the problem,a dn resolve it. Throwing ultimatums (ultimata?) over the fence at each other is not effective, although it has been publicly reported as occuring several times. Yes, in the case of a gap the confirming body should be asking "did you really work as hard as you possibly could to deal with this?" And they are probably entitled to ask for more specifics as to what the problem really is. Things will certainly get complicated if the liaison from that body thinks that the nomcom is actually being lazy or stubborn, rather than really working. But at that point there are several parties who can get involved in the discussion. (First round, the chair and past chair. Second round? The whole committee.) It is also important the the nomcom be very aware that they are responsible for filling all the slots. They should not easily say "well, we can't do this one now, so we will take our time and get it done after the next meeting, so that we do a really good job." The deadlines and requirements are there to give the nomcom chair a tool to help get the committee to actually finish the work. (Yes, it matters, and yes having those tools is helpful.) Like most engineering, the nomcom job can easily run into the best being the enemy of the good. (I would hesitate to use the word "optimal" in describing any aspect of this task for that exact reason.) One reason that I would not want to create a strict rule on filling all seats is that it encourages the nomcom to game the system instead of solving the problem. (People often react that way to rules :-) After all, filling resignations operates on a different schedule. Yours, Joel M. Halpern PS: Note that for both IAB and IESG confirmation, it is quite reasonable in my opinion for the confirming body to want a whole slate for confirmation. Both bodies have significant interaction and skill coverage issues. Which the confirming body is supposed to look at. Scott O. Bradner wrote: > John sed: >> the implied ability of the Nomcom to decide to not fill some positions > > the one time I know that a nomcom did that the IESG tolld them that > was not acceptable & that they should go fill the seats they > had been told to fill > > Scott > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From john-ietf@jck.com Sun May 10 11:11: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 1470A3A6B18 for ; Sun, 10 May 2009 11:11:37 -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, J_CHICKENPOX_71=0.6] 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 Rw4nrauCVjEm for ; Sun, 10 May 2009 11:11:36 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id DA72D3A6B07 for ; Sun, 10 May 2009 11:11:35 -0700 (PDT) Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1M3DWK-000OIW-8e; Sun, 10 May 2009 14:13:04 -0400 Date: Sun, 10 May 2009 14:13:02 -0400 From: John C Klensin To: "Joel M. Halpern" , ietf-nomcom@ietf.org Message-ID: <682B8D1E798F6DA17718BE3C@[192.168.1.110]> In-Reply-To: <4A06EDAF.6090405@joelhalpern.com> References: <20090510143921.6FFE716D7C2F@newdev.eecs.harvard.edu> <4A06EDAF.6090405@joelhalpern.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 10 May 2009 18:11:37 -0000 --On Sunday, May 10, 2009 11:07 AM -0400 "Joel M. Halpern" wrote: > I strongly suspect that the problem here (of not getting all > slates filled) is not a rules problem. > > There is no question that the nomcom should fill the positions > it is tasked to fill. That is what it is chartered and > selected to do. > Equally, if there is a real problem, then the nomcom and the > confirming body need to communicate about the problem,a dn > resolve it. Throwing ultimatums (ultimata?) over the fence at > each other is not effective, although it has been publicly > reported as occuring several times. >... Agreed. However, while I hope it will occur rarely, if ever, I believe that we need to leave the Nomcom the room to say "we have been duly diligent but have concluded that there is no satisfactory person to fill this slot". That is very different from the "lazy Nomcom" hypothesis mentioned elsewhere in your note or even a "we need more time for this position" one, both of which I think can and should be sorted out in other ways. While I agree that confirming bodies should ask hard questions if a Nomcom ever declines to fill a slot, I do not believe that a confirming body has the right to say "we won't start the confirmation process until all slots are filled". Note that "not all slots are filled" is different from "not a complete slate" -- if the Nomcom makes an affirmative decision to not fill a slot, then the "slate" is as full as it is going to get and I don't believe that Nomcom has any obligation to come back and "fill the vacancy" unless new information or new possible nominees come forward (or are brought forward). So that this doesn't sound too much like an abstract, hypothetical, and nearly impossible situation, let me explain the scenario I'm concerned about as an example (there may be others). Over the years, IESG and IAB positions have steadily grown in the amount of work and time commitment expected of those who hold them. The two Chairs have, I believe, become full-time roles and (at least) some of the AD positions are rapidly moving up on them. Asking an organization to donate someone to the IETF full-time for two to four years minimum while continuing to pay full salary and benefits and to support the sometimes-extensive travel and other expenses associated with those positions is a huge requirement and commitment -- especially from organizations who will not make commitments longer than 30 - 60 days to employees and managers with link product (i.e., making a direct contribution to a positive bottom line) responsibilities. If the economic trends continue and organizations respond by becoming conservative about activities that do not contribute directly to profitability, the Nomcom will sooner or later be faced with either no nominees for a given position (even after doing their own search) or with no one whom they believe could do the job well. I get very anxious if the Nomcom has only one plausible candidate for a role but how to handle that is up to them. At that point, I believe it is in the best interests of the community for the Nomcom to say "cannot fill this role as specified" rather than offering a substandard and dubious candidate in the hope that he or she will work out. The relevant body would then either need to operate short-handed, possibly scaling back on its expectations of what it can reasonably hope to accomplish, or would have to think about how to reorganize and define itself to be more consistent with the realities of the situation and available personnel. Those would not necessarily be bad outcomes, IMO. john From john-ietf@jck.com Sun May 10 11:30:25 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 EDF2A3A696E for ; Sun, 10 May 2009 11:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 sj0H3ra856Fp for ; Sun, 10 May 2009 11:30:25 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 131453A6BD6 for ; Sun, 10 May 2009 11:30:25 -0700 (PDT) Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1M3DoX-000OcR-HI; Sun, 10 May 2009 14:31:53 -0400 Date: Sun, 10 May 2009 14:31:52 -0400 From: John C Klensin To: "Scott O. Bradner" , ietf-nomcom@ietf.org Message-ID: <9120F9E886C51F5E012EDA61@[192.168.1.110]> In-Reply-To: <20090510143921.6FFE716D7C2F@newdev.eecs.harvard.edu> References: <20090510143921.6FFE716D7C2F@newdev.eecs.harvard.edu> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 10 May 2009 18:30:26 -0000 --On Sunday, May 10, 2009 10:39 AM -0400 "Scott O. Bradner" wrote: > John sed: >> the implied ability of the Nomcom to decide to not fill some >> positions > > the one time I know that a nomcom did that the IESG tolld them > that was not acceptable & that they should go fill the seats > they had been told to fill I hope that, in that situation, the Nomcom got back to work and found a truly stellar candidate who served effectively for one or more terms. However, I'd be very concerned if the result was a candidate whom the Nomcom selected because they had no better choices in spite of that candidate being either substandard in qualifications or concerns that he or she would not work well within the IESG. john From sm@resistor.net Sun May 10 11:33:05 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 D4B8B3A6C2A for ; Sun, 10 May 2009 11:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 ZPCv3wuCWzad for ; Sun, 10 May 2009 11:33:04 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id D8F193A6BE1 for ; Sun, 10 May 2009 11:33:04 -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 n4AIYNm3010126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2009 11:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1241980473; x=1242066873; bh=+ZZDutjY+SZcTDo6zWmD5xx45R/+rbITrgq6xZl/zo4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=XowwiQK/tl9ZiShxqATpFO5610n6Z7csoJZZPeXlZn1E++YP2GinlTcJjVJ3xoZhs zN2756dEWr1gIKfVkfyOGLpHPcmleYyrnEq6LTXRiuJAZiKxUuitNl/6zdzNLwHelu fYaCvM/RcXZjyLW76TZzE2oE/kqH0aZbHmE5ErgY= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=3zvVvSAacpcXokSPpSU5KY0EMDC4fB24Re23yqGGUoVCYrSyhzhwaMDXNMmAM7X7s H3z7SlwitTG56F4xxYzT/96k1YuA++m8clCeN20+yzp+rz1pGvV2os0SJeNWGso5mjv 8xm1QUXjWbxdi9+xCSNyG6F8Tnz7/sYA7sQYJ3I= Message-Id: <6.2.5.6.2.20090510050800.02f469e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 10 May 2009 09:45:44 -0700 To: Robert Elz , John C Klensin From: SM In-Reply-To: <19058.1241931340@epsilon.noi.kre.to> References: <30F4F99D7834055BBFB7674E@[192.168.1.110]> <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> <4A04748D.9B76163A@ix.netcom.com> <9abf48a60905081110w186a852lb3832e64e3ec19ff@mail.gmail.com> <6c9fcc2a0905091403wb2b9b53y67387872bd793475@mail.gmail.com> <19058.1241931340@epsilon.noi.kre.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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, 10 May 2009 18:33:05 -0000 At 21:55 09-05-2009, Robert Elz wrote: >No, that's entirely the wrong message - there is, and should be, no >deadline - the date on the call for nominations should be the date after >which the nomcom will start actively considering what has been submitted >to it - and so, the later after that a nomination is made, the less likely >it is to be given much weight (all depending upon circumstances, if the >position is already essentially filled, only an outstanding nomination >would even be examined, I assume, whereas if a position has no current viable >takers, almost any nomination, any time, would get serious thought.) Having a "best before" date gives NomCom more time to consider the information submitted. What you are suggesting is a continuous process. I'm not against having that. The "no current viable takers" is not a reason to pick almost any nomination. I think that Option three suggested by John is more appropriate. >There's no reason to tell the nomcom they have discretion to ignore >anything after some mythical deadline - they have the discretion to ignore >anything, anytime, for any reason. BCP 10 specifies a set of rules. Anything unspecified is at the discretion of the committee. If you want NomCom to be able to ignore anything, change the rules instead of telling NomCom that they have the discretion to ignore anything. For example, don't specify a deadline for nominations. >Once again, the nomcom is selected to appoint the I* (and whoever), >they're not selected to decide who the community wants to be on the I*. This is a good point. >This is (one of) the reasons I'm not in favour of publishing lists of >nominees - it is giving the impression that the nomcom is supposed to >be soliciting opinions from everyone, and acting upon them - I have seen >opinions expressed that that's exactly why this change is being made, to >make sure everyone has the chance to express their opinion, as if everyone's >opinion is required, or even matters - neither is or should be true. Participants have an incentive to suggest new nominees if they know who are being considered. One of the problems of having a large number of IETF participants is that it is difficult for the people to get to know each other. If NomCom relies only on feedback from WG Chairs etc. and the person is not known to these people, there won't be adequate feedback. Having said that, having an open list opens up a new set of problems. Regards, -sm From sob@harvard.edu Sun May 10 11:33: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 4F5413A6C23 for ; Sun, 10 May 2009 11:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 cSlj-JQi5Lom for ; Sun, 10 May 2009 11:33:39 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 92FC23A696E for ; Sun, 10 May 2009 11:33:39 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id C19A516D7FD1; Sun, 10 May 2009 14:35:08 -0400 (EDT) To: ietf-nomcom@ietf.org, john-ietf@jck.com, sob@harvard.edu In-Reply-To: <9120F9E886C51F5E012EDA61@[192.168.1.110]> Message-Id: <20090510183508.C19A516D7FD1@newdev.eecs.harvard.edu> Date: Sun, 10 May 2009 14:35:08 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 10 May 2009 18:33:40 -0000 > I hope that, in that situation, the Nomcom got back to work and > found a truly stellar candidate who served effectively for one > or more terms. without going into the details, I'd say that was the result Scott From john-ietf@jck.com Sun May 10 11:48:43 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 430503A6C89 for ; Sun, 10 May 2009 11:48:43 -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 E+STvADAZfsb for ; Sun, 10 May 2009 11:48:43 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id EF23C3A6BE2 for ; Sun, 10 May 2009 11:48:42 -0700 (PDT) Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1M3E6C-000Ovc-4C; Sun, 10 May 2009 14:50:08 -0400 Date: Sun, 10 May 2009 14:50:06 -0400 From: John C Klensin To: "Joel M. Halpern" , ietf-nomcom@ietf.org Message-ID: <56A365C33EBE1F7E4D761A8C@[192.168.1.110]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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, 10 May 2009 18:48:43 -0000 --On Sunday, May 10, 2009 10:34 AM -0400 "Joel M. Halpern" wrote: >... > I agree that the wording has to be clear that the nomcom is > free to add people to the pool at any time, for any reason, on > any basis it decides. > My own take on how to handle that is to simply state that if > individuals are added as nominees later, their names are added > to the public list. This makes it clear that names can be > added later, and indicates how that interacts with the > publication process. Joel, With the understanding that I don't have much sympathy for someone who wants one of these positions but submits his or her name late, if the Nomcom concludes that it has to go recruiting, identify a person whom they want to have in the role, and then convince him or her to "volunteer", I think there should be as few impediments to the person accepting as possible. That means that, if such individuals are reluctant to have their names exposed if they are not selected, the Nomcom should have the discretion to agree to that restriction. So "...are added as nominees later, their names are added to the public list unless the Nomcom concludes that doing so is not in the best interest of the community" works for me. A firm rule does not. john From lars.eggert@nokia.com Mon May 11 04:06: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 CF1383A6BEA for ; Mon, 11 May 2009 04:06:12 -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 sreYV6LkxsmI for ; Mon, 11 May 2009 04:06:08 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 3701A3A6D42 for ; Mon, 11 May 2009 04:05:54 -0700 (PDT) Received: from [IPv6:2001:610:240:13:219:e3ff:fe06:dc74] ([IPv6:2001:610:240:13:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n4BB7A1s058332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 May 2009 14:07:13 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <458476AD-D060-4411-8712-72C696C1DC81@nokia.com> From: Lars Eggert To: "Andrew G. Malis" In-Reply-To: <8c99930d0905081015j101235dbx5e0974016a19bc96@mail.gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-6--407658929; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 11 May 2009 14:07:09 +0300 References: <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> <8c99930d0905081015j101235dbx5e0974016a19bc96@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Mon, 11 May 2009 14:07:16 +0300 (EEST) Cc: Barry Leiba , "ietf-nomcom@ietf.org" Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding on small nominee lists - MUST NOT or SHOULD NOT? 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, 11 May 2009 11:06:12 -0000 --Apple-Mail-6--407658929 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Agree. On 2009-5-8, at 20:15, Andrew G. Malis wrote: > +1, emphatically! > > On Fri, May 8, 2009 at 10:58 AM, Barry Leiba > wrote: >>> maybe "do not need to pad..." >> >> I think there's value to the community in knowing that the list is >> short. And I think that the less padding that goes on, the more >> we'll >> all expect that the lists aren't padded, so the more misleading the >> odd padded list will be. >> >> Where's the value? >> >> I'd go for never padding, ever. >> >> Barry >> _______________________________________________ >> 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 --Apple-Mail-6--407658929 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA1MTExMTA3MTBaMCMGCSqGSIb3DQEJBDEWBBRxeCYihqHhN70L MZKH6n3o1ekMnjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAXYQI+GPsR99zT8ESC3PYs5ZL4MPmocNHcXiz1boL8vhNWLo+bU5c e3+hDXPiWRcrzAJW73F6fDP6l6dZ/hqA0n5emFtytrqW/4GcYYaBqcacNWGufPf072316G4/Vf8W pJTqr7tsAccMWeMUAfckVP3oOUBrpBBWaPDmNzuNVBIBgTYHrQDvTmwPtc+wm0pbqiQHakiPMHG9 vrEn1d1MQYq8u9jGk4qyuAX4fLwsH82egC2YPSsZvTy8vIE759M99P8utpfeJgTbnhgT1nhJoPzr WnQti5TjtKVi4nNluKa4sqdJg5qsqJVzgefW8EOorJ7iNz1vZc5EWMHz3+0qlgAAAAAAAA== --Apple-Mail-6--407658929-- From john@jck.com Sun May 10 11:38:47 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 E2C9E3A6972 for ; Sun, 10 May 2009 11:38:47 -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 u+fzRd6eI-gB for ; Sun, 10 May 2009 11:38:47 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 04EB53A69CA for ; Sun, 10 May 2009 11:38:46 -0700 (PDT) Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1M3Dwd-000Ojx-Vw; Sun, 10 May 2009 14:40:16 -0400 Date: Sun, 10 May 2009 14:40:11 -0400 From: John C Klensin To: "Joel M. Halpern" , ietf-nomcom@ietf.org Message-ID: <2CD8F578F3FB5645A9D22C00@[192.168.1.110]> In-Reply-To: <4A06E5F3.9040406@joelhalpern.com> References: <30F4F99D7834055BBFB7674E@[192.168.1.110]> <20090507123318.3096216BD31F@newdev.eecs.harvard.edu> <6c9fcc2a0905080758s11bb97e3g78796fcb0355c4a8@mail.gmail.com> <4A04748D.9B76163A@ix.netcom.com> <9abf48a60905081110w186a852lb3832e64e3ec19ff@mail.gmail.com> <6c9fcc2a0905091403wb2b9b53y67387872bd793475@mail.gmail.com> <19058.1241931340@epsilon.noi.kre.to> <4A06E5F3.9040406@joelhalpern.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 11 May 2009 08:01:58 -0700 Subject: Re: [ietf-nomcom] Sense-of-the-mailing-list call for padding onsmall nominee lists - MUST NOT or SHOULD NOT? 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, 10 May 2009 18:38:48 -0000 --On Sunday, May 10, 2009 10:34 AM -0400 "Joel M. Halpern" wrote: >... > I agree that the wording has to be clear that the nomcom is > free to add people to the pool at any time, for any reason, on > any basis it decides. > My own take on how to handle that is to simply state that if > individuals are added as nominees later, their names are added > to the public list. This makes it clear that names can be > added later, and indicates how that interacts with the > publication process. Joel, With the understanding that I don't have much sympathy for someone who wants one of these positions but submits his or her name late, if the Nomcom concludes that it has to go recruiting, identify a person whom they want to have in the role, and then convince him or her to "volunteer", I think there should be as few impediments to the person accepting as possible. That means that, if such individuals are reluctant to have their names exposed if they are not selected, the Nomcom should have the discretion to agree to that restriction. So "...are added as nominees later, their names are added to the public list unless the Nomcom concludes that doing so is not in the best interest of the community" works for me. A firm rule does not. john From spencer@wonderhamster.org Mon May 11 08:47:49 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 C1B2B3A6F84 for ; Mon, 11 May 2009 08:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[AWL=-0.939, BAYES_50=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 HGQXMxtlSUvS for ; Mon, 11 May 2009 08:47:48 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 58BEE28C12A for ; Mon, 11 May 2009 08:46:25 -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-1M3XjH3PGq-000cuY; Mon, 11 May 2009 11:47:53 -0400 Message-ID: <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> From: "Spencer Dawkins" To: "Robert Elz" , "John C Klensin" , "SM" References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com><72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com><51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net><874B0EA5B7474E40BC4771582E20F135@china.huawei.com><4A01FF14.1000802@joelhalpern.com><68203580453A41F9BE4A8E17676A40DD@china.huawei.com><52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com><675982CA-8EED-470C-888D-DB876816D256@cisco.com><5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com><4A02DD01.3040009@joelhalpern.com><93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com><11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3d80@resistor.net> Date: Mon, 11 May 2009 10:47:19 -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+LdPR64ps7jVzk9MWmSUykg+u7IB1oPqKfJUt H4XT0U9VW6AZHJ9v6NRojcQEuZK9PNCV3nwwoPKSdNlvDBX8vG 5jAXP27q91DPjDXnrOxF5zZN5SpesoUM5Cifk09EZQ= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 11 May 2009 15:47:49 -0000 I'd like to thank several people for pointing out the additional constraints that were included in text I'd published previously. At this point, it's looking like the draft should say "may publish a list of willing nominees in order to get community feedback". I'm making that change. I'm not feeling good about allowing "padding", based on discussions we've had on this mailing list, so I'll defer text changes in that direction. The normative changes being proposed to RFC 3777 are as follows: The list of nominees willing to serve in positions under review in the current NomCom cycle is not confidential. The NomCom may publish a list of names of willing nominees to the community, in order to obtain feedback from the community on these nominees. The NomCom may publish an updated list if the NomCom identifies errors/omissions in a previously-published version of the public list, or if the NomCom finds it necessary to call for additional nominees, and these nominees indicate a willingness to serve in time to be considered by the NomCom. The list of nominees published for a specific position should contain only the names of nominees who are willing to serve in the position under review. Feedback on willing nominees should always be provided privately to NomCom. Willing nominees should not solicit support, and other IETF community members should not post statements of support/non-support for nominees, Comments are, as always, graciously accepted. Thanks, Spencer From john-ietf@jck.com Mon May 11 09:32:48 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 CD67D3A69C8 for ; Mon, 11 May 2009 09:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 x1ZKrALlCWdm for ; Mon, 11 May 2009 09:32:48 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id E2DA028C128 for ; Mon, 11 May 2009 09:31:18 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1M3YQf-0000NI-05; Mon, 11 May 2009 12:32:37 -0400 Date: Mon, 11 May 2009 12:32:35 -0400 From: John C Klensin To: Spencer Dawkins , Robert Elz , SM Message-ID: <6CE505A3C8C9BCAF9EAFD54B@PST.JCK.COM> In-Reply-To: <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@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: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 11 May 2009 16:32:48 -0000 --On Monday, May 11, 2009 10:47 -0500 Spencer Dawkins wrote: > I'd like to thank several people for pointing out the > additional constraints that were included in text I'd > published previously. > > At this point, it's looking like the draft should say "may > publish a list of willing nominees in order to get community > feedback". I'm making that change. > > I'm not feeling good about allowing "padding", based on > discussions we've had on this mailing list, so I'll defer text > changes in that direction. Spencer, FWIW, my personal recommendation is that you make it very clear --much more clear than it is now -- that "may" (and even "should") in these various sentences has move or less the 2119 meaning, i.e., that the community is giving the Nomcom general guidance, but that the Nomcom is free to do what it thinks necessary and/or desirable and that it is not obligated to explain its reasoning to the community if it doesn't follow the guidance. Without that, "...The NomCom may publish an updated list if the NomCom identifies errors/omissions in a previously-published version..." isn't nearly good enough. And, even then, I'd rather see "...updated list if, for example, ...". In other words, if they can publish an updated list at all (which is clearly the direction in which things are headed), they (i) are not required to do so, regardless of the circumstances, unless they conclude it would be useful and (ii) are permitted to do so under any circumstances that seem wise to them, whether either of the two example conditions occur. That also "fixes" the padding statement, since it says "should contain" and SHOULD leaves the Nomcom room to pad if it concludes that the best interests of the community would be served in that specific case by padding. To give one such example, a Nomcom might have a legitimate interest in understanding how the community would compare the strengths and weaknesses of a particular nominee to those of a hypothetical nominee who was not willing or able to serve. john From spencer@wonderhamster.org Mon May 11 10:16:36 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 1C72D3A6829 for ; Mon, 11 May 2009 10:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.379, 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 bpF5I2JU7yQI for ; Mon, 11 May 2009 10:16:35 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 0DA503A672F for ; Mon, 11 May 2009 10:16:34 -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-1M3Z8O1LAa-000fh3; Mon, 11 May 2009 13:17:53 -0400 Message-ID: <9BBC14519736472A9EC5EE38F062AC7B@china.huawei.com> From: "Spencer Dawkins" To: "John C Klensin" , "Robert Elz" , "SM" References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6CE505A3C8C9BCAF9EAFD54B@PST.JCK.COM> Date: Mon, 11 May 2009 12:17:34 -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: V01U2FsdGVkX18IIoBqUZcJtD6BzedAqbwSICwmN8HDLZbCoHf KAypmRATnRmUJDG7NDm4exmEuoBnu1ztEXwcisolYsiaF80xwh PoZ9+8luDeE+bQ/uvxfagNywnW8VKDmURlS36EVjEk= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 11 May 2009 17:16:36 -0000 Hi, John, Keeping in mind that I was asked to do a small 3777 revision ... ... RFC 3777 doesn't use the 2119 terminology boilerplate, but DOES use (lowercased) "must", "should", and "may" throughout the current text. I'm hoping that current practice in interpreting these terms would be sufficient for a small 3777 revision, and I'm thinking I'd be overreaching to include an explanation of NomCom process-as-guidance in a small 3777 revision. I do agree with the notion that we should prefer guidance to rules - I'm just not sure that can happen in finite time, and the timeframe that was shared with me was a desire for this year's NomCom to be able to ask "the other half of the community" for input (since we seem to ask about half the community for input now, based on the IETF 74 show of hands at plenary). Adding "for example", as you suggested, is obviously the right thing to do, of course. Thanks for feedback, as always. Spencer > Spencer, > > FWIW, my personal recommendation is that you make it very clear > --much more clear than it is now -- that "may" (and even > "should") in these various sentences has move or less the 2119 > meaning, i.e., that the community is giving the Nomcom general > guidance, but that the Nomcom is free to do what it thinks > necessary and/or desirable and that it is not obligated to > explain its reasoning to the community if it doesn't follow the > guidance. > > Without that, "...The NomCom may publish an updated list if the > NomCom identifies errors/omissions in a previously-published > version..." isn't nearly good enough. And, even then, I'd > rather see "...updated list if, for example, ...". In other > words, if they can publish an updated list at all (which is > clearly the direction in which things are headed), they (i) are > not required to do so, regardless of the circumstances, unless > they conclude it would be useful and (ii) are permitted to do so > under any circumstances that seem wise to them, whether either > of the two example conditions occur. > > That also "fixes" the padding statement, since it says "should > contain" and SHOULD leaves the Nomcom room to pad if it > concludes that the best interests of the community would be > served in that specific case by padding. To give one such > example, a Nomcom might have a legitimate interest in > understanding how the community would compare the strengths and > weaknesses of a particular nominee to those of a hypothetical > nominee who was not willing or able to serve. > > john From narten@us.ibm.com Tue May 12 07:16:08 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 64B963A6CF1 for ; Tue, 12 May 2009 07:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 zMmedqYxnfz3 for ; Tue, 12 May 2009 07:16:07 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 3C4CB3A6784 for ; Tue, 12 May 2009 07:15:40 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4CEFH7c013494 for ; Tue, 12 May 2009 08:15:17 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4CEGt8F056676 for ; Tue, 12 May 2009 08:16:58 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4CEGsSI031427 for ; Tue, 12 May 2009 08:16:54 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-48-43-84.mts.ibm.com [9.48.43.84]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4CEGosp031245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2009 08:16:53 -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 n4CEGnw5022309; Tue, 12 May 2009 10:16:49 -0400 Message-Id: <200905121416.n4CEGnw5022309@cichlid.raleigh.ibm.com> To: "Spencer Dawkins" In-reply-to: <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com><72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local><499F3A1A.7020205@thinkingcat.com><51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net><874B0EA5B7474E40BC4771582E20F135@china.huawei.com><4A01FF14.1000802@joelhalpern.com><68203580453A41F9BE4A8E17676A40DD@china.huawei.com><52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com><675982CA-8EED-470C-888D-DB876816D256@cisco.com><5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com><4A02DD01.3040009@joelhalpern.com><93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com><11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3d80@resistor.net> ! <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> Comments: In-reply-to "Spencer Dawkins" message dated "Mon, 11 May 2009 10:47:19 -0500." Date: Tue, 12 May 2009 10:16:49 -0400 From: Thomas Narten Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 12 May 2009 14:16:08 -0000 I'd still really like to see more context about what the intention here is, rather than just listing rules. How about something like: The list of nominees willing to serve in positions under review in the current NomCom cycle is not confidential. The NomCom should publish a list of names of willing nominees to the community, in order to obtain feedback from the community on these nominees. 1st paragraph is same as proposed, but then drop the second paragraph and continue with paragraph 3 (unchanged): The list of nominees published for a specific position should contain only the names of nominees who are willing to serve in the position under review. For paragraph 4, I've added some text at the end (in CAPS for clarity): Feedback on willing nominees should always be provided privately to NomCom. Willing nominees should not solicit support, and other IETF community members should not post statements of support/non-support for nominees IN ANY PUBLIC FORA (E.G., MAILING LIST) Then add: Discussion: Prior to this document, the names of willing nominees was considered confidential and not disclosed publically. The community has long had differing views on this rule. Many have argued that the lack of a published list made it difficult for the community to provide adequate feedback to the nomcom. Others have argued that publishing such a list could lead to campaigning and other undesireable behaviors. The intention of relaxing this rule is to have the nomcom publish a list of willing candidates so that the community has the ability to provide feedback on those being considered for service. However, the nomcom is also chartered to find the best candidate for any particular position. Even after an initial list of willing nominees has been compiled, the nomcom is expected to continue to actively recruit additional nominees, especially in cases where the nominee pool is deemed insufficient. While the nomcom is encouraged to publish all names when it can, it is not required to do so in cases that could interfere with its ability to find the best candidate, e.g., where a nominee is not willing to have their name published, or where a nominee is found relatively late in the process, etc. Thoughts? Thomas From erosen@cisco.com Tue May 12 07:36: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 D44093A6A8C for ; Tue, 12 May 2009 07:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 1CCbEHWB0IzP for ; Tue, 12 May 2009 07:36:09 -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 B724E3A6E3E for ; Tue, 12 May 2009 07:36:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,182,1241395200"; d="scan'208";a="44002778" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 May 2009 14:37:38 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4CEbcls015354; Tue, 12 May 2009 10:37:38 -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.13.8) with ESMTP id n4CEbci6023140; Tue, 12 May 2009 14:37:38 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 n4CEbct8011515; Tue, 12 May 2009 10:37:38 -0400 To: Thomas Narten In-reply-to: Your message of Tue, 12 May 2009 10:16:49 -0400. <200905121416.n4CEGnw5022309@cichlid.raleigh.ibm.com> Date: Tue, 12 May 2009 10:37:38 -0400 Message-ID: <11514.1242139058@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1038; t=1242139058; x=1243003058; c=relaxed/simple; s=rtpdkim1001; 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]=20announcing=20list=20of= 20willing=20candidates=20 |Sender:=20 |To:=20Thomas=20Narten=20; bh=SIHQt/xy3DskxBqU5ROd+FKaTz89UVyAtqnlOhNH47I=; b=ZL4/GHShHEVAVVl8kpWwIfqppQ5Xt95Bl7fPXLmxa7vy1tGCNU2ItXx9Uz Kf94nTgPoU70DbO8HuDMEkpUZSjUrj0SG05KhnIZcfH3HooYcxyQV5N2QVfA SlYajDk6vn; Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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: Tue, 12 May 2009 14:36:09 -0000 > Willing nominees should not solicit support Are you under the impression that this does not happen today? Maybe the rule should be "willing nominees should pretend publicly that they are not soliciting support". > While the nomcom is encouraged to publish all names when it can, it is not > required to do so in cases that could interfere with its ability to find > the best candidate, e.g., where a nominee is not willing to have their > name published, or where a nominee is found relatively late in the > process, etc. You could drive a truck through this loophole. Either the nomcom is required to maintain a publicly accessible list of willing candidates (and only willing candidates) for each position, or else it isn't. It makes no sense at all to say that the nomcom is required to maintain the list except when it doesn't want to do so. Either adopt the rule or not. Let's not go through the pretense of adopting the rule while allowing loopholes that amount to maintaining the status quo. From narten@us.ibm.com Tue May 12 07:43: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 E4B633A6E08 for ; Tue, 12 May 2009 07:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-1.350, 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 Mu-lGPi34l6P for ; Tue, 12 May 2009 07:43:41 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 0D5283A6DE1 for ; Tue, 12 May 2009 07:43:40 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e9.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4CEXjqD006758 for ; Tue, 12 May 2009 10:33:45 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4CEj8nN113678 for ; Tue, 12 May 2009 10:45:08 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4CEj7L4003174 for ; Tue, 12 May 2009 10:45:07 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-48-43-84.mts.ibm.com [9.48.43.84]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4CEj6Wj002977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2009 10:45:07 -0400 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 n4CEj57Q030336; Tue, 12 May 2009 10:45:05 -0400 Message-Id: <200905121445.n4CEj57Q030336@cichlid.raleigh.ibm.com> To: erosen@cisco.com In-reply-to: <11514.1242139058@erosen-linux> References: <11514.1242139058@erosen-linux> Comments: In-reply-to Eric Rosen message dated "Tue, 12 May 2009 10:37:38 -0400." Date: Tue, 12 May 2009 10:45:05 -0400 From: Thomas Narten Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 12 May 2009 14:43:42 -0000 Eric Rosen writes: > > Willing nominees should not solicit support > Are you under the impression that this does not happen today? Maybe the > rule should be "willing nominees should pretend publicly that they are not > soliciting support". Actually, this text comes from earlier. Personally, I think we may be going too far in saying one should not solicit support. That is pretty extreme. And it may even be OK to say "I've thrown my hat into the ring, please send comments to the nomcom". Or some such. But it is also not necessary. The whole point of publishing a list is making it easy for folk to see that you have thrown your name into the ring.... But there is a slippery slope here. And I think we do not want discussion of individual candidates to ever take place on public mailing lists. So some sort of guidance is needed. (We should't try to regulate what goes on in private, however, as enforcement is tricky) > > While the nomcom is encouraged to publish all names when it can, it is not > > required to do so in cases that could interfere with its ability to find > > the best candidate, e.g., where a nominee is not willing to have their > > name published, or where a nominee is found relatively late in the > > process, etc. > You could drive a truck through this loophole. Yep. If a nomcom is hellbent on ignoring any SHOULD type rule, it can do so. But the fix to that is not to make iron-clan MUST rules, since the bigger problem is that the nomcom is out of control and is not acting in accordance with the communities wishes. > Either the nomcom is required to maintain a publicly accessible list of > willing candidates (and only willing candidates) for each position, or else > it isn't. It makes no sense at all to say that the nomcom is required to > maintain the list except when it doesn't want to do so. > Either adopt the rule or not. Let's not go through the pretense of adopting > the rule while allowing loopholes that amount to maintaining the status quo. The difficulty really isn't with publishing "an initial list", but what happens if/when the nomcom wants to add a name for consideration late in the process. Thomas From spencer@wonderhamster.org Tue May 12 08:14: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 679D03A6E5B for ; Tue, 12 May 2009 08:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.057 X-Spam-Level: X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[AWL=-1.893, BAYES_40=-0.185, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] 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 JyQgF72VRNWB for ; Tue, 12 May 2009 08:14:56 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 883223A6E21 for ; Tue, 12 May 2009 08:14:56 -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-1M3tiR3dfV-000d7Y; Tue, 12 May 2009 11:16:27 -0400 Message-ID: <62C2037A68C444388B329B23AF8D3ABD@china.huawei.com> From: "Spencer Dawkins" To: , "Thomas Narten" References: <11514.1242139058@erosen-linux> <200905121445.n4CEj57Q030336@cichlid.raleigh.ibm.com> Date: Tue, 12 May 2009 10:16:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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/RxCa/U5FaCVaDvvH5t4YUMV/xjDpxczCd20L rMcYakU5jTk4AgkQgGaYQRvzOU7D3k4Z2RjD5p4LBoXW1962ES 8X+8U2zw7GugvsRw90wOCA0Ouj38TD0CQ9AKX32DBg= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 12 May 2009 15:14:57 -0000 For what it's worth... >> > Willing nominees should not solicit support > >> Are you under the impression that this does not happen today? Maybe >> the >> rule should be "willing nominees should pretend publicly that they are >> not >> soliciting support". > > Actually, this text comes from earlier. Personally, I think we may be > going too far in saying one should not solicit support. That is pretty > extreme. And it may even be OK to say "I've thrown my hat into the > ring, please send comments to the nomcom". Or some such. But it is > also not necessary. The whole point of publishing a list is making it > easy for folk to see that you have thrown your name into the ring.... Yes, that's what I was thinking when I wrote the text - I could have written text that allowed this, but i couldn't see a reason that this should be necessary. > But there is a slippery slope here. And I think we do not want > discussion of individual candidates to ever take place on public > mailing lists. So some sort of guidance is needed. (We should't try to > regulate what goes on in private, however, as enforcement is tricky) I'm looking at http://www.ietf.org/proceedings/09mar/plenaryw.html, which says "Russ asks who believes that we need to do anything that describes what is acceptable nominee behaviour. many hums Russ asks who doesn't believe this is necessary? a few more hums" I was perfectly OK with not including guidance about this (and letting people who think the NomCom can be campaigned successfully knock themselves out), but that's not the feedback Russ got at plenary. Thanks, Spencer >> > While the nomcom is encouraged to publish all names when it can, it is >> > not >> > required to do so in cases that could interfere with its ability to >> > find >> > the best candidate, e.g., where a nominee is not willing to have their >> > name published, or where a nominee is found relatively late in the >> > process, etc. > >> You could drive a truck through this loophole. > > Yep. If a nomcom is hellbent on ignoring any SHOULD type rule, it can > do so. But the fix to that is not to make iron-clan MUST rules, since > the bigger problem is that the nomcom is out of control and is not > acting in accordance with the communities wishes. > >> Either the nomcom is required to maintain a publicly accessible list of >> willing candidates (and only willing candidates) for each position, or >> else >> it isn't. It makes no sense at all to say that the nomcom is required to >> maintain the list except when it doesn't want to do so. > >> Either adopt the rule or not. Let's not go through the pretense of >> adopting >> the rule while allowing loopholes that amount to maintaining the status >> quo. > > The difficulty really isn't with publishing "an initial list", but > what happens if/when the nomcom wants to add a name for consideration > late in the process. > > Thomas From russ@cisco.com Mon May 11 08:54: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 C82783A6CA7 for ; Mon, 11 May 2009 08:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 6ImE+drMhMQB for ; Mon, 11 May 2009 08:54:11 -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 85CA03A67E1 for ; Mon, 11 May 2009 08:54:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,328,1238976000"; d="scan'208";a="43904033" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 May 2009 15:55:41 +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 n4BFtfR6032683; Mon, 11 May 2009 11:55:41 -0400 Received: from [127.0.0.1] (rtp-vpn2-990.cisco.com [10.82.243.222]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4BFtf3R019405; Mon, 11 May 2009 15:55:41 GMT Message-ID: <4A084A77.8080800@cisco.com> Date: Mon, 11 May 2009 11:55:35 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Spencer Dawkins References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com><499F3A1A.7020205@thinkingcat.com><51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net><874B0EA5B7474E40BC4771582E20F135@china.huawei.com><4A01FF14.1000802@joelhalpern.com><68203580453A41F9BE4A8E17676A40DD@china.huawei.com><52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com><675982CA-8EED-470C-888D-DB876816D256@cisco.com><5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com><4A02DD01.3040009@joelhalpern.com><93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com><11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> In-Reply-To: <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2374; t=1242057341; x=1242921341; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=russ@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[ietf-nomcom]=20announcing=20list=20of= 20willing=20candidates |Sender:=20 |To:=20Spencer=20Dawkins=20; bh=d4garbWDWMKUaiX6ezEmPnzElKt6FFfbDoBa8zDeUgY=; b=Yp1IKecyUBE/sBvid0nUALNMWz5xS1WYOM6EJmgaO39krf0Bb0x9zCN4kJ DRi49AkHkpuuOFwPTLFnlOT+1Bx0oSLu36Jd8GVrf3XpDIoO0z0l2KEpLoqr Sr1PODpcob; Authentication-Results: rtp-dkim-2; header.From=russ@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Mailman-Approved-At: Tue, 12 May 2009 08:24:52 -0700 Cc: NomComDiscussion , Robert Elz Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 11 May 2009 15:54:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This wording looks good, covering the cases well. :-) Russ Spencer Dawkins wrote: > I'd like to thank several people for pointing out the additional > constraints that were included in text I'd published previously. > > At this point, it's looking like the draft should say "may publish a > list of willing nominees in order to get community feedback". I'm making > that change. > > I'm not feeling good about allowing "padding", based on discussions > we've had on this mailing list, so I'll defer text changes in that > direction. > > The normative changes being proposed to RFC 3777 are as follows: > > > The list of nominees willing to serve in positions under review > in the current NomCom cycle is not confidential. > The NomCom may publish a list of names of willing nominees to the > community, > in order to obtain feedback from the community on these nominees. > > > The NomCom may publish an updated list if the NomCom identifies > errors/omissions > in a previously-published version of the public list, or if the NomCom > finds > it necessary to call for additional nominees, and these nominees indicate > a willingness to serve in time to be considered by the NomCom. > > > > The list of nominees published for a specific position > should contain only the names of > nominees who are willing to serve in the position under review. > > > > Feedback on willing nominees should always be provided privately to > NomCom. > Willing nominees > should not solicit support, and other IETF community members should > not post statements of support/non-support for nominees, > > > > > > Comments are, as always, graciously accepted. > > Thanks, > > Spencer > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoISncACgkQER27sUhU9OSNgwCfc7jHcCHy05bmd1BHvMDBxBPr a0YAoOW8T2fbqzktjQNPxzz/2NRwSyRj =TDKg -----END PGP SIGNATURE----- From john@jck.com Tue May 12 10:32: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 1CE103A6E77 for ; Tue, 12 May 2009 10:32:23 -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 ydpNNhdSZynl for ; Tue, 12 May 2009 10:32:22 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id DE8703A6EA8 for ; Tue, 12 May 2009 10:32:21 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1M3vrP-000J58-9L; Tue, 12 May 2009 13:33:47 -0400 Date: Tue, 12 May 2009 13:33:46 -0400 From: John C Klensin To: Thomas Narten , Spencer Dawkins Message-ID: In-Reply-To: <200905121416.n4CEGnw5022309@cichlid.raleigh.ibm.com> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3d80@resistor.net> ! <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <200905121416.n4CEGnw5022309@cichlid.raleigh.ibm.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] announcing list of willing candidates 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, 12 May 2009 17:32:23 -0000 --On Tuesday, May 12, 2009 10:16 -0400 Thomas Narten wrote: > I'd still really like to see more context about what the > intention here is, rather than just listing rules. How about > something like: > > The list of nominees willing to serve in positions under > review in the current NomCom cycle is not confidential. > The NomCom should publish a list of names of willing > nominees to the community, in order to obtain feedback > from the community on these nominees. >... > Thoughts? This (including all of the material I elided on the assumption that people have read your original note) works for me. I think there are at least three important considerations in the Nomcom model and your text manages to be consistent with all of them. None of these are new, but perhaps it is useful to draw them together. (i) This is a recruitment and selection system, not an election. If one is looking for analogies, better ones are found in job applications and recruitment than in elections and votes. (ii) The Nomcom must have whatever discretion is necessary to do its job well, supplemented as needed by general guidance about what the community expects. Doing the job well has to be the priority, not rule-following. We have enough experience with other IETF bodies to know that if it somehow abuses that discretion, more rules will not help. There is no value in trying to either precisely defined rules or to discussions about how discretion can be abused: a Nomcom that is focused in the job and its responsibilities to the community won't be a problem and one that intends to be a problem will ignore the rules, no matter how precise. (iii) The failure case for a Nomcom is appointing a bad nominee. Whether that is a "no other choices" situation or a "we couldn't find anyone else, even after seeking out individuals and asking them to serve" one, or something else, the harm that can result from an inappropriate appointment is far worse than asking a I* body to deal with being short-handed and/or having to reorganize itself. Given the confidentiality rules, we will never know whether the relevant Nomcoms who made bad choices felt that they had no choice or just didn't have enough information. But, given that we demonstrably don't have a workable recall procedure and that requests from within bodies for some members to resign apparently rarely work (or are rarely attempted), all of the selections a Nomcom makes need to be good ones. john From spencer@wonderhamster.org Tue May 12 10:47: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 E71463A6C31 for ; Tue, 12 May 2009 10:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.418, 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 B3bSsKtF3dMr for ; Tue, 12 May 2009 10:47:33 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id E36503A6F80 for ; Tue, 12 May 2009 10:47:32 -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-1M3w6244WD-000d5h; Tue, 12 May 2009 13:48:58 -0400 Message-ID: From: "Spencer Dawkins" To: "John C Klensin" , "Thomas Narten" References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3d80@resistor.net> ! <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <200905121416.n4CEGnw5022309@cichlid.raleigh.ibm.com> Date: Tue, 12 May 2009 12:48:43 -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+OKO9Zv8OXN3ZNKaONH3Jy7eZvVgbYc58R1GK 586RhiA0ZOAeho932I87qlqL9AEC1GbhhOwMNEesdJndACg0GU KmFJn2qu65Cu0UYHmYKdlhnXy1Uusog6GrXlPRkr8g= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 12 May 2009 17:47:34 -0000 Replying to John's e-mail, but I read Thomas's as well... I don't disagree with anything either of you said. My concern is that we're talking about Section 3, bullet 6, which defines confidentiality, and the text Thomas provided describes some fairly fundamental things about NomCom operation, including "actively recruiting additional nominees", that aren't part of RFC 3777 today. I am wondering if this material needs to be part of a small revision to Section 3, bullet 6, or if it should go into (for example) an Informational statement of NomCom principles (such as the excellent "don't pick a nominee just because you can't find anyone else who's willing to serve"), that could be discussed and advanced separately. Opinions are, of course welcomed. Thanks, Spencer > --On Tuesday, May 12, 2009 10:16 -0400 Thomas Narten > wrote: > >> I'd still really like to see more context about what the >> intention here is, rather than just listing rules. How about >> something like: >> >> The list of nominees willing to serve in positions under >> review in the current NomCom cycle is not confidential. >> The NomCom should publish a list of names of willing >> nominees to the community, in order to obtain feedback >> from the community on these nominees. >>... >> Thoughts? > > This (including all of the material I elided on the assumption > that people have read your original note) works for me. > > I think there are at least three important considerations in the > Nomcom model and your text manages to be consistent with all of > them. None of these are new, but perhaps it is useful to draw > them together. > > (i) This is a recruitment and selection system, not an election. > If one is looking for analogies, better ones are found in job > applications and recruitment than in elections and votes. > > (ii) The Nomcom must have whatever discretion is necessary to do > its job well, supplemented as needed by general guidance about > what the community expects. Doing the job well has to be the > priority, not rule-following. We have enough experience with > other IETF bodies to know that if it somehow abuses that > discretion, more rules will not help. There is no value in > trying to either precisely defined rules or to discussions about > how discretion can be abused: a Nomcom that is focused in the > job and its responsibilities to the community won't be a problem > and one that intends to be a problem will ignore the rules, no > matter how precise. > > (iii) The failure case for a Nomcom is appointing a bad nominee. > Whether that is a "no other choices" situation or a "we couldn't > find anyone else, even after seeking out individuals and asking > them to serve" one, or something else, the harm that can result > from an inappropriate appointment is far worse than asking a I* > body to deal with being short-handed and/or having to reorganize > itself. Given the confidentiality rules, we will never know > whether the relevant Nomcoms who made bad choices felt that they > had no choice or just didn't have enough information. But, > given that we demonstrably don't have a workable recall > procedure and that requests from within bodies for some members > to resign apparently rarely work (or are rarely attempted), all > of the selections a Nomcom makes need to be good ones. > > john > > From sm@resistor.net Tue May 12 13:11: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 1C64C3A69FF for ; Tue, 12 May 2009 13:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 hR1JoNfLUuRm for ; Tue, 12 May 2009 13:11:35 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id BC4913A6964 for ; Tue, 12 May 2009 13:11:35 -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 n4CKCr14013515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2009 13:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1242159184; x=1242245584; bh=Tt/5exYHWUZEFXI/6Lgf6RQVd8EStSVwbFzd159sQFE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=tfWdCMm/G7Q2GNx33N+QqKNR1xpE6k4xasQw3f4EeBKfDAPZOIlw2BuZDEO0xaFfU hTBeDkt5D3Iuk+yJ65q70qIkWQeqlUTTIwq1Aj61FBibcQQZzFHQXYB8wPAk1uXL3o 0EdbfqcKkN5q+HwCFW9ohCcE9lcWyoYHQwSKnqns= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=BOwxhDuH4g7+JyT5oLQUWpz8HhEYajzBEejvn7y2WQLNQM+VMLh9BvC5fRc9GLtC+ JQp7wwkMPyZH/IXLleTjqQnZJh/UnAeedvAB4tdt0Nhqqo2CZCjggX3NUhVS+NCKx4L LKNRls258+xuzs+so3Xa015nEboeXyfR+sB04aQ= Message-Id: <6.2.5.6.2.20090512111353.03369dd0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 12 May 2009 12:56:45 -0700 To: Spencer Dawkins , Thomas Narten From: SM In-Reply-To: <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 12 May 2009 20:11:37 -0000 At 08:47 11-05-2009, Spencer Dawkins wrote: >At this point, it's looking like the draft should say "may publish a >list of willing nominees in order to get community feedback". I'm >making that change. In RFC 3777, we have the rules, interpretation of the rules, and discretion. I'll comment on Thomas' message. At 10:17 11-05-2009, Spencer Dawkins wrote: >... RFC 3777 doesn't use the 2119 terminology boilerplate, but DOES >use (lowercased) "must", "should", and "may" throughout the current >text. I'm hoping that current practice in interpreting these terms >would be sufficient for a small 3777 revision, and I'm Let's not get 2119 terminology into this. >thinking I'd be overreaching to include an explanation of NomCom >process-as-guidance in a small 3777 revision. Agreed. At 07:16 12-05-2009, Thomas Narten wrote: >I'd still really like to see more context about what the intention >here is, rather than just listing rules. How about something like: > > The list of nominees willing to serve in positions under review > in the current NomCom cycle is not confidential. The NomCom should > publish a list of names of willing nominees to the community, in > order to obtain feedback from the community on these nominees. I suggest something along the lines of: All deliberations and supporting information that relates to specific nominees, candidates, and confirmed candidates are confidential. The nominating committee retains the discretion to disclose the names of the nominees and the positions in which they are willing to serve to obtain feedback from the community on these nominees. I used "names" instead of "list" so that NomCom can publish a partial list of nominees. Although I did not suggest a time frame for publication, I gather that NomCom will need to have guidelines for that and it will also depend on the circumstances. But it's up to NomCom to draw that up instead of having text in the draft. I didn't mention "padding". The discussion within the IETF Community might influence NomCom to stop that practice. >For paragraph 4, I've added some text at the end (in CAPS for clarity): > > Feedback on willing nominees should always be provided privately > to NomCom. Willing nominees should not solicit support, and > other IETF community members should not post statements of > support/non-support for nominees IN ANY PUBLIC FORA (E.G., > MAILING LIST) Do we really need to say that the feedback should be provided privately? I have not seen any nominees publicly soliciting support or participants posting statements of support. I gather that it's due to the "culture" of the IETF where it is understood that such behavior will be viewed as unacceptable. Once we start saying the community "should not do", we'll have everything else as acceptable. I don't think that's a good idea. >Then add: > > Discussion: Prior to this document, the names of willing nominees > was considered confidential and not disclosed publically. The > community has long had differing views on this rule. Many have > argued that the lack of a published list made it difficult for > the community to provide adequate feedback to the nomcom. Others > have argued that publishing such a list could lead to campaigning > and other undesireable behaviors. > > The intention of relaxing this rule is to have the nomcom publish > a list of willing candidates so that the community has the > ability to provide feedback on those being considered for > service. However, the nomcom is also chartered to find the best > candidate for any particular position. Even after an initial list > of willing nominees has been compiled, the nomcom is expected to > continue to actively recruit additional nominees, especially in > cases where the nominee pool is deemed insufficient. While the > nomcom is encouraged to publish all names when it can, it is not > required to do so in cases that could interfere with its ability > to find the best candidate, e.g., where a nominee is not willing > to have their name published, or where a nominee is found > relatively late in the process, etc. Having that as a discussion is fine. It gives an idea of the intent for the change. BTW, why is there emphasis on "willing"? Nomcom requires feedback on all nominees, whether they are willing to serve or not. If you use "willing" in the above, NomCom has less leeway for recruitment. At 07:45 12-05-2009, Thomas Narten wrote: >But there is a slippery slope here. And I think we do not want >discussion of individual candidates to ever take place on public >mailing lists. So some sort of guidance is needed. (We should't try to >regulate what goes on in private, however, as enforcement is tricky) And how would it be enforced if it's done publicly? I don't expect a answer to the question as it may be better to leave some things unsaid. :-) At 10:48 12-05-2009, Spencer Dawkins wrote: >I am wondering if this material needs to be part of a small revision >to Section 3, bullet 6, or if it should go into (for example) an >Informational statement of NomCom principles (such as the excellent >"don't pick a nominee just because you can't find anyone else who's >willing to serve"), that could be discussed and advanced separately. I prefer to have any guidance in a separate Informational document. Then it cannot be read as telling NomCom how it should do its work. Regards, -sm From narten@us.ibm.com Sun May 17 12:52: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 8468228C23E for ; Sun, 17 May 2009 12:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=0.343, 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 E4rWArwYntTM for ; Sun, 17 May 2009 12:52:55 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 86E5128B23E for ; Sun, 17 May 2009 12:52:55 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4HJqe70029105 for ; Sun, 17 May 2009 13:52:40 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4HJsU38225922 for ; Sun, 17 May 2009 13:54:30 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4HJsUGr028418 for ; Sun, 17 May 2009 13:54:30 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-76-131-135.mts.ibm.com [9.76.131.135]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4HJsTwh028408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 May 2009 13:54:30 -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 n4HJsSxL013390; Sun, 17 May 2009 15:54:28 -0400 Message-Id: <200905171954.n4HJsSxL013390@cichlid.raleigh.ibm.com> To: "Spencer Dawkins" In-reply-to: References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3d80@resistor.net> ! <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <200905121416.n4CEGnw5022309@cichlid.raleigh.ibm.com> Comments: In-reply-to "Spencer Dawkins" message dated "Tue, 12 May 2009 12:48:43 -0500." Date: Sun, 17 May 2009 15:54:28 -0400 From: Thomas Narten Cc: John C Klensin , NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 17 May 2009 19:52:56 -0000 "Spencer Dawkins" writes: > Replying to John's e-mail, but I read Thomas's as well... > I don't disagree with anything either of you said. My concern is that we're > talking about Section 3, bullet 6, which defines confidentiality, and the > text Thomas provided describes some fairly fundamental things about NomCom > operation, including "actively recruiting additional nominees", that aren't > part of RFC 3777 today. Right. Not written down, but IMO, consistent with what was originally intended and what the practice has been. That said, I'd hate to get caught up in "we shouldn't put in that text for process reasons", when it it really helps clarify the guidance being given. My assumption is that at some point, we will need to revised 3777, and we would at that pull in all relevant updates. We could at that point spread out the text to all the appropriate sections of 3777bis. > I am wondering if this material needs to be part of a small revision to > Section 3, bullet 6, or if it should go into (for example) an Informational > statement of NomCom principles (such as the excellent "don't pick a nominee > just because you can't find anyone else who's willing to serve"), that could > be discussed and advanced separately. I do not like the idea of having "principles" and other important context in a separate document that is informational. Principles are most definitely normative, and IMO, we'd be better off generally if the principles were written down clearly. Thomas From narten@us.ibm.com Sun May 17 12:53:08 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 3293528C24C for ; Sun, 17 May 2009 12:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.294 X-Spam-Level: X-Spam-Status: No, score=-6.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 N8L7gearWSiv for ; Sun, 17 May 2009 12:53:02 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id AD8FD28C1B7 for ; Sun, 17 May 2009 12:53:02 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4HJoaj0022646 for ; Sun, 17 May 2009 15:50:36 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4HJsZXq232740 for ; Sun, 17 May 2009 15:54:37 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4HJsZ91022375 for ; Sun, 17 May 2009 15:54:35 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-76-131-135.mts.ibm.com [9.76.131.135]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4HJsXR4022355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 May 2009 15:54:34 -0400 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 n4HJsW2W013397; Sun, 17 May 2009 15:54:32 -0400 Message-Id: <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> To: SM In-reply-to: <6.2.5.6.2.20090512111353.03369dd0@resistor.net> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> Comments: In-reply-to SM message dated "Tue, 12 May 2009 12:56:45 -0700." Date: Sun, 17 May 2009 15:54:32 -0400 From: Thomas Narten Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 17 May 2009 19:53:08 -0000 SM writes: > At 07:16 12-05-2009, Thomas Narten wrote: > >I'd still really like to see more context about what the intention > >here is, rather than just listing rules. How about something like: > > > > The list of nominees willing to serve in positions under review > > in the current NomCom cycle is not confidential. The NomCom should > > publish a list of names of willing nominees to the community, in > > order to obtain feedback from the community on these nominees. > I suggest something along the lines of: > All deliberations and supporting information that relates to specific > nominees, candidates, and confirmed candidates are confidential. > The nominating committee retains the discretion to disclose the names > of the nominees and the positions in which they are willing to serve to > obtain feedback from the community on these nominees. I think this text is better in some ways, but saying "retains the discretion to disclose names" does not capture the WG intent, which is clearly a "SHOULD publish the names". If every other nomcom decides (based on the inclinations of each year's particular nomcom) decide not to publish a list at all, I suspect the community would not be happy. > I used "names" instead of "list" so that NomCom can publish a partial > list of nominees. Although I did not suggest a time frame for > publication, I gather that NomCom will need to have guidelines for > that and it will also depend on the circumstances. But it's up to > NomCom to draw that up instead of having text in the draft. I didn't > mention "padding". The discussion within the IETF Community might > influence NomCom to stop that practice. Generally, I do prefer that the operational details of what to post be left to the nomcom. > >For paragraph 4, I've added some text at the end (in CAPS for clarity): > > > > Feedback on willing nominees should always be provided privately > > to NomCom. Willing nominees should not solicit support, and > > other IETF community members should not post statements of > > support/non-support for nominees IN ANY PUBLIC FORA (E.G., > > MAILING LIST) > Do we really need to say that the feedback should be provided > privately? Yes. If there is no text saying discussions on the IETF list are not appropriate, somebody will end up doing it, claiming it is perfectly OK to do so. > I have not seen any nominees publicly soliciting support > or participants posting statements of support. In the past we viewed the list of nominees to be confidential and solicting support would have been frowned upon. By loosening up the rules, we would presumably also be loosening up the expectations in other areas to. > I gather that it's due to the "culture" of the IETF where it is > understood that such behavior will be viewed as unacceptable. Once > we start saying the community "should not do", we'll have everything > else as acceptable. I don't think that's a good idea. You seem to be saying that if we say in a document "you should not do X", that somehow implies anything "not X" implicitely becomes allowed. I don't see how that follows. Moreover, the implications of such reasoning would surely complicate all our documents, that weren't written with such an assumption > >Then add: > > > > Discussion: Prior to this document, the names of willing nominees > > was considered confidential and not disclosed publically. The > > community has long had differing views on this rule. Many have > > argued that the lack of a published list made it difficult for > > the community to provide adequate feedback to the nomcom. Others > > have argued that publishing such a list could lead to campaigning > > and other undesireable behaviors. > > > > The intention of relaxing this rule is to have the nomcom publish > > a list of willing candidates so that the community has the > > ability to provide feedback on those being considered for > > service. However, the nomcom is also chartered to find the best > > candidate for any particular position. Even after an initial list > > of willing nominees has been compiled, the nomcom is expected to > > continue to actively recruit additional nominees, especially in > > cases where the nominee pool is deemed insufficient. While the > > nomcom is encouraged to publish all names when it can, it is not > > required to do so in cases that could interfere with its ability > > to find the best candidate, e.g., where a nominee is not willing > > to have their name published, or where a nominee is found > > relatively late in the process, etc. > Having that as a discussion is fine. It gives an idea of the intent > for the change. BTW, why is there emphasis on "willing"? "Willing" comes from earlier text, and indicates the person is "willing to serve", and by implication, is not a ringer. > Nomcom requires feedback on all nominees, whether they are willing > to serve or not. If you use "willing" in the above, NomCom has less > leeway for recruitment. Seems like the nomcom (and the community) should not spend much time on nominees that are not willing to serve... > At 07:45 12-05-2009, Thomas Narten wrote: > >But there is a slippery slope here. And I think we do not want > >discussion of individual candidates to ever take place on public > >mailing lists. So some sort of guidance is needed. (We should't try to > >regulate what goes on in private, however, as enforcement is tricky) > And how would it be enforced if it's done publicly? I don't expect a > answer to the question as it may be better to leave some things > unsaid. :-) Public shaming. If it does, I'd expect the community to say "stop doing this" and point to the document for justification. > At 10:48 12-05-2009, Spencer Dawkins wrote: > >I am wondering if this material needs to be part of a small revision > >to Section 3, bullet 6, or if it should go into (for example) an > >Informational statement of NomCom principles (such as the excellent > >"don't pick a nominee just because you can't find anyone else who's > >willing to serve"), that could be discussed and advanced separately. > I prefer to have any guidance in a separate Informational document. > Then it cannot be read as telling NomCom how it should do its work. As said in another post, the guidance we give should be normative. Otherwise, why bother giving it? Thomas From john-ietf@jck.com Sun May 17 13:41: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 40F8628C0EB for ; Sun, 17 May 2009 13:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 ncrtJ2io2WYj for ; Sun, 17 May 2009 13:41:57 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id CFAC03A68F5 for ; Sun, 17 May 2009 13:41:56 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1M5nCe-000Jok-Pp; Sun, 17 May 2009 16:43:25 -0400 Date: Sun, 17 May 2009 16:43:23 -0400 From: John C Klensin To: Thomas Narten , SM Message-ID: <8D4D03EE457311B3CD40992F@PST.JCK.COM> In-Reply-To: <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.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] announcing list of willing candidates 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, 17 May 2009 20:41:58 -0000 --On Sunday, May 17, 2009 15:54 -0400 Thomas Narten wrote: >... >> I suggest something along the lines of: > >> All deliberations and supporting information that relates >> to specific nominees, candidates, and confirmed candidates >> are confidential. The nominating committee retains the >> discretion to disclose the names of the nominees and the >> positions in which they are willing to serve to obtain >> feedback from the community on these nominees. > > I think this text is better in some ways, but saying "retains > the discretion to disclose names" does not capture the WG > intent, which is clearly a "SHOULD publish the names". Which "WG intent" did you have in mind here? I don't seem to see any active WG, nor a consensus and published charter, nor... That said, I believe that the general sense of things is to make the default to publish but to give the Nomcom wide discretion to avoid publishing some or all names and to do so without having to explain its reasons to the community (since doing so would almost certainly disclose confidential candidate or comparative information). I still fear that default will make things worse and narrow the choice of possible nominees, but I do think it is the trend of the discussions. >... >> Do we really need to say that the feedback should be provided >> privately? > > Yes. If there is no text saying discussions on the IETF list > are not appropriate, somebody will end up doing it, claiming > it is perfectly OK to do so. Sadly, I agree. >... > "Willing" comes from earlier text, and indicates the person is > "willing to serve", and by implication, is not a ringer. While I agree with the "not a ringer" part, I am not sure that what you are reading as "willing to serve" really means anything more than "willing to have name considered". Volunteering to have one's name considered is rather different from guaranteeing that, if one is selected, one will serve (and be able to serve). Over the years, different Nomcoms have given possible nominees different advice about how certain they need to be about availability and willingness to serve. And, of course, at least some Nomcoms have asked people permission before using their names as ringers. So the line might be a little more vague than the discussion above and earlier would imply (and, incidentally, in an unstable market environment, the longer we stretch the Nomcom process out, the harder it will become to make those distinctions). >> Nomcom requires feedback on all nominees, whether they are >> willing to serve or not. If you use "willing" in the above, >> NomCom has less leeway for recruitment. > > Seems like the nomcom (and the community) should not spend > much time on nominees that are not willing to serve... How about a nominee who would be willing to serve given resources (which might be very uncertain) and under some set of conditions that might or might not be made explicit to the Nomcom? Again, while I appreciate the distinction you are making, I don't see the boundary as being nearly as clear as "willing" versus "not willing". Let me try an example to illustrate that this is not just theoretical. Suppose someone gave the IASA a large grant whose purpose was to guarantee travel and related expense costs for any person selected to the IESG or IAB who did not have employer support for those activities. Suppose the IAOC decided to accept that grant (while I hope they would extensively consult the community before doing so, I don't believe their recent interpretations of BCP 101 would require them to do that). I suggest that decision would immediately and dramatically change the "willing to serve" equation. Now, if someone were "willing to serve" iff such a miracle occurred, how much do you think he or she should be considered? >> I prefer to have any guidance in a separate Informational >> document. Then it cannot be read as telling NomCom how it >> should do its work. > > As said in another post, the guidance we give should be > normative. Otherwise, why bother giving it? Because we can reasonably expect the Nomcom to take advice and guidance from the community. If they don't or won't, we have bigger problems than what a document says, whether it is formally "normative" or not. I fear, instead, that having too many formally normative statements around will either overconstrain the Nomcom's ability to apply discretion or become an avenue for appeals against Nomcom procedures and decisions -- appeals that could cause the IETF public embarrassment and entangle us for a very long time. Remember that, although some of us have trouble figuring out why, some individuals or their companies really _want_ those positions. john From sm@resistor.net Sun May 17 23:22:05 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 58CAF28C21C for ; Sun, 17 May 2009 23:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 DTVHiXmDhKOS for ; Sun, 17 May 2009 23:22:04 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 315893A6F71 for ; Sun, 17 May 2009 23:22:04 -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 n4I6NO81017168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 May 2009 23:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1242627815; x=1242714215; bh=eMKz3z0bm8CBcpZzwWhpmHJvmx7sEuHsG5jrjY8Yvvc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=IcjC4/sNk5sQO5iEbgVs8Z3GKRyTOwvVbhZlkKdFswMVBRseckVHF6ZF0M8aqjYo3 +hGEqmYD7L5rNwFDPAl02gu7gUDnyxuvmsZ9a24qdbHkkNxIRu5wr7HNj5OtDjqGQP 8JW3y+ol9zb1pJ/R41LrbrU0UU3HszwRZdMuH5Rg= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=JoidCdztBafpmtZcsNSdpRyQEbXJJ3GMAyVYTt28vAJf6uorZ9f9FY2fxsPAiiVea 5ZOckCrh6hc/PZfmLzOnX0ew1oOwTVoQ7ZeUrNe5y3efplCC8gbYlVUIj0hRZ7MvgvL qhRePKByOhEihuyjHpN3liOPfkMuL3WMU5dlFSc= Message-Id: <6.2.5.6.2.20090517204631.03545390@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 17 May 2009 23:19:10 -0700 To: Thomas Narten From: SM In-Reply-To: <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 18 May 2009 06:22:05 -0000 Hi Thomas, At 12:54 17-05-2009, Thomas Narten wrote: >I think this text is better in some ways, but saying "retains the >discretion to disclose names" does not capture the WG intent, which is >clearly a "SHOULD publish the names". RFC 3777 sets the rules that apply to the process. It does not use key words to indicate requirement levels. The WG is asking for change which is viewed as minimal without looking at the bigger picture. Let's review the question. Should the names be published? After all, it's an open secret as it is sent to all WG chairs. Most people would answer yes to that question. >If every other nomcom decides (based on the inclinations of each >year's particular nomcom) decide not to publish a list at all, I >suspect the community would not be happy. NomCom seeks to be representative of the community (this note is for some of the people who have been posting on this thread. I could not come up with a better wording to explain it). If the intent of the IETF community is to have the names published and NomCom does not have that intent, then there is a disconnect somewhere. NomCom is not there to make the community happy. It is there to judge the technical, people and process management skills of the nominee. >Yes. If there is no text saying discussions on the IETF list are not >appropriate, somebody will end up doing it, claiming it is perfectly >OK to do so. The community should use its powers of persuasion so that the discussions do not take place on the IETF list. :-) >In the past we viewed the list of nominees to be confidential and >solicting support would have been frowned upon. By loosening up the >rules, we would presumably also be loosening up the expectations in >other areas to. NomCom can shape the expectations when it solicits feedback. >You seem to be saying that if we say in a document "you should not do >X", that somehow implies anything "not X" implicitely becomes >allowed. I don't see how that follows. Moreover, the implications of >such reasoning would surely complicate all our documents, that weren't >written with such an assumption It's a cultural thing. In some cultures, everything not expressly allowed is forbidden. In others, everything not expressly forbidden is allowed. How does that is pertinent to this discussion? Our documents generally don't try to regulate social behavior. This one does. Every now and then I come across a (non-IETF) discussion about requirement levels in a RFC and interpretation of the text. The arguments are at odds with the assumptions of the author of the document. From a social perspective, that can also happen in the IETF of today as it is not cohesive due to its size and the involvement of participants. >"Willing" comes from earlier text, and indicates the person is >"willing to serve", and by implication, is not a ringer. John commented on this. >Seems like the nomcom (and the community) should not spend much time >on nominees that are not willing to serve... Rectification, it's the community that does not want to waste its time on ringers; NomCom already has access to the willing list. :-) >Public shaming. If it does, I'd expect the community to say "stop >doing this" and point to the document for justification. This is a case where the community could explain why it is a "bad idea" instead of pointing to some requirement in a document for justification. You could oppose my suggestion by pointing to one of the fundamentals of the IETF process. :-) >As said in another post, the guidance we give should be >normative. Otherwise, why bother giving it? You can coerce people with a stick. Or you can appeal to their better judgement. In the IETF, the latter is like herding cats. Regards, -sm From narten@us.ibm.com Mon May 18 06:09: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 CEDC73A6C42 for ; Mon, 18 May 2009 06:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.929 X-Spam-Level: X-Spam-Status: No, score=-5.929 tagged_above=-999 required=5 tests=[AWL=0.670, 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 Cm+TgtIS6Aq7 for ; Mon, 18 May 2009 06:09:36 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 63BA53A6A63 for ; Mon, 18 May 2009 06:09:36 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4ICoUnF009979 for ; Mon, 18 May 2009 06:50:30 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4ICrDNc222538 for ; Mon, 18 May 2009 06:53:13 -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 n4ICrDJj013217 for ; Mon, 18 May 2009 06:53:13 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-49-159-236.mts.ibm.com [9.49.159.236]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4ICrBmd013168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 May 2009 06:53:13 -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 n4ICr8v3032718; Mon, 18 May 2009 08:53:08 -0400 Message-Id: <200905181253.n4ICr8v3032718@cichlid.raleigh.ibm.com> To: John C Klensin In-reply-to: <8D4D03EE457311B3CD40992F@PST.JCK.COM> References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! ! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> <8D4D03EE457311B3CD40992F@PST.JCK.COM> Comments: In-reply-to John C Klensin message dated "Sun, 17 May 2009 16:43:23 -0400." Date: Mon, 18 May 2009 08:53:08 -0400 From: Thomas Narten Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 18 May 2009 13:09:37 -0000 > > I think this text is better in some ways, but saying "retains > > the discretion to disclose names" does not capture the WG > > intent, which is clearly a "SHOULD publish the names". > Which "WG intent" did you have in mind here? I don't seem to > see any active WG, nor a consensus and published charter, nor... Sorry, loose language. There is no WG, obviously. But the various hums and discussions indicate to me that the community wants the list of nominees published. As in "should be published" rather than "has the discretion to publish". > That said, I believe that the general sense of things is to make > the default to publish but to give the Nomcom wide discretion to > avoid publishing some or all names and to do so without having > to explain its reasons to the community (since doing so would > almost certainly disclose confidential candidate or comparative > information). I still fear that default will make things worse > and narrow the choice of possible nominees, but I do think it is > the trend of the discussions. Agreed. > >... > >> Do we really need to say that the feedback should be provided > >> privately? > > > > Yes. If there is no text saying discussions on the IETF list > > are not appropriate, somebody will end up doing it, claiming > > it is perfectly OK to do so. > Sadly, I agree. > > >... > > "Willing" comes from earlier text, and indicates the person is > > "willing to serve", and by implication, is not a ringer. > While I agree with the "not a ringer" part, I am not sure that > what you are reading as "willing to serve" really means anything > more than "willing to have name considered". Volunteering to > have one's name considered is rather different from guaranteeing > that, if one is selected, one will serve (and be able to serve). > Over the years, different Nomcoms have given possible nominees > different advice about how certain they need to be about > availability and willingness to serve. And, of course, at least > some Nomcoms have asked people permission before using their > names as ringers. So the line might be a little more vague than > the discussion above and earlier would imply (and, incidentally, > in an unstable market environment, the longer we stretch the > Nomcom process out, the harder it will become to make those > distinctions). Agreed. > >> Nomcom requires feedback on all nominees, whether they are > >> willing to serve or not. If you use "willing" in the above, > >> NomCom has less leeway for recruitment. > > > > Seems like the nomcom (and the community) should not spend > > much time on nominees that are not willing to serve... > How about a nominee who would be willing to serve given > resources (which might be very uncertain) and under some set of > conditions that might or might not be made explicit to the > Nomcom? Again, while I appreciate the distinction you are > making, I don't see the boundary as being nearly as clear as > "willing" versus "not willing". OK. Then perhaps the wording needs to be more explicit about which names should be published and which not. At a minimum, we should say "no ringers". But if the nomcom is required to get permission from the nominee before publishing their name, I suspect we won't be satisfying what I assume many in the community are calling for. > Let me try an example to illustrate that this is not just > theoretical. Suppose someone gave the IASA a large grant whose > purpose was to guarantee travel and related expense costs for > any person selected to the IESG or IAB who did not have employer > support for those activities. Suppose the IAOC decided to > accept that grant (while I hope they would extensively consult > the community before doing so, I don't believe their recent > interpretations of BCP 101 would require them to do that). I > suggest that decision would immediately and dramatically change > the "willing to serve" equation. Now, if someone were "willing > to serve" iff such a miracle occurred, how much do you think he > or she should be considered? > > >> I prefer to have any guidance in a separate Informational > >> document. Then it cannot be read as telling NomCom how it > >> should do its work. > > > > As said in another post, the guidance we give should be > > normative. Otherwise, why bother giving it? > Because we can reasonably expect the Nomcom to take advice and > guidance from the community. If they don't or won't, we have > bigger problems than what a document says, whether it is > formally > "normative" or not. I fear, instead, that having too many > formally normative statements around will either overconstrain > the Nomcom's ability to apply discretion or become an avenue for > appeals against Nomcom procedures and decisions -- appeals that > could cause the IETF public embarrassment and entangle us for a > very long time. Remember that, although some of us have > trouble figuring out why, some individuals or their companies > really _want_ those positions. While I agree at one level, I also have the opposite concern. Namely, that some folk will argue since the guidance text is informational, it is not normative and hence can be ignored. Seems we can't win either way. :-( And again, I agree that we should not overconstrain the nomcom through too many rules. What I want to see though is a clear articulation of the principles, so that they can be applied to whatever situation the nomcom finds itself in. Those principles need to be normative, or by defintion some will argue they don't *really* apply. Thomas From jmh@joelhalpern.com Mon May 18 07:09: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 0B25D3A6A3D for ; Mon, 18 May 2009 07:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 0U+mV29DsjKK for ; Mon, 18 May 2009 07:09:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 570283A6824 for ; Mon, 18 May 2009 07:09:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 85E474303B2; Mon, 18 May 2009 07:10:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-141.clppva.btas.verizon.net [71.161.52.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id D7044430380; Mon, 18 May 2009 07:10:58 -0700 (PDT) Message-ID: <4A116C71.2000406@joelhalpern.com> Date: Mon, 18 May 2009 10:10:57 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: SM References: <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@epsilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> <6.2.5.6.2.20090517204631.03545390@resistor.net> In-Reply-To: <6.2.5.6.2.20090517204631.03545390@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 18 May 2009 14:09:24 -0000 You note below that the wording is not precise. I think it is important because the question of what the nomcom "is" can cause confusion and dissension. The nomcom selection process is designed to be "inclusive". It can not be "representative", since there are a lot more than 10 variations in the community. The nomcom is charged with acting in the best interest of the community, not with "representing" the community. The nomcom acts on behalf of the community, with understanding of the desires of the community. But I think injecting the word "represent" is asking for confusion. Yours, Joel M. Halpern SM wrote: ... > NomCom seeks to be representative of the community (this note is for > some of the people who have been posting on this thread. I could not > come up with a better wording to explain it). If the intent of the IETF > community is to have the names published and NomCom does not have that > intent, then there is a disconnect somewhere. NomCom is not there to > make the community happy. It is there to judge the technical, people > and process management skills of the nominee. ... From spencer@wonderhamster.org Mon May 18 08:26:38 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 E96D63A691E for ; Mon, 18 May 2009 08:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_50=0.001, 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 ZZkFB33XI6m2 for ; Mon, 18 May 2009 08:26:38 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 1F2D13A68D8 for ; Mon, 18 May 2009 08:26:38 -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-1M64ku45HL-000cg4; Mon, 18 May 2009 11:28:01 -0400 Message-ID: <716CFDC12AB24BAFB202DB62E3BEE0FA@china.huawei.com> From: "Spencer Dawkins" To: "John C Klensin" , "Thomas Narten" , "SM" References: <8D4D03EE457311B3CD40992F@PST.JCK.COM> Date: Mon, 18 May 2009 10:27:42 -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/TjaQgPuqvPnBKSgDgG0YwDQXZGg8/c8dmgV8 zmqivnGJHtCxtRfCCyWUraN6RKw27Z5B7UXOUZ1umnYJsNG7+Z Kl4urd2wqe+qFW3kxGNddio+xyAsqCE/swn+mpqONI= Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 18 May 2009 15:26:39 -0000 Hi, John, >> "Willing" comes from earlier text, and indicates the person is >> "willing to serve", and by implication, is not a ringer. > > While I agree with the "not a ringer" part, I am not sure that > what you are reading as "willing to serve" really means anything > more than "willing to have name considered". Volunteering to > have one's name considered is rather different from guaranteeing > that, if one is selected, one will serve (and be able to serve). > Over the years, different Nomcoms have given possible nominees > different advice about how certain they need to be about > availability and willingness to serve. And, of course, at least > some Nomcoms have asked people permission before using their > names as ringers. So the line might be a little more vague than > the discussion above and earlier would imply (and, incidentally, > in an unstable market environment, the longer we stretch the > Nomcom process out, the harder it will become to make those > distinctions). I believe that s/willing/willing to be considered/g is a useful distinction. I'll include this in the next draft revision. The point of the previous text was "do NOT include the people who have already told you 'no way' ...". The wording I chose was broader than that. Sorry, and thanks for the comment. Spencer From kre@munnari.OZ.AU Mon May 18 09:12:17 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 C496B3A6CC8 for ; Mon, 18 May 2009 09:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.893 X-Spam-Level: X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 2Ss7n6ZfSeqZ for ; Mon, 18 May 2009 09:12:11 -0700 (PDT) Received: from jade.coe.psu.ac.th (unknown [202.28.99.196]) by core3.amsl.com (Postfix) with ESMTP id A368F3A6AFC for ; Mon, 18 May 2009 09:12:10 -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 n4IGBvSD000055; Mon, 18 May 2009 23:11:57 +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 n4IGBDdZ001806; Mon, 18 May 2009 23:11:41 +0700 (ICT) From: Robert Elz To: SM In-Reply-To: <6.2.5.6.2.20090517204631.03545390@resistor.net> References: <6.2.5.6.2.20090517204631.03545390@resistor.net> <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@e! psilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 May 2009 23:11:13 +0700 Message-ID: <1490.1242663073@epsilon.noi.kre.to> Sender: kre@munnari.OZ.AU Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 18 May 2009 16:12:17 -0000 Date: Sun, 17 May 2009 23:19:10 -0700 From: SM Message-ID: <6.2.5.6.2.20090517204631.03545390@resistor.net> | Should the names be published? | After all, it's an open secret as it is sent to all WG chairs. This is where I disagree with (what has been, I believe, recently at least) the current process - the list shouldn't have ever been sent to the WG chairs (not as such). Or to anyone else. If that wasn't done, there wouldn't be nearly as much of an "open secret" and that argument for publishing the list would not exist - that is, the supporters of that position wouldn't be able to just say "it happens anyway, let's recognise that and formalise it" but would instead need to produce arguments as to why things would work better this way. Before responding (anyone) - please rest assured, my aim is not to deprive the nomcom of the opportunity of obtaining input, I know the nomcom needs to seek advice, as given the way the nomcom is selected there's no way to expect that the nomcom members will have any particular knowledge of any of the nominees, let alone all of them. The way I'd like things to work is ... Everything up through the call for nominations just like happens now (or no changes relevant to this discussion) - with the knowledge that the call never actually ends. Nomcom contacts all names put forward with its questionnaire, with the most important question being the willingness to serve ... I would never ask the nominee why they should be selected though, but rather just concentrate on facts (what they've been doing in the IETF community, and experience in other bodies, etc.) But that's not important. Armed with the initial list of nominees, the nomcom examines each one, and for each, produces a list of three or four (or so) names of IETF people who ought to be aware of the nominees work - WG chairs, other draft authors in the same WG, ... ideally keeping those lists as disjoint as possible (ie: pick different people for each nominee, as much as possible.) Those lists are coalesced, so there's a list of people to contact, and for each, a list of the nominees that person is to be asked about (ideally just one name in most cases, two or three perhaps in a few). Those people (probably a hundred or so of them max) then get asked if they're willing to be sent confidential nomcom info, and will keep it confidential, and send in opinions of nominees. Where they reply in the affirmative, they're sent the list that was generated for them and asked for comments. When the nomcom gets the replies, they should be able to be characterised into one of 4 general groups - "good", "indifferent", "bad" and "don't know". The occasional "don't know" gets ignored - but many of those replies for a nominee doesn't mean the nomcom needs to ask more people, it means the nominee is not well known, which almost certainly means is not yet ready for a leadership position (at the nomcom appointment level anyway). Aside from those, all good or a mixture of good/indifferent replies probably means the nomcom is worth considering (one would hope the replies will be more that one word, to give the nomcom a better idea why the response is the way it is.) All bad, or indifferent/bad most likely implies the nominee should be dropped. All indifferent would move the nominee to "only if there's no other choice". A mixture of bad/good (with or without indifferent as well) probably means that the nominee might be divisive, and probably isn't a good choice. Only where the nomcom really finds itself list because of the responses it receives should it really need to consult more than those initial 4 or so referees - the aim is not to discover the IETF's opinion, but to educate the nomcom as to the qualities of each nominee - too much input generally just means greater levels of uncertainty. Finally, the nomcom should NEVER ask a referee (by which I mean someone the nomcom has selected to ask questions of) to rank nominees, or "which of A B C would make the better X?" or anything like that - that's the nomcom's job to evaluate, not the referee's. The referee should just be asked to comment upon a particular nominees's ability to do the job, in isolation of all other possible nominees. By all means ask for the names of other people the referee thinks could do the job better - that's part of the continuous process of enlarging the nominee pool. If the referee suggests people who were already nominees (ideally, without that being known by the referee), then the committee has gained free information. If some new name is suggested, that should be treated just like any other nomination and acceptance of that person sought, etc. | >If every other nomcom decides (based on the inclinations of each | >year's particular nomcom) decide not to publish a list at all, I | >suspect the community would not be happy. I was earlier going to reply to Thomas directly, on this point, but since I'm here, and you quoted this ... As I understand it, all this arose because the nomcom chair (past nomcom chair) thought it would be easier for the nomcom if the names could be published - prior to that I wasn't aware of any great community demand for any change in this area. That is, we're not really responding to the community's desire for publication of names, but seeking to discover if the nomcom process can be made better, where this is one potential change. I don't see (at all) that the community would not be happy, should some nomcom decide it had no need to publish nominee names, and so did not. The community have no need to know who the nominees are, there's no election or popularity contest occurring - there's no need for feedback from the community in general, that's not how the nomcom process should be working. | NomCom seeks to be representative of the community (this note is for | some of the people who have been posting on this thread. I could not | come up with a better wording to explain it). I agree with Joel's response to this - selection of the nomcom members is done in a way that it should result in a committee that is roughly representative (in the sense of being a good cross section of the community ... for now, the IETF meeting attending part of the community anyway) but beyond that there's nothing at all representative about the process. | NomCom is | not there to make the community happy. It is there to judge the | technical, people and process management skills of the nominee. This I absolutely agree with, in the sense you intended it I believe. If the nomcom do a good job, it is likely the community will be happy with the results, but producing the best available candidates is the aim, not the ones that most please the community. | It's a cultural thing. In some cultures, everything not expressly | allowed is forbidden. In others, everything not expressly forbidden | is allowed. In this case, I think it may be something in between - if a doc says nothing at all, then neither forbidden nor allowed is necessarily implied - but once a doc starts to set out what is allowed, or what is not allowed, there is a very strong temptation (so strong, it is a principle of legal interpretation, at least in English law) that whatever is written is (by default) the totality of what was intended. That is, the assumption is made that if you have listed 5 allowable activities, then nothing else is allowable, or it would have been listed with the "good 5" - or if you have listed some prohibited activities, then nothing else, except what is listed, is prohibited. This is all possible to avoid, but doing so isn't always as easy as it might seem. | >Seems like the nomcom (and the community) should not spend much time | >on nominees that are not willing to serve... | | Rectification, it's the community that does not want to waste its | time on ringers; NomCom already has access to the willing list. :-) Unfortunately, there's no way to really know. I doubt it has been much of a problem so far, but there's no way to avoid ringers in this sense - the nomcom doesn't really have access to the willing list, just the list of people who said they'd be willing. Which of those would really serve if selected isn't known until later (and the confidential nature of the process means that outside the nomcom, and perhaps the confirming body, no-one else ever knows). That is, if some segment of the community decided that a bunch of ringers would for some weird reason be a good idea, they could all just nominate each other, and say they're willing when first asked, without having any real intention to serve. There's no way I know of, to prevent this (we can't force people to serve when selected, even if they earlier said they would - circumstances change). So, it is absurd to prohibit ringers, that can't be done. What should be being made clear to the nomcom is that it is not required to add ringers in order to meet some perceived confidentially requirement. If the nomcom operated as I outlined above, the whole issue would never arise. The whole concept of ringers appeared because nomcom has grown a tendancy to want to get as much input on every nominee from as many people as possible, which has meant disclosing the entire list of nominees (for at least a particular position) to a comparatively large set of people (so ringers were invented to try and keep the real list secret). IMO, that's not the right way to operate - stop it, stop seeking input from everyone about everyone, and the whole problem goes away (as does any rational need to publish any list of nominees - the practical implications of which, including just when it happens, how often it happens, when names are added or removed from the published list, etc, haven't even begun to be considered.) kre From jmh@joelhalpern.com Mon May 18 09:32:47 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 145E73A68AB for ; Mon, 18 May 2009 09:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 TAFtx1A0t8lh for ; Mon, 18 May 2009 09:32:40 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1F7E528C30D for ; Mon, 18 May 2009 09:32:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 622C14303CF for ; Mon, 18 May 2009 09:34:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-141.clppva.btas.verizon.net [71.161.52.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 5BD4B4303DF for ; Mon, 18 May 2009 09:34:13 -0700 (PDT) Message-ID: <4A118E03.9090009@joelhalpern.com> Date: Mon, 18 May 2009 12:34:11 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NomComDiscussion References: <6.2.5.6.2.20090517204631.03545390@resistor.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@e! psilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> <1490.1242663073@epsilon.noi.kre.to> In-Reply-To: <1490.1242663073@epsilon.noi.kre.to> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 18 May 2009 16:32:47 -0000 I believe that the process Robert suggests, while much better than no input, would not give the nomcom the input it desires. While I have comments on other aspects below a portion of Robert's note, I am responding to the primary suggestion here. If the nomcom were to select a small number of people to provide input on each nominee, there would be several likely failure modes. For areas where the nomcom was light on expertise, the nomcom would have to rely on the known leadership. THe goal is to get broader input than just from the leadership. For many of our most active people, there are communities of people who react differently to them. It is important to hear from those folks, so as to know there is an issue. (Evaluating that in more detail is the nomcom's job, and not by counting members of each "constituency.") But it is quite easy if you pick a few people to miss such facts Even for folks who are not as controversial, it is often useful to get input from outside of their natural interaction group. One finds out things about folks from how they work with other folks. But often the nomcom is in no position to know who to ask. (In many ways one of the most interesting aspects of any nominee for the IAB or IESG is how they work with other areas or activities outside of their center of competence and activity.) Letting the community see the list allows community members who have information know that it may be useful to the nomcom. Hiding the list does not seem to achieve anything of value to the nomcom, has significant drawbacks for the community, and has, as far as I can tell, only narrow advantages even for the community. .... Robert Elz wrote: > Date: Sun, 17 May 2009 23:19:10 -0700 > From: SM > Message-ID: <6.2.5.6.2.20090517204631.03545390@resistor.net> > > | Should the names be published? > | After all, it's an open secret as it is sent to all WG chairs. > > This is where I disagree with (what has been, I believe, recently at > least) the current process - the list shouldn't have ever been sent to > the WG chairs (not as such). Or to anyone else. > > If that wasn't done, there wouldn't be nearly as much of an "open secret" > and that argument for publishing the list would not exist - that is, the > supporters of that position wouldn't be able to just say "it happens > anyway, let's recognise that and formalise it" but would instead need > to produce arguments as to why things would work better this way. > > Before responding (anyone) - please rest assured, my aim is not to > deprive the nomcom of the opportunity of obtaining input, I know the > nomcom needs to seek advice, as given the way the nomcom is selected > there's no way to expect that the nomcom members will have any particular > knowledge of any of the nominees, let alone all of them. > > The way I'd like things to work is ... > > Everything up through the call for nominations just like happens now (or > no changes relevant to this discussion) - with the knowledge that the call > never actually ends. > > Nomcom contacts all names put forward with its questionnaire, with the > most important question being the willingness to serve ... I would never > ask the nominee why they should be selected though, but rather just > concentrate on facts (what they've been doing in the IETF community, and > experience in other bodies, etc.) But that's not important. > > Armed with the initial list of nominees, the nomcom examines each one, > and for each, produces a list of three or four (or so) names of IETF people > who ought to be aware of the nominees work - WG chairs, other draft authors in > the same WG, ... ideally keeping those lists as disjoint as possible > (ie: pick different people for each nominee, as much as possible.) > > Those lists are coalesced, so there's a list of people to contact, and > for each, a list of the nominees that person is to be asked about (ideally > just one name in most cases, two or three perhaps in a few). > > Those people (probably a hundred or so of them max) then get asked if they're > willing to be sent confidential nomcom info, and will keep it confidential, > and send in opinions of nominees. Where they reply in the affirmative, > they're sent the list that was generated for them and asked for comments. > > When the nomcom gets the replies, they should be able to be characterised > into one of 4 general groups - "good", "indifferent", "bad" and "don't know". > The occasional "don't know" gets ignored - but many of those replies for > a nominee doesn't mean the nomcom needs to ask more people, it means the > nominee is not well known, which almost certainly means is not yet ready > for a leadership position (at the nomcom appointment level anyway). > > Aside from those, all good or a mixture of good/indifferent replies > probably means the nomcom is worth considering (one would hope the replies > will be more that one word, to give the nomcom a better idea why the > response is the way it is.) All bad, or indifferent/bad most likely > implies the nominee should be dropped. All indifferent would move the > nominee to "only if there's no other choice". A mixture of bad/good > (with or without indifferent as well) probably means that the nominee > might be divisive, and probably isn't a good choice. > > Only where the nomcom really finds itself list because of the responses > it receives should it really need to consult more than those initial > 4 or so referees - the aim is not to discover the IETF's opinion, but > to educate the nomcom as to the qualities of each nominee - too much > input generally just means greater levels of uncertainty. > > Finally, the nomcom should NEVER ask a referee (by which I mean someone > the nomcom has selected to ask questions of) to rank nominees, or > "which of A B C would make the better X?" or anything like that - that's > the nomcom's job to evaluate, not the referee's. The referee should > just be asked to comment upon a particular nominees's ability to do the > job, in isolation of all other possible nominees. > > By all means ask for the names of other people the referee thinks could > do the job better - that's part of the continuous process of enlarging > the nominee pool. If the referee suggests people who were already > nominees (ideally, without that being known by the referee), then the > committee has gained free information. If some new name is suggested, > that should be treated just like any other nomination and acceptance of > that person sought, etc. --------- > > | >If every other nomcom decides (based on the inclinations of each > | >year's particular nomcom) decide not to publish a list at all, I > | >suspect the community would not be happy. > > I was earlier going to reply to Thomas directly, on this point, but > since I'm here, and you quoted this ... As I understand it, all this > arose because the nomcom chair (past nomcom chair) thought it would be > easier for the nomcom if the names could be published - prior to that > I wasn't aware of any great community demand for any change in this area. Allow me to slightly clarify. I, and quite a few other people, have been asking for this change for years. I was a vocal advocate for this change when I was participating in the actual working group many years ago. What struck me as nomcom chair was that it was a more important change than I had thought. Many members of this years committee pushed me very hard to just use a fully disclosed list. Also note that this item was on the list reported by the "previous chairs" before I was ever even appointed chair. While I can not claim this change represents the rough consensus of the community, it has been asked for by a wide range of people, including general IETF members, leaders, nomcom members and leaders, ... This was not about "ease". While the committee members did a lot of work, and I commend them for it, my pushing this is not to reduce the work. It is to create a modification that is both more effective, in giving the input that is needed, and more honest, in not pretending to provide confidentiality that it does not provide. It should be noted that even when the disclosure list was a lot smaller than it is now, the feedback disclosure system leaked. So asking a hundred people to keep something confidential is not likely to work, even if I liked the idea. Yours, Joel M. Halpern From bernie@ietf.hoeneisen.ch Mon May 18 10:03:47 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 0701228C0F8 for ; Mon, 18 May 2009 10:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 lykzV5E9C+Sy for ; Mon, 18 May 2009 10:03:45 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 69CE93A6A73 for ; Mon, 18 May 2009 10:03:45 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1M66H6-0002ll-9N; Mon, 18 May 2009 19:05:16 +0200 Date: Mon, 18 May 2009 19:05:16 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "Joel M. Halpern" In-Reply-To: <4A118E03.9090009@joelhalpern.com> Message-ID: References: <6.2.5.6.2.20090517204631.03545390@resistor.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@e! psilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> <1490.1242663073@epsilon.noi.kre.to> <4A118E03.9090009@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: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 18 May 2009 17:03:47 -0000 I fully agree with Joel. cheers, Bernie On Mon, 18 May 2009, Joel M. Halpern wrote: > I believe that the process Robert suggests, while much better than no input, > would not give the nomcom the input it desires. > > While I have comments on other aspects below a portion of Robert's note, I am > responding to the primary suggestion here. > > If the nomcom were to select a small number of people to provide input on > each nominee, there would be several likely failure modes. > For areas where the nomcom was light on expertise, the nomcom would have to > rely on the known leadership. THe goal is to get broader input than just > from the leadership. > For many of our most active people, there are communities of people who react > differently to them. It is important to hear from those folks, so as to know > there is an issue. (Evaluating that in more detail is the nomcom's job, and > not by counting members of each "constituency.") But it is quite easy if you > pick a few people to miss such facts > Even for folks who are not as controversial, it is often useful to get input > from outside of their natural interaction group. One finds out things about > folks from how they work with other folks. But often the nomcom is in no > position to know who to ask. (In many ways one of the most interesting > aspects of any nominee for the IAB or IESG is how they work with other areas > or activities outside of their center of competence and activity.) > > Letting the community see the list allows community members who have > information know that it may be useful to the nomcom. Hiding the list does > not seem to achieve anything of value to the nomcom, has significant > drawbacks for the community, and has, as far as I can tell, only narrow > advantages even for the community. > > .... > > Robert Elz wrote: >> Date: Sun, 17 May 2009 23:19:10 -0700 >> From: SM >> Message-ID: <6.2.5.6.2.20090517204631.03545390@resistor.net> >> >> | Should the names be published? >> | After all, it's an open secret as it is sent to all WG chairs. >> >> This is where I disagree with (what has been, I believe, recently at >> least) the current process - the list shouldn't have ever been sent to >> the WG chairs (not as such). Or to anyone else. >> >> If that wasn't done, there wouldn't be nearly as much of an "open secret" >> and that argument for publishing the list would not exist - that is, the >> supporters of that position wouldn't be able to just say "it happens >> anyway, let's recognise that and formalise it" but would instead need >> to produce arguments as to why things would work better this way. >> >> Before responding (anyone) - please rest assured, my aim is not to >> deprive the nomcom of the opportunity of obtaining input, I know the >> nomcom needs to seek advice, as given the way the nomcom is selected >> there's no way to expect that the nomcom members will have any particular >> knowledge of any of the nominees, let alone all of them. >> >> The way I'd like things to work is ... >> >> Everything up through the call for nominations just like happens now (or >> no changes relevant to this discussion) - with the knowledge that the call >> never actually ends. >> >> Nomcom contacts all names put forward with its questionnaire, with the >> most important question being the willingness to serve ... I would never >> ask the nominee why they should be selected though, but rather just >> concentrate on facts (what they've been doing in the IETF community, and >> experience in other bodies, etc.) But that's not important. >> >> Armed with the initial list of nominees, the nomcom examines each one, >> and for each, produces a list of three or four (or so) names of IETF people >> who ought to be aware of the nominees work - WG chairs, other draft authors >> in >> the same WG, ... ideally keeping those lists as disjoint as possible >> (ie: pick different people for each nominee, as much as possible.) >> >> Those lists are coalesced, so there's a list of people to contact, and >> for each, a list of the nominees that person is to be asked about (ideally >> just one name in most cases, two or three perhaps in a few). >> >> Those people (probably a hundred or so of them max) then get asked if >> they're >> willing to be sent confidential nomcom info, and will keep it confidential, >> and send in opinions of nominees. Where they reply in the affirmative, >> they're sent the list that was generated for them and asked for comments. >> >> When the nomcom gets the replies, they should be able to be characterised >> into one of 4 general groups - "good", "indifferent", "bad" and "don't >> know". >> The occasional "don't know" gets ignored - but many of those replies for >> a nominee doesn't mean the nomcom needs to ask more people, it means the >> nominee is not well known, which almost certainly means is not yet ready >> for a leadership position (at the nomcom appointment level anyway). >> >> Aside from those, all good or a mixture of good/indifferent replies >> probably means the nomcom is worth considering (one would hope the replies >> will be more that one word, to give the nomcom a better idea why the >> response is the way it is.) All bad, or indifferent/bad most likely >> implies the nominee should be dropped. All indifferent would move the >> nominee to "only if there's no other choice". A mixture of bad/good >> (with or without indifferent as well) probably means that the nominee >> might be divisive, and probably isn't a good choice. >> >> Only where the nomcom really finds itself list because of the responses >> it receives should it really need to consult more than those initial >> 4 or so referees - the aim is not to discover the IETF's opinion, but >> to educate the nomcom as to the qualities of each nominee - too much >> input generally just means greater levels of uncertainty. >> >> Finally, the nomcom should NEVER ask a referee (by which I mean someone >> the nomcom has selected to ask questions of) to rank nominees, or >> "which of A B C would make the better X?" or anything like that - that's >> the nomcom's job to evaluate, not the referee's. The referee should >> just be asked to comment upon a particular nominees's ability to do the >> job, in isolation of all other possible nominees. >> >> By all means ask for the names of other people the referee thinks could >> do the job better - that's part of the continuous process of enlarging >> the nominee pool. If the referee suggests people who were already >> nominees (ideally, without that being known by the referee), then the >> committee has gained free information. If some new name is suggested, >> that should be treated just like any other nomination and acceptance of >> that person sought, etc. > --------- >> >> | >If every other nomcom decides (based on the inclinations of each >> | >year's particular nomcom) decide not to publish a list at all, I >> | >suspect the community would not be happy. >> >> I was earlier going to reply to Thomas directly, on this point, but >> since I'm here, and you quoted this ... As I understand it, all this >> arose because the nomcom chair (past nomcom chair) thought it would be >> easier for the nomcom if the names could be published - prior to that >> I wasn't aware of any great community demand for any change in this area. > > Allow me to slightly clarify. > I, and quite a few other people, have been asking for this change for years. > I was a vocal advocate for this change when I was participating in the actual > working group many years ago. What struck me as nomcom chair was that it was > a more important change than I had thought. Many members of this years > committee pushed me very hard to just use a fully disclosed list. Also note > that this item was on the list reported by the "previous chairs" before I was > ever even appointed chair. While I can not claim this change represents the > rough consensus of the community, it has been asked for by a wide range of > people, including general IETF members, leaders, nomcom members and leaders, > ... This was not about "ease". While the committee members did a lot of > work, and I commend them for it, my pushing this is not to reduce the work. > It is to create a modification that is both more effective, in giving the > input that is needed, and more honest, in not pretending to provide > confidentiality that it does not provide. > > It should be noted that even when the disclosure list was a lot smaller than > it is now, the feedback disclosure system leaked. So asking a hundred people > to keep something confidential is not likely to work, even if I liked the > idea. > > Yours, > Joel M. Halpern > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From narten@us.ibm.com Tue May 19 08:56: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 8925C3A6E7B for ; Tue, 19 May 2009 08:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.033 X-Spam-Level: X-Spam-Status: No, score=-5.033 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_20=-0.74, 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 OAHyy6ThHmRf for ; Tue, 19 May 2009 08:56:53 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 272043A6BA6 for ; Tue, 19 May 2009 08:56:53 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4JFmNH6019645 for ; Tue, 19 May 2009 11:48:23 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4JFwRGD184944 for ; Tue, 19 May 2009 11:58:27 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4JFwR4L026465 for ; Tue, 19 May 2009 11:58:27 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-49-159-236.mts.ibm.com [9.49.159.236]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4JFwP2g026423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 May 2009 11:58:26 -0400 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 n4JFwOeM010339; Tue, 19 May 2009 11:58:25 -0400 Message-Id: <200905191558.n4JFwOeM010339@cichlid.raleigh.ibm.com> To: Robert Elz In-reply-to: <1490.1242663073@epsilon.noi.kre.to> References: <6.2.5.6.2.20090517204631.03545390@resistor.net> <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@e!! psilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> <1490.1242663073@epsilon.noi.kre.to> Comments: In-reply-to Robert Elz message dated "Mon, 18 May 2009 23:11:13 +0700." Date: Tue, 19 May 2009 11:58:24 -0400 From: Thomas Narten Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 19 May 2009 15:56:58 -0000 Robert Elz writes: > | >If every other nomcom decides (based on the inclinations of each > | >year's particular nomcom) decide not to publish a list at all, I > | >suspect the community would not be happy. > I was earlier going to reply to Thomas directly, on this point, but > since I'm here, and you quoted this ... As I understand it, all this > arose because the nomcom chair (past nomcom chair) thought it would be > easier for the nomcom if the names could be published - prior to that > I wasn't aware of any great community demand for any change in this area. > That is, we're not really responding to the community's desire for > publication of names, but seeking to discover if the nomcom process can > be made better, where this is one potential change. Well, this is a pretty important point. My sense is that we've had folk calling for publishing the list for quite some time now. Not just from former nomcom people. If this were not the case, I don't think we'd be having this discussion now. And the plenary poll on this point confirmed more support for publishing a list than not. That said, I personally remain opposed to publishing a list. My participation on this topic has been more about getting the wording right, than support for the goal. My concern is that publishing a list will leave the nomcom with fewer choices than it has today. There are people who simply will not be willing to be considered, if their names are published as requirement. This is not because such folk do not have thick skin, but because having it known that one is opposing an incumbant can complicate their relationship with the incumband and/or others. It will be viewed, after all, as a sort of "no confidence" vote w.r.t. the incumbant. IETF participants can have fairly complex relationships with other IETF participants, and having ones names published, can complicate those relationships. For example, if nominee X works for the same employer as an incumbant, agreeing to be considered will certainly complicate the relationship between the two. Moreover, the two employees may well work closely together internally, their professional careers may overlap (one may be a manager for the other, be a necessary reference for promotions, etc.) It may also be viewed negatively (within the company) for one employee to be opposing another publically. Bottom line: it may be a career-complicating, if not limiting, move for someone to publically oppose an incumbant, especially if they are not chosen by the nomcom. Many folk will think twice before doing this. There are many varients to the above theme involving folk working at different companies. Vendor X may be partnering with Vendor Y, and having someone from vendor X publically oppose an incumbent from partner Y could cause problems or complicate the business relationship. Or, an individual may be worried about how they (and their documents) will be treated going forward by the incumbant, if the incumbant is reappointed. The overall point is that someone may well be willing to be considered, but not if this is publically known unless they are chosen. The community may well find itself with fewer willing nominees as a result of having published lists, which is presumably not an intended outcome. Thomas From jmh@joelhalpern.com Tue May 19 09:10: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 1A3703A6FB4 for ; Tue, 19 May 2009 09:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 2ohO3ZhPkS0W for ; Tue, 19 May 2009 09:10:30 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 09F5A3A6948 for ; Tue, 19 May 2009 09:10:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0D48443023A; Tue, 19 May 2009 09:12:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-141.clppva.btas.verizon.net [71.161.52.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id CD2B143022B; Tue, 19 May 2009 09:12:05 -0700 (PDT) Message-ID: <4A12DA53.20903@joelhalpern.com> Date: Tue, 19 May 2009 12:12:03 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Thomas Narten References: <6.2.5.6.2.20090517204631.03545390@resistor.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@e!! psilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> <1490.1242663073@epsilon.noi.kre.to> <200905191558.n4JFwOeM010339@cichlid.raleigh.ibm.com> In-Reply-To: <200905191558.n4JFwOeM010339@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NomComDiscussion , Robert Elz Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 19 May 2009 16:10:31 -0000 The aspect of name publication Thomas raises below is important, but is one where we come to different conclusions. (Comments after the excerpt from his text.) Thomas Narten wrote: ... > My concern is that publishing a list will leave the nomcom with fewer > choices than it has today. There are people who simply will not be > willing to be considered, if their names are published as > requirement. This is not because such folk do not have thick skin, but > because having it known that one is opposing an incumbant can > complicate their relationship with the incumband and/or others. It > will be viewed, after all, as a sort of "no confidence" vote > w.r.t. the incumbant. While you raises several interesting perspectives (retained below), I think that the right way to address this is to change the view. I know of several ADs who explicitly told their advisory boards and chairs "if you are at all willing to serve, please volunteer." They made it quite clear that there would be no objection or consequence for volunteering. I would recommend to a nomcom (if I were not serving on it) that any AD who I learned was likely to take volunteers badly should be seriously considered for replacement, no matter how good a job they are doing. That is not the behavior we want. Similarly, we need to make it clear to the companies supporting folks that there are many factors cosnidered by the nomcom and that they should not consider rejection of an incumbent as a job negative. This is complex because companies often do value those roles, and feel deprived when they are removed. And I have heard of cases where such removals made life harder on people. But we need the nominees. And note that if the nominees are secret, but are going to do the nomcom much good, then any of the cases you outline below may happen anyway when the alternate person is selected. So, while I sympathize with some of the concerns, I think publication of nominees names is the right model. We need to better describe the process / choice model so that folks understand and believe that it is not a negative to be turned down. (And yes, I know that perspective from first hand experience as well.) Yours, Joel M. Halpern > > IETF participants can have fairly complex relationships with other > IETF participants, and having ones names published, can complicate > those relationships. > > For example, if nominee X works for the same employer as an incumbant, > agreeing to be considered will certainly complicate the relationship > between the two. Moreover, the two employees may well work closely > together internally, their professional careers may overlap (one may > be a manager for the other, be a necessary reference for promotions, > etc.) It may also be viewed negatively (within the company) for one > employee to be opposing another publically. Bottom line: it may be a > career-complicating, if not limiting, move for someone to publically > oppose an incumbant, especially if they are not chosen by the > nomcom. Many folk will think twice before doing this. > > There are many varients to the above theme involving folk working at > different companies. Vendor X may be partnering with Vendor Y, and > having someone from vendor X publically oppose an incumbent from > partner Y could cause problems or complicate the business > relationship. > > Or, an individual may be worried about how they (and their documents) > will be treated going forward by the incumbant, if the incumbant is > reappointed. > > The overall point is that someone may well be willing to be > considered, but not if this is publically known unless they are > chosen. The community may well find itself with fewer willing nominees > as a result of having published lists, which is presumably not an > intended outcome. > > Thomas > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From spencer@wonderhamster.org Tue May 19 09:19: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 00A8E3A6A24 for ; Tue, 19 May 2009 09:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 UU1DdV8P5QlK for ; Tue, 19 May 2009 09:19:50 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id D71FC3A6832 for ; Tue, 19 May 2009 09:19:50 -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-1M6S3V2axc-000cip; Tue, 19 May 2009 12:20:46 -0400 Message-ID: From: "Spencer Dawkins" To: "Joel M. Halpern" , "Thomas Narten" References: <6.2.5.6.2.20090517204631.03545390@resistor.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@e!! psilon.noi.kre.to><6.2.5.6.2.20090508212200.031d3!d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> <1490.1242663073@epsilon.noi.kre.to><200905191558.n4JFwOeM010339@cichlid.raleigh.ibm.com> <4A12DA53.20903@ joelhalpern.com> Date: Tue, 19 May 2009 11:20:26 -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: V01U2FsdGVkX18Ij61YGoHuLsc5cTqfnnOYY4B7GQu02czvg5Q vThXOIeus/4Qkkc3cNqMoHEKocn9CTs/WNrHAl23fkIp5Liokw YPrwXjLGNz3uzNlR2nI63rKKAfildV3R+/+RarO85U= Cc: NomComDiscussion , Robert Elz Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 19 May 2009 16:19:52 -0000 Without reference to the conclusions being discussed in this thread, it's worth noting that my current working text for what gets added to 3777 begins with The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential. The NomCom may publish a list of names of nominees who are willing to be considered for positions under review to the community, in order to obtain feedback from the community on these nominees. The text no longer requires NomCom to publish a list (if NomCom doesn't need feedback on the nominees under consideration), and no longer requires publication of a complete list (if NomCom doesn't need feedback on a complete list). Speaking for myself ... I've actually been listening to the meta-discussion about having too many rules that might prevent a NomCom from doing the right thing, so I'm OK with just explicitly giving NomCom the ability to ask for feedback if they need it, without the current shadow-puppet exercise currently practiced. Thanks, Spencer > The aspect of name publication Thomas raises below is important, but is > one where we come to different conclusions. > (Comments after the excerpt from his text.) > > Thomas Narten wrote: > ... >> My concern is that publishing a list will leave the nomcom with fewer >> choices than it has today. There are people who simply will not be >> willing to be considered, if their names are published as >> requirement. This is not because such folk do not have thick skin, but >> because having it known that one is opposing an incumbant can >> complicate their relationship with the incumband and/or others. It >> will be viewed, after all, as a sort of "no confidence" vote >> w.r.t. the incumbant. > > While you raises several interesting perspectives (retained below), I > think that the right way to address this is to change the view. > I know of several ADs who explicitly told their advisory boards and chairs > "if you are at all willing to serve, please volunteer." They made it > quite clear that there would be no objection or consequence for > volunteering. > > I would recommend to a nomcom (if I were not serving on it) that any AD > who I learned was likely to take volunteers badly should be seriously > considered for replacement, no matter how good a job they are doing. That > is not the behavior we want. > > Similarly, we need to make it clear to the companies supporting folks that > there are many factors cosnidered by the nomcom and that they should not > consider rejection of an incumbent as a job negative. This is complex > because companies often do value those roles, and feel deprived when they > are removed. And I have heard of cases where such removals made life > harder on people. But we need the nominees. And note that if the > nominees are secret, but are going to do the nomcom much good, then any of > the cases you outline below may happen anyway when the alternate person is > selected. > > So, while I sympathize with some of the concerns, I think publication of > nominees names is the right model. We need to better describe the process > / choice model so that folks understand and believe that it is not a > negative to be turned down. (And yes, I know that perspective from first > hand experience as well.) > > Yours, > Joel M. Halpern > >> >> IETF participants can have fairly complex relationships with other >> IETF participants, and having ones names published, can complicate >> those relationships. >> >> For example, if nominee X works for the same employer as an incumbant, >> agreeing to be considered will certainly complicate the relationship >> between the two. Moreover, the two employees may well work closely >> together internally, their professional careers may overlap (one may >> be a manager for the other, be a necessary reference for promotions, >> etc.) It may also be viewed negatively (within the company) for one >> employee to be opposing another publically. Bottom line: it may be a >> career-complicating, if not limiting, move for someone to publically >> oppose an incumbant, especially if they are not chosen by the >> nomcom. Many folk will think twice before doing this. >> >> There are many varients to the above theme involving folk working at >> different companies. Vendor X may be partnering with Vendor Y, and >> having someone from vendor X publically oppose an incumbent from >> partner Y could cause problems or complicate the business >> relationship. >> >> Or, an individual may be worried about how they (and their documents) >> will be treated going forward by the incumbant, if the incumbant is >> reappointed. >> >> The overall point is that someone may well be willing to be >> considered, but not if this is publically known unless they are >> chosen. The community may well find itself with fewer willing nominees >> as a result of having published lists, which is presumably not an >> intended outcome. >> >> Thomas >> >> _______________________________________________ >> 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 stbryant@cisco.com Tue May 19 23:30: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 2A9DF28C142 for ; Tue, 19 May 2009 23:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.881 X-Spam-Level: X-Spam-Status: No, score=-7.881 tagged_above=-999 required=5 tests=[AWL=-1.282, 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 x4DE88lLeGPA for ; Tue, 19 May 2009 23:30:17 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 16FF528C157 for ; Tue, 19 May 2009 23:30:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,219,1241395200"; d="scan'208";a="76780285" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-5.cisco.com with ESMTP; 20 May 2009 06:31:53 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4K6Vqcr000489; Wed, 20 May 2009 08:31:52 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4K6Vqra020405; Wed, 20 May 2009 06:31:52 GMT Received: from Stewarts-Computer-2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n4K6VnS17885; Wed, 20 May 2009 07:31:50 +0100 (BST) Message-ID: <4A13A3D5.3060004@cisco.com> Date: Wed, 20 May 2009 07:31:49 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Thomas Narten References: <6.2.5.6.2.20090517204631.03545390@resistor.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@e!! psilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> <1490.1242663073@epsilon.noi.kre.to> <200905191558.n4JFwOeM010339@cichlid.raleigh.ibm.com> In-Reply-To: <200905191558.n4JFwOeM010339@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=738; t=1242801112; x=1243665112; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[ietf-nomcom]=20announcing=20list=20of= 20willing=20candidates |Sender:=20; bh=Y6G5+gXCE4XgNw3+hYZS5nJQDDdf0oQSIihQmgr2u8Q=; b=hnCadS5Q5X2Df63tKVfC+P3rFs1DewhAio3FDfB/vabXjOgNYoRsy+ws25 Ox9QuuXG6M9EC5/L1hUYyuV8ebRcLCUwstri7QGoewdo6nzGACBLV5Vs3WQ6 45lF06Y/P7; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: NomComDiscussion , Robert Elz Subject: Re: [ietf-nomcom] announcing list of willing candidates X-BeenThere: ietf-nomcom@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@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, 20 May 2009 06:30:24 -0000 Thomas > > My concern is that publishing a list will leave the nomcom with fewer > choices than it has today. There are people who simply will not be > willing to be considered, if their names are published as > requirement. This is not because such folk do not have thick skin, but > because having it known that one is opposing an incumbant can > complicate their relationship with the incumband and/or others. It > will be viewed, after all, as a sort of "no confidence" vote > w.r.t. the incumbant. > > In practice, as soon as the Nomcom asks for feedback, one way of another, the incumbent gets to find out who the candidate list. Therefore your concern is one that applies to the current system. Stewart From spencer@wonderhamster.org Mon May 25 06:37:22 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 6FD013A6FB0 for ; Mon, 25 May 2009 06:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_50=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 D1zxv3DNZfhZ for ; Mon, 25 May 2009 06:37:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 0CDBE3A6FBC for ; Mon, 25 May 2009 06:37:18 -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-1M8aO00Qyb-000csr; Mon, 25 May 2009 09:38:41 -0400 Message-ID: From: "Spencer Dawkins" To: "NomComDiscussion" Date: Mon, 25 May 2009 08:38:33 -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: V01U2FsdGVkX19AEm8wYco55+P+2T4cxnoViJOjNHC+tGNPXtm LorxioIFM/tDD3SbiCxutZ4q+4rMlPZmFe19u3MzdGtKZDJHfW VOeqLc1SIAcmKob6wrpdVUUACg4Wu5hQOGbWS90j7Y= Subject: [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: Mon, 25 May 2009 13:37:22 -0000 Just to let people know, I posted an update to -openlist (available at http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-openlist-03.txt). Most of the text changes have previously appeared on the mailing list, but this is another great opportunity to review the draft and send feedback. Please comment to this mailing list, of course. Thanks, Spencer From spencer@wonderhamster.org Mon May 25 06:39: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 B6DFE3A6FC6 for ; Mon, 25 May 2009 06:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.243 X-Spam-Level: X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_20=-0.74] 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 7ZTzLXNmyH4S for ; Mon, 25 May 2009 06:39:18 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id EFD363A6FC0 for ; Mon, 25 May 2009 06:39:17 -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-1M8aPr00u6-000coY; Mon, 25 May 2009 09:40:36 -0400 Message-ID: <1711E17AEFED4BDCA8B609FEA4BB7D63@china.huawei.com> From: "Spencer Dawkins" To: "NomComDiscussion" Date: Mon, 25 May 2009 08:40:28 -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+ERc7iKkDGKnHv2D0w0UqKVMsIY0gRqvrCW2O 7vU/zJKfx5F5/uQhrqkgs5vP0nRx7b5E1FELE3/SKLZNzSYObK kY/7/25GDaYOgFo5sFq7U1H7PDIxkGJfUZXqOVgOqI= Subject: [ietf-nomcom] draft-dawkins-nomcom-dont-wait-02.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: Mon, 25 May 2009 13:39:18 -0000 I've just posted a revision to this draft, available at http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-dont-wait-02.txt. This draft hasn't gotten much additional feedback since -01, so I'm thinking Russ may forward it for publication "soon". This would be a great time to send comments if you have them... Thanks, Spencer From sob@harvard.edu Mon May 25 07:05: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 A099A3A67E6 for ; Mon, 25 May 2009 07:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 W7uuXbM+7-B9 for ; Mon, 25 May 2009 07:04:56 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 5047B3A6B7C for ; Mon, 25 May 2009 07:04:56 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 67D5717658E6; Mon, 25 May 2009 10:06:35 -0400 (EDT) To: spencer@wonderhamster.org In-Reply-To: <1711E17AEFED4BDCA8B609FEA4BB7D63@china.huawei.com> Message-Id: <20090525140635.67D5717658E6@newdev.eecs.harvard.edu> Date: Mon, 25 May 2009 10:06:35 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Cc: ietf-nomcom@ietf.org Subject: Re: [ietf-nomcom] draft-dawkins-nomcom-dont-wait-02.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: Mon, 25 May 2009 14:05:01 -0000 looks ready to go to me Scott ---- From: "Spencer Dawkins" To: "NomComDiscussion" Date: Mon, 25 May 2009 08:40:28 -0500 I've just posted a revision to this draft, available at http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-dont-wait-02.txt. This draft hasn't gotten much additional feedback since -01, so I'm thinking Russ may forward it for publication "soon". This would be a great time to send comments if you have them... Thanks, Spencer From bernie@ietf.hoeneisen.ch Mon May 25 07:14: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 1AE463A6950 for ; Mon, 25 May 2009 07:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 tOtuFrD0iAk2 for ; Mon, 25 May 2009 07:14:21 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 9C6493A6EEE for ; Mon, 25 May 2009 07:14:21 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1M8ay9-0007Q4-8N; Mon, 25 May 2009 16:16:01 +0200 Date: Mon, 25 May 2009 16:16:01 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Spencer Dawkins 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 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: Mon, 25 May 2009 14:14:27 -0000 Hi Spencer Good work! I have spotted one sentence I am not sure whether it should be in the document: However, if the NomCom wishes to request community feedback, it should request feedback from the entire community. I don't see the reason for it (I might have missed sth) and I am affraid that it will constrain to much the NomCom under certain circumstances. Of course, it all depends how strong a "should" is to be interpreted. Could you please shortly explain the background for this? cheers, Bernie On Mon, 25 May 2009, Spencer Dawkins wrote: > Just to let people know, I posted an update to -openlist (available at > http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-openlist-03.txt). > > Most of the text changes have previously appeared on the mailing list, but > this is another great opportunity to review the draft and send feedback. > > Please comment to this mailing list, of course. > > Thanks, > > Spencer > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From bernie@ietf.hoeneisen.ch Mon May 25 07:20: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 B0CC33A6FE5 for ; Mon, 25 May 2009 07:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 hulxzcwl4F0r for ; Mon, 25 May 2009 07:20:20 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id CCC993A6FEC for ; Mon, 25 May 2009 07:20:19 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1M8b3t-0007RE-Ak; Mon, 25 May 2009 16:21:57 +0200 Date: Mon, 25 May 2009 16:21:57 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "Scott O. Bradner" In-Reply-To: <20090525140635.67D5717658E6@newdev.eecs.harvard.edu> Message-ID: References: <20090525140635.67D5717658E6@newdev.eecs.harvard.edu> 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: NomCom Discussion Subject: Re: [ietf-nomcom] draft-dawkins-nomcom-dont-wait-02.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: Mon, 25 May 2009 14:20:20 -0000 Looks good to me too. Good work! cheers, Bernie On Mon, 25 May 2009, Scott O. Bradner wrote: > looks ready to go to me > > Scott > > > ---- > From: "Spencer Dawkins" > To: "NomComDiscussion" > Date: Mon, 25 May 2009 08:40:28 -0500 > > I've just posted a revision to this draft, available at > http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-dont-wait-02.txt. > > This draft hasn't gotten much additional feedback since -01, so I'm thinking > Russ may forward it for publication "soon". This would be a great time to > send comments if you have them... > > Thanks, > > Spencer > > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From spencer@wonderhamster.org Mon May 25 08:16:16 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 C160E3A69A4 for ; Mon, 25 May 2009 08:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_40=-0.185] 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 yZ2tuWrW+iu1 for ; Mon, 25 May 2009 08:16:15 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 37B523A6A33 for ; Mon, 25 May 2009 08:15:47 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1M8bvY0ni0-000g9T; Mon, 25 May 2009 11:17:26 -0400 Message-ID: <4213D9AF36794C9484FE218C65E7BE4B@china.huawei.com> From: "Spencer Dawkins" To: "Bernie Hoeneisen" References: Date: Mon, 25 May 2009 10:17:16 -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: V01U2FsdGVkX19dAQzDpUUFQ2q9JyvCPQ8NPp0qQMaV/KON3+v uES2gF+pv3u2OMeuFjbF/wDkCMbC7vRwxk5SgjSMBl5EThVxLZ 5Ej3fmaPyBaidMYqgElueG72ynhLQzo/b+dSOPer0Y= 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: Mon, 25 May 2009 15:16:16 -0000 Hi, Bernie, > Hi Spencer > > > Good work! > > > I have spotted one sentence I am not sure whether it should be in the > document: > > However, if the NomCom wishes to request community > feedback, it should request feedback from the entire community. > > I don't see the reason for it (I might have missed sth) and I am affraid > that it will constrain to much the NomCom under certain circumstances. Of > course, it all depends how strong a "should" is to be interpreted. > > Could you please shortly explain the background for this? What this sentence was trying to say was something like "request feedback from the entire community, not targeted segments". I'm thinking that this sentence could very easily go away from the next revision... Thanks, Spencer From jmh@joelhalpern.com Mon May 25 08:48: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 D59893A6F48 for ; Mon, 25 May 2009 08:48:13 -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 moNdJBd9vKgP for ; Mon, 25 May 2009 08:48: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 01F333A6B8C for ; Mon, 25 May 2009 08:48:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 46245430144; Mon, 25 May 2009 08:49:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.10] (pool-173-49-75-79.phlapa.fios.verizon.net [173.49.75.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id AD2AB4300FD; Mon, 25 May 2009 08:49:53 -0700 (PDT) Message-ID: <4A1ABE1F.7060207@joelhalpern.com> Date: Mon, 25 May 2009 11:49:51 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Spencer Dawkins References: <4213D9AF36794C9484FE218C65E7BE4B@china.huawei.com> In-Reply-To: <4213D9AF36794C9484FE218C65E7BE4B@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 25 May 2009 15:48:14 -0000 That sentence is probably a bad idea. As written, complying with the should would mean that the nomcom could not ask anyone indidivudally questions it does not ask the community. As such, the should will not be complied with, and we "should" not write rules we know will be ignored. Yours, Joel Spencer Dawkins wrote: > Hi, Bernie, > > >> Hi Spencer >> >> >> Good work! >> >> >> I have spotted one sentence I am not sure whether it should be in the >> document: >> >> However, if the NomCom wishes to request community >> feedback, it should request feedback from the entire community. >> >> I don't see the reason for it (I might have missed sth) and I am >> affraid that it will constrain to much the NomCom under certain >> circumstances. Of course, it all depends how strong a "should" is to >> be interpreted. >> >> Could you please shortly explain the background for this? > > What this sentence was trying to say was something like "request > feedback from the entire community, not targeted segments". I'm thinking > that this sentence could very easily go away from the next revision... > > Thanks, > > Spencer > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From spencer@wonderhamster.org Mon May 25 09:41:22 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 6AF273A69E9 for ; Mon, 25 May 2009 09:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 x9TUPb6kCtsC for ; Mon, 25 May 2009 09:41:16 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 671283A68BA for ; Mon, 25 May 2009 09:41:01 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1M8dFp0uko-000ftP; Mon, 25 May 2009 12:42:28 -0400 Message-ID: <0D8D6DBC6D4E46A5B6F12F91ABBFDD5C@china.huawei.com> From: "Spencer Dawkins" To: "Joel M. Halpern" References: <4213D9AF36794C9484FE218C65E7BE4B@china.huawei.com> <4A1ABE1F.7060207@joelhalpern.com> Date: Mon, 25 May 2009 11:42:16 -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/sDOVVAnBr6FXMdq43QcZlwVx868b7HUuIB1a Te6s3qm7ZWpmwOYcwtF8Nm9DHVfasrHUpAHBAB4VdniNaWAVDb ezPbPLyME7Z3ZQjhWljdeLJ11VEVqSJL+dLiPcIwk4= 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: Mon, 25 May 2009 16:41:22 -0000 Hi, Joel? What sentence? It's gone now :-) Thanks, Spencer > That sentence is probably a bad idea. As written, complying with the > should would mean that the nomcom could not ask anyone indidivudally > questions it does not ask the community. As such, the should will not be > complied with, and we "should" not write rules we know will be ignored. > > Yours, > Joel > > Spencer Dawkins wrote: >> Hi, Bernie, >> >> >>> Hi Spencer >>> >>> >>> Good work! >>> >>> >>> I have spotted one sentence I am not sure whether it should be in the >>> document: >>> >>> However, if the NomCom wishes to request community >>> feedback, it should request feedback from the entire community. >>> >>> I don't see the reason for it (I might have missed sth) and I am affraid >>> that it will constrain to much the NomCom under certain circumstances. >>> Of course, it all depends how strong a "should" is to be interpreted. >>> >>> Could you please shortly explain the background for this? >> >> What this sentence was trying to say was something like "request feedback >> from the entire community, not targeted segments". I'm thinking that this >> sentence could very easily go away from the next revision... >> >> Thanks, >> >> Spencer >> >> _______________________________________________ >> ietf-nomcom mailing list >> ietf-nomcom@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-nomcom >> > From john-ietf@jck.com Wed May 27 06:27:43 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 364173A6946 for ; Wed, 27 May 2009 06:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 fP-jvYP4sFKI for ; Wed, 27 May 2009 06:27:42 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 62C203A67AA for ; Wed, 27 May 2009 06:27:42 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1M9JAk-000JMn-Qi for ietf-nomcom@ietf.org; Wed, 27 May 2009 09:27:58 -0400 Date: Wed, 27 May 2009 09:27:57 -0400 From: John C Klensin To: NomComDiscussion Message-ID: 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: [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: Wed, 27 May 2009 13:27:43 -0000 Hi. During the plenary in San Francisco, several people made the point that it is probably time to think carefully about the mechanisms of the Nomcom model, not just to try to do the small incremental tuning discussed recently on this list. Spencer and I have been kicking around an idea for some years that addresses one of those key issues: the relationship between nominees would are incumbents in a given role and those who would be new to it. Those differences are particularly important because of the large number of incumbents Nomcoms end up returning to their positions and because issues about "running against" an incumbent are at the root of several of the objections to (or likely need for exceptions from) an open list of nominees. I've just queued a document, draft-klensin-nomcom-incumbents-first-00.txt, for posting that addresses that issue by proposing a significant change to Nomcom operations. We look forward to your comments. john From jmh@joelhalpern.com Wed May 27 07:38:02 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 B2E733A6B93 for ; Wed, 27 May 2009 07:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 dCaRrUTersyl for ; Wed, 27 May 2009 07:38:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7A3DE3A6A85 for ; Wed, 27 May 2009 07:38:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 76B52430380 for ; Wed, 27 May 2009 07:39: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 A98554302A7 for ; Wed, 27 May 2009 07:39:03 -0700 (PDT) Message-ID: <4A1D5086.9080702@joelhalpern.com> Date: Wed, 27 May 2009 10:39:02 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: NomComDiscussion References: In-Reply-To: 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: Wed, 27 May 2009 14:38:02 -0000 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. It seems likely to me that real world variation means that there is no right number. At a guess, given what the community has said, I would personnaly expect to see about half returned each time. And if I look at the numbers in the table, 49/95 have been returned. Whatever problems there may be in this dimension, they seem to be self-correcting and self-balancing. 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. 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. 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. 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. 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. 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. This seems an extremely difficult and counter-productive restriction to place on the nomcom. 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. 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. In summary, these seems to me a process which would make the nomcom's work harder, would make the work take longer, and would likely reduce the quality of the result. Yours, Joel M. Halpern John C Klensin wrote: > Hi. > > During the plenary in San Francisco, several people made the > point that it is probably time to think carefully about the > mechanisms of the Nomcom model, not just to try to do the small > incremental tuning discussed recently on this list. > > Spencer and I have been kicking around an idea for some years > that addresses one of those key issues: the relationship between > nominees would are incumbents in a given role and those who > would be new to it. Those differences are particularly > important because of the large number of incumbents Nomcoms end > up returning to their positions and because issues about > "running against" an incumbent are at the root of several of the > objections to (or likely need for exceptions from) an open list > of nominees. > > I've just queued a document, > draft-klensin-nomcom-incumbents-first-00.txt, for posting that > addresses that issue by proposing a significant change to Nomcom > operations. We look forward to your comments. > > john > > _______________________________________________ > ietf-nomcom mailing list > ietf-nomcom@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-nomcom > From sm@resistor.net Wed May 27 08:32:17 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 DAAD73A6F3B for ; Wed, 27 May 2009 08:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_20=-0.74] 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 n5KwH4skcdyS for ; Wed, 27 May 2009 08:32:16 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 3EFEA3A6859 for ; Wed, 27 May 2009 08:30:51 -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 n4RF0uYT003574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 08:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1243436467; x=1243522867; bh=ONahl+xdZ8xlchufoky2sirNepnPgHN/puuYbXmetMA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Cemxvpj1iNs5pVayyElqwVsdALaX5IXUT4rpfUWiBUE+ZJAQqz8v0DiUAiKZt7ZnT 2zsJEwobOqoG0K0BVebCsjJvWIA83NpiElrniIxzjsUztqK/Gf+p19wvah6Y9MMaDF t9pLuZBAzGBxnK1JPNTPrXe7P9XEdLqBDc3+VLPY= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=dx86EQ/gnptZrj05kSYirv8Y+Rj9oRBZShdvUN780GVfj2n+KJv8grsBnHc1uoJGL 6DJ5LA68EwkF16gbD3xfTYV3N3B8aVhx3Q0prRb4jouA4VDFmgmSAi5+smZwKtJfShA 31jZi93QdkxpXYSXcQpUeMKZkAtWUnyVyigY9so= Message-Id: <6.2.5.6.2.20090527065337.033d12c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 May 2009 08:00:14 -0700 To: Robert Elz , "Joel M. Halpern" From: SM In-Reply-To: <1490.1242663073@epsilon.noi.kre.to> References: <6.2.5.6.2.20090517204631.03545390@resistor.net> <8EFB68EAE061884A8517F2A755E8B60A1CD8A4B0C3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <72E1E2EDDBD5CBDD92BF837F@eList-eXpress-LLC.local> <499F3A1A.7020205@thinkingcat.com> <51C740C6-2F58-4B5D-BB51-C6C937D5EF35@tcb.net> <874B0EA5B7474E40BC4771582E20F135@china.huawei.com> <4A01FF14.1000802@joelhalpern.com> <68203580453A41F9BE4A8E17676A40DD@china.huawei.com> <52670AA1-1957-4C8C-9A51-4336DFB1ECFC@cisco.com> <675982CA-8EED-470C-888D-DB876816D256@cisco.com> <5CEDB6DE69CE4EB18AD366AFFEC06F54@china.huawei.com> <4A02DD01.3040009@joelhalpern.com> <93AEDB8B-47E1-4FEA-A342-1D549F157453@cisco.com> <11211.1241802463@e! psilon.noi.kre.to> <6.2.5.6.2.20090508212200.031d3! d80@resistor.net> <5809C3060E3948E8BFF2846F44C614CD@china.huawei.com> <6.2.5.6.2.20090512111353.03369dd0@resistor.net> <200905171954.n4HJsW2W013397@cichlid.raleigh.ibm.com> <1490.1242663073@epsilon.noi.kre.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: NomComDiscussion Subject: Re: [ietf-nomcom] announcing list of willing candidates 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, 27 May 2009 15:32:18 -0000 At 09:11 18-05-2009, Robert Elz wrote: >If that wasn't done, there wouldn't be nearly as much of an "open secret" >and that argument for publishing the list would not exist - that is, the >supporters of that position wouldn't be able to just say "it happens >anyway, let's recognise that and formalise it" but would instead need >to produce arguments as to why things would work better this way. That's an interesting line of argument. I like what you said in the last sentence. >I agree with Joel's response to this - selection of the nomcom members >is done in a way that it should result in a committee that is roughly >representative (in the sense of being a good cross section of the >community ... for now, the IETF meeting attending part of the community >anyway) but beyond that there's nothing at all representative about the >process. I appreciate Joel correcting me on this. At the end of the day, we need to chose some people (the committee) to do the selection. For such a choice (the way it is done) to gain wide acceptance, it has to be perceived as inclusive. Joel's and your responses sums up what I wanted to convey. >So, it is absurd to prohibit ringers, that can't be done. What should >be being made clear to the nomcom is that it is not required to add ringers >in order to meet some perceived confidentially requirement. If the Agreed. Regards, -sm From spencer@wonderhamster.org Wed May 27 08:57: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 CAECA3A6F74 for ; Wed, 27 May 2009 08:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_50=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 TrRRiuC1ROUs for ; Wed, 27 May 2009 08:57:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 06BED3A6A67 for ; Wed, 27 May 2009 08:57:31 -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-1M9LWI1aQu-000d07; Wed, 27 May 2009 11:58:23 -0400 Message-ID: <84AB9EE93974405AB2E39EBEE5A1CF0A@china.huawei.com> From: "Spencer Dawkins" To: "NomComDiscussion" References: <1711E17AEFED4BDCA8B609FEA4BB7D63@china.huawei.com> Date: Wed, 27 May 2009 10:58:17 -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+D6olgY/vux59hcysTeL5Qc0xTtEQEFe/QzNc ViauAzoOdCVrT14bF16PKiOrtlnQLU/eAEKgwNkPcsLmZ1Wcrp Zl9rB9G9stfzwX9oRKrXKvUZzrfigKmEgQRBHu+mv0= Subject: [ietf-nomcom] draft-dawkins-nomcom-dont-wait-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, 27 May 2009 15:57:32 -0000 I've just posted a revision to this draft, available at http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-dont-wait-03.txt. Russ did an AD review on -02 and asked me to make a few editorial changes (more capitalization than anything else). I also added an explicit informational reference for the IETF 74 plenary minutes. Thanks, Spencer From sm@resistor.net Thu May 28 02:26: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 7EACF3A6A2E for ; Thu, 28 May 2009 02:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_20=-0.74] 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 8YGpo9mr75Ur for ; Thu, 28 May 2009 02:26:23 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 3006A3A6784 for ; Thu, 28 May 2009 02:26:22 -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 n4S9RoLC006530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 02:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1243502879; x=1243589279; bh=qkyzB60vTPK+AzDc9lwgTIEXXZa5D86LlLP7+2hWF90=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=qv8s5jb4nVtEk8MDlUFFjeyAu8TdrG61Qi4Eu6g5pYFkwyb74UKbVyTMoAwmcwKNT zw9J4hizftwzBNyi9R1QKIN+2iPUCIzx4bx6C+MwQFje6kDWaIQmLkb32uJtBIDIKc qedgF2o1nlP36LgdFgbskOA0+QFpvtcG0HRbaMZo= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=0itgT6TISclZYD9/Red/+SL12WvLJ0wzekx/zgHF4RrBqTQ9g6tO+dOL/OUPTY6to e4GSujRKhsGYZNNNmFCRjy3toKFcvvcBYrULUmHTfdrgiB1QhA6etEzrbfJoNyMGrIF 8Zty7zWiybLSusIgcB3WeorOxWl7+n/6TFyw8vs= Message-Id: <6.2.5.6.2.20090527225634.033e53e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 May 2009 02:27:35 -0700 To: John C Klensin From: SM In-Reply-To: References: 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: Thu, 28 May 2009 09:26:30 -0000 Hi John, At 06:27 27-05-2009, John C Klensin wrote: >During the plenary in San Francisco, several people made the >point that it is probably time to think carefully about the >mechanisms of the Nomcom model, not just to try to do the small >incremental tuning discussed recently on this list. It's good to think about the mechanism for NomCom. I am ambivalent on whether to change it in such a way. Whether I agree to the changes or not, I believe that it can be easier to do the small incremental tuning. However, that can turn into flipping bits without looking at the larger picture. The various possible cases posted previously show that the relationships can be quite complex. >Spencer and I have been kicking around an idea for some years >that addresses one of those key issues: the relationship between >nominees would are incumbents in a given role and those who >would be new to it. Those differences are particularly >important because of the large number of incumbents Nomcoms end >up returning to their positions and because issues about >"running against" an incumbent are at the root of several of the >objections to (or likely need for exceptions from) an open list >of nominees. A few days ago, I was looking at the length of AD terms. The average length of term for an AD is three and a half years. The figures point to incumbents keeping their seats. That's both good and bad. It's good if we like the body, as a whole, to have continuity. And it's bad because it creates the old boys and girls club. I'm using the IESG as an example. I haven't looked at the statistics for the other bodies. Before I proceed to your draft, I'll mention a (probably bad) idea. :-) It would add some zest to the mix to ask the incumbent to suggest an alternative for the position. Obviously, the two people should have as little relationship as possible. Ideally, the "period of contributing to the community" should be brief. That encourages a flat structure where knowledge is dispersed. In Section 2 of draft-klensin-nomcom-incumbents-first, it is mentioned that the "too-low turnover in a decision-making body can contribute to that body's having an incomplete impression of the views of the community". It also create a core group and the rest. We need leaders for an organization. Sometimes we want a strong leadership to weather the storms or to instill a sense of direction in uncertain times. Given the way the IETF operates, enablers may be better than leaders as that favors a bottom-up approach. Every now and then, I hear a question about "what is the I* body doing about X". Such a question should be viewed as pertaining to communicating what's going on instead of one where the I* body is expected to be the only solution provider. Unfortunately, the rest find it easier to be complacent and delegate their fate to some higher authority. This is more pronounced in other communities. I'll diverge from the topic in this paragraph. The view from the community is through the proceedings of the I* bodies. That's available through the minutes they publish. At this date, the lastest IESG's minutes are for May 7 which is less than one month. The latest IAB's minutes are for January 28 which is around four months. The latest IAOC's minutes are dated January 22. It's difficult to say why NomCom is returning about half the incumbents in each cycle. I will not ask for an reason to that as I don't expect NomCom to justify their choices (see previous discussions about the open-list draft where I commented on the role of NomCom). As mentioned in your (and Spender's draft), a rate like that discourages people from volunteering. One of the important points, in my opinion, of your draft are the principles outlined in Section 2. When you bear a responsibility for too long, it becomes a career. I'll leave it to the reader to decide whether this is a service to the IETF. There is a learning curve for any job. That should not be used as an excuse for people on their first term. The discussion about the performance of incumbents in Section 2.1 is at odds with what has been said about the "recruiting" model. In such a model, we do make comparisons where the replacement faces a higher hurdle unless the incumbent is really bad. It is good to have diversity in a group or a committee. That creates a group with a breadth of experience and different views (to look at a problem from different angles). Remember that the group is a collegial body and not a group of people where each of them compete for resources. Not having a complete slate of candidates can create an imbalance in the group. Every now and then we need a disruptive idea. Without that, we become complacent. We follow traditions. They are formalized as rules. And then they become dogma. Regards, -sm From fred@cisco.com Thu May 28 03:33:05 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 058383A68E7 for ; Thu, 28 May 2009 03:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 vErJZxlCxfDX for ; Thu, 28 May 2009 03:33:04 -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 CE44F3A6889 for ; Thu, 28 May 2009 03:33:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,264,1241395200"; d="scan'208";a="45403227" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 May 2009 10:34:34 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4SAYY0L022434; Thu, 28 May 2009 06:34:34 -0400 Received: from [172.16.1.44] (rtp-vpn2-1713.cisco.com [10.82.246.179]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4SAYXj3015017; Thu, 28 May 2009 10:34:34 GMT Message-Id: <50A46B4A-1B5D-40CB-8A87-713444537D62@cisco.com> From: Fred Baker To: "Joel M. Halpern" In-Reply-To: <4A1D5086.9080702@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 06:34:33 -0400 References: <4A1D5086.9080702@joelhalpern.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=798; t=1243506874; x=1244370874; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[ietf-nomcom]=20Changing=20the=20candid ate=20selection=20model |Sender:=20 |To:=20=22Joel=20M.=20Halpern=22=20; bh=opkZxD1zXeK1cOBsZGAkcY8Eqfexl4AlLgpfWg6HROQ=; b=gN7uHbdRTQJaks0e5NVtipJt78tnqkBkANmv0mBoct9tzL+/zWP1MuMm02 zu9cwGS10tkA1eKLqFgwj3mnbBGS7h6XNP7puhR7BmnFzcZJxboFGdOciw7l xWazkZlBll; Authentication-Results: rtp-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 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: Thu, 28 May 2009 10:33:05 -0000 On May 27, 2009, at 10:39 AM, Joel M. Halpern wrote: > 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. That and whether the nomcom believes that the incumbents did a good job. I know of at least one case where it is rumored that 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. That seems unnecessary. And one could just as easily imagine a case in which the nomcom felt that none should be returned. IMHO, the job of the nomcom is not to pass judgement on the incumbents. It is, in your words, to find the best person for the job. From sm@resistor.net Sat May 30 08:22:50 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 CC8C83A6F13 for ; Sat, 30 May 2009 08:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=-0.641, 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 2BxkXZEgLfLC for ; Sat, 30 May 2009 08:22:49 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 8B71D3A6F3F for ; Sat, 30 May 2009 08:22:49 -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 n4UFOKBf003915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 08:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1243697071; x=1243783471; bh=QHXrm3LXdZGBFjmXr8yjSTxBW8sSF2AHzGfHzH2Eqjs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=CTPxN1h6koWUTcU1TIhTnDw5PJnrB8pTPwJDRy5xF72Epbe5+ZlD6ClRQYE5GZFNb uA/aV2Ul4PdijUmICbXLGRA0x6HAMSuuwnC0rDYFcZ//kjnEh1lK3Z/bxnQN1Y7LRT VXj3tH5lzSJtvA+2vcl8nIohhnhOS6AF7XJ7j6sg= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=H+3JC/u+d4mlGjeNDyOFm8RudQEXBM8l1lOMMSNFCNvYWg1bhwE0jgUzgfgf/FhAh JKbjJV47J2gIrIL3xm6hE85gb56AVMb40QHI20dFgyS0w/pMUK/9h5MDy+rU6J4nBPt ZKPxJHlAauWdraG5zAOoGCr655HXDWRZtbkdykw= Message-Id: <6.2.5.6.2.20090530022114.0332e6f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 30 May 2009 08:22:42 -0700 To: "Joel M. Halpern" From: SM In-Reply-To: <4A1D5086.9080702@joelhalpern.com> References: <4A1D5086.9080702@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: Sat, 30 May 2009 15:22:51 -0000 Hi Joel, At 07:39 27-05-2009, Joel M. Halpern wrote: >Having read the draft, it seems to me that this is a bad idea. Maybe. :-) >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. It seems likely to me that real world variation >means that there is no right number. At a guess, given what the >community has said, I would personnaly expect to see about half >returned each time. And if I look at the numbers in the table, 49/95 >have been returned. Whatever problems there may be in this >dimension, they seem to be self-correcting and self-balancing. There is a notion of incumbents being "fired". That seems to be the problem when the incumbent is not selected for a new term. What is the appropriate number of incumbents to be returned? How many is too many and how many is too few? By mentioning a number, we will create another "ringer" problem. I agree that there isn't a right number. Section 2 of the draft has a table with the percentage of incumbents returned. That provides us with a trend. Now, what do we do when we see a trend? We figure out whether there is a reason. >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. I agree. >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. Yes. >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. 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 We have a problem here. If the goal is to appoint the best available person to the job, then returning too many should not be a consideration. Let's see what happens when you return too many. It may discourage people from running and it encourages a closed social network. >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. If the IETF community doesn't ensure that there are enough good nominees, then it has the leadership it deserves. It has been pointed out (not in the draft) that in practice NomCom has ways to find nominees. Not filling in the seat has more to do with the relationship between NomCom and the appointing body. It is perceived that not being selected for a new term means that the member has been fired as it is more sociably acceptable to do that instead of invoking the recall process. That perception could be tackled by eliminating the notion of incumbents. We can remove "running against" or "firing" from the discussion by doing away with consecutive terms. The draft mentions that retirement after a single term is uneconomic for the community. That obvious fix is to have longer terms but then we may have to invoke the recall process. As it will likely be seen as too controversial to use that process, we'll end up in the same situation as now. Feel free to beat the idea around and point out why it's a bad one. Regards, -sm