RFC 8713

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

๐Ÿ“… published February 2020, from ietf

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 (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:

  1. The Internet Research Task Force (IRTF) and Internet Research Steering Group (IRSG) are not part of the process here. ๐Ÿ™…โ€โ™€๏ธ
  2. 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:

  1. Picking and organizing the NomCom members. ๐Ÿงš
  2. The NomCom selecting candidates. ๐Ÿ’–
  3. 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:

  1. 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 ๐Ÿ”
  2. 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 โฐ
  3. 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 ๐Ÿซก
  4. 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 ๐ŸŒˆ

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:

  1. The NomCom completes the advice and consent process for the open position being filled by the candidate currently sitting on the IAB.
  2. The newly confirmed candidate resigns from their current position on the IAB.
  3. 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.
  4. 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 ๐Ÿ—ณ๏ธ

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:

  1. The results of this process are final and binding. There is no appeal. ๐Ÿ’€
  2. The process begins with the submission of a request, as described below, to the Internet Society President. ๐Ÿ“ฉ
  3. 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. ๐Ÿงš
  4. All parties to the process are subject to the same confidentiality rules as each member of the NomCom. ๐Ÿ”’
  5. The process should be completed within two weeks. โฐ

here's how the process goes:

  1. The party seeking resolution submits a written request (email is acceptable) to the Internet Society President that details the issue to be resolved. โœ๏ธ
  2. The Internet Society President appoints an arbiter to investigate and resolve the issue. A self-appointment is permitted. ๐Ÿ‘‘
  3. 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. ๐Ÿ•ต๏ธโ€โ™€๏ธ
  4. 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. โšก
  5. The arbiter summarizes the issue, the resolution, and the rationale for the resolution for the Internet Society President. ๐Ÿ“
  6. 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. ๐Ÿ“‘
  7. 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 ๐Ÿ”—

10.2. Informative References ๐Ÿงพ


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 ๐Ÿซถ

  1. 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 ๐Ÿ’…
  2. 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 ๐Ÿ™ˆ
  3. 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 ๐ŸŒˆ
  4. 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 โญ
  5. 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:

  1. First is the selection and organization of the committee members. Three months are allotted for this ๐ŸŒธ
  2. Second is the selection of the candidates by the NomCom. Four months are allotted for this ๐Ÿ”ฅ
  3. 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 ๐Ÿงš

  1. 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]
  2. The Chair establishes and announces milestones to ensure the timely selection of the NomCom members. [1]
  3. 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]
  4. 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]
  5. 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]
  6. 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]
  7. During the challenge period, the Chair contacts each of the committee members and confirms their availability to participate. [0]
  8. 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]
  9. 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]
  10. 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]
  11. 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]
  12. 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]
  13. 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]
  14. 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]
  15. The confirming bodies have one month to deliberate and, in communication with the NomCom, accept or reject candidates. [4]
  16. The Chair notifies and advises unsuccessful nominees that they have not been selected. [1]
  17. 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