idnits 2.17.1 draft-dawkins-nomcom-openlist-03.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 (May 24, 2009) is 5441 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) May 24, 2009 5 Intended status: BCP 6 Expires: November 25, 2009 8 Nominating Committee Process: Open Disclosure of Willing Nominees 9 draft-dawkins-nomcom-openlist-03 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 November 25, 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 NomCom 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 . . . . . . . . . . . . . . . . . . . . . 8 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. 89 [RFC3777] describes the confidential nature of NomCom deliberations 90 in 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), all working group chairs (for IAB and IAOC 119 positions), and all document authors. The combined target audience 120 for all short lists includes multiple hundreds of recipients - recent 121 NomComs have sent out about 1500 requests for short list feedback. 123 This practice is unavoidable, because most NomCom members will not 124 have personal experience with most nominees for most positions, but 125 it is periodically challenged because it's not explicitly allowed as 126 an exception to the blanket requirement for confidentiality. 128 In an attempt to maintain the required level of confidentiality, past 129 NomComs have also included "ringers" (as "padding") on the short list 130 - nominees who have notified NomCom that they are NOT willing to be 131 considered. Since anyone who sees the short list does not know who 132 the ringers are, consciencious IETF participants also provide 133 feedback on nominees who have already declined. This is a waste of 134 precious IETF-participant cycles, and there are widespread reports 135 that strict confidentiality about which candidates are "real", and 136 which are included as "padding", is not successfully maintained in 137 practice. Even if confidentiality about padding is maintained, the 138 community is aware that some nominees on the short list aren't 139 willing to be considered, but doesn't know which nominees are really 140 willing, and this may act as a disincentive to comment on the NON- 141 padding nominees. 143 We also note that the practice of publishing a "short list" penalizes 144 IETF participants who aren't members of one of the target audiences 145 being surveyed - they have no way of knowing who is being considered, 146 except for incumbent(s), and have little incentive to provide 147 feedback to NomCom on individuals who might not even be nominees. 149 4. Asking the Entire Community for Feedback 151 NomComs are not required to ask for community input at all, but at 152 the current IETF scale, many NomComs DO request community input, 153 because members do not have personal experience with all nominees for 154 all positions under review. 156 We assume that asking the larger community for feedback about these 157 nominees is preferable to NomCom members without personal experience 158 simply deferring to the members of the NomCom who DO have personal 159 experience with specific nominees. 161 We assume that asking for feedback from the entire community is 162 preferable to asking for feedback from large segments of the 163 community, while keeping the rest of the community "in the dark". 165 5. Publishing a Nominee List 167 In proposing that a nominee list be published as part of NomCom's 168 request for feedback from the community, we considered three 169 possibilities: 171 1. Asking for feedback on all nominees, whether they are willing to 172 be considered or not. 174 2. Asking for feedback on all nominees who are willing to be 175 considered. 177 3. Asking for feedback on the nominees that NomCom is seriously 178 considering (the "short list"). 180 Asking for feedback on nominees who are not willing to be considered 181 is a waste of precious IETF-participant cycles, and may make it less 182 likely that NomCom would receive feedback on some nominees who ARE 183 willing to be considered. 185 Asking for feedback on all nominees who are willing to be considered 186 allows the community to point out specific strengths and weaknesses 187 of all nominees, and this feedback should be useful to NomCom in 188 deciding which nominees to seriously consider. It also allows NomCom 189 to receive feedback on nominees who might not appear on a "short 190 list" initially, in the event that a strong nominee is suddenly 191 unwilling or unable to serve. 193 We also note that the list of nominees would include incumbents who 194 are willing to be considered for an additional term. 196 6. Concerns About Open Nominee Lists 198 This section acknowledges possible concerns about publishing open 199 nominee lists in previous discussions. 201 One concern is that nominees who are willing to be considered if the 202 nominee list is not published, would not be willing to be considered 203 if the nominee list is published. This reluctance might be cultural, 204 the result of personal pride, or the result of the fear of 205 retribution, for a nominee being considered as a replacement for the 206 nominee's managing Area Director (this concern is usually raised in 207 an IESG context). 209 We note that (for example) the Internet Architecture Board publishes 210 the nominee list for their representative to the Internet Society 211 Board of Trustees, without apparent ill effects, but we are also 212 willing to accept that a NomCom might consider nominees whose names 213 have not been announced, for a variety of reasons, if this is the 214 right thing to do, in NomCom's judgement. 216 Another concern is that publishing the nominee list publicly would 217 lead to "lobbying", public statements supporting nominees on the IETF 218 mailing list, etc. 220 We note that nominees know they are under consideration and can 221 "lobby" today, by telling people they are willing to be considered 222 and asking them to provide feedback to NomCom. Several nominees 223 (both incumbents and non-incumbents) have posted statements of 224 candidacy to the IETF Discussion mailing list in recent years, for 225 example. 227 7. Updated text from RFC 3777 229 At the end of the three paragraphs in [RFC3777], section 3, 230 "General", bullet 6, which are currently: 232 All deliberations and supporting information that relates to 233 specific nominees, candidates, and confirmed candidates are 234 confidential. 236 The nominating committee and confirming body members will be 237 exposed to confidential information as a result of their 238 deliberations, their interactions with those they consult, and 239 from those who provide requested supporting information. All 240 members and all other participants are expected to handle this 241 information in a manner consistent with its sensitivity. 243 It is consistent with this rule for current nominating committee 244 members who have served on prior nominating committees to advise 245 the current committee on deliberations and results of the prior 246 committee, as necessary and appropriate. 248 add the following paragraphs: 250 The list of nominees willing to be considered for positions under 251 review in the current NomCom cycle is not confidential. The 252 NomCom may publish a list of names of nominees who are willing to 253 be considered for positions under review to the community, in 254 order to obtain feedback from the community on these nominees. 256 The NomCom may publish an updated list if the NomCom considers 257 this necessary. For example, the NomCom might publish an updated 258 list if the NomCom identifies errors/omissions in a previously- 259 published version of the public list, or if the NomCom finds it 260 necessary to call for additional nominees, and these nominees 261 indicate a willingness to be considered before NomCom has 262 completed its deliberations. 264 The NomCom may consider nominees without asking for community 265 feedback. However, if the NomCom wishes to request community 266 feedback, it should request feedback from the entire community. 268 The list of nominees published for a specific position should 269 contain only the names of nominees who are willing to be 270 considered for the position under review. 272 Feedback on nominees should always be provided privately to 273 NomCom. Nominees should not solicit support, and other IETF 274 community members should not post statements of support/ 275 non-support for nominees in any public forum, 277 8. Security Considerations 279 This specification describes issues with the current IETF Nominating 280 Committee process ([RFC3777]) and proposes an update to allow the 281 NomCom to solicit feedback from the entire community on nominees 282 under consideration. No security considerations apply. 284 9. IANA Considerations 286 No IANA actions are requested in this specification. 288 10. Acknowledgements 290 The editor thanks the following folks who have provided useful 291 observations and guidance on previous versions of this draft: Fred 292 Baker, Ross Callon, Brian Carpenter, Leslie Daigle, Lars Eggert, 293 Robert Elz, Joel Halpern, Bernie Hoeneisen, John Klensin, Barry 294 Leiba, Danny McPherson, S. Moonesamy, Thomas Narten. 296 The editor also thanks IETF plenary meeting participants who have 297 provided useful feedback on previous versions of this draft. 299 11. Normative References 301 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 302 Recall Process: Operation of the Nominating and Recall 303 Committees", BCP 10, RFC 3777, June 2004. 305 Author's Address 307 Spencer Dawkins (editor) 308 Huawei Technologies (USA) 310 Phone: +1 214 755 3870 311 Email: spencer@wonderhamster.org