| RFC 9389 | Nominating Committee Eligibility | April 2023 |
| Duke | Best Current Practice | [Page] |
The IETF Nominating Committee (NomCom) appoints candidates to several IETFleadership committees. RFC 8713 provides criteria for NomCom membership thatattempt to ensure NomCom volunteers are members of the loosely definedIETF 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 onlineplenary meetings that drove rapid advancement in remote meeting technologies andprocedures, including an experiment that included remote attendance for NomComeligibility. This document updates RFC 8713 by defining a new set of eligibilitycriteria from first principles, with consideration to the increased salience ofremote attendance. This document obsoletes RFCs 8788 and 8989.¶
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 athttps://www.rfc-editor.org/info/rfc9389.¶
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.¶
[RFC8713] defines the process for the selection of the Internet ArchitectureBoard (IAB), Internet Engineering Steering Group (IESG), IETF Trust, and theIETF 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 toconfirmation 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 restrictionsto ensure that no more than two volunteers with the same primary affiliation arechosen.¶
Section 4.14 of [RFC8713] requires volunteers to have attended three ofthe previous five meetings. In practice, this meant that the volunteerpicked up their registration badge at an in-person meeting. Current members ofthe Internet Society Board of Trustees and bodies for which the NomCom nominatesmembers are ineligible.¶
[RFC8989] specified an experiment in the wake of six consecutive fully onlinemeetings from 2020 to 2021, because the historic interpretation of the requirementwould have resulted in no eligible volunteers. It extended the meeting attendancerequirement to include logging in to at least onesession of a fully online IETF meeting.¶
[RFC8989] also created two other tracks to obtain eligibility: (1) serving as aworking group chair or secretary in the past three years, and (2) being an author oreditor of an IETF Stream RFC in the past five years, which includes Internet-Draftsin the RFC Editor queue.¶
This document discusses some of the first principles that inform the design ofNomCom eligibility, and makes recommendations on how the process ofattendance-based qualification should work.¶
This document replaces the attendance criteria in the first two paragraphs ofSection 4.14 of [RFC8713] with the criteria described in[RFC8989], and it obsoletes RFC 8989 to clarify that the document has been superseded. Allother text in[RFC8713], including the other paragraphs of Section4.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.¶
The NomCom is intended to be composed of randomly selected members of "thecommunity." For many years, in-person attendance was a reasonable proxy for thecommitment associated with being a member. Two days of travel and an attendancefee is a relatively large expenditure of time and money. Additionally, in-personattendance is thought to increase personal familiarity with candidates forleadership positions and with the spirit of the IETF, although there is nomechanism to ensure any interaction.¶
A basic principle of the IETF is that the community should govern itself, so volunteersmust have a demonstrated commitment to the IETF. Limiting the number ofvolunteers sponsored by any one organization avoids the potential for mischiefthat disrupts IETF operations or works against the interests of the community asa 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 technologycontinues to improve, many longstanding community members are choosingto 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 hashistorically provided a fee-free remote participation option, via waiver orotherwise, the only required investment is to log on once per meeting at aspecific time (sometimes a locally inconvenient hour). While this documentdoes not formally impose a requirement for the NomCom to function entirelyremotely, including remote-only attendees in the pool is likely to effectivelyrequire a remote component to NomCom operations.¶
Finally, overly restrictive criteria work against getting a broad talent pool.¶
The following text replaces the first two paragraphs ofSection 4.14 of [RFC8713]:¶
Members of the IETF community must satisfy the conditions in one of three pathsin order to volunteer. Any one of the paths is sufficient, unless the person isotherwise disqualified underSection 4.15 of [RFC8713].¶
- Path 1:
- The person has registered for and attended three out of the last five IETFmeetings, either in-person or online. In-person attendance is as determined bythe record keeping of the Secretariat. Online attendance is based on being aregistered 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 yearsprior 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 twoIETF Stream RFCs within the last five years prior to the day the call forNomCom volunteers is sent to the community. An Internet-Draft that has beenapproved by the IESG and is in the RFC Editor queue counts the same as apublished RFC, with the relevant date being the date the draft was added to theRFC Editor queue. For avoidance of doubt, the five-year timer extends back tothe date five years before the date when the call for NomCom volunteers is sentto the community.¶
The most potent threat associated with NomCom eligibility is that anorganization or group of coordinating organizations could attempt to obtain amajority of NomCom positions, in order to select an IETF leadership in supportof an agenda that might be self-serving and against the interests of thecommunity as a whole.¶
Note that[RFC8713] lets the NomCom Chair decide the NomCom votingrequirement, so a simple majority may be inadequate. However, seven of ten formsa quorum, so at worst seven NomCom members working together can almost certainlyimpose their will.¶
Whatever the merits of admitting remote attendees, it reduces the minimum costof creating a NomCom-eligible volunteer from three in-person trips of aroundfive days each over the course of at least eight months, to zero financial costand the time required to log in three times over at least eight months. Someorganizations might not be deterred in either case, while others might.¶
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 fromany organization, basic probability shows that to have even a 50% chance ofcontrolling six or more NomCom positions, an attacker needs roughly 60% of thevolunteer pool. For example, if there are 300 "legitimate" volunteers, anattacker must produce 365 volunteers to exceed a 50% chance of NomCom capture(seeAppendix A).¶
A sudden surge in the number of volunteers, particularly of people that no onerecognizes as a part of the community, is an early-warning sign of an attempt at capture. Anyone withconcerns about the integrity of the process should bring those concerns to theIESG to investigate. Where needed, the confirming bodies can take action to invalidate such candidates as defined inSection 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 whichincreases the difficulty of an attack.¶
The two-per-organization limit described inSection 4.17 of [RFC8713] complicates such a capture attack. To circumvent it, an organization would have to do one or more of the following:¶
While the IETF does not routinely confirm the affiliation of volunteers, as partof an investigation it could eliminate volunteers who have misrepresented saidaffiliation. Publishing the list of volunteers and affiliations also gives thecommunity 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 (seeAppendix A).¶
Attendance at three meetings requires at least eight months of waiting. Giventhe volume of volunteers necessary to capture the process, an attack requires asurge in attendees over the course of a year. Such a surge might trigger acommunity challenge to the list of eligible volunteers, and/or a leadershipinvestigation to detect suspicious behavior (e.g., logging in to a singlesession and then immediately logging out). In the event of abuse of process, theleadership would then have months to adjust policy in response before the NomComcycle begins, and/or disqualify candidates.¶
Note that counting remote participation towards NomCom eligibility allowsfor a single individual to mount an attack that previously requiredcoordination. By registering for remote attendance to IETF meetings using anumber of different identities over a year, an individual can make each of thoseidentities NomCom eligible and then serve under any one of them that is selectedfor the NomCom. Once selected, an individual could seek to disrupt the processor prevent the timely conclusion of its work. Less severely, an attacker couldsimply improve their chances of being selected for NomCom.¶
This attack is much harder to detect or prevent than equivalent attacks werepreviously, as it does not require coordination among multiple attendees.While the attacker cannot be sure of fee waivers for some or all of thedifferent identities, the lower cost for remote participation also makes thisattack more feasible than it would have been under prior rules.¶
However, the voting member recall procedure inSection 5.7 of [RFC8713] existsto allow removal and replacement of disruptive figures.¶
Additional changes to the process to further obstruct attacks against theNomCom are beyond the scope of this document. However, a challenge processagainst volunteers with a suspicious reported affiliation, or that might bealiases of a single volunteer, could trigger an investigation.¶
Similarly, the challenge to the random selection described inSection 4.17 of [RFC8713] can explicitly include appeals against the dataused to qualify the volunteer, rather than the randomization process.¶
This document has no IANA actions.¶
Section 4 offers some mathematical results for the probabilityof 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¶
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 anattacker) and A be the number of attacking volunteers. Then there are the following ways to select a NomCom:¶
The number of outcomes where attackers capture the NomCom is:¶
Therefore, the probability of capture is¶
For L = 300, this probability crosses 50% at A = 365.¶
Assume that the population of L is drawn from L different organizations (thisassumption is unfavorable to the attacker). Assume also that there are threeconspiring 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¶
And the probability of capture is¶
For L = 300, the A required to exceed a 50% probability of capture is 771.¶
Brian Carpenter andStephen Farrell wrote RFC 8989, which provides the core ofthis document.¶
Luc André Burdet,Brian Carpenter, andDonald Eastlake provided usefuleditorial suggestions.¶