doc: Add RFC documents

1 files changed, 450 insertions, 0 deletions

diff --git a/doc/rfc/rfc9389.txt b/doc/rfc/rfc9389.txt
new file mode 100644
index 0000000..7f025d7
--- /dev/null
+++ b/doc/rfc/rfc9389.txt
@@ -0,0 +1,450 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                           M. Duke
+Request for Comments: 9389                                    Google LLC
+BCP: 10                                                       April 2023
+Obsoletes: 8788, 8989                                                   
+Updates: 8713                                                           
+Category: Best Current Practice                                         
+ISSN: 2070-1721
+
+
+                    Nominating Committee Eligibility
+
+Abstract
+
+   The IETF Nominating Committee (NomCom) appoints candidates to several
+   IETF leadership committees.  RFC 8713 provides criteria for NomCom
+   membership that attempt to ensure 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 RFC 8713 by defining a new set of
+   eligibility criteria from first principles, with consideration to the
+   increased salience of remote attendance.  This document obsoletes
+   RFCs 8788 and 8989.
+
+Status of This Memo
+
+   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 at
+   https://www.rfc-editor.org/info/rfc9389.
+
+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.  NomCom Principles
+   3.  Criteria
+   4.  Security Considerations
+     4.1.  NomCom Capture
+       4.1.1.  A Surge of Volunteers
+       4.1.2.  The Two-per-Organization Limit
+       4.1.3.  One Year of Participation
+     4.2.  Disruptive Candidates
+     4.3.  Additional Remedies
+   5.  IANA Considerations
+   6.  References
+     6.1.  Normative References
+     6.2.  Informative References
+   Appendix A.  NomCom Capture Calculations
+     A.1.  No per-Organization Limit
+     A.2.  Two per Organization
+   Acknowledgments
+   Author's Address
+
+1.  Introduction
+
+   [RFC8713] defines the process for the selection of the Internet
+   Architecture Board (IAB), Internet Engineering Steering Group (IESG),
+   IETF Trust, and the IETF 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 to
+   confirmation 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
+   restrictions to ensure that no more than two volunteers with the same
+   primary affiliation are chosen.
+
+   Section 4.14 of [RFC8713] requires volunteers to have attended three
+   of the previous five meetings.  In practice, this 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, because the historic
+   interpretation of the requirement would have resulted in no eligible
+   volunteers.  It extended the meeting attendance requirement to
+   include 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) being an author or editor of an IETF Stream RFC in the
+   past five years, 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 should work.
+
+   This document replaces the attendance criteria in the first two
+   paragraphs of Section 4.14 of [RFC8713] with the criteria described
+   in [RFC8989], and it obsoletes RFC 8989 to 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 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 and remote meeting technology continues to improve, many
+   longstanding community members are choosing to 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 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 a majority of 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 of an attempt at capture.  Anyone with concerns about
+   the integrity of the process should bring those concerns to the IESG
+   to investigate.  Where needed, the confirming bodies can take action
+   to invalidate such candidates as defined in Section 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 which increases the difficulty of an attack.
+
+4.1.2.  The Two-per-Organization Limit
+
+   The two-per-organization limit described in Section 4.17 of [RFC8713]
+   complicates such a capture attack.  To circumvent it, an organization
+   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.  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
+   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 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/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/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 items is often expressed as
+
+                              ⎛a⎞      a!
+                              ⎜ ⎟ = ────────
+                              ⎝b⎠   (a-b)!b!
+
+                                  Figure 1
+
+A.1.  No per-Organization Limit
+
+   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 an attacker) and A be the number of attacking volunteers.
+   Then there are the following ways to select a NomCom:
+
+                                   ⎛L+A⎞
+                                   ⎜   ⎟
+                                   ⎝ 10⎠
+
+                                  Figure 2
+
+   The number of outcomes where attackers capture the NomCom is:
+
+                              10
+                              ——
+                              ╲  ⎡⎛A⎞ ⎛ L  ⎞⎤
+                              ╱  ⎢⎜ ⎟ ⎜    ⎟⎥
+                              —— ⎣⎝i⎠ ⎝10-i⎠⎦
+                              i=6
+
+                                  Figure 3
+
+   Therefore, the probability of capture is
+
+                               10 ⎛A⎞ ⎛ L  ⎞
+                               —— ⎜ ⎟ ⎜    ⎟
+                               ╲  ⎝i⎠ ⎝10-i⎠
+                               ╱  ──────────
+                               ——  ⎛L + A⎞
+                               i=6 ⎜     ⎟
+                                   ⎝  10 ⎠
+
+                                  Figure 4
+
+   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 5
+
+   And the probability of capture is
+
+                                    C(6)
+                                  ───────
+                                  6
+                                  ——
+                                  ╲
+                                  ╱  C(i)
+                                  ——
+                                  i=0
+
+                                  Figure 6
+
+   For L = 300, the A required to exceed a 50% probability of capture is
+   771.
+
+Acknowledgments
+
+   Brian Carpenter and Stephen Farrell wrote 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