idnits 2.17.1 draft-ietf-poisson-nomcom-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 1997) is 9591 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 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 J. Galvin 3 INTERNET DRAFT CommerceNet 4 draft-ietf-poisson-nomcom-03.txt December 1997 6 IAB and IESG Selection, Confirmation, and Recall Process: 7 Operation of the Nominating and Recall Committees 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are valid for a maximum of six months and may be 17 updated, replaced, or obsoleted by other documents at any time. It 18 is inappropriate to use Internet Drafts as reference material or to 19 cite them other than as ``work in progress''. 21 To learn the current status of any Internet Draft, please check the 22 1id-abstracts.txt listing contained in one of the Internet Drafts 23 Shadow Directories on ds.internic.net (US East Coast), venera.isi.edu 24 (US West Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net 25 (Europe). 27 Abstract 29 The process by which the members of the IAB and IESG are selected, 30 confirmed, and recalled is specified. The evolution of the process 31 has relied principally on oral tradition as a means by which the 32 lessons learned could be passed on to successive committees. This 33 document is a self-consistent, organized compilation of the process 34 as it is known today. 36 1. Introduction 38 This document supercedes RFC2027, the first complete specification of 39 the process by which members of the IAB and IESG are selected, 40 confirmed, and recalled. Prior to that time, a single paragraph in 41 RFC1602 is the extent to which the process had been formally 42 recorded. 44 This revision is based on the experience of the 1996 Nominating 45 Committee, the first committee to operate according to RFC2027. The 46 following two assumptions of that specification are also true for 47 this revision. 49 (1) The Internet Research Task Force (IRTF) and Internet Research 50 Steering Group (IRSG) are not a part of the process described 51 here. 53 (2) The organization (and re-organization) of the IESG is not a 54 part of the process described here. 56 The time frames specified here use IETF meetings as a frame of 57 reference. The time frames assume that the IETF meets at least once 58 per year with that meeting occurring during the North American Spring 59 time, i.e., the IETF meets at least on or about March of each year. 61 The remainder of this document is divided into four major topics as 62 follows. 64 General 65 This a set of rules and constraints that apply to the selection 66 and confirmation process as a whole. 68 Nominating Committee Selection 69 This is the process by which volunteers from the IETF community 70 are recognized to serve on the committee that nominates 71 candidates to serve on the IESG and IAB. 73 Nominating Committee Operation 74 This is the set of principles, rules, and constraints that guide 75 the activities of the nominating committee, including the 76 confirmation process. 78 Member Recall 79 This is the process by which the behavior of a sitting member of 80 the IESG or IAB may be questioned, perhaps resulting in the 81 removal of the sitting member. 83 A final section describes how this document differs from its 84 predecessor: RFC2027. 86 2. General 88 The following set of rules apply to the selection and confirmation 89 process as a whole. If necessary, a paragraph discussing the 90 interpretation of each rule is included. 92 (1) The principal functions of the nominating committee are to 93 review the open IESG and IAB positions and to either nominate 94 its incumbent or recruit a superior candidate. 96 The nominating committee does not select the open positions to 97 be reviewed; it is instructed as to which positions to review. 99 At a minimum, the nominating committee will be given the title 100 of the position to be reviewed. The nominating committee may be 101 given a desirable set of qualifications for the candidate 102 nominated to fill each position. 104 Incumbents must notify the nominating committee if they do not 105 wish to be nominated. 107 The nominating committee does not confirm its candidates; it 108 presents its candidates to the appropriate confirming body as 109 indicated below. 111 (2) The annual selection and confirmation process is expected to 112 be completed within 3 months. 114 The annual selection and confirmation process is expected to be 115 completed one month prior to the friday of the week before the 116 Spring IETF. It is expected to begin 4 months prior to the 117 friday of the week before the Spring IETF. 119 (3) One-half of each of the then current IESG and IAB positions is 120 selected to be reviewed each year. 122 The intent of this rule to ensure the review of approximately 123 one-half of each of the sitting IESG and IAB members each year. 124 It is recognized that circumstances may exist that will require 125 the nominating committee to review more or less than one-half of 126 the current positions, e.g., if the IESG or IAB have re- 127 organized prior to this process and created new positions, or if 128 there are an odd number current positions. 130 (4) Confirmed candidates are expected to serve at least a 2 year 131 term. 133 The intent of this rule is to ensure that members of the IESG 134 and IAB serve the number of years that best facilitates the 135 review of one-half of the members each year. 137 It is consistent with this rule for the nominating committee to 138 choose one or more of the currently open positions to which it 139 may assign a term greater than 2 years in order to ensure the 140 ideal application of this rule in the future. 142 It is consistent with this rule for the nominating committee to 143 choose one or more of the currently open positions that share 144 responsibilities with other positions (both those being reviewed 145 and those sitting) to which it may assign a term greater than 2 146 years to ensure that all such members will not be reviewed at 147 the same time. 149 All member terms end during the Spring IETF meeting 150 corresponding to the end of the term for which they were 151 confirmed. The term ends no later than the second to last day 152 and no sooner than the Open Plenary session of the Spring IETF, 153 as determined by the mutual agreement of the confirmed candidate 154 and the currently sitting member. The term begins no later than 155 the last day and no sooner than the Open Plenary session of the 156 Spring IETF meeting, as determined by the mutual agreement of 157 the confirmed candidate and the currently sitting member. 159 (5) Mid-term vacancies are filled by the same rules as documented 160 here with four qualifications. First, the most recently 161 constituted nominating committee is reconvened to nominate a 162 candidate to fill the vacancy. Second, the selection and 163 confirmation process is expected to be completed within 1 164 month, with all other time periods otherwise unspecified 165 prorated accordingly. Third, the confirming body has two 166 weeks from the day it is notified of a candidate to reject the 167 candidate, otherwise the candidate is assumed to have been 168 confirmed. Fourth, the term of the confirmed candidate will 169 be either: 171 a. the remainder of the term of the open position if that remainder 172 is not less than one year. 174 b. the remainder of the term of the open position plus the next 2 175 year term if that remainder is less than one year. 177 (6) All deliberations and supporting information that relates to 178 specific nominees, candidates, and confirmed candidates are 179 confidential. 181 The nominating committee and confirming body members will be 182 exposed to confidential information as a result of their 183 deliberations, their interactions with those they consult, and 184 from those who provide requested supporting information. All 185 members and all other participants are expected to handle this 186 information in a manner consistent with its sensitivity. 188 (7) Unless otherwise specified, the advise and consent model is 189 used throughout the process. This model is characterized as 190 follows. 192 a. The IETF Executive Director advises the nominating committee of 193 the IESG and IAB positions to be reviewed. 195 b. The nominating committee selects candidates and advises the 196 confirming bodies of them. 198 c. The sitting IAB members review the IESG candidates, consenting 199 to some, all, or none. 201 If all of the candidates are confirmed, the job of the 202 nominating committee with respect to reviewing the open IESG 203 positions is considered complete. If some or none of the 204 candidates are confirmed, the nominating committee must 205 reconvene to select alternate candidates for the rejected 206 candidates. Any additional time required by the nominating 207 committee should not exceed its maximum time allotment. 209 d. The Internet Society Board of Trustees reviews the IAB 210 candidates, consenting to some, all, or none. 212 If all of the candidates are confirmed, the job of the 213 nominating committee with respect to reviewing the open IAB 214 positions is considered complete. If some or none of the 215 candidates are confirmed, the nominating committee must 216 reconvene to select alternate candidates for the rejected 217 candidates. Any additional time required by the nominating 218 committee should not exceed its maximum time allotment. 220 e. The confirming bodies decide their consent according to a 221 mechanism of their own choosing, which must ensure that at least 222 one-half of the sitting members agree with the decision. 224 At least one-half of the sitting members of the confirming 225 bodies must agree to either confirm or reject each individual 226 nominee. The agreement must be decided within a reasonable 227 timeframe. The agreement may be decided by conducting a formal 228 vote, by asserting consensus based on informal exchanges 229 (email), or by whatever mechanism is used to conduct the normal 230 business of the confirming body. 232 3. Nominating Committee Selection 234 The following set of rules apply to the creation of the nominating 235 committee and the selection of its members. 237 (1) The committee is comprised of at least a non-voting Chair, 10 238 voting volunteers, and 3 non-voting liaisons. 240 A Chair is permitted to invite additional non-voting advisors to 241 participate in some or all of the deliberations of the 242 committee. 244 (2) The Internet Society President appoints the non-voting Chair, 245 who must meet the usual requirements for membership in the 246 nominating committee. 248 The nominating committee Chair must agree to invest the time 249 necessary to complete the duties of the nominating committee and 250 to perform in the best interests of the IETF community during 251 the performance of those duties. 253 (3) The Chair obtains the list of IESG and IAB positions to be 254 reviewed and publishes it along with a solicitation for names 255 of volunteers from the IETF community willing to serve on the 256 nominating committee. 258 The list of open positions is published with the solicitation to 259 facilitate community members choosing between volunteering for 260 an open position and volunteering for the nominating committee. 262 The list and solicitation must be publicized using at least the 263 same mechanism used by the IETF secretariat for its 264 announcements. 266 (4) Members of the IETF community must have attended at least 2 of 267 the last 3 IETF meetings in order to volunteer. 269 (5) Internet Society Board of Trustees, sitting members of the 270 IAB, and sitting members of the IESG may not volunteer. 272 (6) The Chair announces the pool of volunteers from which the 10 273 voting volunteers will be randomly selected. 275 The announcement must be made using at least the same mechanism 276 used by the IETF secretariat for its announcements. 278 (7) The Chair randomly selects the 10 voting voluteers from the 279 pool of names of volunteers using a method that can be 280 independently verified to be unbiased and fair. 282 A method is fair if each eligible volunteer is equally likely to 283 be selected. A method is unbiased if no one can influence its 284 outcome. 286 The method must include an announcement of an enumerated list of 287 the pool of names together with the specific algorithm for how 288 names will be chosen from the list. The output of the selection 289 algorithm must depend on random data whose value is not known at 290 the time the list and algorithm are announced. 292 One possible method is to compute the MD5 hash of future winning 293 lottery numbers and use the result to select names from the 294 list. 296 All announcements must be made using at least the mechanism used 297 by the IETF secretariat for its announcements. 299 (8) The sitting IAB and IESG members each appoint a non-voting 300 liaison to the nominating committee from their current 301 membership who are not sitting in an open position. 303 (9) The Chair of the prior year's nominating committee serves as a 304 non-voting liaison. 306 The prior year's Chair may designate an alternate voting member 307 from the prior year's committee if the Chair is unavailable. If 308 the prior year's Chair is unavailable and is unable or unwilling 309 to make such a designation in a timely fashion, the Chair of the 310 current committee may do so. 312 (10) The Chair may solicit additional non-voting liaisons from 313 other organizations, who must meet the usual requirements for 314 membership in the nominating committee. 316 4. Nominating Committee Operation 318 The following rules apply to the operation of the nominating 319 committee. If necessary, a paragraph discussing the interpretation 320 of each rule is included. 322 The rules are organized approximately in the order in which they 323 would be invoked. 325 The term nominee refers to an individual under consideration by the 326 nominating committee. The term candidate refers to a nominee that 327 has been selected by the nominating committee to be considered for 328 confirmation by a confirming body. A confirmed candidate is a 329 candidate that has been reviewed and approved by a confirming body. 331 (1) All rules and special circumstances not otherwise specified 332 are at the discretion of the Chair. 334 Exceptional circumstances will occasionally arise during the 335 normal operation of the nominating committee. This rule is 336 intended to foster the continued forward progress of the 337 committee. All members of the committee should consider whether 338 the exception is worthy of mention in the next revision of this 339 document and followup accordingly. 341 (2) The Chair must establish and publicize milestones, which must 342 include at least a call for nominations. 344 There is a defined time period during which the selection and 345 confirmation process must be completed. The Chair must 346 establish a set of milestones which, if met in a timely fashion, 347 will result in the completion of the process on time. The Chair 348 should allow time for iterating the activities of the committee 349 if one or more candidates is not confirmed. 351 The milestones must be publicized using at least the same 352 mechanism used by the IETF secretariat for its announcements. 354 (3) The Chair must establish a voting mechanism. 356 The committee must be able to objectively determine when a 357 decision has been made during its deliberations. The criteria 358 for determining closure must be established and known to all 359 members of the nominating committee. 361 (4) At least a quorum of committee members must participate in a 362 vote. A quorum is comprised of at least 7 voting members. 364 (5) The Chair may establish a process by which a member of the 365 nominating committee may be recalled. 367 The process, if established, must be agreed to by a 3/4 majority 368 of the members of the nominating committee, including the non- 369 voting members since they would be subject to the same process. 371 (6) All members of the nominating committee may participate in all 372 deliberations. 374 The emphasis of this rule is that no member, whether voting or 375 non-voting, can be explicitly excluded from any deliberation. 376 However, a member may individually choose not to participate in 377 a deliberation. 379 (7) The Chair announces the open positions to be reviewed and the 380 call for nominees. 382 The call for nominees must include a request for comments 383 regarding the past performance of incumbents, which will be 384 considered during the deliberations of the nominating committee. 386 The announcements must be publicized using at least the same 387 mechanism used by the IETF secretariat for its announcements. 389 (8) Any member of the IETF community may nominate any member of 390 the IETF community for any open position. 392 A self-nomination is permitted. 394 (9) Nominating committee members must not be nominees. 396 To be a nominee is to enter the process of being selected as a 397 candidate and confirmed. Nominating committee members are not 398 eligible to be considered for filling any open position. 400 (10) Members of the IETF community who were recalled from any IESG 401 or IAB position during the previous two years must not be 402 nominees. 404 (11) The nominating committee selects candidates based on its 405 understanding of the IETF community's consensus of the 406 qualifications required to fill the open positions. 408 The intent of this rule is to ensure that the nominating 409 committee consults with a broad base of the IETF community for 410 input to its deliberations. 412 The consultations are permitted to include a slate of nominees, 413 if all parties to the consultation agree to observe customary 414 and reasonable rules of confidentiality. 416 A broad base of the community should include the existing 417 members of the IAB and IESG, especially sitting members who 418 share responsibilities with open positions, e.g., co-Area 419 Directors. 421 (12) Nominees should be advised that they are being considered and 422 must consent to their nomination prior to being confirmed. 424 The nominating committee should help nominees provide 425 justification to their employers. 427 A nominee's consent must be written (email is acceptable) and 428 include a commitment to provide the resources necessary to fill 429 the open position and an assurance that the nominee will perform 430 the duties of the position for which they are being considered 431 in the best interests of the IETF community. 433 (13) The nominating committee advises the confirming bodies of 434 their candidates, specifying a single candidate for each open 435 position and a testament as to how each candidate meets the 436 qualifications of an open position. 438 The testament may include a brief resume of the candidate and a 439 summary of the deliberations of the nominating committee. 441 (14) With respect to any action to be taken in the context of 442 notifying and announcing confirmed candidates, and notifying 443 rejected nominees and candidates, the action must be valid 444 according to all of the rules specified below prior to its 445 execution. 447 a. Up until a candidate is confirmed, the identity of the candidate 448 must be kept confidential. 450 b. The identity of all nominees must be kept confidential (except 451 that the nominee may publicize their intentions). 453 c. Rejected nominees may be notified as soon as they are rejected. 455 d. Rejected candidates may be notified as soon as they are 456 rejected. 458 e. Rejected nominees and candidates must be notified prior to 459 announcing confirmed candidates. 461 f. Confirmed candidates may be notified and announced as soon as 462 they are confirmed. 464 It is consistent with these rules for a nominee to never know if 465 they were a candidate or not. 467 It is consistent with these rules for some nominees to be 468 rejected early in the process and for some nominees to be kept 469 as alternates in case a candidate is rejected by a confirming 470 body. In the matter of whether a confirmed candidate was a 471 first choice or an alternate, that information need not ever be 472 disclosed and, in fact, probably never should be. 474 It is consistent with these rules for confirmed candidates to be 475 notified and announced as quickly as possible instead of 476 requiring all confirmed candidates to wait until all open 477 positions have been reviewed. 479 When consulting with individual members of the IETF community, 480 if all parties to the consultation agree to observe customary 481 and reasonable rules of confidentiality the consultations are 482 permitted to include a slate of nominees. 484 The announcements must be publicized using at least the same 485 mechanism used by the IETF secretariat for its announcements. 487 5. Member Recall 489 The following rules apply to the recall process. If necessary, a 490 paragraph discussing the interpretation of each rule is included. 492 (1) Anyone may request the recall of any sitting IAB or IESG 493 member, at any time, upon written (email is acceptable) 494 request with justification to the Internet Society President. 496 (2) Internet Society President shall appoint a Recall Committee 497 Chair. 499 The Internet Society President must not evaluate the recall 500 request. It is explicitly the responsibility of the IETF 501 community to evaluate the behavior of its leaders. 503 (3) The recall committee is created according to the same rules as 504 is the nominating committee with the qualifications that the 505 person being investigated and the person requesting the recall 506 must not be a member of the recall committee in any capacity. 508 (4) The recall committee operates according to the same rules as 509 the nominating committee with the qualification that there is 510 no confirmation process. 512 (5) The recall committee investigates the circumstances of the 513 justification for the recall and votes on its findings. 515 The investigation must include at least both an opportunity for 516 the member being recalled to present a written statement and 517 consultation with third parties. 519 (6) A 3/4 majority of the members who vote on the question is 520 required for a recall. 522 (7) If a sitting member is recalled the open position is to be 523 filled according to the mid-term vacancy rules. 525 6. Changes From RFC2027 527 (1) In order to foster better communication between nominating 528 committees from one year to the next the Chair of each year's 529 committee has been added as a non-voting liaison of the next 530 year's committee. 532 (2) In order to confirm the eligibility of each volunteer in the 533 pool of names from which nominating committee members are 534 chosen the Chair must announce the list prior to the random 535 selection. 537 (3) In order to confirm the random selection process used to 538 select voting nominating committee members the Chair must 539 announce the fair and unbiased method used in advance of its 540 execution. 542 (4) Some guidance was added to ensure that the nominating 543 committee consults with a broad base of the IETF community. 545 (5) Some guidance was added to ensure that the nominating 546 committee understands that it may name prospective nominees 547 when consulting with individual members of the IETF community. 549 (6) Some guidance was added to ensure that the nominating 550 committee understands that it is responsible for ensuring that 551 an appropriate set of one-half of each of the IESG and IAB 552 positions are reviewed each year. 554 7. Security Considerations 556 Any selection, confirmation, or recall process necessarily involves 557 investigation into the qualifications and activities of prospective 558 candidates. The investigation may reveal confidential or otherwise 559 private information about candidates to those participating in the 560 process. Each person who participates in any aspect of the process 561 has a responsibility to maintain the confidentiality of any and all 562 information not explicitly identified as suitable for public 563 dissemination. 565 8. Editor's Address 567 James M. Galvin 568 CommerceNet Consortium 569 PO Box 220 570 Glenwood, MD, 21738 572 Table of Contents 574 Status of this Memo ........................................... 1 575 Abstract ...................................................... 1 576 1 Introduction ................................................. 1 577 2 General ...................................................... 3 578 3 Nominating Committee Selection ............................... 6 579 4 Nominating Committee Operation ............................... 8 580 5 Member Recall ................................................ 12 581 6 Changes From RFC2027 ......................................... 12 582 7 Security Considerations ...................................... 13 583 8 Editor's Address ............................................. 13