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

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]