RFC 8989
Additional Criteria for Nominating Committee Eligibility
RFC 8989: Additional Criteria for Nominating Committee Eligibility β¨
Request for Comments: 8989 π Category: Experimental (a process experiment, not a standard π§ͺ) ISSN: 2070-1721 Date: February 2021 πΈ Authors: B. Carpenter (Univ. of Auckland) and S. Farrell (Trinity College Dublin) π Obsoletes / Updates: The title block doesn't list anything it obsoletes or updates. What it does do is temporarily vary the rules in RFC 8713, which the Abstract spells out π¦
Abstract β¨
Okay bestie, so this doc sets up a process experiment under RFC 3933 that temporarily changes who qualifies to be a volunteer for the IETF Nominating Committee (NomCom) π Since recall petition signers are supposed to have the same eligibility as NomCom volunteers, it also changes the rules for signing a community recall petition π«Ά
Why? Remote participation has been blowing up and face-to-face meetings are getting rarer, so the old criteria needed to be more flexible. The experiment has a fixed duration and covers one, or at most two, back-to-back NomCom cycles starting in 2021. It temporarily varies the rules in RFC 8713 β¨
Status of This Memo π
Quick vibe check: this document is not an Internet Standards Track specification. It's published so people can examine it, try it out in experimental implementations, and evaluate it π§ͺ
It defines an Experimental Protocol for the Internet community, and it's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, though. Section 2 of RFC 7841 has the deets π
For the current status, any errata, and how to send feedback, check out https://www.rfc-editor.org/info/rfc8989 π
Copyright Notice π
Copyright (c) 2021 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) as they're in effect on the publication date. Please actually read these, because they spell out your rights and restrictions for this document π Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License π
Table of Contents ποΈ
1. Introduction
2. Term and Evaluation of the Experiment
3. Goals
4. Criteria
4.1. Clarifying Detail
5. Omitted Criteria
6. IANA Considerations
7. Security Considerations
8. Normative References
Appendix A. Available Data
Acknowledgements
Authors' Addresses
1. Introduction π¦
Okay so, according to [RFC8713], the IETF Nominating Committee (NomCom) is filled from a pool of volunteers with a specified record of attendance at IETF plenary meetings. Those meetings were assumed to be face-to-face when that document was approved π
Then things changed! The IETF 107, 108, 109, and 110 face-to-face meetings got cancelled, there's a risk of more cancellations, face-to-face meetings will probably be less frequent in the future for sustainability reasons, and remote participation is just generally up. So this document defines a process experiment [RFC3933] of fixed duration (more on that in Section 2) that uses modified and additional criteria to qualify volunteers π
The eligibility criteria for signing recall petitions are also modified during this experiment. [RFC8713] defines those to be the same as NomCom eligibility, so they change too, as described in this document. The experiment has no other effect on the recall process π«Ά
2. Term and Evaluation of the Experiment β³
The cancellation of the in-person IETF 107 through 110 meetings means the current criteria are already seriously messed up for at least 2 years. So the experiment needs to start ASAP πββοΈ However, the experiment did not apply to picking the 2020-2021 NomCom, which was done according to [RFC8788] πΈ
The experiment will initially cover the IETF NomCom cycle that begins in 2021. As soon as the entire 2021-2022 NomCom is seated, the IESG must consult the 2021-2022 NomCom Chair and the 2020-2021 NomCom Chair (who keep NomCom confidentiality) and publish a report on the experiment's results π Things to look at include whether the experiment produced a big enough and diverse enough pool of people, whether enough of them volunteered to make a representative NomCom with good knowledge of the IETF, and whether all the goals in Section 3 were met. If possible, you should compare it with results from the previous procedure (aka RFC 8713) β¨
After that, the IESG must also start a community discussion about whether to:
- Amend [RFC8713] in time for the 2022-2023 NomCom cycle; or
- Prolong the current experiment for a second and final year with additional clarifications specific to the 2022-2023 cycle; or
- Run a different experiment for the next nominating cycle; or
- Revert to [RFC8713].
The IESG will announce the consensus result of that discussion in good time for the 2022-2023 NomCom cycle to start π
If the experiment gets prolonged for a second year, the IESG will repeat the consultation, report, and community discussion process accordingly. But this document lapses at the end of the 2022-2023 NomCom cycle, so it's not forever π₯Ή
3. Goals π―
The goals of the modified and additional criteria are as follows:
- Mitigate the issue of active remote (or, rarely, in-person) participants being disenfranchised in the NomCom and recall processes π«Ά
- Enable the selection of a 2021-2022 NomCom, and possibly a 2022-2023 NomCom, when it's impossible for anyone to have attended 3 out of the last 5 IETF meetings in person π
- Prepare for an era in which face-to-face plenary meetings are less frequent (which extends the issue to many, maybe a majority, of participants) π
- Ensure that those eligible have enough current understanding of IETF practices and people to make informed decisions π§
- Provide algorithmic criteria, so the Secretariat can check them mechanically against available data π§
4. Criteria π
This experiment specifies several alternative paths to qualification, replacing the single criterion in 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. For meetings held entirely online, online registration and attendance count as attendance. For the 2021-2022 NomCom, the meetings concerned are IETF 106, 107, 108, 109, and 110. Attendance is as determined by the record keeping of the Secretariat for in-person meetings, and it's based on being a registered person who logged in for at least one session of an online 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 π
Notes:
- Path 1 corresponds approximately to [RFC8713], modified as per [RFC8788] πΈ
- Path 3 includes approved drafts, since some documents spend a long time in the RFC Editor's queue β³
- Path 3 extends to 5 years because it commonly takes 3 or 4 years for new documents to be approved in the IETF Stream, so 3 years would be too short a sampling period π
- All the required data are available to the IETF Secretariat from meeting attendance records or the IETF Datatracker ποΈ
4.1. Clarifying Detail π
Path 1 does not qualify people who register and attend face-to-face meetings remotely. That means it does not qualify remote attendees at IETF 106, because that meeting happened before anyone was thinking about cancelling meetings π ββοΈ
If the IESG prolongs this experiment for a second year, as Section 2 allows, the IESG must also clarify how Path 1 applies to IETF 111, 112, and 113 π§Ύ
Appendix A. Available Data πβ¨
okay bestie, this appendix is where the authors show their receipts π§Ύπ . They ran the criteria against August 2020 to see how many NomCom-qualified people there would be. The results are the Venn diagrams below (Figures 1 through 4). Two catches: the numbers are a little off from manual counts because the databases don't perfectly match π, and the timing wasn't the normal NomCom formation period. They also used the remote attendee lists for IETF 107 and 108, even though those weren't posted on the IETF website yet π.
The real drama is the data itself. It's messy π. You get duplicate entries, a person with two versions of their name, and "impersonal authors" like organisations. (The example here is "IAB", which qualifies under Path 3 π€‘. Meanwhile one actual volunteer somehow doesn't qualify π.) The takeaway is that auto-generated lists of eligible and qualified people always need a human to check them π«Ά.
The first two diagrams compare the new paths (2 and 3) against the meeting participation path (1) π¦. Figure 1 shows the raw numbers, and Figure 2 removes anyone disqualified under RFC 8713. The actual 2020 volunteer pool is in there too πΈ.
People eligible via Path 1,
3 of 5 meetings: 842
+----------------------+
| |
| 379 |
| +-----------+----------------+
| | | | People eligible
| | 332 | 1104 | via Path 2
| | | | or Path 3:
| +------+-----------+-------+ | 1541
| | | | | |
| | 29 | 102 | | |
| | | | | |
| | | | | |
+---+------+-----------+ | |
| | | |
| | 3 | |
| | | |
| +-------------------+--------+
| |
| 1 |
| |
+--------------------------+
2020 actual volunteers: 135
Figure 1: All Paths, before Disqualification
Qualified via Path 1,
3 of 5 meetings: 806
+----------------------+
| |
| 375 |
| +-----------+----------------+
| | | | Qualified
| | 300 | 1104 | via Path 2
| | | | or Path 3:
| +------+-----------+-------+ | 1509
| | | | | |
| | 29 | 102 | | |
| | | | | |
| | | | | |
+---+------+-----------+ | |
| | | |
| | 3 | |
| | | |
| +-------------------+--------+
| |
| 1 |
| |
+--------------------------+
2020 actual volunteers: 135
Figure 2: All Paths, after Disqualification
Figures 3 and 4 are about how the new paths (2 and 3) interact with each other, again before and after disqualification π. The discarded path through IESG and IAB service (Section 5) shows up as Path "I", and the data basically confirms it's a total dud π. It has no practical value π ββοΈ.
People eligible via Path 2
Total: 253
+----------------------+
| |
| 46 |
| +-----------+----------------+
| | | | People eligible
| | 176 | 1266 | via Path 3
| | | | Total:
| +------+-----------+-------+ | 1493
| | | | | |
| | 2 | 29 | | |
| | | | | |
| | | | | |
+---+------+-----------+ | |
| | | |
| | 22 | |
| | | |
| +-------------------+--------+
| |
| 2 |
| |
+--------------------------+
People eligible via Path "I": 55
Figure 3: New Paths, before Disqualification
Qualified via Path 2
Total: 234
+----------------------+
| |
| 45 |
| +-----------+----------------+
| | | | Qualified
| | 172 | 1264 | via Path 3
| | | | Total:
| +------+-----------+-------+ | 1463
| | | | | |
| | 1 | 16 | | |
| | | | | |
| | | | | |
+---+------+-----------+ | |
| | | |
| | 11 | |
| | | |
| +-------------------+--------+
| |
| 0 |
| |
+--------------------------+
Qualified via Path "I": 28
Figure 4: New Paths, after Disqualification
Acknowledgements π«Άπ
big thank-you energy to everyone who sent in useful comments π: Abdussalam Baryun, Alissa Cooper, Lars Eggert, Adrian Farrel, Bron Gondwana, Russ Housley, Christian Huitema, Ben Kaduk, John Klensin, Victor Kuarsingh, Warren Kumari, Barry Leiba, Eric Rescorla, Michael Richardson, Rich Salz, Ines Robles, Martin Thomson, and Magnus Westerlund β¨.
The data analysis was mainly done by Robert Sparks π. Carsten Bormann figured out how to draw the Venn diagrams in ASCII art π. Literal legends π.
Authors' Addresses π¦
Brian E. Carpenter
The University of Auckland
School of Computer Science
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Stephen Farrell
Trinity College Dublin
College Green
Dublin
Ireland
Email: stephen.farrell@cs.tcd.ie
π¦ where this page comes from
- ietf: rfc8989 2021-02
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms