RFC 2727

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

๐Ÿ“… published February 2000, from ietf

RFC 2727: IAB and IESG Selection, Confirmation, and Recall Process ๐Ÿฆ‹

okay bestie, this one is a Best Current Practice (BCP 10) ๐ŸŽ€ It's by J. Galvin from eList eXpress LLC, published in February 2000. It obsoletes RFC 2282, which is the older version, so this is the one to read now. It's all about how the people on the IAB and IESG get picked, confirmed, and (if it ever comes to that) recalled ๐Ÿ‘‘

Status of this Memo ๐ŸŒธ

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

Copyright Notice ๐Ÿ’œ

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract ๐Ÿ“

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self-consistent, organized compilation of the process as it was known at the time of publication.

Table of Contents ๐Ÿงš

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

1. Introduction โœจ

okay so this doc is a revision of RFC2282 and it supercedes it (that's the spelling in the original, bestie ๐Ÿ˜ญ). It's a complete spec for how IAB and IESG members get selected, confirmed, and recalled, as of the date it was approved. BUT the procedures can change, and any change takes effect right away on approval, even if this doc hasn't been updated yet ๐Ÿ’…

Two assumptions are still true for this spec:

(1) The Internet Research Task Force (IRTF) and Internet Research Steering Group (IRSG) are not part of the process here. ๐Ÿ™ˆ

(2) The organization (and re-organization) of the IESG is not part of the process here.

The time frames use IETF meetings as the reference point. They assume the IETF meets at least once per calendar year, and everything is measured relative to the first IETF of the calendar year, aka "First IETF" ๐Ÿ—“๏ธ

The rest of the doc is split into four big topics:

General: a set of rules and constraints for the selection and confirmation process as a whole. ๐ŸŽ€

Nominating Committee Selection: how volunteers from the IETF community get recognized to serve on the committee that nominates candidates for the IESG and IAB. ๐ŸŒˆ

Nominating Committee Operation: the principles, rules, and constraints that guide what the nominating committee does, including the confirmation process. ๐Ÿ”ฅ

Member Recall: how the behavior of a sitting IESG or IAB member can be questioned, which might end in them being removed. ๐Ÿ’€

There's also a final section on how this doc differs from its predecessor, RFC2282 ๐Ÿฆ‹

2. General ๐Ÿ‘‘

okay this is the big rules section, and it applies to the whole selection and confirmation process. If a rule needs explaining, there's a paragraph about how to read it right after ๐Ÿซถ

(1) The main jobs of the nominating committee are to review the open IESG and IAB positions, and either nominate the incumbent or recruit a superior candidate ๐Ÿ’–

The nominating committee does not pick which open positions to review. It's told which ones to review ๐Ÿ“‹

At a minimum, the committee gets the title of the position being reviewed. It may also get a desirable set of qualifications for the candidate who'll fill each position โœจ

Incumbents must notify the nominating committee if they don't want to be nominated. ๐Ÿ™…โ€โ™€๏ธ

The nominating committee does not confirm its own candidates. It presents them to the right confirming body (more on that below) ๐Ÿ’…

(2) The annual selection and confirmation process is expected to be finished within 3 months ๐Ÿ—“๏ธ

It's expected to be done one month before the Friday of the week before the First IETF. It's expected to start 4 months before that same Friday. The timeline is giving very specific energy ๐Ÿ˜ญ

(3) Exactly one-half of each of the current IESG and IAB positions gets selected for review every year ๐ŸŒธ

The point here is to review roughly half of the sitting IESG and IAB members each year. Circumstances might mean the committee reviews more or fewer than half, like if the IESG or IAB reorganized and made new positions beforehand, or if there's an odd number of current positions ๐Ÿ™ˆ

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

The goal of this rule is to make sure members serve the number of years that makes reviewing half of them each year work best ๐Ÿงš

It's okay for the nominating committee to pick one or more of the currently open positions and give them a term longer than 2 years, so the rule can be applied perfectly in the future ๐ŸŒˆ

It's also okay for the committee to pick open positions that share responsibilities with other positions (both the ones being reviewed and the ones sitting). They can give those a term longer than 2 years too, so all of those members won't get reviewed at the same time ๐Ÿ’œ

All sitting member terms end during the First IETF meeting that matches the end of the term they were confirmed for. All confirmed candidate terms begin during the First IETF meeting that matches the start of that term. Normally, the 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 and no later than the last day of the meeting, as long as the sitting member and the confirmed candidate agree on it. The candidate's term may overlap the sitting member's term during the meeting if they both agree to that too โญ

Note for later parts: Section 2 continues with item (5) on mid-term vacancies, item (6) on confidentiality, and item (7) on the advise and consent model.

3. Nominating Committee Selection ๐ŸŽ€

okay bestie, this is the rulebook for how the nominating committee gets put together 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 ๐Ÿซถ

Any committee member can propose adding a non-voting advisor to join some or all of the committee's deliberations โœจ The addition must be approved by both the voting and non-voting members of the committee, using its established voting mechanism. Advisors join as individuals ๐Ÿงš

Any committee member can also propose adding a non-voting liaison from other unrepresented organizations to join some or all of the deliberations ๐ŸŒธ The addition must be approved by both the voting and non-voting members of the committee, using its established voting mechanism. Liaisons join as representatives of their own organizations, so it's giving team player energy ๐Ÿฆ‹

Advisors and liaisons must meet the usual requirements for membership in the nominating committee. For liaisons, the requirements apply to the organization, not the individual ๐Ÿ’œ

(2) The Internet Society President appoints the non-voting Chair, and that Chair must meet the usual requirements for membership in the nominating committee ๐Ÿ‘‘

The nominating committee Chair must agree to invest the time needed to make sure the committee finishes its assigned duties, and to act in the best interests of the IETF community while in that role ๐Ÿซถ

(3) The Chair gets the list of IESG and IAB positions up for review, then publishes it along with a call for names of IETF community volunteers who want to serve on the nominating committee ๐Ÿ“ฃ

The open positions list goes out with the call so community members can compare volunteering for an open position with volunteering for the nominating committee. Very strategic ๐Ÿ“

The list and the call must be publicized 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) Internet Society Board of Trustees members, sitting members of the IAB, and sitting members of the IESG may not volunteer. Sorry, you're benched for this one ๐Ÿ’€

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

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

(7) The Chair randomly picks the 10 voting volunteers from the pool of names, using a method that can be independently verified as unbiased and fair ๐Ÿ”ฅ

A method is fair if every eligible volunteer is equally likely to be picked. A method is unbiased if nobody can push its outcome toward a specific result. Fairness with receipts ๐Ÿงพ

The method must include an announcement of an enumerated list of the pool of names, along with the specific algorithm for how names will be chosen from that list. The output of the selection algorithm must depend on random data whose value is not known when the list and algorithm are announced. No peeking allowed ๐Ÿ™ˆ

One possible method is described in [1] ๐Ÿ“–

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. Main character returns ๐Ÿ‘‘

The prior year's Chair may select a designee from a pool made up of the voting members of the prior year's committee and all prior Chairs, if the Chair is unavailable. If the prior year's Chair is unavailable and can't or won't make that designation in a timely way, the Chair of the current committee may do so ๐ŸŒˆ

Picking a member of the prior year's committee as the designee means the experience from last year's deliberations is easy for the current committee to access. Picking an earlier prior year Chair as the designee means the experience of being a Chair, along with that Chair's committee deliberations, is easy to access too. Institutional memory is everything ๐Ÿงš๐Ÿ’–

4. Nominating Committee Operation โœจ

okay so this is where the nominating committee actually gets to work ๐Ÿ’… If a rule needs a little explaining, there's a paragraph right under it ๐ŸŽ€

The rules are roughly in the order you'd hit them ๐Ÿฆ‹

Quick vocab, bestie ๐Ÿ“–: a nominee is someone the committee is thinking about ๐Ÿ‘€. A candidate is a nominee the committee picked to go to a confirming body ๐ŸŒธ. A confirmed candidate is a candidate a confirming body has reviewed and approved ๐Ÿ’œ.

(1) All rules and special circumstances not otherwise specified are at the discretion of the committee. โœจ

Exceptional circumstances will pop up now and then ๐Ÿ˜ญ This rule is there so the committee keeps moving forward ๐Ÿƒโ€โ™€๏ธ

Any member of the committee MAY propose a rule for adoption by the committee. The rule MUST be approved by both the voting and non-voting members of the committee according to its established voting mechanism ๐Ÿ—ณ๏ธ

All members of the committee SHOULD consider whether the exception is worthy of mention in the next revision of this document and followup accordingly ๐Ÿ“

(2) The Chair MUST establish and publicize milestones, which MUST include at least a call for nominations. ๐Ÿ“ฃ

There is a defined time period during which the selection and confirmation process MUST be completed โฐ The Chair MUST establish a set of milestones which, if met in a timely fashion, will result in the completion of the process on time. The Chair SHOULD allow time for iterating the activities of the committee if one or more candidates is not confirmed ๐Ÿ”

The milestones MUST be publicized using at least the same mechanism used by the IETF secretariat for its announcements.

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

The committee MUST be able to objectively determine when a decision has been made during its deliberations. The criteria for determining closure MUST be established and known to all members of the nominating committee ๐Ÿ”

(4) At least a quorum of committee members MUST participate in a vote. A quorum comprises at least 7 voting members. ๐Ÿ™Œ

(5) The Chair MAY establish a process by which a member of the nominating committee MAY be recalled. ๐Ÿซฃ

The process, if established, MUST be agreed to by a 3/4 majority of the members of the nominating committee, including the non-voting members since they would be subject to the same process ๐Ÿค

(6) All members of the nominating committee MAY participate in all deliberations. ๐Ÿ’ฌ

The emphasis of this rule is that no member, whether voting or non-voting, can be explicitly excluded from any deliberation. However, a member MAY individually choose not to participate ๐Ÿซถ

(7) The Chair announces the open positions to be reviewed and the call for nominees. ๐Ÿ“ข

The call for nominees MUST include a request for comments regarding the past performance of incumbents, which will be considered during the deliberations of the nominating committee ๐Ÿ‘€

The announcements MUST be publicized using at least the same mechanism used by the IETF secretariat for its announcements.

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

A self-nomination is permitted. Main character energy ๐Ÿ‘‘

(9) Nominating committee members MUST NOT be nominees. ๐Ÿ™…โ€โ™€๏ธ

To be a nominee is to enter the process of being selected as a candidate and confirmed. Nominating committee members are not eligible to be considered for filling any open position. They become ineligible as soon as their role is announced to the IETF community, and they remain ineligible for the duration of this nominating committee's term ๐ŸŽ€

(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 selects candidates based on its understanding of the IETF community's consensus of the qualifications required to fill the open positions. ๐Ÿง 

The intent of this rule is to make sure the nominating committee consults a broad base of the IETF community for input to its deliberations ๐ŸŒ

The consultations are permitted to include a slate of nominees, if all parties to the consultation agree to observe 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 advised that they are being considered and MUST consent to their nomination prior to being confirmed. ๐Ÿ’Œ

The nominating committee SHOULD help nominees provide justification to their employers ๐Ÿ’ผ

A nominee's consent MUST be written (email is acceptable) and MUST include a commitment to provide the resources necessary to fill the open position, plus an assurance that the nominee will perform the duties of the position for which they are being considered in the best interests of the IETF community ๐Ÿซถ

(13) The nominating committee advises the confirming bodies of their candidates, specifying a single candidate for each open position and a testament as to how each candidate meets the qualifications of an open position. ๐Ÿ“ฎ

The testament MAY include a brief resume of the candidate and a summary of the deliberations of the nominating committee ๐Ÿ“„

(14) With respect to any action to be taken in the context of notifying and announcing confirmed candidates, and notifying rejected nominees and candidates, the action MUST be valid according to all of the rules specified below prior to its execution. ๐Ÿงพ

a. Up until a candidate is confirmed, the identity of the candidate MUST be kept confidential. ๐Ÿ”’

b. The identity of all nominees MUST be kept confidential (except that the nominee MAY publicize their intentions). ๐Ÿค

c. Rejected nominees MAY be notified as soon as they are rejected. ๐Ÿ’”

d. Rejected candidates MAY be notified as soon as they are rejected. ๐Ÿ’”

e. Rejected nominees and candidates MUST be notified prior to announcing confirmed candidates. ๐Ÿ“ฌ

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

It is consistent with these rules for a nominee to never know if they were a candidate or not ๐Ÿ™ˆ

It is consistent with these rules for some nominees to be rejected early in the process, and for some nominees to be kept as alternates in case a candidate is rejected by a confirming body. Whether a confirmed candidate was a first choice or an alternate is information that need not ever be disclosed and, in fact, probably never should be ๐Ÿค

It is consistent with these rules for confirmed candidates to be notified and announced as quickly as possible, instead of requiring all confirmed candidates to wait until all open positions have been reviewed ๐Ÿš€

When consulting with individual members of the IETF community, if all parties to the consultation agree to observe customary and reasonable rules of confidentiality, the consultations are permitted to include a slate of nominees ๐Ÿซข

The announcements MUST be publicized using at least the same mechanism used by the IETF secretariat for its announcements.

5. Member Recall ๐Ÿšจ

okay, recall rules time, and these are serious but still kinda iconic ๐Ÿ˜ค If something needs explaining, there's a paragraph for it ๐Ÿ’…

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

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

The Internet Society President MUST NOT evaluate the recall request. It is explicitly the responsibility of the IETF community to evaluate the behavior of its leaders ๐Ÿง

(3) The recall committee is created according to the same rules as the nominating committee, with the qualifications that the person being investigated and the person requesting the recall MUST NOT be a member of the recall committee in any capacity. ๐Ÿ™…โ€โ™€๏ธ

(4) The recall committee operates according to the same rules as the nominating committee, with the qualification that there is no confirmation process. ๐Ÿ”„

(5) The recall committee investigates the circumstances of the justification for the recall and votes on its findings. ๐Ÿ”Ž

The investigation MUST include at least both an opportunity for the member being recalled to present a written statement and consultation with 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 is to be filled according to the mid-term vacancy rules. ๐Ÿช„

6. Changes From RFC2282 ๐ŸŒธ

okay so this part is the tea โ˜• It lists the substantive changes from RFC2282 ๐Ÿ’– Editorial changes aren't described here, just the substantive ones. They're listed in the order they show up in the document ๐Ÿ“š

(1) The frame of reference for timeframes was changed from the seasonal "Spring IETF" reference to the less geographic and more temporal "First IETF" reference. ๐ŸŒท

(2) The terms of the sitting members and their respective confirmed candidates are explicitly permitted to overlap during the First IETF, as determined by their mutual agreement. ๐Ÿค

(3) Nominating committee members who have served on prior committees are explicitly permitted to advise the current committee on the deliberations and results of the prior committee. ๐Ÿง 

(4) The role and opportunity for additional advisors and liaisons to the nominating committee was clarified. ๐Ÿ—ฃ๏ธ

(5) A reference to a documented and accepted fair and unbiased mechanism for randomly selecting nominating committee members from the pool of volunteers was added. ๐ŸŽฒ

(6) The option for the prior year's Chair to select a designee to serve as liaison to the current year's committee was clarified, to ensure the Chair selected a non-voting liaison from a pool composed of the prior year's voting members and all prior committee Chairs. ๐Ÿงš

(7) The responsibility and authority for the activities of the nominating committee rest with the committee as a whole, not with the Chair. The operation of the committee was clarified to require changes in process and the handling of exceptions to be approved by the committee as a whole, as opposed to being at the discretion of the Chair. ๐Ÿซถ

(8) The rule that prevented nominating committee members from being eligible to be considered for any open position was clarified to explicitly state that the rule applies from the point in time that the committee membership is announced through the entire term of the current committee. ๐Ÿ’…โœจ

7. Acknowledgements โœจ

okay bestie, big shoutout time ๐ŸŽ€ a huge chunk of credit goes to the first three Nomcom Chairs ๐Ÿ‘‘, who had to run the whole thing with zero documented process. no cap, they just vibed on oral tradition and their own good sense, and that became the very first version of this doc ๐Ÿ’–

1993 - Jeff Case 1994 - Fred Baker 1995 - John Curran

we can't forget the chairs after them either ๐Ÿ˜ญ they all had to survive the bug-hunting grind since the first publication ๐Ÿซถ

1996 - Guy Almes 1997 - Geoff Houston 1998 - Mike St. Johns 1999 - Donald Eastlake

and of course the bulk of the love goes to the members of the POISSON Working Group, formerly the POISED Working Group ๐Ÿฆ‹ the prose is only this good because they reviewed it so carefully and so insightfully ๐Ÿ’… special thanks to Scott Bradner and John Klensin, who kept making this document better the whole way through its evolution ๐ŸŒˆ

8. Security Considerations ๐Ÿ™ˆ

Real talk, this section is serious, so read it carefully bestie ๐Ÿ’€

any selection, confirmation, or recall process has to dig into the qualifications and activities of the candidates, no way around it. that digging can reveal confidential or otherwise private info about candidates to the people taking part in the process ๐Ÿ˜ณ so everyone who participates in any part of the process has a responsibility to keep confidential any and all information that hasn't been explicitly marked as okay for public sharing ๐Ÿ”’โœจ

9. References ๐Ÿ“š

  • [1] Eastlake, D., "Publicly Verifiable Nomcom Random Selection", RFC 2777, February 2000.

10. Editor's Address ๐Ÿ’Œ

James M. Galvin eList eXpress LLC 607 Trixsam Road Sykesville, MD 21784

EMail: galvin@elistx.com

Copyright (C) The Internet Society (2000). All Rights Reserved. ๐ŸŒธ

this document and translations of it can be copied and shared with others ๐Ÿซถ, and derivative works that comment on it, explain it, or help with implementing it can be written, copied, published and distributed, in whole or in part, with no restrictions of any kind ๐Ÿฆ‹. the one catch is that the copyright notice and this paragraph have to stay on all copies and derivative works ๐Ÿ’… however, this document itself may not be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet organizations ๐Ÿ™…โ€โ™€๏ธ. the exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's translated into languages other than English ๐ŸŒ

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 in it 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 ๐Ÿ˜ญ๐Ÿซ 

Acknowledgement ๐Ÿ™

funding for the RFC Editor function is currently provided by the Internet Society ๐Ÿ’ธโœจ

๐Ÿ“ฆ where this page comes from