idnits 2.17.1 draft-dawkins-nomcom-openlist-04.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 (June 3, 2009) is 5440 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) June 3, 2009 5 Intended status: BCP 6 Expires: December 5, 2009 8 Nominating Committee Process: Open Disclosure of Willing Nominees 9 draft-dawkins-nomcom-openlist-04 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 December 5, 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 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. Publishing a Nominee List . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 guess incorrectly that an 139 actual nominee is part of the padding, and don't provide needed 140 feedback to NomCom about a nominee who is actively being considered. 142 We also note that the practice of publishing 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. Publishing a Nominee List 166 In proposing that a nominee list be published 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 would include 193 incumbents who are willing to be considered for an additional term. 195 6. Concerns About Open Nominee Lists 197 This section acknowledges possible concerns about publishing open 198 nominee lists in previous discussions. 200 One concern is that nominees who are willing to be considered if the 201 nominee list is not published, would not be willing to be considered 202 if the nominee list is published. This reluctance might be cultural, 203 the result of personal pride, or the result of the fear of 204 retribution, for a nominee being considered as a replacement for the 205 nominee's managing Area Director (this concern is usually raised in 206 an IESG context). 208 We note that (for example) the Internet Architecture Board publishes 209 the nominee list for their representative to the Internet Society 210 Board of Trustees, without apparent ill effects, but we are also 211 willing to accept that a NomCom might consider nominees whose names 212 have not been announced, for a variety of reasons, if this is the 213 right thing to do. 215 Another concern is that publishing the nominee list publicly would 216 lead to "lobbying", public statements supporting nominees on the IETF 217 mailing list, etc. 219 We note that nominees know they are under consideration and can 220 "lobby" today, by telling people they are willing to be considered 221 and asking them to provide feedback to NomCom. Several nominees 222 (both incumbents and non-incumbents) have posted statements of 223 candidacy to the IETF Discussion mailing list in recent years, for 224 example. 226 7. Updated text from RFC 3777 228 At the end of the three paragraphs in [RFC3777], section 3, 229 "General", bullet 6, which are currently: 231 All deliberations and supporting information that relates to 232 specific nominees, candidates, and confirmed candidates are 233 confidential. 235 The nominating committee and confirming body members will be 236 exposed to confidential information as a result of their 237 deliberations, their interactions with those they consult, and 238 from those who provide requested supporting information. All 239 members and all other participants are expected to handle this 240 information in a manner consistent with its sensitivity. 242 It is consistent with this rule for current nominating committee 243 members who have served on prior nominating committees to advise 244 the current committee on deliberations and results of the prior 245 committee, as necessary and appropriate. 247 add the following paragraphs: 249 The list of nominees willing to be considered for positions under 250 review in the current NomCom cycle is not confidential. The 251 NomCom may publish a list of names of nominees who are willing to 252 be considered for positions under review to the community, in 253 order to obtain feedback from the community on these nominees. 255 The NomCom may publish an updated list if the NomCom considers 256 this necessary. For example, the NomCom might publish an updated 257 list if the NomCom identifies errors/omissions in a previously- 258 published version of the public list, or if the NomCom finds it 259 necessary to call for additional nominees, and these nominees 260 indicate a willingness to be considered before NomCom has 261 completed its deliberations. 263 The list of nominees published for a specific position should 264 contain only the names of nominees who are willing to be 265 considered for the position under review. 267 Feedback on nominees should always be provided privately to 268 NomCom. Nominees should not solicit support, and other IETF 269 community members should not post statements of support/ 270 non-support for nominees in any public forum. 272 8. Security Considerations 274 This specification describes issues with the current IETF Nominating 275 Committee process ([RFC3777]) and proposes an update to allow the 276 NomCom to solicit feedback from the entire community on nominees 277 under consideration. No security considerations apply. 279 9. IANA Considerations 281 No IANA actions are requested in this specification. 283 10. Acknowledgements 285 The editor thanks the following folks who have provided useful 286 observations and guidance on previous versions of this draft: Fred 287 Baker, Ross Callon, Brian Carpenter, Leslie Daigle, Lars Eggert, 288 Robert Elz, Joel Halpern, Bernie Hoeneisen, John Klensin, Barry 289 Leiba, Danny McPherson, S. Moonesamy, and Thomas Narten. 291 The editor also thanks IETF plenary meeting participants who have 292 provided useful feedback on previous versions of this draft. 294 11. Normative References 296 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 297 Recall Process: Operation of the Nominating and Recall 298 Committees", BCP 10, RFC 3777, June 2004. 300 Author's Address 302 Spencer Dawkins (editor) 303 Huawei Technologies (USA) 305 Phone: +1 214 755 3870 306 Email: spencer@wonderhamster.org