idnits 2.17.1 draft-galvin-rfc2727bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 24, 2002) is 8127 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) ** Obsolete normative reference: RFC 2727 (ref. '1') (Obsoleted by RFC 3777) ** Obsolete normative reference: RFC 2777 (ref. '2') (Obsoleted by RFC 3797) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 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 eList eXpress LLC 4 Expires: July 25, 2002 January 24, 2002 6 IAB and IESG Selection, Confirmation, and Recall Process: Operation 7 of the Nominating and Recall Committees 8 draft-galvin-rfc2727bis-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 25, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 The process by which the members of the IAB and IESG are selected, 40 confirmed, and recalled is specified. This document is a self- 41 consistent, organized compilation of the process as it was known at 42 the time of publication. 44 Discussion of this Draft 46 Please direct all comments, suggestions, and questions regarding this 47 draft to the following mailing list: 49 ietf-nomcom@lists.elistx.com 51 To subscribe to that mailing list you may send a message with the 52 single word "subscribe" in the body to: 54 ietf-nomcom-request@lists.elistx.com 56 Or you may visit the web-based subscription manager at: 58 60 1. Introduction 62 This document is a revision of and supercedes RFC2727. [1] It is a 63 complete specification of the process by which members of the IAB and 64 IESG are selected, confirmed, and recalled as of the date of its 65 approval. However, these procedures are subject to change and such 66 change takes effect immediately upon its approval, regardless of 67 whether this document has yet been revised. 69 The following two assumptions continue to be true of this 70 specification. 72 1. The Internet Research Task Force (IRTF) and Internet Research 73 Steering Group (IRSG) are not a part of the process described 74 here. 76 2. The organization (and re-organization) of the IESG is not a part 77 of the process described here. 79 The time frames specified here use IETF meetings as a frame of 80 reference. The time frames assume that the IETF meets three times 81 per calendar year with approximately equal amounts of time between 82 them. The meetings are referred to as the First IETF, Second IETF, 83 or Third IETF as needed. 85 A sitting member of either the IAB or IESG is a person who is 86 currently serving a term of membership in that committee. 88 The remainder of this document is divided into four major topics as 89 follows. 91 General: This a set of rules and constraints that apply to the 92 selection and confirmation process as a whole. 94 Nominating Committee Selection: This is the process by which 95 volunteers from the IETF community are recognized to serve on the 96 committee that nominates candidates to serve on the IESG and IAB. 98 Nominating Committee Operation: This is the set of principles, rules, 99 and constraints that guide the activities of the nominating 100 committee, including the confirmation process. 102 Member Recall: This is the process by which the behavior of a sitting 103 member of the IESG or IAB may be questioned, perhaps resulting in 104 the removal of the sitting member. 106 A final section describes how this document differs from its 107 predecessor: RFC2727. [1] 109 2. General 111 The following set of rules apply to the selection and confirmation 112 process as a whole. If necessary, a paragraph discussing the 113 interpretation of each rule is included. 115 1. The principal functions of the nominating committee are to review 116 the open IESG and IAB positions and to either nominate its 117 incumbent or recruit a superior candidate. 119 The nominating committee does not select the open positions to be 120 reviewed; it is instructed as to which positions to review. 122 At a minimum, the nominating committee will be given the title of 123 the position to be reviewed. The nominating committee may be 124 given a desirable set of qualifications for the candidate 125 nominated to fill each position. 127 Incumbents must notify the nominating committee if they do not 128 wish to be nominated. 130 The nominating committee does not confirm its candidates; it 131 presents its candidates to the appropriate confirming body as 132 indicated below. 134 2. The annual selection and confirmation process is expected to be 135 completed within 3 months. 137 The annual selection and confirmation process is expected to be 138 completed one month prior to the friday of the week before the 139 First IETF. It is expected to begin 4 months prior to the Friday 140 of the week before the First IETF. 142 3. One-half of each of the then current IESG and IAB positions is 143 selected to be reviewed each year. 145 The intent of this rule to ensure the review of approximately 146 one-half of each of the sitting IESG and IAB members each year. 147 It is recognized that circumstances may exist that will require 148 the nominating committee to review more or less than one-half of 149 the current positions, e.g., if the IESG or IAB have re-organized 150 prior to this process and created new positions, or if there are 151 an odd number of current positions. 153 4. Confirmed candidates are expected to serve at least a 2 year 154 term. 156 The intent of this rule is to ensure that members of the IESG and 157 IAB serve the number of years that best facilitates the review of 158 one-half of the members each year. 160 It is consistent with this rule for the nominating committee to 161 choose one or more of the currently open positions to which it 162 may assign a term greater than 2 years in order to ensure the 163 ideal application of this rule in the future. 165 It is consistent with this rule for the nominating committee to 166 choose one or more of the currently open positions that share 167 responsibilities with other positions (both those being reviewed 168 and those sitting) to which it may assign a term greater than 2 169 years to ensure that all such members will not be reviewed at the 170 same time. 172 All sitting member terms end during the First IETF meeting 173 corresponding to the end of the term for which they were 174 confirmed. All confirmed candidate terms begin during the First 175 IETF meeting corresponding to the beginning of the term for which 176 they were confirmed. Normally, the confirmed candidate's term 177 begins when the currently sitting member's term ends on the last 178 day of the meeting. A term may begin or end no sooner than the 179 first day of the meeting and no later than the last day of the 180 meeting as determined by the mutual agreement of the currently 181 sitting member and the confirmed candidate. The confirmed 182 candidate's term may overlap the sitting member's term during the 183 meeting as determined by their mutual agreement. 185 5. Mid-term vacancies are filled by the same rules as documented 186 here with four qualifications. First, the most recently 187 constituted nominating committee is reconvened to nominate a 188 candidate to fill the vacancy. Second, the selection and 189 confirmation process is expected to be completed within 1 month, 190 with all other time periods otherwise unspecified prorated 191 accordingly. Third, the confirming body has two weeks from the 192 day it is notified of a candidate to reject the candidate, 193 otherwise the candidate is assumed to have been confirmed. 194 Fourth, the term of the confirmed candidate will be either: 196 1. the remainder of the term of the open position if that 197 remainder is not less than one year. 199 2. the remainder of the term of the open position plus the next 200 2 year term if that remainder is less than one year. 202 6. All deliberations and supporting information that relate to 203 specific nominees, candidates, and confirmed candidates are 204 confidential. 206 The nominating committee and confirming body members will be 207 exposed to confidential information as a result of their 208 deliberations, their interactions with those they consult, and 209 from those who provide requested supporting information. All 210 members and all other participants are expected to handle this 211 information in a manner consistent with its sensitivity. 213 It is consistent with this rule for current nominating committee 214 members who have served on prior nominating committees to advise 215 the current committee on deliberations and results of the prior 216 committee, as necessary and appropriate. 218 7. The Chair is responsible for ensuring all information related to 219 the selection and confirmation of candidates is archived with the 220 Internet Society President upon completion of the nominating 221 committee's responsibilities. 223 Information includes but is not limited to the archive of any 224 electronic discussion forum used by the nominating committee, for 225 example, a mailing list. 227 All electronic information should be collected and formatted as a 228 single file using a popular application format, for example, zip 229 or tar, to facilitate its management and storage. 231 Electronic information should be encrypted using a popular and 232 generally well regarded security application. Encryption keys 233 must be provided separately to the Internet Society President in 234 a mutually agreed upon format. 236 8. Unless otherwise specified, the advise and consent model is used 237 throughout the process. This model is characterized as follows. 239 1. The IETF Executive Director advises the nominating committee 240 of the IESG and IAB positions to be reviewed. 242 2. The nominating committee selects candidates and advises the 243 confirming bodies of them. 245 3. The sitting IAB members review the IESG candidates, 246 consenting to some, all, or none. 248 If all of the candidates are confirmed, the job of the 249 nominating committee with respect to reviewing the open IESG 250 positions is considered complete. If some or none of the 251 candidates are confirmed, the nominating committee must 252 reconvene to select alternate candidates for the rejected 253 candidates. Any additional time required by the nominating 254 committee should not exceed its maximum time allotment. 256 4. The Internet Society Board of Trustees reviews the IAB 257 candidates, consenting to some, all, or none. 259 If all of the candidates are confirmed, the job of the 260 nominating committee with respect to reviewing the open IAB 261 positions is considered complete. If some or none of the 262 candidates are confirmed, the nominating committee must 263 reconvene to select alternate candidates for the rejected 264 candidates. Any additional time required by the nominating 265 committee should not exceed its maximum time allotment. 267 5. The confirming bodies decide their consent according to a 268 mechanism of their own choosing, which must ensure that at 269 least one-half of the sitting members agree with the 270 decision. 272 At least one-half of the sitting members of the confirming 273 bodies must agree to either confirm or reject each individual 274 nominee. The agreement must be decided within a reasonable 275 timeframe. The agreement may be decided by conducting a 276 formal vote, by asserting consensus based on informal 277 exchanges (email), or by whatever mechanism is used to 278 conduct the normal business of the confirming body. 280 3. Nominating Committee Selection 282 The following set of rules apply to the creation of the nominating 283 committee and the selection of its members. 285 1. The committee comprises at least a non-voting Chair, 10 voting 286 volunteers, and 3 non-voting liaisons. 288 Any committee member may propose the addition of a non-voting 289 advisor to participate in some or all of the deliberations of the 290 committee. The addition must be approved by both the voting and 291 non-voting members of the committee according to its established 292 voting mechanism. Advisors participate as individuals. 294 Any committee member may propose the addition of a non-voting 295 liaison from other unrepresented organizations to participate in 296 some or all of the deliberations of the committee. The addition 297 must be approved by both the voting and non-voting members of the 298 committee according to its established voting mechanism. 299 Liaisons participate as representatives of their respective 300 organizations. 302 Advisors and liaisons must meet the usual requirements for 303 membership in the nominating committee. In the case of liaisons 304 the requirements apply to the organization not to the individual. 306 2. The Internet Society President appoints the non-voting Chair, who 307 must meet the usual requirements for membership in the nominating 308 committee. 310 The nominating committee Chair must agree to invest the time 311 necessary to ensure that the nominating committee completes its 312 assigned duties and to perform in the best interests of the IETF 313 community in that role. 315 The appointment must be completed no later than the Second IETF 316 meeting to ensure it can be announced during a plenary session at 317 that meeting as determined by the IETF secretariat. This ensures 318 the Chair has approximately two months to conduct the selection 319 process for the nominating committee members and approximately 320 one month to organize one or more initial meetings of the 321 nominating committee prior to the Third IETF meeting. 323 3. The Chair obtains the list of IESG and IAB positions to be 324 reviewed and publishes it along with a solicitation for names of 325 volunteers from the IETF community willing to serve on the 326 nominating committee. 328 The list of open positions is published with the solicitation to 329 facilitate community members choosing between volunteering for an 330 open position and volunteering for the nominating committee. 332 The opportunity to volunteer must be available for at least one 333 month. The opportunity to volunteer must end no later than one 334 week prior to the earliest time at which the selection process 335 may begin. 337 The list and solicitation must be publicized using at least the 338 same mechanism used by the IETF secretariat for its 339 announcements. 341 4. Members of the IETF community must have attended at least 2 of 342 the last 3 IETF meetings in order to volunteer. 344 The 3 meetings are the three most recent meetings that ended 345 prior to the date on which the solicitation for nominating 346 committee volunteers was submitted for distribution to the IETF 347 community. 349 5. Internet Society Board of Trustees, sitting members of the IAB, 350 and sitting members of the IESG may not volunteer. 352 6. The Chair announces an enumerated list of the pool of volunteers 353 from which the 10 voting volunteers will be randomly selected. 355 The announcement must be made at least one week prior to the 356 earliest time the selection process may begin. 358 The announcement must be made using at least the same mechanism 359 used by the IETF secretariat for its announcements. 361 The enumerated list should be announced incrementally to ensure 362 the pool of volunteers is unbiased. The enumeration is immutable 363 such that if a volunteer withdraws or is otherwise ineligible to 364 be selected, that slot is left blank and is skipped during the 365 execution of the selection process. 367 7. The Chair randomly selects the 10 voting volunteers from the pool 368 of names of volunteers using a method that can be independently 369 verified to be unbiased and fair. 371 A method is fair if each eligible volunteer is equally likely to 372 be selected. A method is unbiased if no one can influence its 373 outcome in favor of a specific outcome. 375 The method must include an announcement of an enumerated list of 376 the pool of names together with the specific algorithm for how 377 names will be chosen from the list. 379 The method must depend on random data whose value is not known at 380 the time the list and algorithm are announced and can not be 381 known for at least one week from the time of the announcement. 383 As soon as the random data is available it must be possible for 384 anyone with access to it to execute the method and confirm that 385 the correct 10 voting volunteers were selected. 387 If a selected volunteer is unable to complete their commitment 388 for any reason, it must be possible to iterate the method and 389 randomly select the next eligible volunteer in turn. 391 One possible method is described in RFC2777. [2] 393 All announcements must be made using at least the mechanism used 394 by the IETF secretariat for its announcements. 396 8. The sitting IAB and IESG members each appoint a non-voting 397 liaison to the nominating committee from their current membership 398 who are not sitting in an open position. 400 9. The Chair of the prior year's nominating committee serves as a 401 non-voting liaison. 403 The prior year's Chair may select a designee from a pool composed 404 of the voting members of the prior year's committee and all prior 405 Chairs if the Chair is unavailable. If the prior year's Chair is 406 unavailable and is unable or unwilling to make such a designation 407 in a timely fashion, the Chair of the current committee may do 408 so. 410 Selecting a prior year's committee member as the designee permits 411 the experience of the prior year's deliberations to be readily 412 available to the current committee. Selecting an earlier prior 413 year Chair as the designee permits the experience of being a 414 Chair as well as that Chair's committee deliberations to be 415 readily available to the current committee. 417 4. Nominating Committee Operation 419 The following rules apply to the operation of the nominating 420 committee. If necessary, a paragraph discussing the interpretation 421 of each rule is included. 423 The rules are organized approximately in the order in which they 424 would be invoked. 426 The term nominee refers to an individual under consideration by the 427 nominating committee. The term candidate refers to a nominee that 428 has been selected by the nominating committee to be considered for 429 confirmation by a confirming body. A confirmed candidate is a 430 candidate that has been reviewed and approved by a confirming body. 432 1. All rules and special circumstances not otherwise specified are 433 at the discretion of the committee. 435 Exceptional circumstances will occasionally arise during the 436 normal operation of the nominating committee. This rule is 437 intended to foster the continued forward progress of the 438 committee. 440 Any member of the committee may propose a rule for adoption by 441 the committee. The rule must be approved by both the voting and 442 non- voting members of the committee according to its 443 established voting mechanism. 445 All members of the committee should consider whether the 446 exception is worthy of mention in the next revision of this 447 document and followup accordingly. 449 2. The Chair must establish and publicize milestones, which must 450 include at least a call for nominations. 452 There is a defined time period during which the selection and 453 confirmation process must be completed. The Chair must 454 establish a set of milestones which, if met in a timely fashion, 455 will result in the completion of the process on time. The Chair 456 should allow time for iterating the activities of the committee 457 if one or more candidates is not confirmed. 459 The milestones must be publicized using at least the same 460 mechanism used by the IETF secretariat for its announcements. 462 3. The Chair must establish a voting mechanism. 464 The committee must be able to objectively determine when a 465 decision has been made during its deliberations. The criteria 466 for determining closure must be established and known to all 467 members of the nominating committee. 469 4. At least a quorum of committee members must participate in a 470 vote. A quorum comprises at least 7 voting members. 472 5. The Chair may establish a process by which a member of the 473 nominating committee may be recalled. 475 The process, if established, must be agreed to by a 3/4 majority 476 of the members of the nominating committee, including the non- 477 voting members since they would be subject to the same process. 479 6. All members of the nominating committee may participate in all 480 deliberations. 482 The emphasis of this rule is that no member, whether voting or 483 non-voting, can be explicitly excluded from any deliberation. 484 However, a member may individually choose not to participate in 485 a deliberation. 487 7. The Chair announces the open positions to be reviewed and the 488 call for nominees. 490 The call for nominees must include a request for comments 491 regarding the past performance of incumbents, which will be 492 considered during the deliberations of the nominating committee. 494 The announcements must be publicized using at least the same 495 mechanism used by the IETF secretariat for its announcements. 497 8. Any member of the IETF community may nominate any member of the 498 IETF community for any open position. 500 A self-nomination is permitted. 502 9. Nominating committee members must not be nominees. 504 To be a nominee is to enter the process of being selected as a 505 candidate and confirmed. Nominating committee members are not 506 eligible to be considered for filling any open position. They 507 become ineligible as soon as their role is announced to the IETF 508 community and they remain ineligible for the duration of this 509 nominating committee's term. 511 10. Members of the IETF community who were recalled from any IESG or 512 IAB position during the previous two years must not be nominees. 514 11. The nominating committee selects candidates based on its 515 understanding of the IETF community's consensus of the 516 qualifications required to fill the open positions. 518 The intent of this rule is to ensure that the nominating 519 committee consults with a broad base of the IETF community for 520 input to its deliberations. 522 The consultations are permitted to include a slate of nominees, 523 if all parties to the consultation agree to observe customary 524 and reasonable rules of confidentiality. 526 A broad base of the community should include the existing 527 members of the IAB and IESG, especially sitting members who 528 share responsibilities with open positions, e.g., co-Area 529 Directors. 531 12. Nominees should be advised that they are being considered and 532 must consent to their nomination prior to being confirmed. 534 The nominating committee should help nominees provide 535 justification to their employers. 537 A nominee's consent must be written (email is acceptable) and 538 include a commitment to provide the resources necessary to fill 539 the open position and an assurance that the nominee will perform 540 the duties of the position for which they are being considered 541 in the best interests of the IETF community. 543 13. A candidate may not be confirmed to serve for both an IESG and 544 an IAB position concurrently. 546 A nominee may be a sitting member of either the IESG or the IAB 547 and confirmed for an alternate position in either the IESG or 548 the IAB. 550 If the term of the sitting role does not end coincident with the 551 start of the term of the new role, the confirmed candidate must 552 choose exactly one role. 554 14. The nominating committee advises the confirming bodies of their 555 candidates, specifying a single candidate for each open position 556 and a testament as to how each candidate meets the 557 qualifications of an open position. 559 The testament may include a brief resume of the candidate and a 560 summary of the deliberations of the nominating committee. 562 15. With respect to any action to be taken in the context of 563 notifying and announcing confirmed candidates, and notifying 564 rejected nominees and candidates, the action must be valid 565 according to all of the rules specified below prior to its 566 execution. 568 1. Up until a candidate is confirmed, the identity of the 569 candidate must be kept confidential. 571 2. The identity of all nominees must be kept confidential 572 (except that the nominee may publicize their intentions). 574 3. Rejected nominees may be notified as soon as they are 575 rejected. 577 4. Rejected candidates may be notified as soon as they are 578 rejected. 580 5. Rejected nominees and candidates must be notified prior to 581 announcing confirmed candidates. 583 6. Confirmed candidates may be notified and announced as soon 584 as they are confirmed. 586 It is consistent with these rules for a nominee to never 587 know if they were a candidate or not. 589 It is consistent with these rules for some nominees to be 590 rejected early in the process and for some nominees to be 591 kept as alternates in case a candidate is rejected by a 592 confirming body. In the matter of whether a confirmed 593 candidate was a first choice or an alternate, that 594 information need not ever be disclosed and, in fact, 595 probably never should be. 597 It is consistent with these rules for confirmed candidates 598 to be notified and announced as quickly as possible instead 599 of requiring all confirmed candidates to wait until all open 600 positions have been reviewed. 602 When consulting with individual members of the IETF 603 community, if all parties to the consultation agree to 604 observe customary and reasonable rules of confidentiality 605 the consultations are permitted to include a slate of 606 nominees. 608 The announcements must be publicized using at least the same 609 mechanism used by the IETF secretariat for its 610 announcements. 612 5. Member Recall 614 The following rules apply to the recall process. If necessary, a 615 paragraph discussing the interpretation of each rule is included. 617 1. Anyone may request the recall of any sitting IAB or IESG member, 618 at any time, upon written (email is acceptable) request with 619 justification to the Internet Society President. 621 2. Internet Society President shall appoint a Recall Committee 622 Chair. 624 The Internet Society President must not evaluate the recall 625 request. It is explicitly the responsibility of the IETF 626 community to evaluate the behavior of its leaders. 628 3. The recall committee is created according to the same rules as is 629 the nominating committee with the qualifications that the person 630 being investigated and the person requesting the recall must not 631 be a member of the recall committee in any capacity. 633 4. The recall committee operates according to the same rules as the 634 nominating committee with the qualification that there is no 635 confirmation process. 637 5. The recall committee investigates the circumstances of the 638 justification for the recall and votes on its findings. 640 The investigation must include at least both an opportunity for 641 the member being recalled to present a written statement and 642 consultation with third parties. 644 6. A 3/4 majority of the members who vote on the question is 645 required for a recall. 647 7. If a sitting member is recalled the open position is to be filled 648 according to the mid-term vacancy rules. 650 6. Changes From RFC2727 652 Editorial changes are not described here, only substantive changes. 653 They are listed here in the order in which they appear in the 654 document. 656 1. A definition for "sitting member" was added. 658 2. An information retention policy was added requiring the Chair to 659 submit a collection of all information related to the operation 660 of and execution of the responsibilities of the nominating 661 committee to the Internet Society President for long-term 662 storage. Previous Chairs have done this so the addition is just 663 a formalization of existing practice. 665 3. A timeframe for the appointment of the Chair was added. The 666 timeframe could always be inferred from the text but to avoid 667 confusion it is now explicitly stated. 669 4. Some explicit guidance was added regarding the timeframe for 670 volunteering to serve on the nominating committee. 672 5. Some explicit guidance was added to the process of selecting the 673 nominating committee members. Among other things it must be 674 possible to iterate the selection method more than just 10 times 675 to ensure that unavailable or ineligible volunteers can be 676 replaced. 678 6. It is now explicitly stated that no person may serve on both the 679 IESG and the IAB concurrently. 681 7. Acknowledgements 683 There have been a number of people involved with the development of 684 this document over the years. A great deal of credit goes to the 685 first three Nominating Committee Chairs: 687 1993 - Jeff Case 689 1994 - Fred Baker 691 1995 - John Curran 693 who had the pleasure of operating without the benefit of a documented 694 process. It was their fine work and oral tradition that became the 695 first version of this document. Of course we can not overlook the 696 bug discovery burden that each of the Chairs since the first 697 publication have had to endure: 699 1996 - Guy Almes 701 1997 - Geoff Houston 703 1998 - Mike St. Johns 705 1999 - Donald Eastlake 707 2000 - Avia Doria 709 2001 - Ted T'so 711 Of course the bulk of the credit goes to the members of the POISSON 712 Working Group, previously the POISED Working Group. The prose here 713 would not be what it is were it not for the attentive and insightful 714 review of its members. Specific acknowledgement must be extended to 715 Scott Bradner and John Klensin, who have consistently contributed to 716 the improvement of this document throughout its evolution. 718 8. Security Considerations 720 Any selection, confirmation, or recall process necessarily involves 721 investigation into the qualifications and activities of prospective 722 candidates. The investigation may reveal confidential or otherwise 723 private information about candidates to those participating in the 724 process. Each person who participates in any aspect of the process 725 has a responsibility to maintain the confidentiality of any and all 726 information not explicitly identified as suitable for public 727 dissemination. 729 References 731 [1] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall 732 Process: Operation of the Nominating and Recall Committees", BCP 733 10, RFC 2727, February 2000. 735 [2] Eastlake, D., "Publicly Verifiable Nomcom Random Selection", RFC 736 2777, February 2000. 738 Author's Address 740 James M. Galvin 741 eList eXpress LLC 742 607 Trixsam Road 743 Sykesville, MD 21784 744 US 746 Phone: +1 410-549-4619 747 Fax: +1 410-795-7978 748 EMail: galvin+ietf@elistx.com 749 URI: http://www.elistx.com/ 751 Full Copyright Statement 753 Copyright (C) The Internet Society (2002). All Rights Reserved. 755 This document and translations of it may be copied and furnished to 756 others, and derivative works that comment on or otherwise explain it 757 or assist in its implementation may be prepared, copied, published 758 and distributed, in whole or in part, without restriction of any 759 kind, provided that the above copyright notice and this paragraph are 760 included on all such copies and derivative works. However, this 761 document itself may not be modified in any way, such as by removing 762 the copyright notice or references to the Internet Society or other 763 Internet organizations, except as needed for the purpose of 764 developing Internet standards in which case the procedures for 765 copyrights defined in the Internet Standards process must be 766 followed, or as required to translate it into languages other than 767 English. 769 The limited permissions granted above are perpetual and will not be 770 revoked by the Internet Society or its successors or assigns. 772 This document and the information contained herein is provided on an 773 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 774 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 775 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 776 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 777 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 779 Acknowledgement 781 Funding for the RFC Editor function is currently provided by the 782 Internet Society.