Additional Criteria for Nominating Committee Eligibility
RFC 8989
| Document | Type |
RFC - Experimental
(February 2021; No errata)
Was draft-carpenter-eligibility-expand (individual)
|
|
|---|---|---|---|
| Authors | Brian Carpenter , Stephen Farrell | ||
| Last updated | 2021-02-05 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text html xml pdf htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Bron Gondwana | ||
| Shepherd write-up | Show (last changed 2020-12-07) | ||
| IESG | IESG state | RFC 8989 (Experimental) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Alissa Cooper | ||
| Send notices to | (None) | ||
| IANA | IANA review state | IANA OK - No Actions Needed | |
| IANA action state | No IANA Actions | ||
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 8989 Univ. of Auckland
Category: Experimental S. Farrell
ISSN: 2070-1721 Trinity College Dublin
February 2021
Additional Criteria for Nominating Committee Eligibility
Abstract
This document defines a process experiment under RFC 3933 that
temporarily updates the criteria for qualifying volunteers to
participate in the IETF Nominating Committee. It therefore also
updates the criteria for qualifying signatories to a community recall
petition. The purpose is to make the criteria more flexible in view
of increasing remote participation in the IETF and a reduction in
face-to-face meetings. The experiment is of fixed duration and will
apply to one, or at most two, consecutive Nominating Committee
cycles, starting in 2021. This document temporarily varies the rules
in RFC 8713.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. 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). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see 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/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) 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without 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
According to [RFC8713], the IETF Nominating Committee (NomCom) is
populated from a pool of volunteers with a specified record of
attendance at IETF plenary meetings, which were assumed to be face-
to-face meetings when that document was approved. In view of the
cancellation of the IETF 107, 108, 109, and 110 face-to-face
meetings; the risk of future cancellations; the probability of less-
frequent face-to-face meetings in the future in support of
sustainability; and a general increase in remote participation, this
document defines a process experiment [RFC3933] of fixed duration
(described in Section 2) to use modified and additional criteria to
qualify volunteers.
During this experiment, the eligibility criteria for signing recall
petitions -- which [RFC8713] defines to be the same as those for
NomCom eligibility -- are consequently also modified as described in
this document. This 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
that the current criteria are in any case seriously perturbed for at
least 2 years. The experiment therefore needs to start as soon as
possible. However, the experiment did not apply to the selection of
the 2020-2021 NomCom, which was performed 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 will maintain NomCom confidentiality) and publish a report
on the results of the experiment. Points to be considered are
whether the experiment has produced a sufficiently large and diverse
pool of individuals, whether enough of those individuals have
volunteered to produce a representative NomCom with good knowledge of
the IETF, and whether all the goals in Section 3 have been met. If
possible, a comparison with results from the previous procedure
(i.e., RFC 8713) should be made.
The IESG must then also begin a community discussion of whether to:
1. Amend [RFC8713] in time for the 2022-2023 NomCom cycle; or
2. Prolong the current experiment for a second and final year with
additional clarifications specific to the 2022-2023 cycle; or
3. Run a different experiment for the next nominating cycle; or
4. Revert to [RFC8713].
The IESG will announce the results of the consensus determination of
this discussion in good time for the 2022-2023 NomCom cycle to
commence.
In the event of prolongation of this experiment 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.
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 is 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 (thus extending the issue to many, perhaps 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 that 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 will be IETF 106, 107,
108, 109, and 110. Attendance is as determined by the record
keeping of the Secretariat for in-person meetings and is 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 is, it does not qualify remote attendees at
IETF 106, because that meeting took place prior to any question of
cancelling meetings.
If the IESG prolongs this experiment for a second year, as allowed by
Section 2, the IESG must also clarify how Path 1 applies to IETF 111,
112, and 113.
5. Omitted Criteria
During community discussions of this document, certain criteria were
rejected as not truly indicating effective IETF participation or as
being unlikely to significantly expand the volunteer pool. These
included authorship of individual or Working-Group-adopted Internet-
Drafts, sending email to IETF lists, reviewing drafts, acting as a
BOF Chair, and acting in an external role for the IETF (liaisons,
etc.).
One path -- service in the IESG or IAB within the last 5 years -- was
found to have no benefit, since historical data show that such people
always appear to be qualified by another path.
Since the criteria must be measurable by the Secretariat, no
qualitative evaluation of an individual's contributions is
considered.
6. IANA Considerations
This document has no IANA actions.
7. Security Considerations
This document should not affect the security of the Internet.
8. Normative References
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process
Experiments", BCP 93, RFC 3933, DOI 10.17487/RFC3933,
November 2004, <https://www.rfc-editor.org/info/rfc3933>.
[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>.
[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>.
Appendix A. Available Data
An analysis of how some of the above criteria would affect the number
of NomCom-qualified participants if applied in August 2020 has been
performed. The results are presented below in Venn diagrams as
Figures 1 through 4. Note that the numbers shown differ slightly
from manual counts due to database mismatches, and the results were
not derived at the normal time of the year for NomCom formation. The
lists of remote attendees for IETF 107 and 108 were used, although
not yet available on the IETF web site.
A specific difficulty is that the databases involved inevitably
contain a few inconsistencies, such as duplicate entries, differing
versions of a person's name, and impersonal authors. (For example,
"IAB" qualifies under Path 3, and one actual volunteer artificially
appears not to qualify.) This underlines that automatically
generated lists of eligible and qualified people will always require
manual checking.
The first two diagrams illustrate how the new paths (2 and 3) affect
eligibility numbers compared to the meeting participation path (1).
Figure 1 gives the raw numbers, and Figure 2 removes those
disqualified according to RFC 8713. The actual 2020 volunteer pool
is shown 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 illustrate how the new paths (2 and 3) interact with
each other, also before and after disqualifications. The discarded
path via IESG and IAB service (Section 5) is also shown, as Path "I".
The data clearly show that Path "I" 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
Useful comments were received from 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
showed how to represent Venn diagrams in ASCII art.
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