Additional Criteria for Nominating Committee EligibilityThe University of AucklandSchool of Computer SciencePB 92019Auckland1142New Zealandbrian.e.carpenter@gmail.comTrinity College DublinCollege GreenDublinIrelandstephen.farrell@cs.tcd.ieThis 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
.
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
() 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
. Introduction
. Term and Evaluation of the Experiment
. Goals
. Criteria
. Clarifying Detail
. Omitted Criteria
. IANA Considerations
. Security Considerations
. Normative References
. Available Data
Acknowledgements
Authors' Addresses
IntroductionAccording to , 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
of fixed duration (described in ) to use modified and
additional criteria to qualify volunteers.
During this experiment, the eligibility criteria for signing recall
petitions -- which
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.
Term and Evaluation of the ExperimentThe 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 .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
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:
Amend 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 .
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.GoalsThe 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.
CriteriaThis experiment specifies several alternative paths to qualification,
replacing the single criterion in .
Any one of the paths is sufficient, unless the person is otherwise disqualified
under :
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 , modified
as per .
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.
Clarifying DetailPath 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 ,
the IESG must also clarify how Path 1 applies to IETF 111, 112, and 113.Omitted CriteriaDuring 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.IANA ConsiderationsThis document has no IANA actions.Security ConsiderationsThis document should not affect the security of the Internet.Normative ReferencesA Model for IETF Process ExperimentsThe IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight. This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall CommitteesThe process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.This document obsoletes RFC 7437 and RFC 8318.Eligibility for the 2020-2021 Nominating CommitteeThe 2020-2021 Nominating Committee (NomCom) is to be formed between the IETF 107 and IETF 108 meetings, and the issue of eligibility of who can serve on that NomCom needs clarification. This document provides a one-time interpretation of the eligibility rules that is required for the exceptional situation of the cancellation of the in-person IETF 107 meeting. This document only affects the seating of the 2020-2021 NomCom and any rules or processes that relate to NomCom eligibility before IETF 108; it does not set a precedent to be applied in the future.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 through .
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).
gives the raw numbers, and
removes
those disqualified according to RFC 8713. The actual
2020 volunteer pool is shown too.All Paths, before Disqualification
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
All Paths, after 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
Figures and
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 () is also shown, as Path "I".
The data clearly show that Path "I" has no practical value.New Paths, before Disqualification
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
New Paths, after 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
AcknowledgementsUseful comments were received from ,
, , ,
, , , , , , ,
, , , , , ,
and .The data analysis was mainly done by . showed how
to represent Venn diagrams in ASCII art.Authors' AddressesThe University of AucklandSchool of Computer SciencePB 92019Auckland1142New Zealandbrian.e.carpenter@gmail.comTrinity College DublinCollege GreenDublinIrelandstephen.farrell@cs.tcd.ie