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

elegy                                                            M. Duke
Internet-Draft                                                Google LLC
Obsoletes: 8989 (if approved)                          16 September 2022
Updates: 8713 (if approved)                                             
Intended status: Best Current Practice                                  
Expires: 20 March 2023

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

Abstract

   The IETF Nominating Committee (NomCom) appoints candidates to most
   IETF leadership committee.  RFC8713 provides criteria for membership
   on NomCom 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 building a
   new set of eligibility criteria from first principles, with
   consideration for the increased salience of remote attendance.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 20 March 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Duke                      Expires 20 March 2023                 [Page 1]
Internet-Draft                 rfc8989bis                 September 2022

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  NomCom Principles . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Criteria  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Available Data  . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     6.1.  A Surge of Volunteers . . . . . . . . . . . . . . . . . .   5
     6.2.  The Two-Per-Organization Limit  . . . . . . . . . . . . .   6
     6.3.  One Year of Participation . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  NomCom Capture Calculations  . . . . . . . . . . . .   7
     A.1.  No per-organization limit . . . . . . . . . . . . . . . .   7
     A.2.  Two per Organization  . . . . . . . . . . . . . . . . . .   8
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .   8
     B.1.  Since draft-duke-elegy-rfc8989bis-00  . . . . . . . . . .   8
     B.2.  Since draft-duke-gendispatch-rfc8989bis-00  . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   [RFC8713] defines the process for selection of the Internet
   Architecture Board (IAB), Internet Engineering Steering Group (IESG),
   IETF Trust, and the IETF LLC Director.  These four committees form
   the senior leadership of the IETF.  A key actor in the process is the
   Nominating Committee (NomCom), which nominates a single candidate for
   each open position from the pool of volunteers, subject to
   confirmation by other bodies.

   NomCom voting members are themselves volunteers that have met certain
   eligibility requirements.  The actual NomCom is selected at random
   from the pool of eligible volunteers, with restrictions to ensure
   that no more than two volunteers with the same primary affiliation
   are chosen.

Duke                      Expires 20 March 2023                 [Page 2]
Internet-Draft                 rfc8989bis                 September 2022

   Section 4.14 of [RFC8713] requires that volunteers must have attended
   three of the previous five in-person meetings.  In practice, this has
   meant that the volunteer picked up their registration badge.  Current
   members of the Internet Society Board of Trustees, IETF Trust, LLC
   Board, IAB, and IESG are ineligible.

   [RFC8989] specified an experiment in the wake of six consecutive
   fully online meetings from 2020 to 2021, where the traditional
   interpretation of the requirement would have resulted in no eligible
   volunteers.  It extended the attendance requirement to define meeting
   attendance as including logging in to at least one session of a
   fully-online IETF meeting.

   RFC8989 also created two other tracks to obtain eligibility: (1)
   serving as a working group chair or secretary in the past 3 years,
   and (2) author or editor of an IETF Stream RFC in the past five
   years, including internet-drafts in the RFC Editor queue.

   This document discusses some of the first principles that inform the
   design of NomCom eligibility.  It makes recommendations on how the
   future process should work.  Its objective is to eventually replace
   Section 4.14 of RFC8713 with criteria loosely based on those in
   RFC8989.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  NomCom Principles

   The NomCom is intended to be composed of randomly selected members of
   "the community."  For many years, in-person attendance was a
   reasonable proxy for the commitment associated with being a member.
   Two days of travel and an attendance fee is a relatively large
   expenditure of time and money.  Additionally, in-person attendance is
   thought to increase personal familiarity with candidates for
   leadership positions, although there is no mechanism to ensure any
   interactions.  Finally, the NomCom interview process was largely
   conducted in-person at IETF meetings, so the ability to attend was a
   prerequisite to participate.

Duke                      Expires 20 March 2023                 [Page 3]
Internet-Draft                 rfc8989bis                 September 2022

   Beyond the principle that the community should govern itself,
   selecting volunteers with a demonstrated commitment to the
   organization, while limiting the number from any organization, avoids
   the potential for mischief via nominations that disrupt IETF
   operations or work 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.  The system has
   always excluded community members due to cost or personal reasons.
   Further, the NomCom can now fully complete its business using online
   tools.

   Counting remote attendance lowers the barriers to entry.  As IETF is
   committed to having a no-fee remote option
   ([I-D.draft-ietf-shmoo-remote-fee]), the only required investment is
   to log on once per meeting at a specific time (sometimes a locally
   inconvenient hour).  While this document does not formally impose a
   requirement for the NomCom to function entirely remotely, including
   remote-only attendees in the pool is likely to effectively require a
   remote component to NomCom operations.

   Finally, it is historically difficult to recruit volunteers for
   NomCom, so overly restrictive criteria work against getting a deep
   talent pool.

4.  Criteria

   The following paths to qualification replace Section 4.14 of
   [RFC8713].  Any one of the paths is sufficient, unless the person is
   otherwise disqualified under Section 4.15 of [RFC8713].

   Path 1: The person has registered for and attended 3 out of the last
   5 IETF meetings, either in-person or online.  In-person attendance is
   as determined by the record keeping of the Secretariat.  Online
   attendance is based on being a registered person who logged in for at
   least one session of an IETF meeting.

   Path 2: The person has been a Working Group Chair or Secretary within
   the 3 years prior to the day the call for NomCom volunteers is sent
   to the community.

   Path 3: The person has been a listed author or editor (on the front
   page) of at least two IETF Stream RFCs within the last 5 years prior
   to the day the call for NomCom volunteers is sent to the community.
   An Internet-Draft that has been approved by the IESG and is in the
   RFC Editor queue counts the same as a published RFC, with the
   relevant date being the date the draft was added to the RFC Editor

Duke                      Expires 20 March 2023                 [Page 4]
Internet-Draft                 rfc8989bis                 September 2022

   queue.  For avoidance of doubt, the 5-year timer extends back to the
   date 5 years before the date when the call for NomCom volunteers is
   sent to the community.

5.  Available Data

   TODO: This document should contain data about how the proposed
   criteria would have affected eligibility for NomComs in the recent
   past.

6.  Security Considerations

   The threat model associated with NomCom eligibility is that an
   organization or group of organizations would attempt to obtain a
   majority of NomCom positions, in order to select an IETF leadership
   in support of an agenda that might be self-serving and against the
   interests of the community as a whole.

   Note that [RFC8713] lets the Chair decide the NomCom voting
   requirement, so a simple majority may be inadequate.  However, 7 of
   10 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
   flights and ~5 days of travel over the course of a year, to zero
   financial cost and the time required to log in three times over the
   course of a year.  Some organizations might not be deterred in either
   case, while others might now find such an attack to be feasible.

6.1.  A Surge of Volunteers

   A large number of "legitimate" volunteers makes it quite difficult to
   control 6 of 10 NomCom slots.  Setting aside limitations on the
   number of selections from any organization, basic probability shows
   that to have even a 50% chance of controlling 6 or more NomCom
   positions, an attacker needs somewhat roughly 60% of the volunteer
   pool.  For example, if there are 300 "legitimate" volunteers, an
   attacker must produce 365 volunteers to exceed a 50% chance of NomCom
   capture (see Appendix A).

   A sudden surge in the number of volunteers, particularly of people
   that no one recognizes as a part of the community is an early-warning
   system for leadership to further investigate.

Duke                      Expires 20 March 2023                 [Page 5]
Internet-Draft                 rfc8989bis                 September 2022

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

6.2.  The Two-Per-Organization Limit

   The two-per-organization limit in [RFC8713] complicates such an
   attack.  To circumvent it, an organization must either (1) coordinate
   with at least two like-minded organizations to produce a NomCom
   majority, (2) incentivize members of other organizations (possibly
   through a funding agreement) to support its agenda, or (3) propose
   candidates with false affiliations.

   While the IETF does not routinely confirm the affiliation of
   volunteers, as part of an investigation it could eliminate volunteers
   who have misrepresented said affiliation.  Publishing the list of
   volunteers and affiliations also gives the community an opportunity
   to review the truth of such claims.

   Assuming that 300 legitimate volunteers are all from different
   organizations, three conspiring organizations would need 771
   volunteers (257 per organization) for a 50% chance of NomCom capture
   (see Appendix A).

6.3.  One Year of Participation

   Attendance at 3 meetings requires at least 1 year.  Given the volume
   of volunteers necessary to capture the process, an attack requires a
   surge in attendees over the course of a year.  IETF leadership SHOULD
   analyze unexplained surges in attendance to look for signs of
   manipulating the eligibility requirements (e.g. logging in to a
   single session and then immediately logging out).  In the event of
   malfeasance, the leadership would then have months to adjust policy
   in response before the NomCom cycle begins.

7.  IANA Considerations

   This document has no IANA actions.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Duke                      Expires 20 March 2023                 [Page 6]
Internet-Draft                 rfc8989bis                 September 2022

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8713]  Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
              Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection,
              Confirmation, and Recall Process: Operation of the IETF
              Nominating and Recall Committees", BCP 10, RFC 8713,
              DOI 10.17487/RFC8713, February 2020,
              <https://www.rfc-editor.org/info/rfc8713>.

8.2.  Informative References

   [I-D.draft-ietf-shmoo-remote-fee]
              Kuehlewind, M., Reed, J., and R. Salz, "Open Participation
              Principle regarding Remote Registration Fee", Work in
              Progress, Internet-Draft, draft-ietf-shmoo-remote-fee-03,
              3 June 2022, <https://www.ietf.org/archive/id/draft-ietf-
              shmoo-remote-fee-03.txt>.

   [RFC8989]  Carpenter, B. and S. Farrell, "Additional Criteria for
              Nominating Committee Eligibility", RFC 8989,
              DOI 10.17487/RFC8989, February 2021,
              <https://www.rfc-editor.org/info/rfc8989>.

Appendix A.  NomCom Capture Calculations

   Section 6 offers some mathematical results for the probability of
   NomCom capture.  This appendix shows the work.

   Let (a ch b) mean the number of combinations of b items chosen from a
   population of a items, or

   (a ch b) = fact(a) / (fact(a-b) * fact(b))

A.1.  No per-organization limit

   The first computation assumes there is no limit of two per
   organization, or equivalently, no organization produces more than two
   volunteers.

   Let L be the number of "legitimate" volunteers (i.e. those not allied
   with an attacker" and A be the number of attacking volunteers.  Then
   there are ((L+A) ch 10) ways to select a NomCom.  The number of
   outcomes where attackers capture the NomCom is

   Sum(i=6..10)[(A ch i) * (L ch (10-i)]

Duke                      Expires 20 March 2023                 [Page 7]
Internet-Draft                 rfc8989bis                 September 2022

   and the probability of capture is therefore

   Sum(i=6..10)[(A ch i) * (L ch (10-i)] / ((L+A) ch 10).

   For L = 300, this probability crosses 50% at A = 365.

A.2.  Two per Organization

   Assume that the population of L is drawn from L different
   organizations (this assumption is unfavorable to the attacker).
   Assume also that there are three conspiring organizations.  Then no
   more than 6 members can be drawn from A.

   Let B be the number of nominees per attacking organization, so that A
   = 3B.

   The number of combinations to pick exactly N attackers, N <= 6, is

   C(N) = (L ch (10-N)) * Sum(i=0:min(N,2))[(B ch i)_Sum(j=0..min(2,
   N-i))[(B ch j)_(B ch min(2, N-i-j))]]

   And the probability of capture is

   C(6) / Sum(i=0..6)[C(i)]

   For L = 300, the A required to exceed a 50% probability of capture is
   771.

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

   *  Editorial suggestions from Luc Andre Burdet

B.2.  Since draft-duke-gendispatch-rfc8989bis-00

   *  Matched normative section to RFC8989

   *  Added security considerations and appendix

Acknowledgments

   TODO acknowledge.

Duke                      Expires 20 March 2023                 [Page 8]
Internet-Draft                 rfc8989bis                 September 2022

Author's Address

   Martin Duke
   Google LLC
   Email: martin.h.duke@gmail.com

Duke                      Expires 20 March 2023                 [Page 9]