RFC 8713
IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees
RFC 8713: The Nerd Squad Behind IETF Leadership Picks ๐ ๐
Okay bestie, let's talk about RFC 8713. It's a Best Current Practice (BCP 10) ๐, which means it's the IETF's official recommended way of doing things. It came out in February 2020 and it's ISSN 2070-1721. The title is "IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees." Long name, big energy โจ
The authors are M. Kucherawy, Ed., R. Hinden, Ed. (from Check Point Software ๐ฆ), and J. Livingood, Ed. (from Comcast ๐ธ). Also, this one obsoletes RFC 7437 and RFC 8318, so if you're still reading an older version, it's giving outdated ๐
Internet Engineering Task Force (IETF)
Abstract ๐ฅ
Okay so the abstract is basically the TL;DR. This doc spells out how the people who sit on the IAB and IESG, some IETF Trust Trustees, and some IETF Administration LLC (IETF LLC) Directors get picked, confirmed, and (if needed) recalled. ๐
It's based on RFC 7437, but only the bits that needed to change for the IETF Administrative Support Activity (IASA) 2.0 got updated. Anything else is saved for future docs. Iconic restraint ๐ซถ
This document obsoletes RFC 7437 and RFC 8318.
Status of This Memo ๐
This memo documents an Internet Best Current Practice. ๐
This is an IETF product. It reflects consensus across the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. More info on BCPs is in Section 2 of RFC 7841 ๐
For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8713 ๐
Copyright Notice โญ
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. ๐
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they explain your rights and restrictions. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says ๐
Table of Contents ๐ง
1. Introduction
2. Definitions
3. General
3.1. Completion Due
3.2. Nominating Committee Principal Functions
3.3. Positions to Be Reviewed
3.4. Term Lengths
3.5. Mid-term Vacancies
3.6. Confidentiality
3.7. Advice and Consent Model
3.7.1. Positions to Be Reviewed
3.7.2. Candidate Selection
3.7.3. Candidate Review
3.7.4. Confirmation
3.8. Sitting Members, Directors, and Trustees
3.9. Announcements
4. Nominating Committee Selection
4.1. Timeline
4.2. Term
4.3. Structure
4.4. Chair Duties
4.5. Chair Selection
4.6. Temporary Chair
4.7. Liaisons
4.8. Liaison Appointment
4.9. Advisors
4.10. Past Chair
4.11. Voting Volunteers
4.12. Milestones
4.13. Open Positions
4.14. Volunteer Qualification
4.15. Not Qualified
4.16. Selection Process
4.17. Announcement of Selection Results
4.18. Committee Organization
5. Nominating Committee Operation
5.1. Discretion
5.2. Selection Timeline
5.3. Confirmation Timeline
5.4. Milestones
5.5. Voting Mechanism
5.6. Voting Quorum
5.7. Voting Member Recall
5.8. Chair Recall
5.9. Deliberations
5.10. Call for Nominees
5.11. Nominations
5.12. Candidate Selection
5.13. Consent to Nomination
5.14. Notifying Confirming Bodies
5.15. Confirming Candidates
5.16. Archives
6. Dispute Resolution Process
7. Member, Trustee, and Director Recall
7.1. Petition
7.1.1. Community Petition
7.1.2. Ombudsteam Petition
7.2. Recall Committee Chair
7.3. Recall Committee Creation
7.4. Recall Committee Rules
7.5. Recall Committee Operation
7.6. 3/4 Majority
7.7. Position to Be Filled
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Changes Since RFC 3777
Appendix B. Changes Since RFC 7437
Appendix C. Oral Tradition
Appendix D. Nominating Committee Timeline
Acknowledgments
Authors' Addresses
1. Introduction ๐ธ
Okay so this doc is a revision of [RFC7437], updated so it lines up with the IASA 2.0 changes. RFC 7437 was built on [RFC3777], which had already combined and updated a bunch of other RFCs into one spec. Basically, this is the complete, all-in-one guide for how members of the Internet Architecture Board (IAB) and Internet Engineering Steering Group (IESG), plus some IETF Trust Trustees and some IETF LLC Directors, get selected, confirmed, and recalled. ๐ฆ
This revision only handles the stuff IASA 2.0 requires. If the community agrees on other changes, those will land in future documents ๐ง
Section 2 of [RFC8714] has more details on the IETF Trust Trustee seats that the IETF Nominating Committee (NomCom) fills.
Section 5 of [RFC8711] has more details on the IETF LLC Director seats that the NomCom fills.
Two assumptions are still true for this spec:
- The Internet Research Task Force (IRTF) and Internet Research Steering Group (IRSG) are not part of the process here. ๐ โโ๏ธ
- How the IESG is organized (and reorganized) is not part of the process here. ๐ โโ๏ธ
The timeframes in here are measured in IETF meetings ๐ . They assume the IETF meets three times per calendar year, with roughly equal gaps between meetings. We call them the First IETF, Second IETF, or Third IETF, as needed. โจ
The next section lists the words and phrases that show up a lot in this doc, along with what they mean.
The main body is split into four big topics:
- General: Rules and constraints that apply to the selection and confirmation process as a whole. ๐
- Nominating Committee Selection: How the volunteers who will serve on the NomCom get picked. ๐
- Nominating Committee Operation: The principles, rules, and constraints that guide what the NomCom does, including the confirmation process. ๐
- Member, Trustee, and Director Recall: How the behavior of a sitting IESG or IAB member, an IETF Trust Trustee, or an IETF LLC Director can be questioned. This could end in that person being removed. See Section 2 for what "sitting member" means for each group. ๐ญ
A final section explains how this doc differs from [RFC3777] and [RFC7437] ๐. There's also an appendix of handy facts and practices collected from past NomComs ๐
This document updates the IAB, IESG, and IAOC Selection, Confirmation, and Recall Process so it matches the IASA 2.0 Model [RFC8711]. That model creates an IETF Administration Limited Liability Company (IETF LLC) run by a Board of Directors (IETF LLC Board) ๐ This document obsoletes [RFC7437] and [RFC8318].
2. Definitions ๐
These words and phrases come up all over the doc. They're listed here so you don't have to guess what they mean ๐
- Candidate: A nominee who got selected to be considered for confirmation by a confirming body. ๐
- Confirmed Candidate: A candidate that a confirming body has reviewed and approved. โ
- Nominating Committee Term: The term starts when its members are officially announced. That's expected to happen before the Third IETF, so the committee is fully up and running by then. The term ends at the Third IETF (not three meetings) after the next NomCom's term begins. ๐ฆ
- IETF Executive Director: The person in charge of the day-to-day running of the IETF's admin functions. (See Section 4.1 of [RFC8711].) Note: this used to be the name of the IETF Secretariat position that's now called the "Managing Director, IETF Secretariat". ๐ง
- Managing Director, IETF Secretariat: The person in charge of running the IETF Secretariat function. (See Section 2 of [RFC3710] and [RFC8717].) ๐ซถ
- Nominee: A person who is being, or has been, considered for one or more open positions on the IESG, IAB, IETF Trust Trustee seats, or the IETF LLC. ๐
- Sitting Member: A person who is currently serving as a member of the IESG or IAB. ๐
- Sitting Director: A person who is currently serving as a Director of the IETF LLC. ๐ธ
- Sitting IETF Trust Trustee: A person who is currently serving as a Trustee of the IETF Trust. ๐
3. General ๐
Okay so these rules apply to the whole process. If a rule needs some explaining, there's a paragraph about how to interpret it right after ๐
3.1. Completion Due โฐ
The annual process has to be finished within seven months.
More specifically, it's due one month before the Friday of the week before the First IETF. It's expected to kick off at least eight months before the Friday of the week before the First IETF ๐
The process officially begins when the committee's Chair is announced. It officially ends when all confirmed candidates have been announced. ๐
The annual process has three big parts:
- Picking and organizing the NomCom members. ๐ง
- The NomCom selecting candidates. ๐
- Confirming the candidates. โ
There's an extra month set aside between when the annual process is expected to end and when the new candidates' terms are supposed to start. In unusual situations, that time can be used to stretch out any of the parts listed above ๐ฆ
3.2. Nominating Committee Principal Functions ๐
The NomCom's main job is to review each open IESG, IAB, IETF Trust, and IETF LLC Director position, and then select either the current holder or a superior candidate. ๐
There's no term limit for serving in any IESG, IAB, or IETF Trust position. Even so, the NomCom can use how long someone has served as one of its criteria when it evaluates an incumbent ๐
The NomCom doesn't pick which open positions get reviewed. It's told which positions to review. ๐ โโ๏ธ
The NomCom will be given the titles of the positions to be reviewed, plus a short summary of the expertise wanted in the candidate who fills each position. ๐ซถ
Incumbents have to let the NomCom know if they want to be nominated. ๐ฅ
The NomCom doesn't confirm its own candidates. Instead, it presents them to the appropriate confirming body, as described below. ๐
A superior candidate is one the NomCom believes would help improve or enhance the body they're nominated to. That's the vibe ๐ธโจ
3.3. Positions to Be Reviewed ๐
Each year, about half of the then-current IESG and IAB positions, one IETF Trust position, and one IETF LLC Director position get selected for review. Bestie, that's the rotation in a nutshell ๐ธ
The point of this rule is to make sure roughly half of the IESG and IAB sitting members get reviewed each year, plus one of the three NomCom-nominated IETF LLC Director positions and one of the three nominated IETF Trust Trustee positions. Okay but life happens, so the NomCom may end up reviewing more or fewer positions than usual. That could happen if the IESG, IAB, IETF Trust, or IETF LLC Board reorganized before this process and created new positions, if there's an odd number of current positions, or if a member, a Director, or a Trustee unexpectedly resigns ๐ซถ
3.4. Term Lengths โณ
Confirmed IESG and IAB candidates are expected to serve at least a two-year term. The goal here is for IESG and IAB members to serve the number of years that makes reviewing half of the members each year work smoothly โจ
Confirmed IETF LLC Director candidates are expected to serve at least a three-year term, unless a nominating or selection body decides on a shorter term to allow for initial staggered appointments. For more on term length and term limits for the IETF LLC Board, check out Section 6 of [RFC8711] ๐ผ
Confirmed IETF Trust Trustee candidates are expected to serve at least a three-year term, unless a nominating or selection body decides on a shorter term to allow for initial staggered appointments. For more on term length and term limits for the IETF Trust, see Section 2 of [RFC8714] ๐ฆ
The term of a confirmed candidate selected under the mid-term vacancy rules may be less than a full term (two years for IESG and IAB, three years for the IETF Trust and IETF LLC), as stated elsewhere in this document ๐
It's consistent with this rule for the NomCom to choose one or more of the currently open positions and give them a term of no more than three years, so the rule can be applied ideally in the future ๐
It's also consistent with this rule for the NomCom to choose one or more of the currently open positions that share responsibilities with other positions (both those being reviewed and those sitting). The NomCom can give those a term of no more than three years so that all of those members, Directors, or Trustees won't be reviewed at the same time ๐
All sitting member terms end during the First IETF meeting corresponding to the end of the term for which they were confirmed. All confirmed candidate terms begin during the First IETF meeting corresponding to the beginning of the term for which they were confirmed ๐
For confirmed IESG candidates, terms begin no later than when the currently sitting members' terms end 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 agreed upon by mutual agreement of the currently sitting member and the confirmed candidate. A confirmed candidate's term may overlap the sitting member's term during the meeting, as determined by their mutual agreement ๐ค
For confirmed IAB candidates, the terms overlap with the terms of the sitting members for the entire week of the meeting ๐ธ
For confirmed Trustee candidates of the IETF Trust, the term begins at the next IETF Trust meeting or as dictated by the policies and procedures of the IETF Trust ๐ง
For confirmed Director candidates of the IETF LLC, the term begins at the next appropriate IETF LLC Board meeting or as dictated by the policies and procedures of the IETF LLC Board ๐
For candidates confirmed under the mid-term vacancy rules, the term begins as soon as possible after the confirmation โญ
3.5. Mid-term Vacancies ๐
Mid-term vacancies get filled by the same rules documented here, with four qualifications, namely:
- When there is only one official NomCom, the body with the mid-term vacancy relegates the responsibility to fill the vacancy to it. If the mid-term vacancy occurs during the period when the term of the prior year's NomCom overlaps with the term of the current year's NomCom, the body with the mid-term vacancy must relegate the responsibility to fill the vacancy to the prior year's NomCom ๐
- If the NomCom is reconvening to fill the mid-term vacancy, then completing the candidate selection and confirmation process is due within six weeks, with all other time periods otherwise unspecified prorated accordingly โฐ
- The confirming body has two weeks from the day it's notified of a candidate to reject that candidate. Otherwise, the candidate is assumed to have been confirmed ๐ซก
- 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, or
- B. the remainder of the term of the open position plus the next two-year term for IESG and IAB positions, or three-year term for IETF LLC Director and IETF Trust positions, if that remainder is less than one year ๐
In both cases, a year is the period of time from a First IETF meeting to the next First IETF meeting ๐
3.6. Confidentiality ๐คซ
All deliberations and supporting information that relate to specific nominees, candidates, and confirmed candidates are confidential. Keep it locked down, bestie ๐
The NomCom and confirming body members will be exposed to confidential information through their deliberations, their interactions with those they consult, and from those who provide requested supporting information. All members and all other participants are expected to handle this information in a manner consistent with its sensitivity ๐ง
It's consistent with this rule for current NomCom members who have served on prior NomComs to advise the current committee on the deliberations and results of the prior committee, as necessary and appropriate ๐ญ
The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential. The NomCom may disclose a list of names of nominees who are willing to be considered for positions under review to the community, so it can get feedback on these nominees ๐ฃ
The list disclosed for a specific position should contain only the names of nominees who are willing to be considered for that position under review ๐ฏ
The NomCom may choose not to include some names in the disclosed list, at its discretion ๐
The NomCom may disclose an updated list, at its discretion. For example, the NomCom might disclose an updated list if it identifies errors or omissions in a previously disclosed version, or if it finds it necessary to call for additional nominees, and those nominees indicate a willingness to be considered before the NomCom has completed its deliberations ๐
Nominees may choose to ask people to provide feedback to the NomCom, but they should not encourage any public statements of support. NomComs should consider nominee-encouraged lobbying and campaigning to be unacceptable behavior ๐ซ
IETF community members are encouraged to provide feedback on nominees to the NomCom, but they should not post statements of support or non-support for nominees in any public forum ๐
3.7. Advice and Consent Model ๐
Unless otherwise specified, the advice and consent model is used throughout the process. Here's how it works ๐
3.7.1. Positions to Be Reviewed ๐
The Chairs of the IESG, IAB, IETF Trust, and IETF LLC Board each inform the NomCom of their respective positions to be reviewed ๐
The IESG, IAB, IETF Trust, and IETF LLC are responsible for providing a summary of the expertise they want from the candidates selected for their respective open positions. These summaries go to the NomCom for consideration โจ
3.7.2. Candidate Selection ๐
The NomCom selects candidates based on its understanding of the IETF community's consensus on the required qualifications, and it advises each confirming body of its respective candidates ๐ซถ
3.7.3. Candidate Review ๐ง
The confirming bodies review their respective candidates. They may, at their discretion, communicate with the NomCom, and then consent to some, all, or none of the candidates ๐
The sitting IAB members review the IESG candidates ๐ฆ
The Internet Society Board of Trustees reviews the IAB candidates ๐
The sitting IESG members review the IETF Trust Trustee candidates ๐ธ
The IETF LLC Director candidate is reviewed as specified in [RFC8711] ๐ผ
The confirming bodies conduct their reviews using all information and any means acceptable to them. That includes, but isn't limited to, the supporting information provided by the NomCom, information known personally to members of the confirming bodies and shared within the confirming body, the results of interactions within the confirming bodies, and the confirming bodies' interpretation of what is in the best interests of the IETF community ๐ง
If all of the candidates are confirmed, the NomCom's job with respect to those open positions is complete ๐
If some or none of the candidates submitted to a confirming body are confirmed, the confirming body should communicate with the NomCom to explain why all the candidates weren't confirmed, and to understand the NomCom's rationale for its candidates ๐ฌ
The confirming body may reject individual candidates, in which case the NomCom must select alternate candidates for the rejected ones ๐
Any additional time required by the NomCom should not exceed its maximum time allotment โฑ๏ธ
3.7.4. Confirmation โ
A confirming body decides whether to confirm each candidate using a confirmation decision rule of its own choosing ๐
If a confirming body has no specific confirmation decision rule, then confirming a given candidate should require at least one-half of the confirming body's sitting members to agree to that confirmation ๐
The decision may be made by a formal vote, by asserting consensus based on informal exchanges (e.g., email), or by any other mechanism used to conduct the normal business of the confirming body ๐ณ๏ธ
Regardless of which decision rule the confirming body uses, any candidate who isn't confirmed under that rule is considered rejected ๐
The confirming body must make its decision within a reasonable time frame. Its results must be reported promptly to the NomCom ๐ฌ
3.8. Sitting Members, Directors, and Trustees โจ
okay so this one is for when the person being picked is already sitting on the IESG or IAB, is an IETF Trust Trustee, or is an IETF LLC Director, and they're NOT sitting in an open seat the NomCom is filling ๐ These rules apply to nominees and candidates like that.
Getting confirmed for an open position does not automatically create a vacancy in the seat they already hold on the IESG, IAB, IETF Trust, or IETF LLC Board ๐ โโ๏ธ A mid-term vacancy can't exist until two things happen. First, the candidate formally resigns from their current position. Second, the body that has the vacancy formally decides for itself that it wants the NomCom to fill it, following the mid-term vacancy rules written up elsewhere in this document. The order is literally everything ๐ญ
The resignation should take effect when the term of the new position begins ๐ฆ It may stay confidential among the IESG, IAB, IETF Trust, IETF LLC Board, and NomCom until the confirmed candidate gets announced for the new role. Once the vacancy is publicly announced, the process of filling the seat they left can start, following the rules elsewhere in this document ๐
Filling a mid-term vacancy is its own separate, independent thing, not part of the usual open-position filling ๐ So a NomCom must finish its job on the open positions first, and only then move on to the mid-term vacancy, following the mid-term vacancy rules elsewhere in this document. Two steps, not one blob ๐ง
There's one exception, but only when the candidate for the open position is a sitting IAB member ๐ It's still consistent with these rules for the resignation of the sitting IAB member and the announcement of the confirmed candidate for the mid-term vacancy they leave behind to all happen at the same time, as long as the events actually unfold in this order:
- The NomCom completes the advice and consent process for the open position being filled by the candidate currently sitting on the IAB.
- The newly confirmed candidate resigns from their current position on the IAB.
- The IAB Chair (or the Managing Director, IETF Secretariat, if no Chair has been named or the vacancy was created via the departure of the IAB Chair) informs the NomCom of the mid-term vacancy.
- The NomCom acts on the request to fill the mid-term vacancy.
3.9. Announcements ๐ฃ
every announcement must be made using at least the same mechanism the IETF Secretariat uses for its announcements, which includes a notice on the IETF web site ๐ธ
As of publication of this document, the current mechanism is an email message sent to both the "ietf" and the "ietf-announce" mailing lists ๐
4. Nominating Committee Selection ๐
okay now we're on to the NomCom itself, so the rules for creating it and picking its members ๐ง The following set of rules applies to creating the NomCom and selecting its members.
4.1. Timeline โฐ
Finishing the whole process of selecting and organizing the NomCom members is due within three months โณ
That selection and organization must be done at least one month before the Third IETF ๐๏ธ This makes sure the NomCom is fully operational and available for interviews and consultation during the Third IETF. no last-minute chaos, bestie ๐
4.2. Term ๐ฆ
A NomCom's term is expected to be 15 months ๐
The intent here is that the end of a NomCom's term overlaps the beginning of the next NomCom's term by about three months ๐ซถ
A NomCom's term begins when its members are officially announced. It ends at the Third IETF (not three meetings), which means the IETF meeting after the next NomCom's term begins โจ
A term is expected to begin at least two months before the Third IETF, so the NomCom has at least one month to get organized before it has to prep for the Third IETF ๐
A NomCom is expected to finish any work in progress before it gets dissolved at the end of its term ๐
During the overlap period, all mid-term vacancies get relegated to the prior year's NomCom ๐ That prior year's NomCom has no other responsibilities during the overlap. At all other times there is exactly one official NomCom, and it's responsible for all mid-term vacancies. one NomCom at a time, iconic ๐
When the prior year's NomCom is filling a mid-term vacancy while the terms overlap, the two NomComs operate independently ๐ Some coordination is still needed between them, though. Since the prior year's Chair is a non-voting advisor to the current NomCom, that coordination is expected to be straightforward ๐
4.3. Structure ๐งฉ
The NomCom is made up of at least a Chair, 10 voting volunteers, two liaisons, and an advisor ๐
Any committee member may propose adding an advisor to take part in some or all of the committee's deliberations. The committee must approve the addition according to its established voting mechanism. Advisors participate as individuals ๐ธ
Committee members are encouraged to propose adding advisor(s) who know the operations of the IETF Trust and/or IETF LLC Board, whether or not that NomCom is reviewing an IETF Trust Trustee or IETF LLC Director position ๐ซถ The NomCom may choose to ask the IETF Trust and/or IETF LLC Board to suggest advisors who know their operations, but it may select any advisor it votes to approve ๐ณ๏ธ
Any committee member may propose adding a liaison from other unrepresented organizations to take part in some or all of the committee's deliberations. The committee must approve the addition according to its established voting mechanism. Liaisons participate as representatives of their own organizations ๐
The Chair is selected according to rules stated elsewhere in this document ๐
The 10 voting volunteers are selected according to rules stated elsewhere in this document ๐
The IESG and IAB liaisons are selected according to rules stated elsewhere in this document ๐ฆ
The Internet Society Board of Trustees may appoint a liaison to the NomCom at its own discretion ๐ท
The IETF Trust may appoint a liaison to the NomCom at its own discretion ๐ท
The IETF LLC Board may appoint a liaison to the NomCom at its own discretion ๐ท
The Chair of the prior year's NomCom serves as an advisor according to rules stated elsewhere in this document ๐
The Chair, liaisons, and advisors do not vote on the selection of candidates ๐ โโ๏ธ They do vote on all other issues before the committee, unless this document says otherwise ๐ณ๏ธ
4.4. Chair Duties ๐
The NomCom Chair is responsible for making sure the NomCom finishes its assigned duties on time and performs in the best interests of the IETF community โญ
The Chair must be thoroughly familiar with the rules and guidance throughout this document. The Chair must make sure the NomCom completes its assigned duties in a way that's consistent with this document ๐
At a plenary session of the First IETF, the Chair must attest by proclamation that the committee's results represent its best effort and the best interests of the IETF community ๐คโจ
The Chair does not vote on the selection of candidates ๐ โโ๏ธ
4.5. Chair Selection ๐
The Internet Society President appoints the Chair, and that person must meet the same requirements for NomCom membership as a voting volunteer ๐ธ
The NomCom Chair must agree to invest the time needed to make sure the NomCom completes its assigned duties, and to perform in the best interests of the IETF community in that role ๐ซถ
The appointment is due no later than the Second IETF meeting, so it can be announced during a plenary session at that meeting ๐ฃ Completing the appointment is necessary so the annual process can finish at the time specified elsewhere in this document โฐ
4.6. Temporary Chair ๐
A Chair, in consultation with the Internet Society President, may appoint a temporary substitute for the Chair position ๐ฆ
There are a bunch of ordinary situations that can come up that might leave a Chair unavailable to oversee the committee's activities. The Chair, in consultation with the Internet Society President, may appoint a substitute from a pool made up of the liaisons currently serving on the committee and the prior year's Chair or designee ๐
Any such appointment must be temporary, and it does not absolve the Chair of any or all responsibility for making sure the NomCom completes its assigned duties in a timely fashion ๐
4.7. Liaisons ๐ค
Liaisons are responsible for making sure the NomCom in general, and the Chair in particular, carry out their assigned duties in the best interests of the IETF community ๐
Liaisons are expected to represent their organizations' views during the committee's deliberations ๐ฌ They should share information when it's requested or when they think it would help the committee ๐
Liaisons are expected to provide the NomCom with information about the operation, responsibility, and composition of their respective bodies ๐
Liaisons are expected to pass questions from the committee along to their organizations, and pass those organizations' responses back to the committee, when the committee asks them to ๐๏ธ
Liaisons are expected to review how the NomCom operates and runs its process, and to report any concerns or issues to the NomCom Chair immediately ๐จ If they can't resolve an issue between themselves, liaisons must report it through the dispute resolution process stated elsewhere in this document โ๏ธ
Liaisons from confirming bodies are expected to help the committee prepare the testimony it's required to provide with its candidates ๐
Liaisons may take on other NomCom responsibilities as their organizations require or the NomCom requests, except that those responsibilities may not conflict with any other provisions of this document ๐ผ
Liaisons do not vote on the selection of candidates ๐ โโ๏ธ
4.8. Liaison Appointment ๐
Each sitting IAB and IESG member appoints someone from their current membership, who is not sitting in an open position, to serve as a liaison to the NomCom ๐ซถ
The sitting IETF Trust Trustees and IETF LLC Directors each may appoint a liaison from their current membership, someone who is not sitting in an open position, to serve on the NomCom ๐ท
4.9. Advisors ๐ง
An advisor is responsible for whatever duties are specified in the invitation that resulted in their appointment ๐ฉ
Advisors do not vote on the selection of candidates ๐ โโ๏ธ
4.10. Past Chair ๐
okay so the Chair of last year's NomCom gets to stick around as an advisor to the current committee ๐ซถ main character energy for the previous Chair, honestly โจ
The prior year's Chair is expected to keep an eye on what the current Chair is doing and activities going on ๐ and if anything looks off, they have to flag it to the NomCom Chair right away ๐จ If they can't sort it out between themselves, the prior year's Chair must take it to the dispute resolution process described elsewhere in this document ๐
If the Chair is unavailable, the prior year's Chair can pick a designee from a pool made up of the voting volunteers from last year's committee and all prior Chairs ๐ธ And if the prior year's Chair is unavailable, or can't or won't make that call in a timely fashion, the current year's Chair can pick a designee instead, but they have to consult with the Internet Society President first ๐
Picking a designee from last year's committee means everything they figured out in last year's deliberations is super easy to access for the current committee ๐ Picking an earlier prior year Chair means you get their experience of being a Chair and their committee deliberations, which is iconic ๐ฆ
Anywhere this document says "prior year's Chair," it means whoever is actually in that role, whether that's the real prior year's Chair or their designee ๐ง
4.11. Voting Volunteers ๐โโ๏ธ
Voting volunteers are the ones responsible for getting the NomCom's tasks done in a timely fashion โฐ no pressure, bestie ๐ญ
Every voting volunteer is expected to put in about the same amount of effort as every other voting volunteer across all of the NomCom's activities ๐ช The Chair sets and manages the specific tasks, following the rules stated elsewhere in this document ๐
4.12. Milestones ๐
The Chair must set up and announce milestones for picking the NomCom members ๐ฃ
There's a defined window of time for finishing the selection process ๐๏ธ The Chair must lay out a set of milestones which, if they're hit in a timely fashion, will get the process finished on time โ
4.13. Open Positions ๐
The Chair (or the Managing Director, IETF Secretariat, if no Chair has been named four weeks after the First IETF meeting of the year) gets the list of positions up for review and announces it, along with a call for IETF community members who want to volunteer for the NomCom ๐
If the Managing Director, IETF Secretariat, is the one who sends out the call for volunteers, they must also collect the responses and hand the names of volunteers over to the incoming NomCom Chair once that person is named ๐
At the Chair's request, the IETF Secretariat can help with other clerical support tasks ๐๏ธ but only if the task doesn't need NomCom Chair judgment (in the NomCom Chair's opinion) and only if the community gets properly notified that the request is happening ๐ข That request can come from the incoming NomCom Chair (if one has been picked for this NomCom cycle) or from the previous NomCom Chair (if the search for an incoming NomCom Chair is still going) ๐
The call for volunteers must give the community at least 30 days to decide whether they want to volunteer for the NomCom โณ
The list of open positions gets published along with the call, so community members can weigh volunteering for an open position against volunteering for the NomCom ๐คโ๏ธ
4.14. Volunteer Qualification ๐๏ธ
Members of the IETF community must have attended at least three of the last five IETF meetings in order to volunteer ๐งพ
The five meetings are the five most recent meetings that ended before the date the call for NomCom volunteers was submitted for distribution to the IETF community ๐
The IETF Secretariat is responsible for confirming that volunteers have met the attendance requirement โ๏ธ
When volunteering, people must provide their full name, email address, and primary company or organization affiliation (if they have one) ๐
Volunteers are expected to know their way around IETF processes and procedures ๐งญ which you pick up pretty naturally by actively participating in a working group, and especially by serving as a document editor or a working group chair ๐ฆ
4.15. Not Qualified ๐ซ
Anyone who serves on the Internet Society Board of Trustees, the IETF Trust, the IETF LLC Board of Directors, the IAB, or the IESG (including people who serve on those bodies in ex officio positions) may not volunteer to be a voting member of the NomCom ๐ โโ๏ธ On top of that, employees or contractors of the IETF LLC may not volunteer to be voting members either ๐ผ Liaisons to those bodies from other bodies or organizations are not excluded by this rule ๐
4.16. Selection Process ๐ฒ
The Chair announces both the list of the pool of volunteers that the 10 voting volunteers will be randomly picked from, and the method that will be used to do the picking ๐ฃ
The announcement should be made at least one week before the random selection happens ๐๏ธ
The pool of volunteers must be enumerated or otherwise indicated, depending on what the selection method needs ๐ข
The announcement must say what data will be used as input to the selection method ๐ฅ The method must depend on random data whose value isn't known or available until the day the random selection happens ๐ฐ
It must be possible to independently verify that the selection method is both fair and unbiased ๐ A method is fair if every eligible volunteer is equally likely to get picked ๐ฐ A method is unbiased if nobody can influence the outcome to favor a specific result ๐
It must be possible to repeat the selection method, either by iterating it or by restarting it in a way that stays fair and unbiased ๐ This is needed so selected volunteers can be replaced if they become unavailable after being picked ๐ซก
The selection method must produce an ordered list of volunteers ๐
One possible selection method is described in [RFC3797] ๐
4.17. Announcement of Selection Results ๐ฃ
The Chair randomly picks the 10 voting volunteers from the pool of volunteer names and announces the members of the NomCom ๐
No more than two volunteers with the same primary affiliation may be selected for the NomCom ๐ข The Chair checks the primary affiliation of each volunteer, in the order the method picks them ๐ If a volunteer's primary affiliation matches two volunteers who were already selected, that volunteer gets removed from consideration and the method is repeated to find the next eligible volunteer ๐
There must be at least two announcements of all the members of the NomCom ๐ข๐ข
The first announcement should go out as soon after the random selection as is reasonable for the Chair โก The community must have at least one week during which any member can challenge the results of the random selection ๐ก๏ธ
A challenge must be made in writing to the Chair (email is fine) โ๏ธ The Chair has 48 hours to review the challenge and offer a resolution to the member ๐ If the member doesn't accept that resolution, they can report the challenge through the dispute resolution process described elsewhere in this document โ๏ธ
If a selected volunteer reads the announcement with the list of selected volunteers and sees that two or more other volunteers share their affiliation, the volunteer should tell the Chair, who will decide what to do next ๐
During at least that one week challenge period, the Chair must contact each member and confirm they're willing and available to serve ๐ The Chair should make every reasonable effort to reach each member ๐ช
Here's how the reaching-out part works for each kind of member, so nobody gets left on read ๐
- If the Chair can't reach a liaison, the problem gets referred to the liaison's organization to sort out ๐๏ธ The Chair should give the organization a reasonable amount of time to fix it, and then may go ahead without the liaison ๐ซ
- If the Chair can't reach an advisor, the Chair may choose to go ahead without that advisor ๐คทโโ๏ธ The exception is the prior year's Chair, where the Chair must consult with the Internet Society President, as stated elsewhere in this document ๐
- If the Chair can't reach a voting volunteer, the Chair must repeat the random selection process to replace that volunteer ๐ There should be at least one day between the announcement of the iteration and the selection process ๐๏ธ
After at least one week, and once it's confirmed that 10 voting volunteers are ready to serve, the Chair makes the second announcement of the NomCom members ๐ฅณ That's the moment the NomCom's term officially begins ๐
4.18. Committee Organization ๐งฉ
The Chair works with the committee members to get the committee organized so it's ready to tackle its assigned duties ๐
The committee has approximately one month to self-organize ๐๏ธ During that time, its responsibilities include, but aren't limited to, the following:
- Setting up a regular teleconference schedule ๐
- Setting up an internal web site ๐
- Setting up a mailing list for internal discussions ๐ฌ
- Setting up an email address for receiving community input ๐จ
- Establishing operational procedures ๐ ๏ธ
- Establishing milestones so the selection process can be monitored ๐
5. Nominating Committee Operation โ๏ธ
The following rules apply to how the NomCom operates ๐ Where it's needed, a paragraph explaining how to interpret each rule is included ๐
The rules are ordered roughly in the sequence they'd be invoked ๐ฌ
5.1. Discretion ๐ซถ
All rules and special circumstances that aren't otherwise specified are up to the committee's discretion ๐ง
Exceptional circumstances will now and then come up during the NomCom's normal operation ๐ช๏ธ This rule exists to keep the committee moving forward ๐
Any member of the committee can propose a rule for the committee to adopt ๐โโ๏ธ The rule must be approved by the committee using its established voting mechanism ๐ณ๏ธ
All committee members should consider whether the exception is worth mentioning in the next revision of this document, and follow up on that accordingly ๐โจ
5.2. Selection Timeline โณ
The process of selecting candidates to be confirmed by their respective confirming bodies is due within three months ๐๏ธ
The selection process must be completed at least two months before the First IETF ๐๏ธ That gives the NomCom enough time to get through the confirmation process ๐
5.3. Confirmation Timeline โ
The process of confirming the candidates is due within one month ๐
The confirmation process must be completed at least one month before the First IETF ๐
5.4. Milestones ๐
The Chair must set up a set of NomCom milestones for the candidate selection and confirmation process ๐ฃ
There's a defined window of time for the candidate selection and confirmation process to finish ๐๏ธ The Chair must set a set of milestones that, if they're hit in a timely fashion, will get the process finished on time ๐ฏ The Chair should leave room for iterating the committee's activities if one or more candidates don't get confirmed ๐
The Chair should make sure every committee member knows about the milestones ๐ซถ
5.5. Voting Mechanism ๐ณ๏ธ
okay so the Chair has to set up a voting mechanism, no skipping this bestie ๐ The committee MUST be able to objectively tell when a decision has been made during deliberations, because vibes are not a valid closure method ๐ The criteria for deciding when things are closed must be established and known to every single NomCom member ๐ซถ
5.6. Voting Quorum ๐
at least a quorum of committee members has to actually participate in a vote, no ghosting the group chat ๐ป
only voting volunteers get to vote on a candidate selection ๐ณ๏ธ For a candidate selection vote, a quorum is made up of at least seven of the voting volunteers โจ
for literally everything else, a quorum is present if at least 75% of the NomCom members are participating ๐
5.7. Voting Member Recall ๐
any NomCom member can propose to the committee that any other member except the Chair gets recalled ๐ The process for recalling the Chair is defined elsewhere in this document, so don't come for the Chair here ๐ โโ๏ธ
okay so life happens ๐ญ There are a bunch of normal situations that could leave a member unable to do their assigned duties, like health stuff, family stuff, or a change of priorities at work ๐ผ A committee member may choose to resign for unspecified personal reasons, no explanation needed ๐ซถ And the committee may not vibe as a group if a member is disruptive or just uncooperative ๐
No matter what's going on, if individual members can't work out their differences between themselves, the entire committee may be called upon to discuss and review the circumstances ๐ฃ๏ธ If no resolution shows up, a vote may be conducted ๐ณ๏ธ A member may be recalled if at least a quorum of all committee members agree, and that includes the vote of the member being recalled ๐ญ
If a liaison member gets recalled, the committee MUST notify the affected organization and MUST allow a reasonable amount of time for the organization to identify a replacement before moving forward ๐ฆ
If an advisor member other than the prior year's Chair gets recalled, the committee MAY choose to proceed without the advisor ๐ธ In the case of the prior year's Chair, the Internet Society President MUST be notified, and the current Chair MUST be allowed a reasonable amount of time to consult with the Internet Society President to identify a replacement before proceeding ๐
If a single voting volunteer position on the NomCom gets vacated, regardless of the circumstances, the committee MAY choose to proceed with only nine voting volunteers at its own discretion ๐ง In all other cases, a new voting member MUST be selected, and the Chair MUST repeat the random selection process, including an announcement of the iteration before the actual selection as stated elsewhere in this document ๐ฒ
A change in the primary affiliation of a voting volunteer during the term of the NomCom is not a cause to request the recall of that volunteer ๐ โโ๏ธ This is true even if the change would result in more than two voting volunteers with the same affiliation, so no drama ๐
5.8. Chair Recall ๐
only the prior year's Chair may request the recall of the current Chair ๐
it is the responsibility of the prior year's Chair to make sure the current Chair completes the assigned tasks in a way that is consistent with this document and in the best interests of the IETF community ๐ซถ
any member of the committee who has an issue or concern about the Chair should report it to the prior year's Chair immediately ๐จ The prior year's Chair is expected to report it to the Chair immediately too ๐ If they can't resolve the issue between themselves, the prior year's Chair MUST report it according to the dispute resolution process stated elsewhere in this document ๐
5.9. Deliberations ๐ธ
all members of the NomCom may participate in all deliberations ๐
the whole point of this rule is that no member can be explicitly excluded from any deliberation ๐ โโ๏ธ That said, a member may individually choose not to participate in a deliberation, which is totally their call โจ
5.10. Call for Nominees ๐ฃ
The Chair announces the open positions to be reviewed, the desired expertise provided by the Managing Director, IETF Secretariat, and the call for nominees ๐
The call for nominees MUST include a request for comments about the past performance of incumbents, and those comments will be considered during the NomCom's deliberations ๐
The call MUST request that a nomination include a valid, working email address, a telephone number, or both for the nominee ๐ฑ The nomination MUST include the set of skills or expertise the nominator believes the nominee has that would be desirable ๐
5.11. Nominations ๐ฆ
any member of the IETF community may nominate any member of the IETF community for any open position ๐ Whether they're eligible to serve will be confirmed by the NomCom ๐
self-nomination is permitted ๐
NomCom members are NOT eligible to be considered for filling any open position by the NomCom they serve on ๐ โโ๏ธ They become ineligible as soon as the term of that NomCom officially begins, and they stay ineligible for the whole duration of that NomCom's term ๐๏ธ
okay here's the twist ๐ Each NomCom's term overlaps with the following NomCom's term, so NomCom members ARE eligible for nomination by the following committee, as long as they aren't otherwise disqualified ๐
members of the IETF community who were recalled from any IESG, IAB, IETF Trust, or IETF LLC Board position during the previous two years are NOT eligible to be considered for filling any open position ๐
5.12. Candidate Selection ๐
the NomCom selects candidates based on its understanding of the IETF community's consensus about the qualifications required to fill the open positions ๐ง
the goal here is to make sure the NomCom consults a broad base of the IETF community for input ๐ฃ๏ธ In particular, the NomCom MUST determine whether the desired expertise for the open positions matches its understanding of the qualifications the IETF community wants ๐
the consultations MAY include names of nominees, if all parties to the consultation agree to follow the same confidentiality rules as the NomCom itself, or if the names are public as discussed in Section 3.6 ๐คซ Feedback on individual nominees SHOULD always be confidential ๐ซถ
a broad base of the community SHOULD include the existing members of the IESG and IAB, IETF Trust Trustees, and IETF LLC Directors ๐ That especially means sitting members who share responsibilities with open positions, like co-Area Directors, and working group chairs, especially the ones in areas with open positions ๐
only voting volunteer members vote to select candidates ๐ณ๏ธ
5.13. Consent to Nomination โ๏ธ
nominees SHOULD be told they're being considered, and they MUST consent to their nomination before being chosen as candidates ๐
the NomCom will make every reasonable effort to contact nominees and stay in touch with them ๐ But if a nominee's contact info changes during the process and they still want to be considered, they SHOULD let the NomCom know about the changes ๐
a nominee's consent MUST be in writing (email is acceptable) ๐ It MUST include a commitment to provide the resources needed to fill the open position, and an assurance that the nominee will perform the duties of the position they're being considered for in the best interests of the IETF community ๐
consenting to a nomination MUST happen before a nominee becomes a candidate, and it MAY happen as soon after the nomination as the NomCom needs ๐๏ธ
consenting to a nomination MUST NOT imply the nominee will be a candidate ๐ โโ๏ธ
the NomCom SHOULD help nominees justify things to their employers ๐ผ
5.14. Notifying Confirming Bodies ๐ฌ
the NomCom advises the confirming bodies about their candidates, specifying a single candidate for each open position and testifying about how each candidate meets the qualifications of an open position ๐
for each candidate, the testimony MUST include a brief statement of the qualifications for the position being filled, which may be exactly the expertise that was requested โจ If the qualifications differ from the expertise originally requested, a brief statement explaining the difference MUST be included ๐
the testimony MAY include a brief resume of the candidate and/or a brief summary of the NomCom's deliberations ๐
5.15. Confirming Candidates ๐ฅ
confirmed candidates MUST consent to their confirmation, and rejected candidates and nominees MUST be notified before confirmed candidates are announced ๐ฃ
it is NOT necessary to notify and get consent from all confirmed candidates together ๐
a nominee may not know they were a candidate ๐คซ This lets a candidate be rejected by a confirming body without the nominee ever knowing about the rejection ๐ซฃ
rejected nominees who consented to their nomination, and rejected candidates, MUST be notified before the confirmed candidates are announced ๐จ
it is NOT necessary to announce all confirmed candidates together ๐
the NomCom MUST ensure that all confirmed candidates are prepared to serve before their confirmation is announced ๐
5.16. Archives ๐๏ธ
the NomCom SHOULD archive the information it has collected or produced for a period of time, but not longer than its term ๐ฆ
the purpose of the archive is to help the NomCom if it ever needs to fill a mid-term vacancy ๐
whether there's an archive, how it's implemented, and what information goes in it is up to the committee's discretion ๐คทโโ๏ธ That decision MUST be approved by a quorum of the voting volunteer members ๐ณ๏ธ
the archive's implementation SHOULD make every reasonable effort to keep the information it contains confidential ๐
6. Dispute Resolution Process ๐
okay bestie, this dispute process is only for the situations the doc tells you to use it in ๐ซถ using it anywhere else is outside what this document covers, so don't even ๐ โโ๏ธ
the NomCom runs on a strict confidentiality rule ๐คซ so when process issues pop up, the move is to make every reasonable effort to sort them out inside the committee first. but if that's not possible, or nothing gets resolved, this is the process to use. ๐
here are the main rules:
- The results of this process are final and binding. There is no appeal. ๐
- The process begins with the submission of a request, as described below, to the Internet Society President. ๐ฉ
- As soon as the process begins, the NomCom may keep going with activities that are unrelated to the issue being resolved, except that it must not submit any candidates to a confirming body until the issue is resolved. ๐ง
- All parties to the process are subject to the same confidentiality rules as each member of the NomCom. ๐
- The process should be completed within two weeks. โฐ
here's how the process goes:
- The party seeking resolution submits a written request (email is acceptable) to the Internet Society President that details the issue to be resolved. โ๏ธ
- The Internet Society President appoints an arbiter to investigate and resolve the issue. A self-appointment is permitted. ๐
- The arbiter investigates the issue and makes every reasonable effort to understand both sides. Since the arbiter has the same confidentiality obligations as all NomCom members, all members are expected to cooperate fully with the arbiter and to provide all relevant information for review. ๐ต๏ธโโ๏ธ
- After consulting the two principal parties to the issue, the arbiter decides on a resolution. Whatever actions are needed to carry it out are begun immediately and completed as quickly as possible. โก
- The arbiter summarizes the issue, the resolution, and the rationale for the resolution for the Internet Society President. ๐
- In consultation with the Internet Society President, the arbiter prepares a report of the dispute and its resolution. The report should include all information that, in the arbiter's judgment, does not violate the confidentiality requirements of the NomCom. ๐
- The Chair includes the dispute report when reporting on the activities of the NomCom to the IETF community. ๐ข
7. Member, Trustee, and Director Recall ๐
the recall rules are below, and if a rule needs some explaining, there's a paragraph about how to read it ๐ง this process covers IESG and IAB Members, the NomCom-appointed IETF Trust Trustees, and the NomCom-appointed IETF LLC Directors. it's a big deal, so the vibes are serious ๐
7.1. Petition ๐
at any time, a signed petition (email is acceptable) may be submitted to the Internet Society President to request the recall of any sitting IESG or IAB member, or NomCom-appointed IETF Trust Trustee, or NomCom-appointed IETF LLC Director. there are two types of petitions: one from participants of the IETF community, and one from the Ombudsteam, as described in [RFC7776]. ๐ฆ
7.1.1. Community Petition ๐โโ๏ธ
a recall petition can be made by at least 20 members of the IETF community who are qualified to be voting members of a NomCom. all the individual and collective qualifications for NomCom eligibility apply, including that no more than two signatories may have the same primary affiliation. ๐ธ
each signature must include a full name, email address, and primary company or organization affiliation. โจ
the IETF Secretariat is responsible for confirming that each signatory is qualified to be a voting member of a NomCom. a valid petition must be signed by at least 20 qualified signatories. ๐๏ธ
the petition must include a statement of justification for the recall and all relevant and appropriate supporting documentation. ๐
the petition and its signatories must be announced to the IETF community. ๐ฃ
7.1.2. Ombudsteam Petition ๐ก๏ธ
the Ombudsteam process lets the Ombudsteam form a recall petition on its own, without needing 20 signatories from the community. as defined in [RFC7776], the petition and its signatories (the Ombudsteam) shall be announced to the IETF community, and a Recall Committee Chair shall be appointed to complete the recall committee process. it is expected that the recall committee will receive a briefing from the Ombudsteam explaining why recall is considered an appropriate remedy. ๐ซถ
7.2. Recall Committee Chair ๐
the 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. ๐ณ๏ธ
7.3. Recall Committee Creation ๐ฑ
the recall committee is created by the same rules as the NomCom, with the qualifications that both the person being investigated and the parties requesting the recall must not be a member of the recall committee in any capacity. ๐ซ
7.4. Recall Committee Rules ๐
the recall committee operates under the same rules as the NomCom, with the qualification that there is no confirmation process. ๐
7.5. Recall Committee Operation ๐
the recall committee investigates the circumstances behind 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. ๐ฃ๏ธ
7.6. 3/4 Majority โ๏ธ
a 3/4 majority of the members who vote on the question is required for a recall. ๐ฏ
7.7. Position to Be Filled ๐ช
if a sitting member is recalled, the open position is to be filled according to the mid-term vacancy rules. ๐
8. IANA Considerations ๐ท
this document has no IANA actions. nothing to see here for IANA, bestie ๐ฅฑ
9. Security Considerations ๐จ
okay this one is super important so pay attention ๐ any selection, confirmation, or recall process necessarily involves looking into the qualifications and activities of prospective candidates. that digging can turn up confidential or otherwise private information about candidates, and it gets shared with the people taking part in the process. so everyone who takes part in any aspect of the process must keep confidential ALL information that isn't explicitly marked as suitable for public dissemination. no leaks, no gossip, no exceptions ๐ค๐
when the NomCom decides it's necessary to share confidential or otherwise private information with others, the sharing must be minimal, and it must include a prior commitment from everyone consulted to follow the same confidentiality rules as the NomCom itself. ๐๐ซถ
10. References ๐
10.1. Normative References ๐
- [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004,
<https://www.rfc-editor.org/info/rfc3777>. - [RFC7437] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 7437, DOI 10.17487/RFC7437, January 2015,
<https://www.rfc-editor.org/info/rfc7437>. - [RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March 2016,
<https://www.rfc-editor.org/info/rfc7776>. - [RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of the IETF Administrative Support Activity, Version 2.0", BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,
<https://www.rfc-editor.org/info/rfc8711>. - [RFC8714] Arkko, J. and T. Hardie, "Update to the Process for Selection of Trustees for the IETF Trust", BCP 101, RFC 8714, DOI 10.17487/RFC8714, February 2020,
<https://www.rfc-editor.org/info/rfc8714>. - [RFC8717] Klensin, J., Ed., "IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology", BCP 101, RFC 8717, DOI 10.17487/RFC8717, February 2020,
<https://www.rfc-editor.org/info/rfc8717>.
10.2. Informative References ๐งพ
- [Err232] RFC Errata, Erratum ID 232, RFC 3777,
<https://www.rfc-editor.org/errata/eid232>. - [Err4179] RFC Errata, Erratum ID 4179, RFC 3777,
<https://www.rfc-editor.org/errata/eid4179>. - [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, DOI 10.17487/RFC3710, February 2004,
<https://www.rfc-editor.org/info/rfc3710>. - [RFC3797] Eastlake 3rd, D., "Publicly Verifiable Nominations Committee (NomCom) Random Selection", RFC 3797, DOI 10.17487/RFC3797, June 2004,
<https://www.rfc-editor.org/info/rfc3797>. - [RFC8318] Dawkins, S., "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee", BCP 10, RFC 8318, DOI 10.17487/RFC8318, January 2018,
<https://www.rfc-editor.org/info/rfc8318>.
Appendix A. Changes Since RFC 3777 ๐
- converted the source file from nroff to XML, which caused some reformatting ๐
- applied errata for RFC 3777 ([Err232] and [Err4179]) ๐ฉน
- applied the RFC 5078 update โ
- applied the RFC 5633 update โ
- applied the RFC 5680 update โ
- applied the RFC 6859 update โ
- corrected a few grammatical errors โ๏ธ
- added a reference to RFC 3710 ๐
Appendix B. Changes Since RFC 7437 ๐
- changed all mentions of the Internet Administrative Oversight committee (IAOC) and replaced them with the appropriate references to the IETF Administration LLC (IETF LLC). this included making changes, as needed, to some aspects of the process for the IETF LLC, in accordance with IASA2 ๐ผ
- revised the definition of IETF Executive Director, and added a definition of "Managing Director, IETF Secretariat". changed the text to "Managing Director, IETF Secretariat" where appropriate ๐ง
- added references to the appropriate IASA2 documents ๐
- modified the Advice and Consent model so the IESG, IAB, and IETF LLC can communicate directly with the NomCom instead of through the Managing Director, IETF Secretariat ๐ฌ
- updated the removal text to reflect the new LLC rules, which enable removal via the LLC or the IETF recall process, except for the ISOC-appointed Director ๐
- updated the document to clarify that there are members of the IAB and IESG, Trustees of the IETF Trust, and a Director of the IETF LLC ๐
- updated the document to also specify procedures for the NomCom-appointed IETF Trust Trustees ๐ซถ
- revised the Abstract and Introduction to provide current context ๐ธ
- changed "nominating committee" to "NomCom" throughout the document, because it's what most people use to describe the IETF Nominating Committee ๐
- added that the IETF Trust Trustees and IETF LLC Directors may each appoint a liaison to the NomCom ๐ฆ
- incorporated the update to RFC 7437 done by [RFC7776] โจ
- incorporated the update to RFC 7437 done by [RFC8318], and updated it to refer to the IETF Trust and IETF LLC instead of the IAOC ๐ท
- made editorial changes ๐
Appendix C. Oral Tradition ๐ฎ
Over the years, different NomComs have picked up stuff through oral tradition from liaisons, and there are certain patterns in what gets considered during deliberations. So we collected some of that oral tradition here so future NomComs can look at it too ๐ซถ
- It's been found that being an IETF Working Group Chair or an IRTF Research Group Chair is super helpful, because it gives a nominee a taste of what the Area Director job is actually like. It also helps a NomCom judge the technical, people, and process management skills of the nominee ๐
- No person should serve both on the IAB and as an Area Director, except the IETF Chair, whose roles as an IAB member and Area Director of the General Area are set out elsewhere ๐
- The strength of the IAB comes partly from the balance of its members' demographics (e.g., national distribution, years of experience, gender, etc.), the combined skill set of its members, and the combined sectors (e.g., industry, academia, etc.) they represent ๐
- There are no term limits for IAB and IESG members, explicitly, because continuity versus turnover should be evaluated each year according to the expectations of the IETF community, as each NomCom understands them โญ
- The number of NomCom members with the same primary affiliation is limited, so nobody can think the IETF's leadership is being picked with improper bias ๐ Instead of writing precise rules for how to define "affiliation", the IETF community relies on the honor and integrity of the participants to make the process work ๐ฆ
Appendix D. Nominating Committee Timeline ๐๏ธ
This appendix is here for the convenience of the reader, and it is not the definitive timeline ๐ โโ๏ธ It's meant to gather the detail described elsewhere in this document into one place. Every effort was made to keep the description here consistent with the rest of the document, but if there are any conflicts, the definitive rule is the one in the main body of this document ๐
The only absolute in the timeline rules for the annual process is that it has to be completed by the First IETF of the year after the NomCom begins its term ๐ญ This is backed up by the fact that the confirmed candidate terms begin during the week of the First IETF.
The whole annual process is designed to wrap up in seven months, and it's expected to start nine months before the First IETF. The time gets split between three major components, roughly like this:
- First is the selection and organization of the committee members. Three months are allotted for this ๐ธ
- Second is the selection of the candidates by the NomCom. Four months are allotted for this ๐ฅ
- Third is the confirmation of the candidates by their respective confirming bodies. Two months are allotted for this โจ
The list below captures the milestones within each component. For illustration, it assumes the Friday before the First IETF is March 1. Numbers in square brackets show the expected number of weeks at each step ๐ง
- BEGIN Eight Months Prior to First IETF (approx. June 1); Internet Society President appoints the Chair. The appointment must be done no later than the Second IETF or eight months prior to the First IETF, whichever comes first. The Chair must be announced and recognized during a plenary session of the Second IETF. [0]
- The Chair establishes and announces milestones to ensure the timely selection of the NomCom members. [1]
- The Chair contacts the IESG, IAB, and Internet Society Board of Trustees, IETF Trust, and IETF LLC and requests a liaison. The Chair contacts the prior year's Chair and requests an advisor. The Chair obtains the list of IESG, IAB, IETF Trust, and IETF LLC open positions and descriptions from the chairs of each group. [0]
- The Chair announces the solicitation for voting volunteer members, which must remain open for at least 30 days. The announcement must be done no later than seven months and two weeks prior to the First IETF (approx. June 15). [6]
- After the solicitation closes, the Chair announces the pool of volunteers and the date of the random selection, which must be at least one week in the future. The announcement must be done no later than six months and two weeks prior to the First IETF (approx. July 15). [1]
- On the appointed day, the random selection occurs and the Chair announces the members of the committee and the one week challenge period. The announcement must be done no later than six months and one week prior to the First IETF (approx. July 22). [1]
- During the challenge period, the Chair contacts each of the committee members and confirms their availability to participate. [0]
- After the challenge period closes, the Chair announces the members of the committee and its term begins. The announcement must be done no later than six months prior to the First IETF (approx. August 1). [1]
- The committee has one month to self-organize in preparation for completing its assigned duties. This must be done no later than five months prior to the First IETF (approx. September 15). [6]
- END the Committee Member Selection Process; BEGIN the Selection of Candidates; Time is at least five months prior to the First IETF (approx. September 22). [0]
- The Chair establishes and announces the milestones to ensure the timely selection of the candidates, including a call for nominations for the open positions. The announcement must be done no later than five months prior to the First IETF (approx. October 1). [1]
- Over the next three months, the NomCom collects input and deliberates. It should plan to conduct interviews and other consultations during the Third IETF. The committee is due to complete its candidate selection no later than two months prior to the First IETF (approx. January 1). [17]
- END the Selection of Candidates; BEGIN the Confirmation of Candidates; Time is at least two months prior to the First IETF (approx. January 1). [0]
- The committee presents its candidates to their respective confirming bodies. The presentation must be done no later than two months prior to the First IETF (approx. January 1). [0]
- The confirming bodies have one month to deliberate and, in communication with the NomCom, accept or reject candidates. [4]
- The Chair notifies and advises unsuccessful nominees that they have not been selected. [1]
- The Chair announces the confirmed candidates. The announcement must be done no later than one month prior to the First IETF (approx. February 1). [4]
Acknowledgments ๐ซถ
A great deal of work went into the RFCs that came before this one. The 2014 NomCom and this editor want to thank all of them once again for the time and energy it took to get us to where we are now ๐ In no particular order, we acknowledge:
Jeff Case, Fred Baker, John Curran, Guy Almes, Geoff Huston, Michael StJohns, Donald Eastlake, Avri Doria, Bernard Aboba, Ted T'so, Phil Roberts, Jim Galvin, Harald Alvestrand, Leslie Daigle, Joel Halpern, Thomas Narten, Spencer Dawkins, Barry Leiba, Lars Eggert, Ross Callon, Brian Carpenter, Robert Elz, Bernie Hoeneisen, John Klensin, Danny McPherson, S. Moonesamy, Scott Bradner, Ralph Droms, and Pekka Savola. ๐
Allison Mankin and Russ White provided early reviews and feedback about this document ๐
Jari Arkko was incredibly helpful by independently verifying that the previous text from all the merged documents was marshaled correctly into this one, and Adrian Farrel and Brian Carpenter caught the nits that slipped through the cracks ๐
Authors' Addresses ๐
Murray S. Kucherawy (editor)
270 Upland Drive
San Francisco, CA 94127
United States of America
Email: superuser@gmail.com
Robert M. Hinden (editor)
Check Point Software
San Carlos, CA
United States of America
Email: bob.hinden@gmail.com
Jason Livingood (editor)
Comcast
Philadelphia, PA
United States of America
Email: jason_livingood@comcast.com
๐ฆ where this page comes from
- ietf: rfc8713 2020-02
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms