idnits 2.17.1 draft-ietf-poised95-nomcom-04.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-25) 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 1 character 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 (March 1996) is 10268 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 VeriFone/EIT 4 draft-ietf-poised95-nomcom-04.txt March 1996 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, and 13 its Working Groups. Note that other groups may also distribute working 14 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 is 18 inappropriate to use Internet Drafts as reference material or to cite 19 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 Shadow 23 Directories on ds.internic.net (US East Coast), venera.isi.edu (US West 24 Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe). 26 Abstract 28 The process by which the members of the IAB and IESG are selected, 29 confirmed, and recalled has been exercised four times since its formal 30 creation. The evolution of the process has relied principally on oral 31 tradition as a means by which the lessons learned could be passed on to 32 successive committees. This document is a self-consistent, organized 33 compilation of the process as it is known today. 35 1. Introduction 37 By 1992, many aspects of the operation of the Internet Architecture 38 Board (IAB), Internet Engineering Task Force (IETF), and the Internet 39 Engineering Steering Group (IESG) had been reviewed and changes were 40 being implemented. Included in those changes was the process by which 41 members of the IAB and IESG are selected, confirmed, and recalled. 42 Since 1992, the process of selection and confirmation has been exercised 43 four times: 1992, 1993, 1994, and 1995. The recall process has not been 44 exercised. 46 A single paragraph in RFC1602 is the extent to which the process has 47 been formally recorded to date. Informally, following the 1992 exercise 48 of the process, an internet draft was distributed recording many of the 49 details of the operation of that first nominating committee. In 50 addition, in both 1994 and 1995, the POISED working group met, which 51 facilitated the "oral tradition" transference of the selection and 52 confirmation process lessons learned, including the email archives of 53 the working group mailing list. This document is a self-consistent, 54 organized compilation of the process as described by each of these 55 sources. 57 The process described here includes only items for which the consensus 58 of those participating in the various discussions was easily recognized. 59 As a result, two assumptions are made. 61 (1) The Internet Research Task Force (IRTF) and Internet Research 62 Steering Group (IRSG) are not a part of the process described here. 64 (2) The organization (and re-organization) of the IESG is not a part of 65 the process described here. 67 In addition, this document specifies time frames for which the frame of 68 reference is IETF meetings. The time frames assume that the IETF meets 69 at least once per year with that meeting occurring during the North 70 American Spring time, i.e., the IETF meets at least on or about March of 71 each year. 73 The remainder of this document is divided into four major topics as 74 follows. 76 General 77 This a set of rules and constraints that apply to the selection and 78 confirmation process as a whole. 80 Nominating Committee Selection 81 This is the process by which volunteers from the IETF community are 82 recognized to serve on the committee that nominates candidates to 83 serve on the IESG and IAB. 85 Nominating Committee Operation 86 This is the set of principles, rules, and constraints that guide 87 the activities of the nominating committee, including the 88 confirmation process. 90 Member Recall 91 This is the process by which the behavior of a sitting member of 92 the IESG or IAB may be questioned, perhaps resulting in the removal 93 of the sitting member. 95 2. General 97 The following set of rules apply to the selection and confirmation 98 process as a whole. If necessary, a paragraph discussing the 99 interpretation of each rule is included. 101 (1) The principal function of the nominating committee is to recruit 102 and nominate candidates for open IESG and IAB positions. 104 The nominating committee does not select the open positions to be 105 filled; it is instructed as to which positions to fill. At a 106 minimum, the nominating committee will be given the title of the 107 position to be filled. The nominating committee may be given a 108 desirable set of qualifications for the candidates nominated to 109 fill a position. The nominating committee does not confirm its 110 candidates; it presents its candidates to the appropriate 111 confirming body as indicated below. 113 (2) The annual selection and confirmation process is expected to be 114 completed within 3 months. 116 The annual selection and confirmation process is expected to be 117 completed one month prior to the friday of the week before the 118 Spring IETF. It is expected to begin 4 months prior to the friday 119 of the week before the Spring IETF. 121 (3) One-half of each of the then current IESG and IAB positions is 122 selected to be refilled each year. 124 A given position is selected every other year. The intent is to 125 replace no more than 50% of the sitting IESG and IAB members in any 126 one year. 128 A position may be refilled with its sitting member, if the sitting 129 member is nominated by the nominating committee. 131 (4) Confirmed candidates are expected to serve at least a 2 year term. 133 The nominal 2 year term of a confirmed candidate begins no later 134 than the last day and no sooner than the Open Plenary session of 135 the Spring IETF meeting, as determined by the mutual agreement of 136 the confirmed candidate and the currently sitting member. The term 137 ends no later than the second to last day and no sooner than the 138 Open Plenary session of the second Spring IETF meeting following 139 the beginning of the term, as determined by the mutual agreement of 140 the confirmed candidate and the currently sitting member. 142 (5) Mid-term IESG vacancies are filled by the same rules as documented 143 here with four qualifications. First, the most recently 144 constituted nominating committee is reconvened to nominate a 145 candidate to fill the vacancy. Second, the selection and 146 confirmation process is expected to be completed within 1 month, 147 with a prorated time period for all other time periods not 148 otherwise specified. Third, the confirming body has two weeks from 149 the day it is notified of a candidate to reject the candidate, 150 otherwise the candidate is assumed to have been confirmed. Fourth, 151 the term of the confirmed candidate will be either: 153 a. the remainder of the term of the open position if that remainder is 154 not less than one year. 156 b. the remainder of the term of the open position plus the next 2 year 157 term if that remainder is less than one year. 159 (6) Mid-term IAB 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 month, 164 with a prorated time period for all other time periods not 165 otherwise specified. Third, the confirming body has two weeks from 166 the day it is notified of a candidate to reject the candidate, 167 otherwise the candidate is assumed to have been confirmed. Fourth, 168 the term of the confirmed candidate will be either: 170 a. the remainder of the term of the open position if that remainder is 171 not less than one year. 173 b. the remainder of the term of the open position plus the next 2 year 174 term if that remainder is less than one year. 176 (7) All deliberations and supporting information of all the 177 participants in the selection and confirmation process are private. 179 The nominating committee and confirming body members will be 180 exposed to confidential information as a result of their 181 deliberations, their interactions with those they consult, and from 182 nominees who provide requested supporting information. All members 183 and all other participants are expected to handle this information 184 in a manner consistent with its sensitivity. 186 (8) Unless otherwise specified, the advise and consent model is used 187 throughout the process. This model is characterized as follows. 189 a. The IETF Executive Director advises the nominating committee of the 190 IESG and IAB positions to be refilled. 192 b. The nominating committee selects candidates and advises the 193 confirming bodies of them. 195 c. The sitting IAB members review the IESG candidates, consenting to 196 some, all, or none. 198 If all of the candidates are confirmed, the job of the nominating 199 committee with respect to filling the open IESG positions is 200 considered complete. If some or none of the candidates are 201 confirmed, the nominating committee must reconvene to select 202 alternate candidates for the rejected candidates. Any additional 203 time required by the nominating committee should not exceed its 204 maximum time allotment. 206 d. The Internet Society Board of Trustees reviews the IAB candidates, 207 consenting to some, all, or none. 209 If all of the candidates are confirmed, the job of the nominating 210 committee with respect to filling the open IAB positions is 211 considered complete. If some or none of the candidates are 212 confirmed, the nominating committee must reconvene to select 213 alternate candidates for the rejected candidates. Any additional 214 time required by the nominating committee should not exceed its 215 maximum time allotment. 217 e. The confirming bodies decide their consent according to a mechanism 218 of their own choosing, which must ensure that at least one-half of 219 the sitting members agree with the decision. 221 At least one-half of the sitting members of the confirming bodies 222 must agree to either confirm or reject each individual nominee. 223 The agreement must be decided within a reasonable timeframe. The 224 agreement may be decided by conducting a formal vote, by asserting 225 consensus based on informal exchanges (email), or by whatever 226 mechanism is used to conduct the normal business of the confirming 227 body. 229 3. Nominating Committee Selection 231 The following set of rules apply to the creation of the nominating 232 committee and the selection of its members. 234 (1) The committee is comprised of at least a non-voting Chair, 10 235 voting volunteers, and 2 non-voting liaisons. 237 (2) The Internet Society President appoints the non-voting Chair, who 238 must meet the usual requirements for membership in the nominating 239 committee. 241 The nominating committee Chair must agree to invest the time 242 necessary to complete the duties of the nominating committee and to 243 perform in the best interests of the IETF community during the 244 performance of those duties. 246 (3) The Chair obtains the list of IESG and IAB positions to be refilled 247 and publishes it along with a solicitation for names of volunteers 248 from the IETF community willing to serve on the nominating 249 committee. 251 The list of open positions is published with the solicitation to 252 facilitate community members choosing between volunteering for an 253 open position and volunteering for the nominating committee. 255 The list and solicitation must be publicized using at least the 256 same mechanism used by the IETF secretariat for its announcements. 258 (4) Members of the IETF community must have attended at least 2 of the 259 last 3 IETF meetings in order to volunteer. 261 (5) Internet Society Board of Trustees, sitting members of the IAB, and 262 sitting members of the IESG may not volunteer. 264 (6) The Chair randomly selects the 10 voting volunteers from the pool 265 of names of volunteers. 267 (7) The sitting IAB and IESG members each appoint a non-voting liaison 268 to the nominating committee from their current membership who are 269 not sitting in an open position. 271 (8) The Chair may solicit additional non-voting liaisons from other 272 organizations, who must meet the usual requirements for membership 273 in the nominating committee. 275 4. Nominating Committee Operation 277 The following rules apply to the operation of the nominating committee. 278 If necessary, a paragraph discussing the interpretation of each rule is 279 included. 281 The rules are organized approximately in the order in which they would 282 be invoked. 284 The term nominee refers to an individual under consideration by the 285 nominating committee. The term candidate refers to a nominee that has 286 been selected by the nominating committee to be considered for 287 confirmation by a confirming body. A confirmed candidate is a candidate 288 that has been reviewed and approved by a confirming body. 290 (1) All rules not otherwise specified are at the discretion of the 291 Chair. 293 Exceptional circumstances will occasionally arise during the normal 294 operation of the nominating committee. This rule is intended to 295 foster the continued forward progress of the committee. All 296 members of the committee should consider whether the exception is 297 worthy of mention in the next revision of this document and 298 followup accordingly. 300 (2) The Chair must establish and publicize milestones, which must 301 include at least a call for nominations. 303 There is a defined time period during which the selection and 304 confirmation process must be completed. The Chair must establish a 305 set of milestones which, if met in a timely fashion, will result in 306 the completion of the process on time. The Chair should allow time 307 for iterating the activities of the committee if one or more 308 candidates is not confirmed. 310 The milestones must be publicized using at least the same mechanism 311 used by the IETF secretariat for its announcements. 313 (3) The Chair must establish a voting mechanism. 315 The committee must be able to objectively determine when a decision 316 has been made during its deliberations. The criteria for 317 determining closure must be established and known to all members of 318 the nominating committee. 320 (4) At least 7 voting members are required to be present for a quorum. 322 (5) The Chair may establish a process by which a member of the 323 nominating committee may be recalled. 325 The process, if established, must be agreed to by a 3/4 majority of 326 the members of the nominating committee, including the non-voting 327 members since they would be subject to the same process. 329 (6) All members of the nominating committee may participate in all 330 deliberations. 332 The emphasis of this rule is that no member, whether voting or 333 non-voting, can be explicitly excluded from any deliberation. 334 However, a member may individually choose not to participate in a 335 deliberation. 337 (7) The Chair announces the open positions to be filled and the call 338 for nominees. 340 The announcements must be publicized using at least the same 341 mechanism used by the IETF secretariat for its announcements. 343 (8) Any member of the IETF community may nominate any member of the 344 IETF community for any open position. 346 A self-nomination is permitted. 348 (9) Nominating committee members must not be nominees. 350 To be a nominee is to enter the process of being selected as a 351 candidate and confirmed. Nominating committee members are not 352 eligible to be considered for filling any open position. 354 (10) Members of the IETF community who were recalled from any IESG or 355 IAB position during the previous two years must not be nominees. 357 (11) The nominating committee selects candidates based on its 358 understanding of the IETF community's consensus of the 359 qualifications required to fill the open positions. 361 (12) Nominees should be advised that they are being considered and must 362 consent to their nomination prior to being confirmed. 364 The nominating committee should help nominees provide justification 365 to their employers. 367 A nominee's consent must be written (including email) and include a 368 commitment to provide the resources necessary to fill the open 369 position and an assurance that the nominee will perform the duties 370 of the position for which they are being considered in the best 371 interests of the IETF community. 373 (13) The nominating committee advises the confirming bodies of their 374 candidates, specifying a single candidate for each open position 375 and a testament as to how each candidate meets the qualifications 376 of an open position. 378 The testament may include a brief resume of the candidate and a 379 summary of the deliberations of the nominating committee. 381 (14) With respect to any action to be taken in the context of notifying 382 and announcing confirmed candidates, and notifying rejected 383 nominees and candidates, the action must be valid according to all 384 of the rules specified below prior to its execution. 386 a. Up until a candidate is confirmed, the identity of the candidate 387 must be kept strictly confidential. 389 b. The identity of all nominees must be kept strictly confidential 390 (except that the nominee may publicize their intentions). 392 c. Rejected nominees may be notified as soon as they are rejected. 394 d. Rejected candidates may be notified as soon as they are rejected. 396 e. Rejected nominees and candidates must be notified prior to 397 announcing confirmed candidates. 399 f. Confirmed candidates may be notified and announced as soon as they 400 are confirmed. 402 It is consistent with these rules for a nominee to never know if 403 they were a candidate or not. 405 It is consistent with these rules for a nominating committee to 406 reject some nominees early in the process and to keep some nominees 407 as alternates in case a candidate is rejected by a confirming body. 408 In the matter of whether a confirmed candidate was a first choice 409 or an alternate, that information need not ever be disclosed and, 410 in fact, probably never should be. 412 It is consistent with these rules for confirmed candidates to be 413 notified and announced as quickly as possible instead of requiring 414 all confirmed candidates to wait until all open positions have been 415 refilled. 417 The announcements must be publicized using at least the same 418 mechanism used by the IETF secretariat for its announcements. 420 5. Member Recall 422 The following rules apply to the recall process. If necessary, a 423 paragraph discussing the interpretation of each rule is included. 425 (1) Anyone may request the recall of any sitting IAB or IESG member, at 426 any time, upon written (including email) request with justification 427 to the Internet Society President. 429 (2) Internet Society President shall appoint a Recall Committee Chair. 431 The Internet Society President must not evaluate the recall 432 request. It is explicitly the responsibility of the IETF community 433 to evaluate the behavior of its leaders. 435 (3) The recall committee is created according to the same rules as is 436 the nominating committee with the qualifications that the person 437 being investigated and the person requesting the recall must not be 438 a member of the recall committee in any capacity. 440 (4) The recall committee operates according to the same rules as the 441 nominating committee with the qualification that there is no 442 confirmation process. 444 (5) The recall committee investigates the circumstances of the 445 justification for the recall and votes on its findings. 447 The investigation must include at least both an opportunity for the 448 member being recalled to present a written statement and 449 consultation with third parties. 451 (6) A 3/4 majority of the members who vote on the question is required 452 for a recall. 454 If a sitting member is recalled the open position is to be filled 455 according to the mid-term vacancy rules. 457 6. Security Considerations 459 Any selection, confirmation, or recall process necessarily involves 460 investigation into the qualifications and activities of prospective 461 candidates. The investigation may reveal confidential or otherwise 462 private information about candidates to those participating in the 463 process. Each person who participates in any aspect of the process has 464 a responsibility to maintain the confidentiality of any and all 465 information not explicitly identified as suitable for public 466 dissemination. 468 7. Editor's Address 470 James M. Galvin 471 VeriFone/EIT 472 P.O. Box 220 473 Glenwood, MD 21738 475 Email: galvin@eit.com 476 Phone: +1 410.795.6882 478 Table of Contents 480 Status of this Memo .............................................. 1 481 Abstract ......................................................... 1 482 1 Introduction .................................................... 1 483 2 General ......................................................... 3 484 3 Nominating Committee Selection .................................. 6 485 4 Nominating Committee Operation .................................. 7 486 5 Member Recall ................................................... 10 487 6 Security Considerations ......................................... 11 488 7 Editor's Address ................................................ 11