diff options
Diffstat (limited to 'doc/rfc/rfc8713.txt')
| -rw-r--r-- | doc/rfc/rfc8713.txt | 1808 |
1 files changed, 1808 insertions, 0 deletions
diff --git a/doc/rfc/rfc8713.txt b/doc/rfc/rfc8713.txt new file mode 100644 index 0000000..f8213a2 --- /dev/null +++ b/doc/rfc/rfc8713.txt @@ -0,0 +1,1808 @@ + + + + +Internet Engineering Task Force (IETF) M. Kucherawy, Ed. +Request for Comments: 8713 +BCP: 10 R. Hinden, Ed. +Obsoletes: 7437, 8318 Check Point Software +Category: Best Current Practice J. Livingood, Ed. +ISSN: 2070-1721 Comcast + February 2020 + + +IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall + Process: Operation of the IETF Nominating and Recall Committees + +Abstract + + The process by which the members of the IAB and IESG, some Trustees + of the IETF Trust, and some Directors of the IETF Administration LLC + (IETF LLC) are selected, confirmed, and recalled is specified in this + document. This document is based on RFC 7437. Only those updates + required to reflect the changes introduced by IETF Administrative + Support Activity (IASA) 2.0 have been included. Any other changes + will be addressed in future documents. + + This document obsoletes RFC 7437 and RFC 8318. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +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 + + This document is a revision of [RFC7437] that updates it to be + consistent with the IETF Administrative Support Activity (IASA) 2.0 + changes. RFC 7437 was based on [RFC3777] that consolidated and + updated other RFCs that updated that document into a single + specification. The result is a complete specification of the process + by which members of the Internet Architecture Board (IAB) and + Internet Engineering Steering Group (IESG), some Trustees of the IETF + Trust, and some Directors of the IETF Administration LLC (IETF LLC), + are selected, confirmed, and recalled. + + This revision addresses only the changes required for IASA 2.0; + should the community agree on other changes, they will be addressed + in future documents. + + Section 2 of [RFC8714] provides further details about the IETF Trust + Trustees positions that are filled by the IETF Nominating Committee + (NomCom). + + Section 5 of [RFC8711] provides further details about the IETF LLC + Director positions that are filled by the NomCom. + + The following two assumptions continue to be true of this + specification: + + 1. The Internet Research Task Force (IRTF) and Internet Research + Steering Group (IRSG) are not a part of the process described + here. + + 2. The organization (and reorganization) of the IESG is not a part + of the process described here. + + The time frames specified here use IETF meetings as a frame of + reference. The time frames assume that the IETF meets three times + per calendar year with approximately equal amounts of time between + them. The meetings are referred to as the First IETF, Second IETF, + or Third IETF as needed. + + The next section lists the words and phrases commonly used throughout + this document with their intended meaning. + + The majority of this document is divided into four major topics as + follows: + + General: This is a set of rules and constraints that apply to the + selection and confirmation process as a whole. + + Nominating Committee Selection: This is the process by which the + volunteers who will serve on the NomCom are selected. + + Nominating Committee Operation: This is the set of principles, + rules, and constraints that guide the activities of the NomCom, + including the confirmation process. + + Member, Trustee, and Director Recall: This is the process by which + the behavior of a sitting member of the IESG, or IAB, or IETF + Trust Trustee, or IETF LLC Director may be questioned, perhaps + resulting in the removal of the sitting member. See Section 2 for + a description of what a sitting member means for each of these + groups. + + A final section describes how this document differs from [RFC3777] + and [RFC7437]. + + An appendix of useful facts and practices collected from previous + NomComs is also included. + + This document updates the IAB, IESG, and IAOC Selection, + Confirmation, and Recall Process to be aligned with IASA 2.0 Model + [RFC8711] that creates an IETF Administration Limited Liability + Company (IETF LLC) managed by a Board of Directors (IETF LLC Board). + This document obsoletes [RFC7437] and [RFC8318]. + +2. Definitions + + The following words and phrases are commonly used throughout this + document. They are listed here with their intended meaning for the + convenience of the reader. + + Candidate: A nominee who has been selected to be considered for + confirmation by a confirming body. + + Confirmed Candidate: A candidate that has been reviewed and approved + by a confirming body. + + Nominating Committee Term: The term begins when its members are + officially announced, which is expected to be prior to the Third + IETF to ensure it is fully operational at the Third IETF. The + term ends at the Third IETF (not three meetings) after the next + NomCom's term begins. + + IETF Executive Director: The person charged with day-to-day + operation of the IETF's administrative functions. (See + Section 4.1 of [RFC8711]). Note: This was previously the name of + the IETF Secretariat position that is now called the "Managing + Director, IETF Secretariat". + + Managing Director, IETF Secretariat: The person charged with + operation of 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 of the IESG, IAB, IETF Trust Trustee, or 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 + + The following set of rules apply to the process as a whole. If + necessary, a paragraph discussing the interpretation of each rule is + included. + +3.1. Completion Due + + The completion of the annual process is due within seven months. + + The completion of the annual process is due one month prior to the + Friday of the week before the First IETF. It is expected to begin at + least eight months prior to the Friday of the week before the First + IETF. + + The process officially begins with the announcement of the Chair of + the committee. The process officially ends when all confirmed + candidates have been announced. + + The annual process is comprised of three major components as follows: + + 1. The selection and organization of the NomCom members. + + 2. The selection of candidates by the NomCom. + + 3. The confirmation of the candidates. + + There is an additional month set aside between when the annual + process is expected to end and the term of the new candidates is to + begin. This time may be used during unusual circumstances to extend + the time allocated for any of the components listed above. + +3.2. Nominating Committee Principal Functions + + The principal functions of the NomCom are to review each open IESG, + IAB, IETF Trust, and IETF LLC Director position and to select either + its incumbent or a superior candidate. + + Although there is no term limit for serving in any IESG, IAB, or IETF + Trust position, the NomCom may use length of service as one of its + criteria for evaluating an incumbent. + + The NomCom does not select the open positions to be reviewed; it is + instructed as to which positions to review. + + The NomCom will be given the titles of the positions to be reviewed + and a brief summary of the desired expertise of the candidate that is + selected to fill each position. + + Incumbents must notify the NomCom if they wish to be nominated. + + The NomCom does not confirm its candidates; it presents its + candidates to the appropriate confirming body as indicated below. + + A superior candidate is one who the NomCom believes would contribute + in such a way as to improve or enhance the body to which he or she is + nominated. + +3.3. Positions to Be Reviewed + + Approximately one-half of each of the then current IESG and IAB + positions, one IETF Trust position, and one IETF LLC Director + position, is selected to be reviewed each year. + + The intent of this rule is to ensure the review of approximately one- + half of each of the IESG and IAB sitting members, one of the three + NomCom-nominated IETF LLC Director positions, and one of the three + nominated IETF Trust Trustee positions, each year. It is recognized + that circumstances may exist that will require the NomCom to review + more or less than the usual number of positions, e.g., if the IESG, + IAB, IETF Trust, or IETF LLC Board have reorganized prior to this + process and created new positions, if there are 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 intent of this rule is to ensure that members of + the IESG and IAB serve the number of years that best facilitates the + review of one-half of the members each year. + + Confirmed IETF LLC Director candidates are expected to serve at least + a three-year term, except if a nominating or selection body decides + to use a shorter term to allow for initial staggered appointments. + Please refer to Section 6 of [RFC8711] for additional guidance on + term length and term limits for the IETF LLC Board. + + Confirmed IETF Trust Trustee candidates are expected to serve at + least a three-year term, except if a nominating or selection body + decides to use a shorter term to allow for initial staggered + appointments. Please refer to Section 2 of [RFC8714] for additional + guidance on term length and term limits for the IETF Trust. + + The term of a confirmed candidate selected according to 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 is consistent with this rule for the NomCom to choose one or more + of the currently open positions to which it may assign a term of not + more than three years in order to ensure the ideal application of + this rule in the future. + + It is 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) to + which it may assign a term of not more than three years to ensure + that all such members, Directors, or Trustees will not 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 candidates of the IESG, the 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 determined + by the 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 candidates of the IAB, 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 are filled by the same rules as 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 of time + that 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 it is the case that the NomCom is reconvening to fill the mid- + term vacancy, then the completion of 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 is notified of + a candidate to reject the 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. + + The NomCom and confirming body members will be exposed to + confidential information as a result of 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 is consistent with this rule for current NomCom members who have + served on prior NomComs to advise the current committee on + 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, in order to + obtain feedback from the community on these nominees. + + The list of nominees disclosed for a specific position should contain + only the names of nominees who are willing to be considered for the + position under review. + + The NomCom may choose not to include some names in the disclosed + list, at their discretion. + + The NomCom may disclose an updated list, at its discretion. For + example, the NomCom might disclose an updated list if it identifies + errors/omissions in a previously disclosed version of the disclosed + list, or if the NomCom finds it necessary to call for additional + nominees, and these 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 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 should not post statements of support/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. This model is characterized as follows. + +3.7.1. Positions to Be Reviewed + + The Chairs of the IESG, IAB, IETF Trust, and IETF LLC Board each + informs 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 desired of the candidates selected for + their respective open positions. The summaries are provided to the + NomCom for its consideration. + +3.7.2. Candidate Selection + + The NomCom selects candidates based on its understanding of the IETF + community's consensus of the qualifications required and 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, including but not 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 job of the NomCom 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 + both to explain the reason why all the candidates were not 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 + candidates. + + Any additional time required by the NomCom should not exceed its + maximum time allotment. + +3.7.4. Confirmation + + A confirming body decides whether it confirms each candidate using a + confirmation decision rule chosen by the confirming body. + + 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 conducting a formal vote, by asserting + consensus based on informal exchanges (e.g., email), or by any other + mechanism that is used to conduct the normal business of the + confirming body. + + Regardless of which decision rule the confirming body uses, any + candidate that is not confirmed under that rule is considered to be + rejected. + + The confirming body must make its decision within a reasonable time + frame. The results from the confirming body must be reported + promptly to the NomCom. + +3.8. Sitting Members, Directors, and Trustees + + The following rules apply to nominees and candidates who are + currently sitting members of the IESG or IAB, IETF Trust Trustees, or + IETF LLC Directors, and who are not sitting in an open position being + filled by the NomCom. + + The confirmation of a candidate to an open position does not + automatically create a vacancy in the IESG, IAB, IETF Trust, or IETF + LLC Board position currently occupied by the candidate. The mid-term + vacancy cannot exist until, first, the candidate formally resigns + from the current position and, second, the body with the vacancy + formally decides for itself that it wants the NomCom to fill the mid- + term vacancy according to the rules for a mid-term vacancy documented + elsewhere in this document. + + The resignation should be effective as of when the term of the new + position begins. The resignation may remain confidential to the + IESG, IAB, IETF Trust, IETF LLC Board, and NomCom until the confirmed + candidate is announced for the new position. The process, according + to rules set out elsewhere in this document, of filling the seat + vacated by the confirmed candidate may begin as soon as the vacancy + is publicly announced. + + Filling a mid-term vacancy is a separate and independent action from + the customary action of filling open positions. In particular, a + NomCom must complete its job with respect to filling the open + positions and then separately proceed with the task of filling the + mid-term vacancy according to the rules for a mid-term vacancy + documented elsewhere in this document. + + However, the following exception is permitted in the case where the + candidate for an open position is currently a sitting member of the + IAB. It is consistent with these rules for the announcements of a + resignation of a sitting member of the IAB and of the confirmed + candidate for the mid-term vacancy created by that sitting member on + the IAB to all occur at the same time as long as the actual sequence + of events that occurred did so in the following 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 + + All announcements must be made using at least the mechanism used by + the IETF Secretariat for its announcements, including a notice on the + IETF web site. + + As of the publication of this document, the current mechanism is an + email message to both the "ietf" and the "ietf-announce" mailing + lists. + +4. Nominating Committee Selection + + The following set of rules apply to the creation of the NomCom and + the selection of its members. + +4.1. Timeline + + The completion of the process of selecting and organizing the members + of the NomCom is due within three months. + + The completion of the selection and organization process is due at + least one month prior to the Third IETF. This ensures the NomCom is + fully operational and available for interviews and consultation + during the Third IETF. + +4.2. Term + + The term of a NomCom is expected to be 15 months. + + It is the intent of this rule that the end of a NomCom's term overlap + by approximately three months the beginning of the term of the next + NomCom. + + The term of a NomCom begins when its members are officially + announced. The term ends at the Third IETF (not three meetings), + i.e., the IETF meeting after the next NomCom's term begins. + + A term is expected to begin at least two months prior to the Third + IETF to ensure the NomCom has at least one month to get organized + before preparing for the Third IETF. + + A NomCom is expected to complete any work in progress before it is + dissolved at the end of its term. + + During the period of time when the terms of the NomComs overlap, all + mid-term vacancies are to be relegated to the prior year's NomCom. + The prior year's NomCom has no other responsibilities during the + overlap period. At all times other than the overlap period, there is + exactly one official NomCom and it is responsible for all mid-term + vacancies. + + When the prior year's NomCom is filling a mid-term vacancy during the + period of time that the terms overlap, the NomComs operate + independently. However, some coordination is needed between them. + Since the prior year's Chair is a non-voting advisor to the current + NomCom, the coordination is expected to be straightforward. + +4.3. Structure + + The NomCom comprises at least a Chair, 10 voting volunteers, two + liaisons, and an advisor. + + Any committee member may propose the addition of an advisor to + participate in some or all of the deliberations of the committee. + The addition must be approved by the committee according to its + established voting mechanism. Advisors participate as individuals. + + Committee members are encouraged to propose the addition of + advisor(s) who are knowledgeable about 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 are knowledgeable about their operations but may select + any advisor they vote to approve. + + Any committee member may propose the addition of a liaison from other + unrepresented organizations to participate in some or all of the + deliberations of the committee. The addition must be approved by the + committee according to its established voting mechanism. Liaisons + participate as representatives of their respective 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 otherwise specified in this document. + +4.4. Chair Duties + + The Chair of the NomCom is responsible for ensuring the NomCom + completes its assigned duties in a timely fashion and performs in the + best interests of the IETF community. + + The Chair must be thoroughly familiar with the rules and guidance + indicated throughout this document. The Chair must ensure the NomCom + completes its assigned duties in a manner that is consistent with + this document. + + The Chair must attest by proclamation at a plenary session of the + First IETF that the results of the committee 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, who must meet the + same requirements for membership in the NomCom as a voting volunteer. + + The NomCom Chair must agree to invest the time necessary to ensure + that 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 to + ensure it can be announced during a plenary session at that meeting. + The completion of the appointment is necessary to ensure the annual + process can complete 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 variety of ordinary circumstances that may arise from + time to time that could result in a Chair being unavailable to + oversee the activities of the committee. The Chair, in consultation + with the Internet Society President, may appoint a substitute from a + pool comprised of the liaisons currently serving on the committee and + the prior year's Chair or designee. + + Any such appointment must be temporary and does not absolve the Chair + of any or all responsibility for ensuring the NomCom completes its + assigned duties in a timely fashion. + +4.7. Liaisons + + Liaisons are responsible for ensuring the NomCom in general and the + Chair in particular execute their assigned duties in the best + interests of the IETF community. + + Liaisons are expected to represent the views of their respective + organizations during the deliberations of the committee. They should + provide information as requested or when they believe it would be + helpful to the committee. + + Liaisons are expected to provide information to the NomCom regarding + the operation, responsibility, and composition of their respective + bodies. + + Liaisons are expected to convey questions from the committee to their + respective organizations and responses to those questions to the + committee, as requested by the committee. + + Liaisons are expected to review the operation and executing process + of the NomCom and to report any concerns or issues to the Chair of + the NomCom immediately. If they cannot resolve the issue between + themselves, liaisons must report it according to the dispute + resolution process stated elsewhere in this document. + + Liaisons from confirming bodies are expected to assist the committee + in preparing the testimony it is required to provide with its + candidates. + + Liaisons may have other NomCom responsibilities as required by their + respective organizations or requested by the NomCom, except that such + responsibilities may not conflict with any other provisions of this + document. + + Liaisons do not vote on the selection of candidates. + +4.8. Liaison Appointment + + The sitting IAB and IESG members each appoint 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 such duties as specified by the + invitation that resulted in the appointment. + + Advisors do not vote on the selection of candidates. + +4.10. Past Chair + + The Chair of the prior year's NomCom serves as an advisor to the + current committee. + + The prior year's Chair is expected to review the actions and + activities of the current Chair and to report any concerns or issues + to the NomCom Chair immediately. If they cannot resolve the issue + between themselves, the prior year's Chair must report it according + to the dispute resolution process stated elsewhere in this document. + + The prior year's Chair may select a designee from a pool composed of + the voting volunteers of the prior year's committee and all prior + Chairs if the Chair is unavailable. If the prior year's Chair is + unavailable or is unable or unwilling to make such a designation in a + timely fashion, the Chair of the current year's committee may select + a designee in consultation with the Internet Society President. + + Selecting a prior year's committee member as the designee permits the + experience of the prior year's deliberations to be readily available + to the current committee. Selecting an earlier prior year Chair as + the designee permits the experience of being a Chair as well as that + Chair's committee deliberations to be readily available to the + current committee. + + All references to "prior year's Chair" in this document refer to the + person serving in that role, whether it is the actual prior year's + Chair or a designee. + +4.11. Voting Volunteers + + Voting volunteers are responsible for completing the tasks of the + NomCom in a timely fashion. + + Each voting volunteer is expected to participate in all activities of + the NomCom with a level of effort approximately equal to all other + voting volunteers. Specific tasks to be completed are established + and managed by the Chair according to rules stated elsewhere in this + document. + +4.12. Milestones + + The Chair must establish and announce milestones for the selection of + the NomCom members. + + There is a defined time period during which the selection process is + due to be completed. The Chair must establish a set of milestones + which, if met in a timely fashion, will result in the completion of + the process on time. + +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) + obtains the list of positions to be reviewed and announces it along + with a solicitation for names of volunteers from the IETF community + willing to serve on the NomCom. + + If the Managing Director, IETF Secretariat, issues the solicitation + for volunteers, the Managing Director, IETF Secretariat, must also + collect responses to the solicitation and provide the names of + volunteers to the incoming NomCom Chair when the incoming NomCom + Chair is named. + + At the Chair's request, the IETF Secretariat may perform other + clerical support tasks, as long as the task being performed does not + require NomCom Chair judgment, in the NomCom Chair's opinion, and as + long as the community is appropriately notified that this request is + being made. This request may come from the incoming NomCom Chair (if + one has been selected for this NomCom cycle) or the previous NomCom + Chair (if the search for an incoming NomCom Chair is still underway). + + The solicitation must permit the community at least 30 days during + which they may choose to volunteer to be selected for the NomCom. + + The list of open positions is published with the solicitation to + facilitate community members choosing between volunteering for an + open position and 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 prior + to the date on which the solicitation 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. + + Volunteers must provide their full name, email address, and primary + company or organization affiliation (if any) when volunteering. + + Volunteers are expected to be familiar with the IETF processes and + procedures, which are readily learned by active participation in a + working group and especially by serving as a document editor or + working group chair. + +4.15. Not Qualified + + Any person who serves on the Internet Society Board of Trustees, the + IETF Trust, the IETF LLC Board of Directors, the IAB, or the IESG, + including those who serve on these bodies in ex officio positions, + may not volunteer to serve as voting members of the NomCom. In + addition, employees or contractors of the IETF LLC may not volunteer + to serve as voting members of the NomCom. Liaisons to these 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 from + which the 10 voting volunteers will be randomly selected and the + method with which the selection will be completed. + + The announcement should be made at least one week prior to the date + on which the random selection will occur. + + The pool of volunteers must be enumerated or otherwise indicated + according to the needs of the selection method to be used. + + The announcement must specify the data that will be used as input to + the selection method. The method must depend on random data whose + value is not known or available until the date on which the random + selection will occur. + + It must be possible to independently verify that the selection method + used is both fair and unbiased. A method is fair if each eligible + volunteer is equally likely to be selected. A method is unbiased if + no one can influence its outcome in favor of a specific outcome. + + It must be possible to repeat the selection method, either through + iteration or by restarting in such a way as to remain fair and + unbiased. This is necessary to replace selected volunteers should + they become unavailable after selection. + + 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 selects the 10 voting volunteers from the pool of + names of volunteers 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 reviews the primary affiliation + of each volunteer selected by the method in turn. If the primary + affiliation for a volunteer is the same as two previously selected + volunteers, that volunteer is removed from consideration and the + method is repeated to identify the next eligible volunteer. + + There must be at least two announcements of all members of the + NomCom. + + The first announcement should occur as soon after the random + selection as is reasonable for the Chair. The community must have at + least one week during which any member may challenge the results of + the random selection. + + The challenge must be made in writing (email is acceptable) to the + Chair. The Chair has 48 hours to review the challenge and offer a + resolution to the member. If the resolution is not accepted by the + member, that member may report the challenge according to the dispute + resolution process stated elsewhere in this document. + + If a selected volunteer, upon reading the announcement with the list + of selected volunteers, finds that two or more other volunteers have + the same affiliation, then the volunteer should notify the Chair who + will determine the appropriate action. + + During at least the one week challenge period, the Chair must contact + each of the members and confirm their willingness and availability to + serve. The Chair should make every reasonable effort to contact each + member. + + * If the Chair is unable to contact a liaison, the problem is + referred to the respective organization to resolve. The Chair + should allow a reasonable amount of time for the organization to + resolve the problem and then may proceed without the liaison. + + * If the Chair is unable to contact an advisor, the Chair may elect + to proceed without the advisor, except for the prior year's Chair + for whom the Chair must consult with the Internet Society + President as stated elsewhere in this document. + + * If the Chair is unable to contact a voting volunteer, the Chair + must repeat the random selection process in order to replace the + unavailable volunteer. There should be at least one day between + the announcement of the iteration and the selection process. + + After at least one week and confirming that 10 voting volunteers are + ready to serve, the Chair makes the second announcement of the + members of the NomCom, which officially begins the term of the + NomCom. + +4.18. Committee Organization + + The Chair works with the members of the committee to organize itself + in preparation for completing its assigned duties. + + The committee has approximately one month during which it can self- + organize. Its responsibilities during this time include but are not + 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 in order to monitor the progress of the + selection process. + +5. Nominating Committee Operation + + The following rules apply to the operation of the NomCom. If + necessary, a paragraph discussing the interpretation of each rule is + included. + + The rules are organized approximately in the order in which they + would be invoked. + +5.1. Discretion + + All rules and special circumstances not otherwise specified are at + the discretion of the committee. + + Exceptional circumstances will occasionally arise during the normal + operation of the NomCom. This rule is intended to foster the + continued forward progress of the committee. + + Any member of the committee may propose a rule for adoption by the + committee. The rule must be approved by the committee according to + its established voting mechanism. + + All members of the committee should consider whether the exception is + worthy of mention in the next revision of this document and follow up + accordingly. + +5.2. Selection Timeline + + The completion of the process of selecting candidates to be confirmed + by their respective confirming body is due within three months. + + The completion of the selection process is due at least two months + prior to the First IETF. This ensures the NomCom has sufficient time + to complete the confirmation process. + +5.3. Confirmation Timeline + + The completion of the process of confirming the candidates is due + within one month. + + The completion of the confirmation process is due at least one month + prior to the First IETF. + +5.4. Milestones + + The Chair must establish a set of NomCom milestones for the candidate + selection and confirmation process. + + There is a defined time period during which the candidate selection + and confirmation process must be completed. The Chair must establish + a set of milestones that, if met in a timely fashion, will result in + the completion of the process on time. The Chair should allow time + for iterating the activities of the committee if one or more + candidates are not confirmed. + + The Chair should ensure that all committee members are aware of the + milestones. + +5.5. Voting Mechanism + + The Chair must establish a voting mechanism. + + The committee must be able to objectively determine when a decision + has been made during its deliberations. The criteria for determining + closure must be established and known to all members of the NomCom. + +5.6. Voting Quorum + + At least a quorum of committee members must participate in a vote. + + Only voting volunteers vote on a candidate selection. For a + candidate selection vote, a quorum is comprised of at least seven of + the voting volunteers. + + At all other times, a quorum is present if at least 75% of the NomCom + members are participating. + +5.7. Voting Member Recall + + Any member of the NomCom may propose to the committee that any other + member except the Chair be recalled. The process for recalling the + Chair is defined elsewhere in this document. + + There are a variety of ordinary circumstances that may arise that + could result in one or more members of the committee being + unavailable to complete their assigned duties, for example, health + concerns, family issues, or a change of priorities at work. A + committee member may choose to resign for unspecified personal + reasons. In addition, the committee may not function well as a group + because a member may be disruptive or otherwise uncooperative. + + Regardless of the circumstances, if individual committee members + cannot work out their differences between themselves, the entire + committee may be called upon to discuss and review the circumstances. + If a resolution is not forthcoming, a vote may be conducted. A + member may be recalled if at least a quorum of all committee members + agree, including the vote of the member being recalled. + + If a liaison member is recalled, the committee must notify the + affected organization and must allow a reasonable amount of time for + a replacement to be identified by the organization before proceeding. + + If an advisor member other than the prior year's Chair is 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 is 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 prior to 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, even if the change would result in more than two voting + volunteers with the same affiliation. + +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 ensure the + current Chair completes the assigned tasks in a manner consistent + with this document and in the best interests of the IETF community. + + Any member of the committee who has an issue or concern regarding 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. + If they cannot 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 emphasis of this rule is that no member can be explicitly + excluded from any deliberation. However, a member may individually + choose not to participate in a deliberation. + +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 regarding + the past performance of incumbents, which will be considered during + the deliberations of the NomCom. + + 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, whose eligibility to serve will be + confirmed by the NomCom. + + A self-nomination is permitted. + + NomCom members are not eligible to be considered for filling any open + position by the NomCom on which they serve. They become ineligible + as soon as the term of the NomCom on which they serve officially + begins. They remain ineligible for the duration of that NomCom's + term. + + Although each NomCom's term overlaps with the following NomCom's + term, NomCom members are eligible for nomination by the following + committee if not 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 of the qualifications required to fill the open + positions. + + The intent of this rule is to ensure that the NomCom consults with a + broad base of the IETF community for input to its deliberations. In + particular, the NomCom must determine if the desired expertise for + the open positions matches its understanding of the qualifications + desired by the IETF community. + + The consultations are permitted to include names of nominees, if all + parties to the consultation agree to observe the same confidentiality + rules as the NomCom itself, or 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, + especially sitting members who share responsibilities with open + positions, e.g., co-Area Directors, and working group chairs, + especially those in the areas with open positions. + + Only voting volunteer members vote to select candidates. + +5.13. Consent to Nomination + + Nominees should be advised that they are being considered and must + consent to their nomination prior to being chosen as candidates. + + Although the NomCom will make every reasonable effort to contact and + to remain in contact with nominees, any nominee whose contact + information changes during the process and who wishes to still be + considered should inform the NomCom of the changes. + + A nominee's consent must be written (email is acceptable) and must + include a commitment to provide the resources necessary to fill the + open position and an assurance that the nominee will perform the + duties of the position for which they are being considered in the + best interests of the IETF community. + + Consenting to a nomination must occur prior to a nominee being a + candidate and may occur as soon after the nomination as needed by the + NomCom. + + Consenting to a nomination must not imply the nominee will be a + candidate. + + The NomCom should help nominees provide justification to their + employers. + +5.14. Notifying Confirming Bodies + + The NomCom advises the confirming bodies of their candidates, + specifying a single candidate for each open position and testifying + as to 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 that is 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 deliberations of the NomCom. + +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 permits a + candidate to be rejected by a confirming body without the nominee + knowing about the rejection. + + Rejected nominees, who consented to their nomination, and rejected + candidates must be notified prior to announcing the confirmed + candidates. + + It is not necessary to announce all confirmed candidates together. + + The NomCom must ensure that all confirmed candidates are prepared to + serve prior to announcing their confirmation. + +5.16. Archives + + The NomCom should archive the information it has collected or + produced for a period of time but not to exceed its term. + + The purpose of the archive is to assist the NomCom should it be + necessary for it to fill a mid-term vacancy. + + The existence of an archive, how it is implemented, and what + information to archive is at the discretion of the committee. The + decision must be approved by a quorum of the voting volunteer + members. + + The implementation of the archive should make every reasonable effort + to ensure that the confidentiality of the information it contains is + maintained. + +6. Dispute Resolution Process + + The dispute resolution process described here is to be used as + indicated elsewhere in this document. Its applicability in other + circumstances is beyond the scope of this document. + + The NomCom operates under a strict rule of confidentiality. For this + reason, when process issues arise, it is best to make every + reasonable effort to resolve them within the committee. However, + when circumstances do not permit this, or no resolution is + forthcoming, the process described here is to be used. + + The following rules apply to the process: + + 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 continue those + activities that are unrelated to the issue to be 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. + + The process is as follows: + + 1. The party seeking resolution submits a written request (email is + acceptable) to the Internet Society President detailing 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 making every reasonable effort + to understand both sides of the issue. Since the arbiter is + subject to the same confidentiality obligations as all NomCom + members, all members are expected to cooperate fully with the + arbiter and to provide all relevant information to the arbiter + for review. + + 4. After consultation with the two principal parties to the issue, + the arbiter decides on a resolution. Whatever actions are + necessary to execute the resolution are immediately begun 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 judgment of the + arbiter 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 following rules apply to the recall process. If necessary, a + paragraph discussing the interpretation of each rule is included. + + It applies to IESG and IAB Members, the NomCom-appointed IETF Trust + Trustees, and the NomCom-appointed IETF LLC Directors. + +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 different types + of petitions: a petition by participants of the IETF community, and a + petition by 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 + individual and collective qualifications of NomCom eligibility are + applicable, 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 allows the Ombudsteam to form a recall + petition on its own without requiring 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 according to the same rules as is 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 according to 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 of the + justification for the recall and votes on its findings. + + The investigation must include at least both an opportunity for the + member being recalled to present a written statement and consultation + with third parties. + +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. + +9. Security Considerations + + Any selection, confirmation, or recall process necessarily involves + investigation into the qualifications and activities of prospective + candidates. The investigation may reveal confidential or otherwise + private information about candidates to those participating in the + process. Each person who participates in any aspect of the process + must maintain the confidentiality of any and all information not + explicitly identified as suitable for public dissemination. + + When the NomCom decides it is necessary to share confidential or + otherwise private information with others, the dissemination must be + minimal and must include a prior commitment from all persons + consulted to observe 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 source file from nroff to XML, resulting in some + reformatting. + + * Applied errata for RFC 3777 ([Err232] and [Err4179]). + + * Applied RFC 5078 update. + + * Applied RFC 5633 update. + + * Applied RFC 5680 update. + + * Applied 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 it with the appropriate references + to the IETF Administration LLC (IETF LLC). This included making + changes on an as needed basis to some aspects of the process for + the IETF LLC, in accordance with IASA2. + + * Revised definition of IETF Executive Director, and added + definition of "Managing Director, IETF Secretariat". Changed text + to "Managing Director, IETF Secretariat" where appropriate. + + * Added references to appropriate IASA2 documents. + + * Modified the Advice and Consent model to enable IESG, IAB, and + IETF LLC to communicate directly with the NomCom rather than via + the Managing Director, IETF Secretariat. + + * Updated removal text to reflect the new LLC rules, which enables + 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 Director of the IETF + LLC. + + * Updated document to also specify procedures for the NomCom- + appointed IETF Trust Trustees. + + * Revised Abstract and Introduction to provide current context. + + * Changed "nominating committee" to "NomCom" throughout the document + because it is what most use to describe the IETF Nominating + Committee. + + * Added that the IETF Trust Trustees and IETF LLC Directors, each + may 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. + + * Editorial changes. + +Appendix C. Oral Tradition + + Over the years, various NomComs have learned through oral tradition + passed on by liaisons that there are certain consistencies in the + process and information considered during deliberations. Some items + from that oral tradition are collected here to facilitate its + consideration by future NomComs. + + 1. It has been found that experience as an IETF Working Group Chair + or an IRTF Research Group Chair is helpful in giving a nominee + experience of what the job of an Area Director involves. 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 is found in part in the balance of the + demographics of its members (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.) represented by its members. + + 4. There are no term limits for IAB and IESG members explicitly + because the issue of continuity versus turnover should be + evaluated each year according to the expectations of the IETF + community, as it is understood by each NomCom. + + 5. The number of NomCom members with the same primary affiliation is + limited in order to avoid the appearance of improper bias in + choosing the leadership of the IETF. Rather than defining + precise rules for how to define "affiliation", the IETF community + depends on the honor and integrity of the participants to make + the process work. + +Appendix D. Nominating Committee Timeline + + This appendix is included for the convenience of the reader and is + not to be interpreted as the definitive timeline. It is intended to + capture the detail described elsewhere in this document in one place. + Although every effort has been made to ensure the description here is + consistent with the description elsewhere, 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 its completion is due by the First IETF of the year after the + NomCom begins its term. This is supported by the fact that the + confirmed candidate terms begin during the week of the First IETF. + + The overall annual process is designed to be completed in seven + months. It is expected to start nine months prior to the First IETF. + The time is split between three major components of the process + roughly as follows: + + 1. First is the selection and organization of the committee members. + Three months are allotted for this process. + + 2. Second is the selection of the candidates by the NomCom. Four + months are allotted for this process. + + 3. Third is the confirmation of the candidates by their respective + confirming bodies. Two months are allotted for this process. + + The following list captures the details of the milestones within each + component. For illustrative purposes, the list presumes the Friday + before the First IETF is March 1. Numbers shown in square brackets + indicate 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 that 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 during which it is 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 preceded this one. The + 2014 NomCom and this editor would like 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 very 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 fell 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 |