wdiff rfc9389.original rfc9389.txt

ELEGY

Internet Engineering Task Force (IETF) M. Duke
Internet-Draft
Request for Comments: 9389 Google LLC
BCP: 10 April 2023
Obsoletes: 8788, 8989 (if approved) 2 February 2023
Updates: 8713 (if approved)
Intended status:
Category: Best Current Practice
Expires: 6 August 2023
ISSN: 2070-1721

Nominating Committee Eligibility
draft-ietf-elegy-rfc8989bis-05

Abstract

The IETF Nominating Committee (NomCom) appoints candidates to several
IETF leadership committees. RFC8713 RFC 8713 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 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 RFC 8713 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 document obsoletes
RFCs 8788 and an issue tracker can be found at
https://github.com/ietf-wg-elegy/rfc8989bis. 8989.

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 memo documents an Internet Best Current Practice.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of six months RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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.
https://www.rfc-editor.org/info/rfc9389.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(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 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 per-Organization Limit
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 the IETF LLC Director. Directors. A key actor in the process
is the Nominating Committee (NomCom), which nominates a single
candidate for each open position, 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. 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 to 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 because the historic
interpretation of the requirement would have resulted in no eligible
volunteers. It extended the meeting attendance requirement to define meeting
attendance as including
include logging in to at least one session of a
fully-online fully online IETF
meeting.

RFC8989

[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, including internet-drafts 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 based on attendance should work.

This document replaces the attendance criteria in the first two
paragraphs of Section 4.14 of [RFC8713] with the criteria based on those described
in [RFC8989], and it obsoletes RFC8989 RFC 8989 to make it clear that 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 interactions. 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,
evolve and remote meeting technology continues to improve, to the extent that many
longstanding community members choose are choosing to participate remotely. A requirement for
in-person attendance has always excluded some from qualification from
the NomCom, due remotely
(due to cost or personal reasons. Further, reasons). In addition, the NomCom has
completed two cycles using entirely online tools.

Counting

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 six a majority 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. sign of an attempt at capture. Anyone with concerns about
the integrity of the process should bring those concerns to the IESG
to further
investigate,and where needed investigate. Where needed, the confirming bodies can take action
to invalidate such candidates as defined in RFC 8713 Section 3.7.3 to invalidate such candidates. of
[RFC8713].

While loosening eligibility criteria lowers the cost to an attacker
of producing eligible volunteers, it also increases the number of
legitimate volunteers that which increases the difficulty of an attack.

4.1.2. The Two-Per-Organization Two-per-Organization Limit

The two-per-organization limit described in Section 4.17 of [RFC8713]
complicates such an a capture attack. To circumvent it, an organization must either (1)
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)

2. incentivize members of other organizations (possibly through a
funding agreement) to support its agenda, or (3) 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 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.

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>.
<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/rfc/rfc8989>.
<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 item items is often expressed as

⎛a⎞ a!
⎜ ⎟ = ────────
⎝b⎠ (a-b)!b!

Figure 1

A.1. No per-organization limit

The first computation per-Organization Limit

Appendix A.1 assumes there is no limit limitation on the number of two per
organization, or equivalently,
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. (i.e., those not
allied with an attacker" attacker) and A be the number of attacking volunteers.
Then there are the following ways to select a NomCom:

⎛L+A⎞
⎜ ⎟
⎝ 10⎠

ways to select a NomCom.

The number of outcomes where attackers capture the NomCom is is:

10
⎯⎯
——
╲ ⎡⎛A⎞ ⎛ L ⎞⎤
╱ ⎢⎜ ⎟ ⎜ ⎟⎥
⎺⎺
—— ⎣⎝i⎠ ⎝10-i⎠⎦
i=6

Figure 2

and

Therefore, the probability of capture is therefore

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.

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, 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