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

ELEGY                                                            M. Duke
Internet-Draft                                                Google LLC
Obsoletes: 8989 (if approved)                            1 December 2022
Updates: 8713 (if approved)                                             
Intended status: Best Current Practice                                  
Expires: 4 June 2023

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

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.

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 4 June 2023.

Duke                       Expires 4 June 2023                  [Page 1]
Internet-Draft                 RFC8989bis                  December 2022

Copyright Notice

   Copyright (c) 2022 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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  NomCom Principles . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Criteria  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     5.1.  NomCom capture  . . . . . . . . . . . . . . . . . . . . .   5
       5.1.1.  A Surge of Volunteers . . . . . . . . . . . . . . . .   6
       5.1.2.  The Two-Per-Organization Limit  . . . . . . . . . . .   6
       5.1.3.  One Year of Participation . . . . . . . . . . . . . .   7
     5.2.  Disruptive candidates . . . . . . . . . . . . . . . . . .   7
     5.3.  Additional remedies . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  NomCom Capture Calculations  . . . . . . . . . . . .   8
     A.1.  No per-organization limit . . . . . . . . . . . . . . . .   9
     A.2.  Two per Organization  . . . . . . . . . . . . . . . . . .   9
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .   9
     B.1.  Since draft-duke-elegy-rfc8989bis-00  . . . . . . . . . .   9
     B.2.  Since draft-duke-gendispatch-rfc8989bis-00  . . . . . . .  10
   Appendix C.  Acknowledgments  . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [RFC8713] defines the process for 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 4 June 2023                  [Page 2]
Internet-Draft                 RFC8989bis                  December 2022

   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 Tao. 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.  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 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, and makes recommendations on how the
   process of qualification based on attendance should work.

   This document replaces the attendance criteria in Section 4.14 of
   [RFC8713] with criteria based on those in [RFC8989], and obsoletes
   RFC8989 to make it clear that that document has been superceded.  The
   other paragraphs of Section 4.14 of [RFC8713] remain intact.

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.

Duke                       Expires 4 June 2023                  [Page 3]
Internet-Draft                 RFC8989bis                  December 2022

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 and with the spirit of the IETF, 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.

   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 some from attendance, and thus qualification from the
   NomCom, 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.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, 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].

Duke                       Expires 4 June 2023                  [Page 4]
Internet-Draft                 RFC8989bis                  December 2022

   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
   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.  Security Considerations

5.1.  NomCom capture

   The most potent threat associated with NomCom eligibility is that an
   organization or group of coordinating 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 in-
   person trips of ~5 days each over the course of at least 8 months, to
   zero financial cost and the time required to log in three times over
   at least 8 months.  Some organizations might not be deterred in
   either case, while others might now find such an attack to not be
   feasible.

Duke                       Expires 4 June 2023                  [Page 5]
Internet-Draft                 RFC8989bis                  December 2022

5.1.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 sign for the community, leadership and the IETF Secretariat
   to further investigate.  The IETF should monitor and assess a sudden
   increase in the number of online registration fee waivers awarded in
   accordance with Section 4 of [I-D.ietf-shmoo-remote-fee].

   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.

5.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).

Duke                       Expires 4 June 2023                  [Page 6]
Internet-Draft                 RFC8989bis                  December 2022

5.1.3.  One Year of Participation

   Attendance at 3 meetings requires at least 8 months.  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.

5.2.  Disruptive candidates

   Note that the normalization of consistent remote participation allows
   for a single individual to mount an attack that previously required
   coordination.  By registering for 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.

   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.

5.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.

Duke                       Expires 4 June 2023                  [Page 7]
Internet-Draft                 RFC8989bis                  December 2022

6.  IANA Considerations

   This document has no IANA actions.

7.  References

7.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/rfc/rfc2119>.

   [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/rfc/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/rfc/rfc8713>.

7.2.  Informative References

   [I-D.ietf-shmoo-remote-fee]
              Kühlewind, 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://datatracker.ietf.org/doc/html/draft-
              ietf-shmoo-remote-fee-03>.

   [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>.

Appendix A.  NomCom Capture Calculations

   Section 5 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))

Duke                       Expires 4 June 2023                  [Page 8]
Internet-Draft                 RFC8989bis                  December 2022

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))]

   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

Duke                       Expires 4 June 2023                  [Page 9]
Internet-Draft                 RFC8989bis                  December 2022

   *  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 Andre 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 4 June 2023                 [Page 10]