idnits 2.17.1 draft-ietf-poisson-nomcom-01.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-04-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 (August 1997) is 9744 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. -------------------------------------------------------------------------------- 1 Network Working Group J. Galvin 2 INTERNET DRAFT CommerceNet 3 draft-ietf-poisson-nomcom-01.txt August 1997 5 IAB and IESG Selection, Confirmation, and Recall Process: 6 Operation of the Nominating and Recall Committees 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are valid for a maximum of six months and may be 16 updated, replaced, or obsoleted by other documents at any time. It 17 is inappropriate to use Internet Drafts as reference material or to 18 cite them other than as ``work in progress''. 20 To learn the current status of any Internet Draft, please check the 21 1id-abstracts.txt listing contained in one of the Internet Drafts 22 Shadow Directories on ds.internic.net (US East Coast), venera.isi.edu 23 (US West Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net 24 (Europe). 26 Abstract 28 The process by which the members of the IAB and IESG are selected, 29 confirmed, and recalled is specified. The evolution of the process 30 has relied principally on oral tradition as a means by which the 31 lessons learned could be passed on to successive committees. This 32 document is a self-consistent, organized compilation of the process 33 as it is known today. 35 1. Introduction 37 This document supercedes RFC2027, the first complete specification of 38 the process by which members of the IAB and IESG are selected, 39 confirmed, and recalled. Prior to that time, a single paragraph in 40 RFC1602 is the extent to which the process had been formally 41 recorded. 43 This revision is based on the experience of the 1996 Nominating 44 Committee, the first committee to operate according to RFC2027. The 45 following two assumptions of that specification are also true for 46 this revision. 48 (1) The Internet Research Task Force (IRTF) and Internet Research 49 Steering Group (IRSG) are not a part of the process described 50 here. 52 (2) The organization (and re-organization) of the IESG is not a 53 part of the process described here. 55 The time frames specified here use IETF meetings as a frame of 56 reference. The time frames assume that the IETF meets at least once 57 per year with that meeting occurring during the North American Spring 58 time, i.e., the IETF meets at least on or about March of each year. 60 The remainder of this document is divided into four major topics as 61 follows. 63 General 64 This a set of rules and constraints that apply to the selection 65 and confirmation process as a whole. 67 Nominating Committee Selection 68 This is the process by which volunteers from the IETF community 69 are recognized to serve on the committee that nominates 70 candidates to serve on the IESG and IAB. 72 Nominating Committee Operation 73 This is the set of principles, rules, and constraints that guide 74 the activities of the nominating committee, including the 75 confirmation process. 77 Member Recall 78 This is the process by which the behavior of a sitting member of 79 the IESG or IAB may be questioned, perhaps resulting in the 80 removal of the sitting member. 82 A final section describes how this document differs from its 83 predecessor: RFC2027. 85 2. General 87 The following set of rules apply to the selection and confirmation 88 process as a whole. If necessary, a paragraph discussing the 89 interpretation of each rule is included. 91 (1) The principal functions of the nominating committee are to 92 review the open IESG and IAB positions and to either nominate 93 its incumbent or recruit a superior candidate. 95 The nominating committee does not select the open positions to 96 be reviewed; it is instructed as to which positions to review. 98 At a minimum, the nominating committee will be given the title 99 of the position to be reviewed. The nominating committee may be 100 given a desirable set of qualifications for the candidate 101 nominated to fill each position. 103 Incumbents must notify the nominating committee if they do not 104 wish to be nominated. 106 The nominating committee does not confirm its candidates; it 107 presents its candidates to the appropriate confirming body as 108 indicated below. 110 (2) The annual selection and confirmation process is expected to 111 be completed within 3 months. 113 The annual selection and confirmation process is expected to be 114 completed one month prior to the friday of the week before the 115 Spring IETF. It is expected to begin 4 months prior to the 116 friday of the week before the Spring IETF. 118 (3) One-half of each of the then current IESG and IAB positions is 119 selected to be reviewed each year. 121 The intent of this rule to ensure the review of at least one- 122 half of each of the sitting IESG and IAB members each year. It 123 is recognized that circumstances may exist that will require the 124 nominating committee to review more than one-half of the current 125 positions, e.g., if the IESG or IAB have re-organized prior to 126 this process and created new positions. 128 (4) Confirmed candidates are expected to serve at least a 2 year 129 term. 131 The intent of this rule is to ensure that members of the IESG 132 and IAB serve the number of years that best facilitates the 133 review of one-half of the members each year. 135 It is consistent with this rule for the nominating committee to 136 choose one or more of the currently open positions to which it 137 may assign a term greater than 2 years in order to ensure the 138 ideal application of this rule in the future. 140 It is consistent with this rule for the nominating committee to 141 choose one or more of the currently open positions that share 142 responsibilities with other positions (both those being reviewed 143 and those sitting) to which it may assign a term greater than 2 144 years to ensure that all such members will not be reviewed at 145 the same time. 147 All member terms end during the Spring IETF meeting 148 corresponding to the end of the term for which they were 149 confirmed. The term ends no later than the second to last day 150 and no sooner than the Open Plenary session of the Spring IETF, 151 as determined by the mutual agreement of the confirmed candidate 152 and the currently sitting member. The term begins no later than 153 the last day and no sooner than the Open Plenary session of the 154 Spring IETF meeting, as determined by the mutual agreement of 155 the confirmed candidate and the currently sitting member. 157 (5) Mid-term IESG vacancies are filled by the same rules as 158 documented here with four qualifications. First, the most 159 recently constituted nominating committee is reconvened to 160 nominate a candidate to fill the vacancy. Second, the 161 selection and confirmation process is expected to be completed 162 within 1 month, with all other time periods otherwise 163 unspecified prorated accordingly. Third, the confirming body 164 has two weeks from the day it is notified of a candidate to 165 reject the candidate, otherwise the candidate is assumed to 166 have been confirmed. Fourth, the term of the confirmed 167 candidate will be either: 169 a. the remainder of the term of the open position if that remainder 170 is not less than one year. 172 b. the remainder of the term of the open position plus the next 2 173 year term if that remainder is less than one year. 175 (6) Mid-term IAB vacancies are filled by the same rules as 176 documented here with four qualifications. First, the most 177 recently constituted nominating committee is reconvened to 178 nominate a candidate to fill the vacancy. Second, the 179 selection and confirmation process is expected to be completed 180 within 1 month, with all other time periods otherwise 181 unspecified prorated accordingly. Third, the confirming body 182 has two weeks from the day it is notified of a candidate to 183 reject the candidate, otherwise the candidate is assumed to 184 have been confirmed. Fourth, the term of the confirmed 185 candidate will be either: 187 a. the remainder of the term of the open position if that remainder 188 is not less than one year. 190 b. the remainder of the term of the open position plus the next 2 191 year term if that remainder is less than one year. 193 (7) All deliberations and supporting information of all the 194 participants in the selection and confirmation process are 195 confidential. 197 The nominating committee and confirming body members will be 198 exposed to confidential information as a result of their 199 deliberations, their interactions with those they consult, and 200 from nominees who provide requested supporting information. All 201 members and all other participants are expected to handle this 202 information in a manner consistent with its sensitivity. 204 (8) Unless otherwise specified, the advise and consent model is 205 used throughout the process. This model is characterized as 206 follows. 208 a. The IETF Executive Director advises the nominating committee of 209 the IESG and IAB positions to be reviewed. 211 b. The nominating committee selects candidates and advises the 212 confirming bodies of them. 214 c. The sitting IAB members review the IESG candidates, consenting 215 to some, all, or none. 217 If all of the candidates are confirmed, the job of the 218 nominating committee with respect to reviewing the open IESG 219 positions is considered complete. If some or none of the 220 candidates are confirmed, the nominating committee must 221 reconvene to select alternate candidates for the rejected 222 candidates. Any additional time required by the nominating 223 committee should not exceed its maximum time allotment. 225 d. The Internet Society Board of Trustees reviews the IAB 226 candidates, consenting to some, all, or none. 228 If all of the candidates are confirmed, the job of the 229 nominating committee with respect to reviewing the open IAB 230 positions is considered complete. If some or none of the 231 candidates are confirmed, the nominating committee must 232 reconvene to select alternate candidates for the rejected 233 candidates. Any additional time required by the nominating 234 committee should not exceed its maximum time allotment. 236 e. The confirming bodies decide their consent according to a 237 mechanism of their own choosing, which must ensure that at least 238 one-half of the sitting members agree with the decision. 240 At least one-half of the sitting members of the confirming 241 bodies must agree to either confirm or reject each individual 242 nominee. The agreement must be decided within a reasonable 243 timeframe. The agreement may be decided by conducting a formal 244 vote, by asserting consensus based on informal exchanges 245 (email), or by whatever mechanism is used to conduct the normal 246 business of the confirming body. 248 3. Nominating Committee Selection 250 The following set of rules apply to the creation of the nominating 251 committee and the selection of its members. 253 (1) The committee is comprised of at least a non-voting Chair, 10 254 voting volunteers, and 3 non-voting liaisons. 256 A Chair is permitted to invite additional non-voting advisors to 257 participate in some or all of the deliberations of the 258 committee. 260 (2) The Internet Society President appoints the non-voting Chair, 261 who must meet the usual requirements for membership in the 262 nominating committee. 264 The nominating committee Chair must agree to invest the time 265 necessary to complete the duties of the nominating committee and 266 to perform in the best interests of the IETF community during 267 the performance of those duties. 269 (3) The Chair obtains the list of IESG and IAB positions to be 270 reviewed and publishes it along with a solicitation for names 271 of volunteers from the IETF community willing to serve on the 272 nominating committee. 274 The list of open positions is published with the solicitation to 275 facilitate community members choosing between volunteering for 276 an open position and volunteering for the nominating committee. 278 The list and solicitation must be publicized using at least the 279 same mechanism used by the IETF secretariat for its 280 announcements. 282 (4) Members of the IETF community must have attended at least 2 of 283 the last 3 IETF meetings in order to volunteer. 285 (5) Internet Society Board of Trustees, sitting members of the 286 IAB, and sitting members of the IESG may not volunteer. 288 (6) The Chair announces the pool of volunteers from which the 10 289 voting volunteers will be randomly selected. 291 The announcement must be made using at least the same mechanism 292 used by the IETF secretariat for its announcements. 294 (7) The Chair randomly selects the 10 voting voluteers from the 295 pool of names of volunteers using a method that can be 296 independently verified to be unbiased and fair. 298 A method is fair if each eligible volunteer is equally likely to 299 be selected. A method is unbiased if no one can influence its 300 outcome. 302 The method must include an announcement of an enumerated list of 303 the pool of names together with the specific algorithm for how 304 names will be chosen from the list. The output of the selection 305 algorithm must depend on random data whose value is not known at 306 the time the list and algorithm are announced. 308 One possible method is to compute the MD5 hash of future winning 309 lottery numbers and use the result to select names from the 310 list. 312 All announcements must be made using at least the mechanism used 313 by the IETF secretariat for its announcements. 315 (8) The sitting IAB and IESG members each appoint a non-voting 316 liaison to the nominating committee from their current 317 membership who are not sitting in an open position. 319 (9) The Chair of the prior year's nominating committee serves as a 320 non-voting liaison. 322 The prior year's Chair may designate an alternate voting member 323 from the prior year's committee if the Chair is unavailable. 325 (10) The Chair may solicit additional non-voting liaisons from 326 other organizations, who must meet the usual requirements for 327 membership in the nominating committee. 329 4. Nominating Committee Operation 331 The following rules apply to the operation of the nominating 332 committee. If necessary, a paragraph discussing the interpretation 333 of each rule is included. 335 The rules are organized approximately in the order in which they 336 would be invoked. 338 The term nominee refers to an individual under consideration by the 339 nominating committee. The term candidate refers to a nominee that 340 has been selected by the nominating committee to be considered for 341 confirmation by a confirming body. A confirmed candidate is a 342 candidate that has been reviewed and approved by a confirming body. 344 (1) All rules and special circumstances not otherwise specified 345 are at the discretion of the Chair. 347 Exceptional circumstances will occasionally arise during the 348 normal operation of the nominating committee. This rule is 349 intended to foster the continued forward progress of the 350 committee. All members of the committee should consider whether 351 the exception is worthy of mention in the next revision of this 352 document and followup accordingly. 354 (2) The Chair must establish and publicize milestones, which must 355 include at least a call for nominations. 357 There is a defined time period during which the selection and 358 confirmation process must be completed. The Chair must 359 establish a set of milestones which, if met in a timely fashion, 360 will result in the completion of the process on time. The Chair 361 should allow time for iterating the activities of the committee 362 if one or more candidates is not confirmed. 364 The milestones must be publicized using at least the same 365 mechanism used by the IETF secretariat for its announcements. 367 (3) The Chair must establish a voting mechanism. 369 The committee must be able to objectively determine when a 370 decision has been made during its deliberations. The criteria 371 for determining closure must be established and known to all 372 members of the nominating committee. 374 (4) At least a quorum of committee members must participate in a 375 vote. A quorum is comprised of at least 7 voting members. 377 (5) The Chair may establish a process by which a member of the 378 nominating committee may be recalled. 380 The process, if established, must be agreed to by a 3/4 majority 381 of the members of the nominating committee, including the non- 382 voting members since they would be subject to the same process. 384 (6) All members of the nominating committee may participate in all 385 deliberations. 387 The emphasis of this rule is that no member, whether voting or 388 non-voting, can be explicitly excluded from any deliberation. 389 However, a member may individually choose not to participate in 390 a deliberation. 392 (7) The Chair announces the open positions to be reviewed and the 393 call for nominees. 395 The call for nominees must include a request for comments 396 regarding the past performance of incumbents, which will be 397 considered during the deliberations of the nominating committee. 399 The announcements must be publicized using at least the same 400 mechanism used by the IETF secretariat for its announcements. 402 (8) Any member of the IETF community may nominate any member of 403 the IETF community for any open position. 405 A self-nomination is permitted. 407 (9) Nominating committee members must not be nominees. 409 To be a nominee is to enter the process of being selected as a 410 candidate and confirmed. Nominating committee members are not 411 eligible to be considered for filling any open position. 413 (10) Members of the IETF community who were recalled from any IESG 414 or IAB position during the previous two years must not be 415 nominees. 417 (11) The nominating committee selects candidates based on its 418 understanding of the IETF community's consensus of the 419 qualifications required to fill the open positions. 421 The intent of this rule is to ensure that the nominating 422 committee consults with a broad base of the IETF community for 423 input to its deliberations. 425 The consultations are permitted to include a slate of nominees, 426 if all parties to the consultation agree to observe customary 427 and reasonable rules of confidentiality. 429 A broad base of the community should include the existing 430 members of the IAB and IESG, especially sitting members who 431 share responsibilities with open positions, e.g., co-Area 432 Directors. 434 (12) Nominees should be advised that they are being considered and 435 must consent to their nomination prior to being confirmed. 437 The nominating committee should help nominees provide 438 justification to their employers. 440 A nominee's consent must be written (email is acceptable) and 441 include a commitment to provide the resources necessary to fill 442 the open position and an assurance that the nominee will perform 443 the duties of the position for which they are being considered 444 in the best interests of the IETF community. 446 (13) The nominating committee advises the confirming bodies of 447 their candidates, specifying a single candidate for each open 448 position and a testament as to how each candidate meets the 449 qualifications of an open position. 451 The testament may include a brief resume of the candidate and a 452 summary of the deliberations of the nominating committee. 454 (14) With respect to any action to be taken in the context of 455 notifying and announcing confirmed candidates, and notifying 456 rejected nominees and candidates, the action must be valid 457 according to all of the rules specified below prior to its 458 execution. 460 a. Up until a candidate is confirmed, the identity of the candidate 461 must be kept confidential. 463 b. The identity of all nominees must be kept confidential (except 464 that the nominee may publicize their intentions). 466 c. Rejected nominees may be notified as soon as they are rejected. 468 d. Rejected candidates may be notified as soon as they are 469 rejected. 471 e. Rejected nominees and candidates must be notified prior to 472 announcing confirmed candidates. 474 f. Confirmed candidates may be notified and announced as soon as 475 they are confirmed. 477 It is consistent with these rules for a nominee to never know if 478 they were a candidate or not. 480 It is consistent with these rules for some nominees to be 481 rejected early in the process and for some nominees to be kept 482 as alternates in case a candidate is rejected by a confirming 483 body. In the matter of whether a confirmed candidate was a 484 first choice or an alternate, that information need not ever be 485 disclosed and, in fact, probably never should be. 487 It is consistent with these rules for confirmed candidates to be 488 notified and announced as quickly as possible instead of 489 requiring all confirmed candidates to wait until all open 490 positions have been reviewed. 492 When consulting with individual members of the IETF community, 493 if all parties to the consultation agree to observe customary 494 and reasonable rules of confidentiality the consultations are 495 permitted to include a slate of nominees. 497 The announcements must be publicized using at least the same 498 mechanism used by the IETF secretariat for its announcements. 500 5. Member Recall 502 The following rules apply to the recall process. If necessary, a 503 paragraph discussing the interpretation of each rule is included. 505 (1) Anyone may request the recall of any sitting IAB or IESG 506 member, at any time, upon written (email is acceptable) 507 request with justification to the Internet Society President. 509 (2) Internet Society President shall appoint a Recall Committee 510 Chair. 512 The Internet Society President must not evaluate the recall 513 request. It is explicitly the responsibility of the IETF 514 community to evaluate the behavior of its leaders. 516 (3) The recall committee is created according to the same rules as 517 is the nominating committee with the qualifications that the 518 person being investigated and the person requesting the recall 519 must not be a member of the recall committee in any capacity. 521 (4) The recall committee operates according to the same rules as 522 the nominating committee with the qualification that there is 523 no confirmation process. 525 (5) The recall committee investigates the circumstances of the 526 justification for the recall and votes on its findings. 528 The investigation must include at least both an opportunity for 529 the member being recalled to present a written statement and 530 consultation with third parties. 532 (6) A 3/4 majority of the members who vote on the question is 533 required for a recall. 535 (7) If a sitting member is recalled the open position is to be 536 filled according to the mid-term vacancy rules. 538 6. Changes From RFC2027 540 (1) In order to foster better communication between nominating 541 committees from one year to the next the Chair of each year's 542 committee has been added as a non-voting liaison of the next 543 year's committee. 545 (2) In order to confirm the eligibility of each volunteer in the 546 pool of names from which nominating committee members are 547 chosen the Chair must announce the list prior to the random 548 selection. 550 (3) In order to confirm the random selection process used to 551 select voting nominating committee members the Chair must 552 announce the fair and unbiased method used in advance of its 553 execution. 555 (4) Some guidance was added to ensure that the nominating 556 committee consults with a broad base of the IETF community. 558 (5) Some guidance was added to ensure that the nominating 559 committee understands that it may name prospective nominees 560 when consulting with individual members of the IETF community. 562 (6) Some guidance was added to ensure that the nominating 563 committee understands that it is responsible for ensuring that 564 an appropriate set of one-half of each of the IESG and IAB 565 positions are reviewed each year. 567 7. Security Considerations 569 Any selection, confirmation, or recall process necessarily involves 570 investigation into the qualifications and activities of prospective 571 candidates. The investigation may reveal confidential or otherwise 572 private information about candidates to those participating in the 573 process. Each person who participates in any aspect of the process 574 has a responsibility to maintain the confidentiality of any and all 575 information not explicitly identified as suitable for public 576 dissemination. 578 8. Editor's Address 580 James M. Galvin 581 CommerceNet 582 3209A Corporate Court 583 Ellicott City, MD 21042 585 Email: galvin@commerce.net 586 Phone: +1 410.203.2707 588 Table of Contents 590 Status of this Memo ........................................... 1 591 Abstract ...................................................... 1 592 1 Introduction ................................................. 1 593 2 General ...................................................... 3 594 3 Nominating Committee Selection ............................... 6 595 4 Nominating Committee Operation ............................... 8 596 5 Member Recall ................................................ 12 597 6 Changes From RFC2027 ......................................... 13 598 7 Security Considerations ...................................... 13 599 8 Editor's Address ............................................. 14