Internet DRAFT - draft-ietf-elegy-rfc8989bis
draft-ietf-elegy-rfc8989bis
ELEGY M. Duke
Internet-Draft Google LLC
Obsoletes: 8788, 8989 (if approved) 2 February 2023
Updates: 8713 (if approved)
Intended status: Best Current Practice
Expires: 6 August 2023
Nominating Committee Eligibility
draft-ietf-elegy-rfc8989bis-05
Abstract
The IETF Nominating Committee (NomCom) appoints candidates to several
IETF leadership committees. RFC8713 provides criteria for NomCom
membership that attempt to ensure that 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 RFC8713 by defining a
new set of eligibility criteria from first principles, with
consideration to the increased salience of remote attendance.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-elegy/rfc8989bis.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 August 2023.
Duke Expires 6 August 2023 [Page 1]
Internet-Draft RFC8989bis February 2023
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
2. NomCom Principles . . . . . . . . . . . . . . . . . . . . . . 3
3. Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4.1. NomCom Capture . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. A Surge of Volunteers . . . . . . . . . . . . . . . . 5
4.1.2. The Two-Per-Organization Limit . . . . . . . . . . . 6
4.1.3. One Year of Participation . . . . . . . . . . . . . . 6
4.2. Disruptive Candidates . . . . . . . . . . . . . . . . . . 6
4.3. Additional Remedies . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. NomCom Capture Calculations . . . . . . . . . . . . 8
A.1. No per-organization limit . . . . . . . . . . . . . . . . 8
A.2. Two per Organization . . . . . . . . . . . . . . . . . . 9
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 10
B.1. Since draft-duke-elegy-rfc8989bis-00 . . . . . . . . . . 10
B.2. Since draft-duke-gendispatch-rfc8989bis-00 . . . . . . . 10
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
[RFC8713] defines the process for the selection of the Internet
Architecture Board (IAB), Internet Engineering Steering Group (IESG),
IETF Trust, and one IETF LLC Director. A key actor in the process is
the Nominating Committee (NomCom), which nominates a single candidate
for each open position, subject to confirmation by other bodies.
Duke Expires 6 August 2023 [Page 2]
Internet-Draft RFC8989bis February 2023
NomCom voting members are volunteers that have met certain
eligibility requirements. The actual NomCom is selected at random
from the pool of eligible volunteers. 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 that volunteers must have attended
three of the previous five meetings. In practice, this has 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, where the historic
interpretation of the requirement would have resulted in no eligible
volunteers. It extended the attendance requirement to define meeting
attendance as including 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) author or editor of an IETF Stream RFC in the past
five years, including 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 qualification based on attendance should work.
This document replaces the attendance criteria in the first two
paragraphs of Section 4.14 of [RFC8713] with criteria based on those
in [RFC8989], and obsoletes RFC8989 to make it clear that that
document has been superseded. All other text in [RFC8713], including
the other paragraphs of Section 4.14, remains unchanged.
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 interactions.
Duke Expires 6 August 2023 [Page 3]
Internet-Draft RFC8989bis February 2023
A basic principle 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.
However, attitudes to business travel evolve, and remote meeting
technology continues to improve, to the extent that many longstanding
community members choose to participate remotely. A requirement for
in-person attendance has always excluded some from qualification from
the NomCom, due to cost or personal reasons. Further, the NomCom has
completed two cycles using entirely online tools.
Counting 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
Duke Expires 6 August 2023 [Page 4]
Internet-Draft RFC8989bis February 2023
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 six of ten 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. Anyone with concerns about the integrity of the
process should bring those concerns to the IESG to further
investigate,and where needed take action as defined in RFC 8713
Section 3.7.3 to invalidate such candidates.
Duke Expires 6 August 2023 [Page 5]
Internet-Draft RFC8989bis February 2023
While loosening eligibility criteria lowers the cost to an attacker
of producing eligible volunteers, it also increases the number of
legitimate volunteers that increases the difficulty of an attack.
4.1.2. The Two-Per-Organization Limit
The two-per-organization limit in [RFC8713] complicates such an
attack. To circumvent it, an organization must either (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, 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 the 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.
Duke Expires 6 August 2023 [Page 6]
Internet-Draft RFC8989bis February 2023
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/rfc/rfc8713>.
6.2. Informative References
[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/rfc/rfc8989>.
Duke Expires 6 August 2023 [Page 7]
Internet-Draft RFC8989bis February 2023
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 item is often expressed as
⎛a⎞ a!
⎜ ⎟ = ────────
⎝b⎠ (a-b)!b!
Figure 1
A.1. No per-organization limit
The first computation assumes there is no limit of two per
organization, or equivalently, no 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
⎛L+A⎞
⎜ ⎟
⎝ 10⎠
ways to select a NomCom. The number of outcomes where attackers
capture the NomCom is
10
⎯⎯
╲ ⎡⎛A⎞ ⎛ L ⎞⎤
╱ ⎢⎜ ⎟ ⎜ ⎟⎥
⎺⎺ ⎣⎝i⎠ ⎝10-i⎠⎦
i=6
Figure 2
and the probability of capture is therefore
Duke Expires 6 August 2023 [Page 8]
Internet-Draft RFC8989bis February 2023
10 ⎛A⎞ ⎛ L ⎞
⎯⎯ ⎜ ⎟ ⎜ ⎟
╲ ⎝i⎠ ⎝10-i⎠
╱ ──────────
⎺⎺ ⎛L + A⎞
i=6 ⎜ ⎟
⎝ 10 ⎠
Figure 3
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 4
And the probability of capture is
C(6)
───────
6
⎯⎯
╲
╱ C(i)
⎺⎺
i=0
Figure 5
For L = 300, the A required to exceed a 50% probability of capture is
771.
Duke Expires 6 August 2023 [Page 9]
Internet-Draft RFC8989bis February 2023
Appendix B. Change Log
*RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document.
B.1. Since draft-duke-elegy-rfc8989bis-00
* Added more security considerations
* Editorial improvements
B.2. Since draft-duke-gendispatch-rfc8989bis-00
* Matched normative section to RFC8989
* Added security considerations and appendix
Appendix C. Acknowledgments
Brian Carpenter and Stephen Farrell wrote RFC8989, 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
Duke Expires 6 August 2023 [Page 10]
