idnits 2.17.1 draft-dawkins-nomcom-openlist-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3777, updated by this document, for RFC5378 checks: 2002-06-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2009) is 5537 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Dawkins, Ed. 3 Internet-Draft Huawei (USA) 4 Updates: 3777 (if approved) February 26, 2009 5 Intended status: BCP 6 Expires: August 30, 2009 8 Nominating Committee Process: Open Disclosure of Willing Nominees 9 draft-dawkins-nomcom-openlist-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 30, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document updates RFC 3777, Section 3, Bullet 6 to allow a 48 Nominating and Recall Commitee to disclose the list of nominees who 49 are willing to serve in positions the NomCom is responsible for 50 filling. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Current Rules on Confidentiality . . . . . . . . . . . . . . . 3 56 3. Problems with Existing Rules . . . . . . . . . . . . . . . . . 3 57 4. Asking the Entire Community for Feedback . . . . . . . . . . . 4 58 5. Publishing an Accurate Nominee List . . . . . . . . . . . . . . 4 59 6. Concerns About Open Nominee Lists . . . . . . . . . . . . . . . 5 60 7. Updated text from RFC 3777 . . . . . . . . . . . . . . . . . . 6 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 11. Normative References . . . . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The Internet Engineering Steering Group (IESG), the Internet 70 Architecture Board (IAB), and at-large IETF representatives to the 71 IETF Administrative Oversight Committee (IAOC) are selected by a 72 "Nominating and Recall Committee" (universally abbreviated as 73 "NomCom"). [RFC3777] defines how the NomCom is selected, and the 74 processes it follows as it selects candidates for these positions. 76 The NomCom is responsible for filling positions across the breadth of 77 the Internet Engineering Task Force (IETF). The NomCom needs 78 relevant information about nominees being considered for these 79 positions, but current [RFC3777] requirements for confidentiality 80 limit the ability of the NomCom to solicit that information. The 81 process change described in this document allows the NomCom to openly 82 solicit information about willing nominees. 84 2. Current Rules on Confidentiality 86 [RFC3777] is the latest in a series of revisions to the NomCom 87 process. 89 [RFC3777] describes the confidental nature of NomCom deliberations in 90 section 3, "General", bullet 6, which states: 92 All deliberations and supporting information that relates to 93 specific nominees, candidates, and confirmed candidates are 94 confidential. 96 The nominating committee and confirming body members will be 97 exposed to confidential information as a result of their 98 deliberations, their interactions with those they consult, and 99 from those who provide requested supporting information. All 100 members and all other participants are expected to handle this 101 information in a manner consistent with its sensitivity. 103 It is consistent with this rule for current nominating committee 104 members who have served on prior nominating committees to advise 105 the current committee on deliberations and results of the prior 106 committee, as necessary and appropriate. 108 3. Problems with Existing Rules 110 There are two problems with existing practice - nominee lists aren't 111 as confidential as [RFC3777] would lead the reader to believe, but 112 they aren't visible to the entire IETF community, either. 114 Since at least 1996, most NomComs have sent out a "short list" of 115 nominees under consideration to a variety of audiences. The target 116 audiences differ from year to year, but have included members of 117 specific leadership bodies, working group chairs in a specific area 118 (for IESG positions), and all working group chairs (for IAB and IAOC 119 positions). "All working group chairs" includes multiple hundreds of 120 recipients. 122 This practice is unavoidable, because most NomCom members will not 123 have personal experience with most nominees for most positions, but 124 it is periodically challenged because it's not explicitly allowed as 125 an exception to the blanket requirement for confidentiality. 127 In an attempt to maintain the required level of confidentiality, past 128 NomComs have also included "ringers" on the short list - nominees who 129 have notified NomCom that they are NOT willing to serve. Since 130 anyone who sees the short list does not know who the ringers are, 131 consciencious IETF participants also provide feedback on nominees who 132 have already declined. This is a waste of precious IETF-participant 133 cycles, and Joel Halpern (2008-2009 NomCom Chair) reports that "the 134 ringer pool leaks like a sieve" - it's also ineffective. 136 We also note that the practice of publishing a "short list" penalizes 137 IETF participants who aren't members of one of the audiences being 138 surveyed - they have no way of knowing who is being considered, 139 except for incumbent(s), and have little incentive to provide 140 feedback to NomCom on individuals who might not even be nominees. 142 4. Asking the Entire Community for Feedback 144 We take it as given that for today's NomComs, members will not likely 145 have personal experience with all nominees for all positions under 146 review. 148 We assume that asking the larger community for feedback about these 149 nominees is preferable to NomCom members without personal experience 150 simply deferring to the members of the NomCom who DO have personal 151 experience with specific nominees. 153 We assume that asking for feedback from the entire community is 154 preferable to asking for feedback from specific segments of the 155 community. 157 5. Publishing an Accurate Nominee List 159 In proposing that an accurate nominee list be published as part of 160 NomCom's request for feedback from the community, we considered three 161 possibilities: 163 1. Asking for feedback on all nominees, whether they are willing to 164 serve or not. 165 2. Asking for feedback on all nominees who are willing to serve. 166 3. Asking for feedback on the nominees that NomCom is seriously 167 considering (the "short list"). 169 Asking for feedback on nominees who are not willing to serve is a 170 waste of precious IETF-participant cycles, and may make it less 171 likely that NomCom would receive feedback on some nominees who ARE 172 willing to serve. 174 Asking for feedback on all nominees who are willing to serve allows 175 the community to point out specific strengths and weaknesses of all 176 nominees, and this feedback should be useful to NomCom in deciding 177 which nominees to seriously consider. It also allows NomCom to 178 receive feedback on nominees who might not appear on a "short list" 179 initially, in the event that a strong nominee is suddenly unwilling 180 or unable to serve. 182 We also note that the list of willing nominees would include 183 incumbents who are willing to serve an additional term. 185 6. Concerns About Open Nominee Lists 187 This section acknowledges possible concerns about publishing open 188 nominee lists in previous discussions. 190 It is possible that nominees who are willing to be considered if the 191 nominee list is not published, would not be willing to be considered 192 if the nominee list is published. This reluctance might be the 193 result of personal pride, or the result of the fear of retribution, 194 for a nominee being considered as a replacement for the nominee's 195 managing Area Director (this concern is usually raised in an IESG 196 context). 198 Spencer's personal opinion is that if retribution for willingness to 199 be considered for IETF leadership positions is a serious concern, we 200 have bigger problems than nominee list confidentiality, and Spencer 201 notes that it's called the "Nominating AND RECALL Committee" for a 202 reason. 204 We note that (for example) the Internet Architecture Board publishes 205 the nominee list for their representative to the Internet Society 206 Board of Trustees, without apparent ill effects. 208 It is possible that publishing the nominee list publicly would lead 209 to "lobbying", public statements supporting nominees on the IETF 210 mailing list, etc. 212 Rather than trying to prohibit specific "undesirable" behaviors, we 213 trust that NomCom would focus on factual feedback, rather than on 214 statements of support, in its deliberations. 216 We note that nominees know they are under consideration and can 217 "lobby" today, by telling people they are willing to serve and asking 218 them to provide feedback to NomCom. Several nominees (both 219 incumbents and non-incumbents) have posted statements of candidacy to 220 the IETF Discussion mailing list, for example. 222 7. Updated text from RFC 3777 224 At the end of the three paragraphs in [RFC3777], section 3, 225 "General", bullet 6, which are currently: 227 All deliberations and supporting information that relates to 228 specific nominees, candidates, and confirmed candidates are 229 confidential. 231 The nominating committee and confirming body members will be 232 exposed to confidential information as a result of their 233 deliberations, their interactions with those they consult, and 234 from those who provide requested supporting information. All 235 members and all other participants are expected to handle this 236 information in a manner consistent with its sensitivity. 238 It is consistent with this rule for current nominating committee 239 members who have served on prior nominating committees to advise 240 the current committee on deliberations and results of the prior 241 committee, as necessary and appropriate. 243 add the following paragraphs: 245 The list of nominees willing to serve in positions under review in 246 the current NomCom cycle is not confidential. The NomCom will 247 publish the list of names of all willing nominees to the 248 community, in order to obtain feedback from the community on these 249 nominees. The list of nominees published should not contain 250 nominees who have not indicated a willingness to serve in the 251 position(s) under review. 253 The published list is intended to be published as a complete list, 254 but the NomCom may publish an updated list if the NomCom 255 identifies errors/omissions in a previously-published version of 256 the public list, or if the NomCom finds it necessary to call for 257 additional nominees, and these nominees indicate a willingness to 258 serve in time to be considered by the NomCom. 260 8. Security Considerations 262 This specification describes issues with the current IETF Nominating 263 Committee process ([RFC3777]) and proposes an update to allow the 264 NomCom to solicit feedback on willing nominees from the entire 265 community. No security considerations apply. 267 9. IANA Considerations 269 No IANA actions are requested in this specification. 271 10. Acknowledgements 273 The editor thanks the following folks who have provided useful 274 observations and guidance on previous versions of this draft: Brian 275 Carpenter, Leslie Daigle, Joel Halpern, Danny McPherson. 277 11. Normative References 279 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 280 Recall Process: Operation of the Nominating and Recall 281 Committees", BCP 10, RFC 3777, June 2004. 283 Author's Address 285 Spencer Dawkins (editor) 286 Huawei Technologies (USA) 288 Phone: +1 214 755 3870 289 Email: spencer@wonderhamster.org