RFC 2282

IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees

๐Ÿ“… published February 1998, from ietf

Bestie, It's RFC 2282 ๐ŸŽ€โœจ

Okay so this one is a BCP (Best Current Practice) ๐Ÿ’… that's basically the official rulebook for how the IAB and IESG get picked, confirmed, and recalled. The title block is giving: it's by J. Galvin from eList eXpress LLC ๐Ÿฆ‹, dated February 1998, and it obsoletes RFC 2027 (so RFC 2027 is out, bye ๐Ÿ‘‹), and it's filed under Category: Best Current Practice ๐Ÿ‘‘. It's BCP 10, too, so it's very official and very iconic.


Status of this Memo

Okay so the Status part is short but important ๐Ÿ’–. This document specifies an Internet Best Current Practice for the Internet Community, and it's basically asking everyone to talk about it and suggest improvements ๐Ÿซถ. And distribution is totally unlimited, so share away ๐ŸŒˆ.

Copyright (C) The Internet Society (1998). All Rights Reserved. ๐Ÿ”’

Abstract

Okay the Abstract is the tea โ˜•. The process by which the members of the IAB and IESG get selected, confirmed, and recalled is written down here. Honestly the process used to live mostly in oral tradition ๐Ÿ™ˆ, like "ask the veterans what happened last time," which is so chaotic. So this doc is a self-consistent, organized compilation of how it works as of now, and it's giving clarity ๐Ÿ’œ.

Table of Contents

1 Introduction .................................................    1
2 General ......................................................    2
3 Nominating Committee Selection ...............................    6
4 Nominating Committee Operation ...............................    7
5 Member Recall ................................................   11
6 Changes From RFC2027 .........................................   12
7 Security Considerations ......................................   13
8 Editor's Address .............................................   13
9 Full Copyright Statement .....................................   14

1. Introduction ๐ŸŒธ

Okay so this doc supercedes RFC2027 ๐Ÿ“, which was the first complete spec for how IAB and IESG members get selected, confirmed, and recalled. Before that, one single paragraph in RFC1602 was all the process had on paper, so it was pretty bare-bones ๐Ÿ™ˆ.

This revision comes from experience with the 1996 Nominating Committee, which was the first committee to run under RFC2027 ๐Ÿงš. Two assumptions from that spec still hold here too ๐Ÿ‘‘:

  1. The Internet Research Task Force (IRTF) and Internet Research Steering Group (IRSG) are not part of the process described here ๐Ÿซถ.
  2. The organization (and re-organization) of the IESG is not part of the process described here ๐Ÿ’….

The time frames in this doc are measured using IETF meetings as the reference point โญ. They assume the IETF meets at least once a year, during North American Spring, so around March each year ๐ŸŒท.

The rest of the document is split into four big topics ๐ŸŽ€:

General : This is the set of rules and constraints that apply to the selection and confirmation process overall ๐Ÿ’–.

Nominating Committee Selection : This is how IETF community volunteers get recognized to serve on the committee that nominates candidates for the IESG and IAB ๐Ÿฆ‹.

Nominating Committee Operation : This covers the principles, rules, and constraints that guide the nominating committee's work, including the confirmation process ๐Ÿ”ฅ.

Member Recall : This is how the behavior of a sitting IESG or IAB member can be questioned, which might end with that member being removed ๐Ÿ˜ญ.

There's also a final section that explains how this doc differs from its predecessor, RFC2027 โœจ. More to come in the next part, bestie ๐Ÿ’œ๐ŸŽ€

2. General โœจ

okay bestie, these are the ground rules for the whole selection and confirmation process ๐Ÿ’… Each rule gets a little interpretation paragraph after it when it needs one.

(1) The nominating committee's main job is to review the open IESG and IAB positions ๐ŸŽ€ and then either nominate the incumbent or recruit a superior candidate ๐Ÿ‘‘

The nominating committee doesn't pick which positions it reviews ๐Ÿ™ˆ It gets told which ones. At a minimum, it gets the title of each position. It MAY also get a desirable set of qualifications for whoever fills each one ๐Ÿ“

Incumbents MUST notify the nominating committee if they don't wish to be nominated ๐Ÿซถ

The nominating committee does not confirm its candidates. It presents them to the appropriate confirming body, as described below ๐Ÿ’Œ

(2) The annual selection and confirmation process is expected to be completed within 3 months โฐ

It's expected to be finished one month before the Friday of the week before the Spring IETF, and it's expected to kick off 4 months before that same Friday ๐ŸŒธ

(3) Each year, one-half of each of the then-current IESG and IAB positions gets selected for review ๐Ÿฆ‹

The whole point is to review roughly half of the sitting IESG and IAB members every year. It's also recognised that circumstances MAY exist that require the nominating committee to review more or less than one-half of the current positions ๐ŸŒˆ For example, the IESG or IAB might reorganise before this process and create new positions, or there might be an odd number of current positions ๐Ÿ™ƒ

(4) Confirmed candidates are expected to serve at least a 2 year term ๐Ÿ’œ

This rule is all about making sure members serve the number of years that best helps review one-half of the members each year โœจ

It's consistent with this rule for the nominating committee to choose one or more of the currently open positions and give them a term greater than 2 years, so the ideal application of this rule works out in the future ๐Ÿ”ฎ

It's also consistent with this rule for the nominating committee to choose one or more of the currently open positions that share responsibilities with other positions (both those being reviewed and those sitting), and give them a term greater than 2 years. That way, all of those members won't get reviewed at the same time ๐Ÿซง

All member terms begin and end during the Spring IETF meeting that matches the end of the term they were confirmed for ๐Ÿ—“๏ธ Normally, the confirmed candidate's term starts when the sitting member's term ends on the last day of the meeting. A term MAY begin or end no sooner than the first day of the meeting, as long as the currently sitting member and the confirmed candidate mutually agree on it ๐Ÿค

(5) Mid-term vacancies are filled by the same rules as above, with four qualifications ๐Ÿฉท

  • First, the most recently constituted nominating committee gets reconvened to nominate a candidate for the vacancy.
  • Second, the selection and confirmation process is expected to be completed within 1 month, and all other time periods that aren't otherwise specified get prorated accordingly โณ
  • Third, the confirming body has two weeks from the day it's notified of a candidate to reject them. Otherwise, the candidate is assumed to have been confirmed โœ…
  • Fourth, the term of the confirmed candidate will be either:
    • a. the remainder of the term of the open position, if that remainder is not less than one year.
    • b. the remainder of the term of the open position plus the next 2 year term, if that remainder is less than one year.

(6) All deliberations and supporting information about specific nominees, candidates, and confirmed candidates are confidential ๐Ÿคซ๐Ÿ”’

Nominating committee and confirming body members get exposed to confidential info through their deliberations, their chats with the people they consult, and the folks who provide requested supporting info. Everyone involved MUST handle this info in a way that matches how sensitive it is. Wait, sorry, let me fix that: all members and other participants are expected to handle it consistently with its sensitivity ๐Ÿซถ

(7) Unless otherwise specified, the advise and consent model is used throughout the process ๐Ÿ’ซ Here's how it goes:

  • a. The IETF Executive Director advises the nominating committee of the IESG and IAB positions to be reviewed ๐Ÿ“‹
  • b. The nominating committee selects candidates and advises the confirming bodies of them ๐ŸŽฏ
  • c. The sitting IAB members review the IESG candidates, consenting to some, all, or none ๐Ÿง

If all of the candidates are confirmed, the nominating committee's job for the open IESG positions is complete ๐ŸŽ‰ If some or none of them are confirmed, the nominating committee MUST reconvene to select alternate candidates for the rejected ones ๐Ÿ” Any additional time the nominating committee needs SHOULD NOT exceed its maximum time allotment โฑ๏ธ

  • d. The Internet Society Board of Trustees reviews the IAB candidates, consenting to some, all, or none ๐ŸŒท

If all of the candidates are confirmed, the nominating committee's job for the open IAB positions is complete ๐ŸŽ‰ If some or none of them are confirmed, the nominating committee MUST reconvene to select alternate candidates for the rejected ones ๐Ÿ” Any additional time the nominating committee needs SHOULD NOT exceed its maximum time allotment โฑ๏ธ

  • e. The confirming bodies decide their consent using a mechanism of their own choosing, which MUST ensure that at least one-half of the sitting members agree with the decision ๐Ÿ—ณ๏ธ

At least one-half of the sitting members of the confirming bodies MUST agree to either confirm or reject each individual nominee ๐Ÿ’… The agreement MUST be decided within a reasonable timeframe โŒ› It MAY be decided by a formal vote, by asserting consensus based on informal exchanges (email), or by whatever mechanism is used to conduct the normal business of the confirming body ๐Ÿ“ฌ


3. Nominating Committee Selection ๐Ÿงš

okay now we're getting into who actually gets to be on the committee ๐Ÿ‘‘ These rules cover how it's created and how its members get picked.

(1) The committee is made up of at least a non-voting Chair, 10 voting volunteers, and 3 non-voting liaisons ๐ŸŒˆ

A Chair is permitted to invite additional non-voting advisors to take part in some or all of the committee's deliberations ๐Ÿซถ

(2) The Internet Society President appoints the non-voting Chair, who MUST meet the usual requirements for membership in the nominating committee ๐ŸŽ€

The nominating committee Chair MUST agree to invest the time needed to finish the committee's duties, and to perform in the best interests of the IETF community while doing them ๐Ÿ’–

(3) The Chair gets the list of IESG and IAB positions to be reviewed and publishes it, along with a solicitation for names of community volunteers willing to serve on the nominating committee ๐Ÿ“ฃ

The list of open positions gets published alongside the solicitation so community members can choose between volunteering for an open position and volunteering for the nominating committee ๐Ÿฆ‹

The list and the solicitation MUST be publicised using at least the same mechanism the IETF secretariat uses for its announcements ๐Ÿ“ข

(4) Members of the IETF community MUST have attended at least 2 of the last 3 IETF meetings in order to volunteer ๐Ÿงณ

(5) The Internet Society Board of Trustees, sitting members of the IAB, and sitting members of the IESG may not volunteer ๐Ÿ™…โ€โ™€๏ธ

(6) The Chair announces the pool of volunteers that the 10 voting volunteers will be randomly selected from ๐ŸŽฒ

The announcement MUST be made using at least the same mechanism the IETF secretariat uses for its announcements ๐Ÿ“ฃ

(7) The Chair randomly selects the 10 voting volunteers from the pool of names using a method that can be independently verified to be unbiased and fair ๐ŸŽฐ

A method is fair if each eligible volunteer is equally likely to be selected ๐Ÿ€ A method is unbiased if nobody can influence its outcome ๐Ÿ™Œ

The method MUST include an announcement of an enumerated list of the pool of names, together with the specific algorithm for how names will be chosen from the list ๐Ÿ“œ The output of the selection algorithm MUST depend on random data whose value isn't known at the time the list and algorithm are announced ๐Ÿ”

One possible method is to compute the MD5 hash of future winning lottery numbers and use the result to select names from the list ๐ŸŽฑ

All announcements MUST be made using at least the mechanism the IETF secretariat uses for its announcements ๐Ÿ“ข

(8) The sitting IAB and IESG members each appoint a non-voting liaison to the nominating committee from their current membership, as long as that person isn't sitting in an open position ๐Ÿค

(9) The Chair of the prior year's nominating committee serves as a non-voting liaison ๐ŸŒธ

The prior year's Chair MAY designate an alternate voting member from the prior year's committee if the Chair is unavailable ๐Ÿ”„ If the prior year's Chair is unavailable and is unable or unwilling to make that designation in a timely fashion, the Chair of the current committee MAY do so ๐Ÿงก

(10) The Chair MAY solicit additional non-voting liaisons from other organisations, and those liaisons MUST meet the usual requirements for membership in the nominating committee ๐ŸŒŸ

4. Nominating Committee Operation โœจ

okay so here are the rules for how the nominating committee actually runs ๐Ÿ’… some of them get a little paragraph explaining what they mean, and they're roughly lined up in the order you'd actually bump into them ๐Ÿงš

a nominee is anyone the nominating committee is currently thinking about ๐Ÿ‘€ a candidate is a nominee the committee has picked to move forward for confirmation by a confirming body ๐ŸŒธ and a confirmed candidate is a candidate who's been reviewed and approved by a confirming body ๐Ÿ’–

(1) anything the rules don't cover, plus any weird special situations, is up to the Chair ๐Ÿ‘‘

exceptional circumstances will pop up now and then, and this rule is there to keep the committee moving forward ๐Ÿš€ every member SHOULD think about whether the exception is worth mentioning in the next revision of this document and then followup accordingly ๐ŸŽ€

(2) the Chair MUST establish and publicize milestones, and those MUST include at least a call for nominations ๐Ÿ“…

there's a set time window for finishing the selection and confirmation process โฐ the Chair MUST set up milestones that, if they're hit on time, get the whole thing done on time. the Chair SHOULD leave room to go back and redo activities if one or more candidates don't get confirmed ๐Ÿ”

the milestones MUST be publicized using at least the same mechanism the IETF secretariat uses for its announcements ๐Ÿ“ฃ

(3) the Chair MUST establish a voting mechanism ๐Ÿ—ณ๏ธ

the committee MUST be able to objectively tell when a decision has been made during its deliberations ๐Ÿง  the criteria for deciding when things are closed MUST be established and known to every member of the nominating committee ๐Ÿ’œ

(4) at least a quorum of committee members MUST take part in a vote. a quorum is at least 7 voting members ๐Ÿซถ

(5) the Chair MAY establish a process through which a member of the nominating committee MAY be recalled ๐Ÿ”„

if that process gets established, it MUST be agreed to by a 3/4 majority of the nominating committee members, including the non-voting members, since they'd be under the same process too ๐Ÿค

(6) all members of the nominating committee MAY take part in all deliberations ๐Ÿ’ฌ

the big deal here is that nobody, whether voting or non-voting, can be explicitly shut out of any deliberation ๐Ÿ™…โ€โ™€๏ธ but a member MAY individually choose to sit one out ๐ŸŒ™

(7) the Chair announces the open positions to be reviewed, plus the call for nominees ๐Ÿ“ข

the call for nominees MUST include a request for comments about how incumbents have been doing, and the committee will look at those while it deliberates ๐Ÿ‘€ and the announcements MUST be publicized using at least the same mechanism the IETF secretariat uses for its announcements ๐Ÿ“ฃ

(8) any member of the IETF community MAY nominate any member of the IETF community for any open position ๐ŸŒŸ

self-nomination is totally allowed ๐Ÿ™Œ

(9) nominating committee members MUST NOT be nominees ๐Ÿšซ

being a nominee means you're going through the process of being picked as a candidate and getting confirmed. nominating committee members aren't eligible to be considered for any open position ๐Ÿ™ˆ

(10) members of the IETF community who were recalled from any IESG or IAB position during the previous two years MUST NOT be nominees ๐Ÿ’€

(11) the nominating committee picks candidates based on its understanding of the IETF community's consensus about the qualifications required to fill the open positions ๐ŸŒˆ

this rule exists so the committee talks to a broad range of the IETF community for input ๐Ÿ—ฃ๏ธ the consultations MAY include a slate of nominees, as long as every party agrees to follow customary and reasonable rules of confidentiality ๐Ÿคซ a broad base of the community SHOULD include the existing members of the IAB and IESG, especially sitting members who share responsibilities with open positions, e.g., co-Area Directors ๐Ÿฆ‹

(12) nominees SHOULD be told they're being considered, and they MUST consent to their nomination before being confirmed ๐Ÿ’Œ

the nominating committee SHOULD help nominees put together justification for their employers ๐Ÿ’ผ a nominee's consent MUST be written (email is acceptable) and MUST include a commitment to provide the resources needed to fill the open position, plus an assurance that the nominee will perform the duties of that position in the best interests of the IETF community ๐Ÿซก

(13) the nominating committee tells the confirming bodies about their candidates, naming a single candidate for each open position along with a testament about how each candidate meets the qualifications of that open position ๐Ÿ“œ

the testament MAY include a brief resume of the candidate and a summary of the committee's deliberations ๐Ÿงพ

(14) for any action taken while notifying and announcing confirmed candidates, and while notifying rejected nominees and candidates, the action MUST be valid under all of the rules below before it gets executed โœ…

a. until a candidate is confirmed, their identity MUST be kept confidential ๐Ÿค

b. the identity of all nominees MUST be kept confidential, except that the nominee MAY publicize their own intentions ๐Ÿ“ฃ

c. rejected nominees MAY be notified as soon as they're rejected ๐Ÿ’”

d. rejected candidates MAY be notified as soon as they're rejected ๐Ÿ’”

e. rejected nominees and candidates MUST be notified before confirmed candidates are announced ๐Ÿซถ

f. confirmed candidates MAY be notified and announced as soon as they're confirmed ๐ŸŽ‰

it's totally consistent with these rules for a nominee to never find out whether they were a candidate ๐Ÿซฅ it's also consistent for some nominees to get rejected early and for others to be kept as alternates in case a candidate gets rejected by a confirming body ๐Ÿ”„ whether a confirmed candidate was a first choice or an alternate doesn't ever need to be disclosed, and honestly it probably SHOULD NOT ever be ๐Ÿคซ

it's also consistent for confirmed candidates to be notified and announced as quickly as possible, instead of making every confirmed candidate wait until all open positions have been reviewed โšก and when consulting individual members of the IETF community, a slate of nominees MAY be included if all parties agree to customary and reasonable rules of confidentiality ๐Ÿค

the announcements MUST be publicized using at least the same mechanism the IETF secretariat uses for its announcements ๐Ÿ“ฃ


5. Member Recall ๐Ÿฆ‹

okay this is the recall process ๐Ÿฆ‹ if a rule needs some explaining, there's a little paragraph under it

(1) anyone MAY request the recall of any sitting IAB or IESG member, at any time, by written request with justification to the Internet Society President (email is acceptable) ๐Ÿ“จ

(2) the Internet Society President SHALL appoint a Recall Committee Chair ๐Ÿ‘‘

the Internet Society President MUST NOT evaluate the recall request ๐Ÿ™…โ€โ™€๏ธ evaluating how the leaders behave is explicitly the job of the IETF community ๐Ÿซถ

(3) the recall committee is made using the same rules as the nominating committee, with the extra condition that the person being investigated and the person who requested the recall MUST NOT be members of the recall committee in any capacity ๐Ÿšซ

(4) the recall committee runs by the same rules as the nominating committee, with one difference: there's no confirmation process ๐ŸŒธ

(5) the recall committee looks into the circumstances behind the justification for the recall, then votes on its findings ๐Ÿ”

the investigation MUST include at least two things: the member being recalled gets a chance to present a written statement, and the committee consults third parties ๐Ÿ“

(6) a 3/4 majority of the members who vote on the question is REQUIRED for a recall โš–๏ธ

(7) if a sitting member is recalled, the open position gets filled according to the mid-term vacancy rules ๐Ÿ”


6. Changes From RFC2027 ๐Ÿ“

here's what's new compared to RFC2027 ๐Ÿ†•

(1) so nominating committees can talk to each other better from one year to the next, the Chair of each year's committee has been added as a non-voting liaison to the next year's committee ๐Ÿ’ž

(2) to confirm that each volunteer in the pool of names is eligible, the Chair MUST announce the list before the random selection ๐Ÿ“‹

(3) to confirm the random selection process used to pick the voting nominating committee members, the Chair MUST announce the fair and unbiased method in advance of using it ๐ŸŽฒ

(4) some guidance was added to make sure the nominating committee consults with a broad base of the IETF community ๐ŸŒ

(5) some guidance was added so the nominating committee knows it MAY name prospective nominees when consulting individual members of the IETF community ๐Ÿ’ซ

(6) some guidance was added so the nominating committee knows it's responsible for making sure an appropriate set of one-half of each of the IESG and IAB positions gets reviewed each year ๐Ÿ—“๏ธ


7. Security Considerations ๐Ÿ”

this part is serious, bestie, so please read it properly ๐Ÿฅบ

any selection, confirmation, or recall process necessarily involves looking into the qualifications and activities of prospective candidates ๐Ÿ”Ž that investigation MAY reveal confidential or otherwise private information about candidates to the people taking part in the process ๐Ÿ˜ณ so every person who participates in any aspect of the process has a responsibility to keep confidential any and all information that hasn't been explicitly marked as suitable for public dissemination ๐Ÿ”’ no leaks, no gossip, no exceptions ๐Ÿ’€


8. Editor's Address ๐Ÿ’Œ

James M. Galvin
eList eXpress LLC
PO Box 220
Glenwood, MD, 21738

EMail: galvin@elistx.com

Okay bestie, last one, and it's the legal stuff ๐Ÿ™ˆ but the important bits are kinda iconic, so read along โœจ

Copyright (C) The Internet Society (1998). All Rights Reserved. ๐Ÿ’–

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. ๐Ÿฆ‹

Basically: you can share it, and you can write stuff that explains or helps implement it, but the original doc itself can't be edited (no deleting the copyright notice or the Internet Society references), unless it's for developing Internet standards or translating into another language. Respect the copyright, periodt ๐Ÿ’…

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. โญ

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ๐Ÿ˜ญ

๐Ÿ“ฆ where this page comes from