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

This html diff was produced by rfcdiff 1.48.