diff options
Diffstat (limited to 'doc/rfc/rfc9389.txt')
| -rw-r--r-- | doc/rfc/rfc9389.txt | 450 |
1 files changed, 450 insertions, 0 deletions
diff --git a/doc/rfc/rfc9389.txt b/doc/rfc/rfc9389.txt new file mode 100644 index 0000000..7f025d7 --- /dev/null +++ b/doc/rfc/rfc9389.txt @@ -0,0 +1,450 @@ + + + + +Internet Engineering Task Force (IETF) M. Duke +Request for Comments: 9389 Google LLC +BCP: 10 April 2023 +Obsoletes: 8788, 8989 +Updates: 8713 +Category: Best Current Practice +ISSN: 2070-1721 + + + Nominating Committee Eligibility + +Abstract + + The IETF Nominating Committee (NomCom) appoints candidates to several + IETF leadership committees. RFC 8713 provides criteria for NomCom + membership that attempt to ensure NomCom volunteers are members of + the loosely defined IETF community, by requiring in-person attendance + in three of the past five in-person meetings. In 2020 and 2021, the + IETF had six consecutive fully online plenary meetings that drove + rapid advancement in remote meeting technologies and procedures, + including an experiment that included remote attendance for NomCom + eligibility. This document updates RFC 8713 by defining a new set of + eligibility criteria from first principles, with consideration to the + increased salience of remote attendance. This document obsoletes + RFCs 8788 and 8989. + +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/rfc9389. + +Copyright Notice + + Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. NomCom Principles + 3. Criteria + 4. Security Considerations + 4.1. NomCom Capture + 4.1.1. A Surge of Volunteers + 4.1.2. The Two-per-Organization Limit + 4.1.3. One Year of Participation + 4.2. Disruptive Candidates + 4.3. Additional Remedies + 5. IANA Considerations + 6. References + 6.1. Normative References + 6.2. Informative References + Appendix A. NomCom Capture Calculations + A.1. No per-Organization Limit + A.2. Two per Organization + Acknowledgments + Author's Address + +1. Introduction + + [RFC8713] defines the process for the selection of the Internet + Architecture Board (IAB), Internet Engineering Steering Group (IESG), + IETF Trust, and the IETF LLC Directors. A key actor in the process + is the Nominating Committee (NomCom), which nominates a single + candidate for each open position. Nominations are subject to + confirmation by other bodies. + + NomCom voting members are randomly selected from a pool of volunteers + that have met certain eligibility requirements. Thus, it is + important that members of the pool be IETF participants likely to + have knowledge of IETF processes and practices. There are + restrictions to ensure that no more than two volunteers with the same + primary affiliation are chosen. + + Section 4.14 of [RFC8713] requires volunteers to have attended three + of the previous five meetings. In practice, this meant that the + volunteer picked up their registration badge at an in-person meeting. + Current members of the Internet Society Board of Trustees and bodies + for which the NomCom nominates members are ineligible. + + [RFC8989] specified an experiment in the wake of six consecutive + fully online meetings from 2020 to 2021, because the historic + interpretation of the requirement would have resulted in no eligible + volunteers. It extended the meeting attendance requirement to + include logging in to at least one session of a fully online IETF + meeting. + + [RFC8989] also created two other tracks to obtain eligibility: (1) + serving as a working group chair or secretary in the past three + years, and (2) being an author or editor of an IETF Stream RFC in the + past five years, which includes Internet-Drafts in the RFC Editor + queue. + + This document discusses some of the first principles that inform the + design of NomCom eligibility, and makes recommendations on how the + process of attendance-based qualification should work. + + This document replaces the attendance criteria in the first two + paragraphs of Section 4.14 of [RFC8713] with the criteria described + in [RFC8989], and it obsoletes RFC 8989 to clarify that the document + has been superseded. All other text in [RFC8713], including the + other paragraphs of Section 4.14, remains unchanged. + + [RFC8788] established procedures for the 2020-2021 NomCom. While, by + definition, [RFC8788] does not apply to future NomComs, this document + formally obsoletes it. + +2. NomCom Principles + + The NomCom is intended to be composed of randomly selected members of + "the community." For many years, in-person attendance was a + reasonable proxy for the commitment associated with being a member. + Two days of travel and an attendance fee is a relatively large + expenditure of time and money. Additionally, in-person attendance is + thought to increase personal familiarity with candidates for + leadership positions and with the spirit of the IETF, although there + is no mechanism to ensure any interaction. + + A basic principle of the IETF is that the community should govern + itself, so volunteers must have a demonstrated commitment to the + IETF. Limiting the number of volunteers sponsored by any one + organization avoids the potential for mischief that disrupts IETF + operations or works against the interests of the community as a + whole. + + A requirement for in-person attendance has always excluded some from + qualifying for the NomCom. However, as attitudes to business travel + evolve and remote meeting technology continues to improve, many + longstanding community members are choosing to participate remotely + (due to cost or personal reasons). In addition, the NomCom has + completed two cycles using entirely online tools. + + Expanding the attendance requirement to include remote attendance + lowers the barriers to entry. As the IETF has historically provided + a fee-free remote participation option, via waiver or otherwise, the + only required investment is to log on once per meeting at a specific + time (sometimes a locally inconvenient hour). While this document + does not formally impose a requirement for the NomCom to function + entirely remotely, including remote-only attendees in the pool is + likely to effectively require a remote component to NomCom + operations. + + Finally, overly restrictive criteria work against getting a broad + talent pool. + +3. Criteria + + The following text replaces the first two paragraphs of Section 4.14 + of [RFC8713]: + + | Members of the IETF community must satisfy the conditions in one + | of three paths in order to volunteer. Any one of the paths is + | sufficient, unless the person is otherwise disqualified under + | Section 4.15 of [RFC8713]. + | + | Path 1: The person has registered for and attended three out of + | the last five IETF meetings, either in-person or online. + | In-person attendance is as determined by the record + | keeping of the Secretariat. Online attendance is based + | on being a registered person who logged in for at least + | one session of an IETF meeting. + | + | Path 2: The person has been a Working Group Chair or Secretary + | within the three years prior to the day the call for + | NomCom volunteers is sent to the community. + | + | Path 3: The person has been a listed author or editor on the + | front page of at least two IETF Stream RFCs within the + | last five years prior to the day the call for NomCom + | volunteers is sent to the community. An Internet-Draft + | that has been approved by the IESG and is in the RFC + | Editor queue counts the same as a published RFC, with the + | relevant date being the date the draft was added to the + | RFC Editor queue. For avoidance of doubt, the five-year + | timer extends back to the date five years before the date + | when the call for NomCom volunteers is sent to the + | community. + +4. Security Considerations + +4.1. NomCom Capture + + The most potent threat associated with NomCom eligibility is that an + organization or group of coordinating organizations could attempt to + obtain a majority of NomCom positions, in order to select an IETF + leadership in support of an agenda that might be self-serving and + against the interests of the community as a whole. + + Note that [RFC8713] lets the NomCom Chair decide the NomCom voting + requirement, so a simple majority may be inadequate. However, seven + of ten forms a quorum, so at worst seven NomCom members working + together can almost certainly impose their will. + + Whatever the merits of admitting remote attendees, it reduces the + minimum cost of creating a NomCom-eligible volunteer from three in- + person trips of around five days each over the course of at least + eight months, to zero financial cost and the time required to log in + three times over at least eight months. Some organizations might not + be deterred in either case, while others might. + +4.1.1. A Surge of Volunteers + + A large number of legitimate volunteers makes it quite difficult to + control a majority of NomCom slots. Setting aside limitations on the + number of selections from any organization, basic probability shows + that to have even a 50% chance of controlling six or more NomCom + positions, an attacker needs roughly 60% of the volunteer pool. For + example, if there are 300 "legitimate" volunteers, an attacker must + produce 365 volunteers to exceed a 50% chance of NomCom capture (see + Appendix A). + + A sudden surge in the number of volunteers, particularly of people + that no one recognizes as a part of the community, is an early- + warning sign of an attempt at capture. Anyone with concerns about + the integrity of the process should bring those concerns to the IESG + to investigate. Where needed, the confirming bodies can take action + to invalidate such candidates as defined in Section 3.7.3 of + [RFC8713]. + + While loosening eligibility criteria lowers the cost to an attacker + of producing eligible volunteers, it also increases the number of + legitimate volunteers which increases the difficulty of an attack. + +4.1.2. The Two-per-Organization Limit + + The two-per-organization limit described in Section 4.17 of [RFC8713] + complicates such a capture attack. To circumvent it, an organization + would have to do one or more of the following: + + 1. coordinate with at least two like-minded organizations to produce + a NomCom majority, + + 2. incentivize members of other organizations (possibly through a + funding agreement) to support its agenda, and/or + + 3. propose candidates with false affiliations. + + While the IETF does not routinely confirm the affiliation of + volunteers, as part of an investigation it could eliminate volunteers + who have misrepresented said affiliation. Publishing the list of + volunteers and affiliations also gives the community an opportunity + to review the truth of such claims. + + Assuming that 300 legitimate volunteers are all from different + organizations, three conspiring organizations would need 771 + volunteers (257 per organization) for a 50% chance of NomCom capture + (see Appendix A). + +4.1.3. One Year of Participation + + Attendance at three meetings requires at least eight months of + waiting. Given the volume of volunteers necessary to capture the + process, an attack requires a surge in attendees over the course of a + year. Such a surge might trigger a community challenge to the list + of eligible volunteers, and/or a leadership investigation to detect + suspicious behavior (e.g., logging in to a single session and then + immediately logging out). In the event of abuse of process, the + leadership would then have months to adjust policy in response before + the NomCom cycle begins, and/or disqualify candidates. + +4.2. Disruptive Candidates + + Note that counting remote participation towards NomCom eligibility + allows for a single individual to mount an attack that previously + required coordination. By registering for remote attendance to IETF + meetings using a number of different identities over a year, an + individual can make each of those identities NomCom eligible and then + serve under any one of them that is selected for the NomCom. Once + selected, an individual could seek to disrupt the process or prevent + the timely conclusion of its work. Less severely, an attacker could + simply improve their chances of being selected for NomCom. + + This attack is much harder to detect or prevent than equivalent + attacks were previously, as it does not require coordination among + multiple attendees. While the attacker cannot be sure of fee waivers + for some or all of the different identities, the lower cost for + remote participation also makes this attack more feasible than it + would have been under prior rules. + + However, the voting member recall procedure in Section 5.7 of + [RFC8713] exists to allow removal and replacement of disruptive + figures. + +4.3. Additional Remedies + + Additional changes to the process to further obstruct attacks against + the NomCom are beyond the scope of this document. However, a + challenge process against volunteers with a suspicious reported + affiliation, or that might be aliases of a single volunteer, could + trigger an investigation. + + Similarly, the challenge to the random selection described in + Section 4.17 of [RFC8713] can explicitly include appeals against the + data used to qualify the volunteer, rather than the randomization + process. + +5. IANA Considerations + + This document has no IANA actions. + +6. References + +6.1. Normative References + + [RFC8713] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, + Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection, + Confirmation, and Recall Process: Operation of the IETF + Nominating and Recall Committees", BCP 10, RFC 8713, + DOI 10.17487/RFC8713, February 2020, + <https://www.rfc-editor.org/info/rfc8713>. + +6.2. Informative References + + [RFC8788] Leiba, B., "Eligibility for the 2020-2021 Nominating + Committee", BCP 10, RFC 8788, DOI 10.17487/RFC8788, May + 2020, <https://www.rfc-editor.org/info/rfc8788>. + + [RFC8989] Carpenter, B. and S. Farrell, "Additional Criteria for + Nominating Committee Eligibility", RFC 8989, + DOI 10.17487/RFC8989, February 2021, + <https://www.rfc-editor.org/info/rfc8989>. + +Appendix A. NomCom Capture Calculations + + Section 4 offers some mathematical results for the probability of + NomCom capture. This appendix shows the work. + + Note that the number of combinations of b items chosen from a + population of a items is often expressed as + + ⎛a⎞ a! + ⎜ ⎟ = ──────── + ⎝b⎠ (a-b)!b! + + Figure 1 + +A.1. No per-Organization Limit + + Appendix A.1 assumes there is no limitation on the number of + volunteers from a given organization. Appendix A.2 assumes that no + single organization produces more than two volunteers. + + Let L be the number of "legitimate" volunteers (i.e., those not + allied with an attacker) and A be the number of attacking volunteers. + Then there are the following ways to select a NomCom: + + ⎛L+A⎞ + ⎜ ⎟ + ⎝ 10⎠ + + Figure 2 + + The number of outcomes where attackers capture the NomCom is: + + 10 + —— + ╲ ⎡⎛A⎞ ⎛ L ⎞⎤ + ╱ ⎢⎜ ⎟ ⎜ ⎟⎥ + —— ⎣⎝i⎠ ⎝10-i⎠⎦ + i=6 + + Figure 3 + + Therefore, the probability of capture is + + 10 ⎛A⎞ ⎛ L ⎞ + —— ⎜ ⎟ ⎜ ⎟ + ╲ ⎝i⎠ ⎝10-i⎠ + ╱ ────────── + —— ⎛L + A⎞ + i=6 ⎜ ⎟ + ⎝ 10 ⎠ + + Figure 4 + + For L = 300, this probability crosses 50% at A = 365. + +A.2. Two per Organization + + Assume that the population of L is drawn from L different + organizations (this assumption is unfavorable to the attacker). + Assume also that there are three conspiring organizations. Then no + more than 6 members can be drawn from A. + + Let B be the number of nominees per attacking organization, so that A + = 3B. + + The number of combinations to pick exactly N attackers, N <= 6, is + + min(N,2)⎡ min(2,N-i) ⎤ + —— ⎢ —— ⎥ + ⎛ L ⎞ ╲ ⎢⎛B⎞ ╲ ⎛⎛B⎞ ⎛ B ⎞⎞⎥ + C(N) = ⎜ ⎟ ╱ ⎢⎜ ⎟ ╱ ⎜⎜ ⎟ ⎜ ⎟⎟⎥ + ⎝10 - N⎠ —— ⎢⎝i⎠ —— ⎝⎝j⎠ ⎝min(2, N-i-j)⎠⎠⎥ + i=0 ⎣ j=0 ⎦ + + Figure 5 + + And the probability of capture is + + C(6) + ─────── + 6 + —— + ╲ + ╱ C(i) + —— + i=0 + + Figure 6 + + For L = 300, the A required to exceed a 50% probability of capture is + 771. + +Acknowledgments + + Brian Carpenter and Stephen Farrell wrote RFC 8989, which provides + the core of this document. + + Luc André Burdet, Brian Carpenter, and Donald Eastlake provided + useful editorial suggestions. + +Author's Address + + Martin Duke + Google LLC + Email: martin.h.duke@gmail.com |