Internet DRAFT - draft-duke-elegy-rfc8989bis
draft-duke-elegy-rfc8989bis
elegy M. Duke
Internet-Draft Google LLC
Obsoletes: 8989 (if approved) 11 August 2022
Updates: 8713 (if approved)
Intended status: Best Current Practice
Expires: 12 February 2023
Nomcom Eligibility
draft-duke-elegy-rfc8989bis-00
Abstract
The IETF Nominating Committee (NomCom) appoints candidates to most
IETF leadership committee. RFC8713 provides criteria for membership
on Nomcom that attempts 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 building a
new set of eligibility criteria from first principles, with
consideration for the increased salience of remote attendance.
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 12 February 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Duke Expires 12 February 2023 [Page 1]
Internet-Draft rfc8989bis August 2022
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. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. NomCom Principles . . . . . . . . . . . . . . . . . . . . . . 3
4. Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Available Data . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6.1. A Surge of Volunteers . . . . . . . . . . . . . . . . . . 5
6.2. The Two-Per-Organization Limit . . . . . . . . . . . . . 6
6.3. One Year of Participation . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. NomCom Capture Calculations . . . . . . . . . . . . 7
A.1. No per-organization limit . . . . . . . . . . . . . . . . 7
A.2. Two per Organization . . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Since draft-duke-gendispatch-rfc8989bis-00 . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
[RFC8713]} defines the process for selection of the Internet
Architecture Board (IAB), Internet Engineering Steering Group (IESG),
IETF Trust, and the IETF LLC Director. These four committees form
the senior leadership of the IETF. A key actor in the process is the
Nominating Committee (NomCom), which nominates a single candidate for
each open position from the pool of volunteers, subject to
confirmation by other bodies.
Nomcom voting members are themselves volunteers that have met certain
eligibility requirements. The actual NomCom is selected at random
from the pool of eligible volunteers, with restrictions to ensure
that no more than two volunteers with the same primary affiliation
are chosen.
Duke Expires 12 February 2023 [Page 2]
Internet-Draft rfc8989bis August 2022
Section 4.14 of [RFC8713] requires that volunteers must have attended
three of the previous five in-person meetings. In practice, this has
meant that the volunteer picked up their registration badge. Current
members of the Internet Society Board of Trustees, IETF Trust, LLC
Board, IAB, and IESG are ineligible.
[RFC8989] specified an experiment in the wake of six consecutive
fully online meetings from 2020 to 2021, where the traditional
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 3 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. It makes recommendations on how the
future process should work. Its objective is to eventually replace
Section 4.14 of RFC8713 with criteria loosely based on those in
RFC8989.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. 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, although there is no mechanism to ensure any
interactions. Finally, the NomCom interview process was largely
conducted in-person at IETF meetings, so the ability to attend was a
prerequisite to participate.
Beyond the principle that the community should govern itself,
selecting volunteers with a demonstrated commitment to the
organization, while limiting the number from any organization, avoids
Duke Expires 12 February 2023 [Page 3]
Internet-Draft rfc8989bis August 2022
the potential for mischief via nominations that disrupt IETF
operations or attempt to "take over" the IETF on behalf of that
organization.
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. The system has
always excluded community members due to cost or personal reasons.
Further, the NomCom can now fully complete its business using online
tools.
Counting remote attendance lowers the barriers to entry. As IETF is
committed to having a no-fee remote option
([I-D.draft-kuehlewind-shmoo-remote-fee]), 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, it is historically difficult recruit volunteers for NomCom,
so overly restrictive criteria work against getting a deep talent
pool.
4. Criteria
The following paths to qualification replace Section 4.14 of
[RFC8713]. 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 3 out of the last
5 IETF meetings, either in-person or online. In-person attendance is
as determined by the record keeping of the Secretariat. Online
attendance and 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 3 years prior to the day the call for NomCom volunteers is sent
to the community.
Duke Expires 12 February 2023 [Page 4]
Internet-Draft rfc8989bis August 2022
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 5 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 5-year timer extends back to the
date 5 years before the date when the call for NomCom volunteers is
sent to the community.
5. Available Data
TODO: This document should contain data about how the proposed
criteria would have affected eligibility for NomComs in the recent
past.
6. Security Considerations
The threat model associated with NomCom eligibility is that an
organization or group of organizations would attempt to obtain a
majority of NomCom positions, in order to select an IETF leadership
in support of an agenda that might be against the interests of the
community as a whole.
Whatever the merits of admitting remote attendees, it reduces the
minimum cost of creating a NonCom-eligible volunteer from three
flights and ~5 days of travel over the course of year, to $0 and the
time required to log in three times over the course of a year. Some
organizations might not be deterred in either case, while others
might now find such an attack to be feasible.
6.1. A Surge of Volunteers
A large number of "legitimate" volunteers makes it quite difficult to
control 6 of 10 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 6 or more NomCom
positions, an attacker needs somewhat 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
system for leadership to further investigate.
Duke Expires 12 February 2023 [Page 5]
Internet-Draft rfc8989bis August 2022
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 and
detectability of an attack.
6.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
(seeAppendix A).
6.3. One Year of Participation
Attendance at 3 meetings requires at least 1 year. Given the volume
of volunteers necessary to capture the process, an attack requires a
surge in attendees over the course of a year. IETF leadership SHOULD
analyze unexplained surges in attendance to look for signs of
manipulating the eligibility requirements (e.g. logging in to a
single session and then immediately logging out). In the event of
malfeasance, the leadership would then have months to adjust policy
in response before the NomCom cycle begins.
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Duke Expires 12 February 2023 [Page 6]
Internet-Draft rfc8989bis August 2022
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
8.2. Informative References
[I-D.draft-kuehlewind-shmoo-remote-fee]
Kuehlewind, M., Reed, J., and R. Salz, "Open Participation
Principle regarding Remote Registration Fee", Work in
Progress, Internet-Draft, draft-kuehlewind-shmoo-remote-
fee-02, 18 January 2021, <https://www.ietf.org/archive/id/
draft-kuehlewind-shmoo-remote-fee-02.txt>.
[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 6 offers some mathematical results for the probability of
NomCom capture. This appendix shows the work.
Let (a ch b) mean the number of combinations of b items chosen from a
population of a items, or
(a ch b) = fact(a) / (fact(a-b) * fact(b))
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) ch 10) ways to select a NomCom. The number of
outcomes where attackers capture the NomCom is
Sum(i=6..10)[(A ch i) * (L ch (10-i)]
Duke Expires 12 February 2023 [Page 7]
Internet-Draft rfc8989bis August 2022
and the probability of capture is therefore
Sum(i=6..10)[(A ch i) * (L ch (10-i)] / ((L+A) ch 10).
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
C(N) = (L ch (10-N)) * Sum(i=0:min(N,2))[(B ch i)_Sum(j=0..min(2,
N-i))[(B ch j)_(B ch min(2, N-i-j))]]
And the probability of capture is
C(6) / Sum(i=0..6)[C(i)]
For L = 300, the A required to exceed a 50% probability of capture is
771.
Acknowledgments
TODO acknowledge.
Change Log
*RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document.
Since draft-duke-gendispatch-rfc8989bis-00
* Matched normative section to RFC8989
* Added security considerations and appendix
Author's Address
Martin Duke
Google LLC
Email: martin.h.duke@gmail.com
Duke Expires 12 February 2023 [Page 8]
