idnits 2.17.1 draft-dawkins-nomcom-openlist-06.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 (August 10, 2009) is 5366 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) August 10, 2009 5 Intended status: BCP 6 Expires: February 11, 2010 8 Nominating Committee Process: Open Disclosure of Willing Nominees 9 draft-dawkins-nomcom-openlist-06 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 February 11, 2010. 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 be considered to serve in positions the committee is 50 responsible for 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. Disclosing a Nominee List . . . . . . . . . . . . . . . . . . . 5 59 6. Updated text from RFC 3777 . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 63 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 64 Appendix A. Concerns About Open Nominee Lists . . . . . . . . . . 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 nominees who are willing to be considered. 84 2. Current Rules on Confidentiality 86 [RFC3777] is the latest in a series of revisions to the NomCom 87 process, and it describes the confidential nature of NomCom 88 deliberations in section 3, "General", bullet 6, which states: 90 All deliberations and supporting information that relates to 91 specific nominees, candidates, and confirmed candidates are 92 confidential. 94 The nominating committee and confirming body members will be 95 exposed to confidential information as a result of their 96 deliberations, their interactions with those they consult, and 97 from those who provide requested supporting information. All 98 members and all other participants are expected to handle this 99 information in a manner consistent with its sensitivity. 101 It is consistent with this rule for current nominating committee 102 members who have served on prior nominating committees to advise 103 the current committee on deliberations and results of the prior 104 committee, as necessary and appropriate. 106 3. Problems with Existing Rules 108 There are two problems with existing practice - nominee lists aren't 109 as confidential as [RFC3777] would lead the reader to believe, but 110 they aren't visible to the entire IETF community, either. 112 Since at least 1996, most NomComs have sent out a "short list" of 113 nominees under consideration to a variety of audiences. The target 114 audiences differ from year to year, but have included members of 115 specific leadership bodies, working group chairs in a specific area 116 (for IESG positions), all working group chairs (for IAB and IAOC 117 positions), and all document authors. The combined target audience 118 for all short lists includes multiple hundreds of recipients - recent 119 NomComs have sent out about 1500 requests for short list feedback. 121 This practice is unavoidable, because most NomCom members will not 122 have personal experience with most nominees for most positions, but 123 it is periodically challenged because it's not explicitly allowed as 124 an exception to the blanket requirement for confidentiality. 126 In an attempt to maintain the required level of confidentiality, past 127 NomComs have also included "ringers" (as "padding") on the short list 128 - nominees who are NOT under active consideration for a specific 129 position. Since anyone who sees the short list does not know who the 130 ringers are, consciencious IETF participants also provide feedback on 131 nominees who have already declined. This is a waste of precious 132 IETF-participant cycles, and there are widespread reports that strict 133 confidentiality about which candidates are "real", and which are 134 included as "padding", is not successfully maintained in practice. 136 Even if confidentiality about padding is maintained, the community is 137 aware that some nominees on the short list aren't under active 138 consideration. In some cases, people have guessed incorrectly that 139 an actual nominee is part of the padding, and didn't provide needed 140 feedback to NomCom about a nominee who was actively being considered. 142 We also note that the practice of disclosing a "short list" penalizes 143 IETF participants who aren't members of one of the target audiences 144 being surveyed - they have no way of knowing who is being considered, 145 except for incumbent(s), and have little incentive to provide 146 feedback to NomCom on individuals who might not even be nominees. 148 4. Asking the Entire Community for Feedback 150 NomComs are not required to ask for community input at all, but at 151 the current IETF scale, many NomComs do request community input, 152 because members do not have personal experience with all nominees for 153 all positions under review. 155 We assume that asking the larger community for feedback about these 156 nominees is preferable to NomCom members without personal experience 157 simply deferring to the members of the NomCom who do have personal 158 experience with specific nominees. 160 We assume that asking for feedback from the entire community is 161 preferable to asking for feedback from large segments of the 162 community, while keeping the rest of the community "in the dark". 164 5. Disclosing a Nominee List 166 In proposing that a nominee list be disclosed as part of NomCom's 167 request for feedback from the community, we considered three 168 possibilities: 170 1. Asking for feedback on all nominees, whether they are willing to 171 be considered or not. 173 2. Asking for feedback on all nominees who are willing to be 174 considered. 176 3. Asking for feedback on the nominees that NomCom is seriously 177 considering (the "short list"). 179 Asking for feedback on nominees who are not willing to be considered 180 is a waste of precious IETF-participant cycles, and may make it less 181 likely that NomCom would receive feedback on some nominees who ARE 182 willing to be considered. 184 Asking for feedback on all nominees who are willing to be considered 185 allows the community to point out specific strengths and weaknesses 186 of all willing nominees, and this feedback should be useful to NomCom 187 in deciding which nominees to seriously consider. It also allows 188 NomCom to receive feedback on nominees who might not appear on a 189 "short list" initially, in the event that a strong nominee is 190 suddenly unwilling or unable to serve. 192 We also note that the list of willing nominees will include 193 incumbents who are willing to be considered for an additional term. 195 6. Updated text from RFC 3777 197 At the end of the three paragraphs in [RFC3777], section 3, 198 "General", bullet 6, which are currently: 200 All deliberations and supporting information that relates to 201 specific nominees, candidates, and confirmed candidates are 202 confidential. 204 The nominating committee and confirming body members will be 205 exposed to confidential information as a result of their 206 deliberations, their interactions with those they consult, and 207 from those who provide requested supporting information. All 208 members and all other participants are expected to handle this 209 information in a manner consistent with its sensitivity. 211 It is consistent with this rule for current nominating committee 212 members who have served on prior nominating committees to advise 213 the current committee on deliberations and results of the prior 214 committee, as necessary and appropriate. 216 add the following paragraphs: 218 The list of nominees willing to be considered for positions under 219 review in the current NomCom cycle is not confidential. The 220 NomCom may disclose a list of names of nominees who are willing to 221 be considered for positions under review to the community, in 222 order to obtain feedback from the community on these nominees. 224 The list of nominees disclosed for a specific position should 225 contain only the names of nominees who are willing to be 226 considered for the position under review. 228 The NomCom may choose not to include some names in the disclosed 229 list, at their discretion. 231 The NomCom may disclose an updated list, at their discretion. For 232 example, the NomCom might disclose an updated list if the NomCom 233 identifies errors/omissions in a previously-disclosed version of 234 the disclosed list, or if the NomCom finds it necessary to call 235 for additional nominees, and these nominees indicate a willingness 236 to be considered before NomCom has completed its deliberations. 238 Nominees may choose to ask people to provide feedback to NomCom, 239 but should not encourage any public statements of support. 240 NomComs should consider nominee-encouraged lobbying and 241 campaigning to be unacceptable behavior, 243 IETF community members are encouraged to provide feedback on 244 nominees to NomCom, but should not post statements of support/ 245 non-support for nominees in any public forum. 247 7. Security Considerations 249 This specification describes issues with the current IETF Nominating 250 Committee process ([RFC3777]) and proposes an update to allow the 251 NomCom to solicit feedback from the entire community on nominees 252 under consideration. No security considerations apply. 254 8. IANA Considerations 256 No IANA actions are requested in this specification. 258 9. Acknowledgements 260 The editor thanks the following folks who have provided useful 261 observations and guidance on previous versions of this draft: Fred 262 Baker, Ross Callon, Brian Carpenter, Leslie Daigle, Lars Eggert, 263 Robert Elz, Joel Halpern, Bernie Hoeneisen, John Klensin, Barry 264 Leiba, Danny McPherson, S. Moonesamy, and Thomas Narten. 266 The editor also thanks IETF plenary meeting participants who have 267 provided useful feedback on previous versions of this draft. 269 10. Normative References 271 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 272 Recall Process: Operation of the Nominating and Recall 273 Committees", BCP 10, RFC 3777, June 2004. 275 Appendix A. Concerns About Open Nominee Lists 277 This section acknowledges possible concerns about disclosing open 278 nominee lists in previous NomCom-related discussions. Thanks to 279 Leslie Daigle for providing this set of concerns to the document 280 editor. 282 One concern is that nominees who are willing to be considered if the 283 nominee list is not disclosed, would not be willing to be considered 284 if the nominee list is disclosed. This reluctance might be cultural, 285 the result of personal pride, or the result of the fear of 286 retribution, for a nominee being considered as a replacement for the 287 nominee's managing Area Director (this concern is usually raised in 288 an IESG context). 290 Another concern is that publishing the nominee list publicly would 291 lead to "lobbying", public statements supporting nominees on the IETF 292 mailing list, etc. 294 Author's Address 296 Spencer Dawkins (editor) 297 Huawei Technologies (USA) 299 Phone: +1 214 755 3870 300 Email: spencer@wonderhamster.org