idnits 2.17.1 draft-moonesamy-nomcom-selection-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 4, 2012) is 4283 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: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Moonesamy, Ed. 3 Updates: 3777 (if approved) 4 Intended Status: Best Current Practice 5 Expires: February 5, 2012 August 4, 2012 7 The Nominating Committee Process: Selection of volunteers 8 draft-moonesamy-nomcom-selection-01 10 Abstract 12 RFC 3777 specifies the process by which members of the Internet 13 Architecture Board, Internet Engineering Steering Group and IETF 14 Administrative Oversight Committee are selected, confirmed, and 15 recalled. 17 This document updates RFC 3777 to increase the number of volunteers 18 who are eligible to serve on NomCom and to increase the selection of 19 volunteers having different primary affiliations. It also makes some 20 updates to include the IETF Administrative Oversight Committee. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Updated Text from RFC 3777 . . . . . . . . . . . . . . . . . . 3 62 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 63 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 65 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 67 6.2 Informative References . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1 Introduction 72 RFC 3777 [RFC3777] specifies the process by which members of the 73 Internet Architecture Board (IAB), Internet Engineering Steering 74 Group (IESG) and IETF Administrative Oversight Committee (IAOC) are 75 selected, confirmed, and recalled. The Nominating Committee 76 Selection is the process by which volunteers who will serve on the 77 committee (NomCom) are recognized. A random selection of volunteers 78 is used to ensure that the selection is unbiased [RFC3797]. 80 One of the rules for eligibility to serve on NomCom is that 81 volunteers must have attended at least three of the last five IETF 82 meetings in order to volunteer. Previously, a large number of 83 meetings were held in North America. There has been a change in the 84 selection of meeting venues in 2012 as there is a willingness to 85 consider locations outside North America. Volunteers familiar with 86 the IETF processes and procedures end up not being eligible to serve 87 on NomCom if they cannot attend the third of the last five last IETF 88 meetings. 90 Over the last few years a small number of large sponsors for IETF 91 participants have provided a disproportionate number of NomCom 92 volunteers. Since 2010 there has been several occurrences where two 93 volunteers with the same primary affiliation were selected for the 94 nominating committee. 96 This document updates RFC 3777 [RFC3777] to increase the number of 97 volunteers who are eligible to serve on NomCom and to increase the 98 selection of volunteers having different primary affiliations. It 99 also makes some updates to include the IETF Administrative Oversight 100 Committee. 102 2. Updated Text from RFC 3777 104 RFC 3777 [RFC3777], Section 1, "Introduction", Paragraph 11, is 105 replaced as follows: 107 Member Recall: This is the process by which the behavior of a 108 sitting member of the IESG, IAB or IAOC may be questioned, 109 perhaps resulting in the removal of the sitting member. 111 Section 2, "Definitions", Paragraph 5 and 6, are replaced as follows: 113 nominee: A person who is being or has been considered for one or 114 more open positions of the IESG, IAB or IAOC. 116 sitting member: A person who is currently serving a term of 117 membership in the IESG, IAB, IAOC or ISOC Board of Trustees. 119 Section 3, "General", Paragraph 10 and 11, are replaced as follows: 121 The principal functions of the nominating committee are to review 122 each open IESG, IAB and IAOC position and to either nominate its 123 incumbent or a superior candidate. 125 Although there is no term limit for serving in any IESG, IAB or 126 IAOC position, the nominating committee may use length of service 127 as one of its criteria for evaluating an incumbent. 129 Section 3, "General", Bullet 7, is replaced as follows: 131 Unless otherwise specified, the advice and consent model is used 132 throughout the process. This model is characterized as follows. 134 1. The IETF Executive Director informs the nominating committee of 135 the IESG, IAB and IAOC positions to be reviewed. 137 The IESG, IAB and IAOC are responsible for providing summary of 138 the expertise desired of the candidates selected for their 139 respective open positions to the Executive Director. The 140 summaries are provided to the nominating committee for its 141 consideration. 143 2. The nominating committee selects candidates based on its 144 understanding of the IETF community's consensus of the 145 qualifications required and advises each confirming body of its 146 respective candidates. 148 3. The confirming bodies review their respective candidates, they 149 may at their discretion communicate with the nominating 150 committee, and then consent to some, all, or none of the 151 candidates. 153 The sitting IESG members review IAOC candidates. 155 The sitting IAB members review the IESG candidates. 157 The Internet Society Board of Trustees reviews the IAB 158 candidates. 160 The confirming bodies conduct their review using all 161 information and any means acceptable to them, including but not 162 limited to the supporting information provided by the 163 nominating committee, information known personally to members 164 of the confirming bodies and shared within the confirming body, 165 the results of interactions within the confirming bodies, and 166 the confirming bodies interpretation of what is in the best 167 interests of the IETF community. 169 If all of the candidates are confirmed, the job of the 170 nominating committee with respect to those open positions is 171 complete. 173 If some or none of the candidates submitted to a confirming 174 body are confirmed, the confirming body should communicate with 175 the nominating committee both to explain the reason why all the 176 candidates were not confirmed and to understand the nominating 177 committee's rationale for its candidates. 179 The confirming body may reject individual candidates, in which 180 case the nominating committee must select alternate candidates 181 for the rejected candidates. 183 Any additional time required by the nominating committee should 184 not exceed its maximum time allotment. 186 4. A confirming body decides whether it confirms each candidate 187 using a confirmation decision rule chosen by the confirming 188 body. 190 If a confirming body has no specific confirmation decision 191 rule, then confirming a given candidate should require at least 192 one-half of the confirming body's sitting members to agree to 193 that confirmation. 195 The decision may be made by conducting a formal vote, by 196 asserting consensus based on informal exchanges (e.g., email), 197 or by any other mechanism that is used to conduct the normal 198 business of the confirming body. 200 Regardless of which decision rule the confirming body uses, any 201 candidate that is not confirmed under that rule is considered 202 to be rejected. 204 The confirming body must make its decision within a reasonable 205 time frame. The results from the confirming body must be 206 reported promptly to the nominating committee. 208 Section 4, "Nominating Committee Selection", Rule 7, is replaced as 209 follows: 211 Liaisons are responsible for ensuring the nominating committee in 212 general and the Chair in particular execute their assigned duties 213 in the best interests of the IETF community. 215 Liaisons are expected to represent the views of their respective 216 organizations during the deliberations of the committee. They 217 should provide information as requested or when they believe it 218 would be helpful to the committee. 220 Liaisons from the IESG, IAB and IAOC are expected to provide 221 information to the nominating committee regarding the operation, 222 responsibility, and composition of their respective bodies. 224 Liaisons are expected to convey questions from the committee to 225 their respective organizations and responses to those questions to 226 the committee, as requested by the committee. 228 Liaisons from the IESG, IAB, IAOC, and Internet Society Board of 229 Trustees (if one was appointed) are expected to review the 230 operation and executing process of the nominating committee and to 231 report any concerns or issues to the Chair of the nominating 232 committee immediately. If they can not resolve the issue between 233 themselves, liaisons must report it according to the dispute 234 resolution process stated elsewhere in this document. 236 Liaisons from confirming bodies are expected to assist the 237 committee in preparing the testimony it is required to provide 238 with its candidates. 240 Liaisons may have other nominating committee responsibilities as 241 required by their respective organizations or requested by the 242 nominating committee, except that such responsibilities may not 243 conflict with any other provisions of this document. 245 Liaisons do not vote on the selection of candidates. 247 Section 4, "Nominating Committee Selection", Rule 8, is replaced as 248 follows: 250 The sitting IAB, IESG and IAOC members each appoint a liaison from 251 their current membership, someone who is not sitting in an open 252 position, to serve on the nominating committee. 254 Section 4, "Nominating Committee Selection", Rule 14, is replaced as 255 follows: 257 Members of the IETF community must have attended at least three of 258 the last six IETF meetings in order to volunteer. 260 The six meetings are the six most recent meetings that ended prior 261 to the date on which the solicitation for nominating committee 262 volunteers was submitted for distribution to the IETF community. 264 The IETF Secretariat is responsible for confirming that volunteers 265 have met the attendance requirement. 267 Volunteers must provide their full name, email address, and 268 primary company or organization affiliation (if any) when 269 volunteering. 271 Volunteers are expected to be familiar with the IETF processes and 272 procedures, which are readily learned by active participation in a 273 working group and especially by serving as a document editor or 274 working group chair. 276 Section 4, "Nominating Committee Selection", Rule 15, is replaced as 277 follows: 279 Sitting members may not volunteer to serve on the nominating 280 committee. 282 Section 4, "Nominating Committee Selection", Rule 16, is replaced as 283 follows: 285 The Chair announces both the list of the pool of volunteers from 286 which the 10 voting volunteers will be randomly selected and the 287 method with which the selection will be completed. 289 The announcement should be made at least 1 week prior to the date 290 on which the random selection will occur. 292 The pool of volunteers must be enumerated or otherwise indicated 293 according to the needs of the selection method to be used. 295 The announcement must specify the data that will be used as input 296 to the selection method. The method must depend on random data 297 whose value is not known or available until the date on which the 298 random selection will occur. 300 It must be possible to independently verify that the selection 301 method used is both fair and unbiased. A method is fair if each 302 eligible volunteer is equally likely to be selected. A method is 303 unbiased if no one can influence its outcome in favor of a 304 specific outcome. 306 It must be possible to repeat the selection method, either through 307 iteration or by restarting in such a way as to remain fair and 308 unbiased. This is necessary to replace selected volunteers should 309 they become unavailable after selection. 311 The selection method must produce an ordered list of volunteers. 313 One possible selection method is described in RFC 3797 [RFC3797]. 315 Section 4, "Nominating Committee Selection", Rule 17, is replaced as 316 follows: 318 "The Chair randomly selects the ten voting volunteers from the 319 pool of names of volunteers and announces the members of the 320 nominating committee. 322 No more than one volunteer with the same primary affiliation may 323 be selected for the nominating committee. The Chair reviews the 324 primary affiliation of each volunteer selected by the method in 325 turn. If the primary affiliation for a volunteer is the same as 326 previously selected volunteer, that volunteer is removed from 327 consideration and the method is repeated to identify the next 328 eligible volunteer. 330 There must be at least two announcements of all members of the 331 nominating committee. 333 The first announcement should occur as soon after the random 334 selection as is reasonable for the Chair. The community must have 335 at least one week during which any member may challenge the 336 results of the random selection. 338 The challenge must be made in writing (email is acceptable) to the 339 Chair. The Chair has 48 hours to review the challenge and offer a 340 resolution to the member. If the resolution is not accepted by 341 the member, that member may report the challenge according to the 342 dispute resolution process stated elsewhere in this document. 344 If a selected volunteer, upon reading the announcement with the 345 list of selected volunteers, finds that two or more other 346 volunteers have the same affiliation, then the volunteer should 347 notify the Chair who will determine the appropriate action. 349 During at least the one week challenge period the Chair must 350 contact each of the members and confirm their willingness and 351 availability to serve. The Chair should make every reasonable 352 effort to contact each member. 354 * If the Chair is unable to contact a liaison the problem is 355 referred to the respective organization to resolve. The Chair 356 should allow a reasonable amount of time for the organization 357 to resolve the problem and then may proceed without the 358 liaison. 360 * If the Chair is unable to contact an advisor the Chair may 361 elect to proceed without the advisor, except for the prior 362 year's Chair for whom the Chair must consult with the Internet 363 Society President as stated elsewhere in this document. 365 * If the Chair is unable to contact a voting volunteer the Chair 366 must repeat the random selection process in order to replace 367 the unavailable volunteer. There should be at least one day 368 between the announcement of the iteration and the selection 369 process. 371 After at least one week and confirming that 10 voting volunteers 372 are ready to serve, the Chair makes the second announcement of the 373 members of the nominating committee, which officially begins the 374 term of the nominating committee. 376 3 Security Considerations 378 The document makes changes to the IETF process. These changes will 379 not affect the security of the Internet. 381 The IETF community depends on the honor and integrity of the 382 participants to make the process work. Instead of defining 383 "affiliation" this document encourages the volunteers not to cause 384 any perception that their sponsors are "gaming" the system. 386 4 IANA Considerations 388 This document does not require IANA to take any action. 390 5. Acknowledgements 392 Most of text in this document is from RFC 3777 edited by James M. 393 Galvin. Andrew G. Malis suggested loosening Rule 14 to six previous 394 meetings as it is more likely for a volunteer to be familiar with the 395 people that currently contribute to the IETF. 397 6 References 399 6.1 Normative References 401 [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, 402 and Recall Process: Operation of the Nominating and Recall 403 Committees", BCP 10, RFC 3777, June 2004. 405 6.2 Informative References 407 [RFC3797] Eastlake 3rd, D., "Publicly Verifiable Nominations 408 Committee (NomCom) Random Selection", RFC 3797, June 2004. 410 Authors' Addresses 412 S. Moonesamy (editor) 413 76, Ylang Ylang Avenue 414 Quatres Bornes 415 Mauritius 417 Email: sm+ietf@elandsys.com