Internet-Draft | Additional Eligibility Criteria | November 2020 |
Carpenter & Farrell | Expires 5 May 2021 | [Page] |
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, Nominating Committee cycles. This document temporarily varies the rules in RFC 8713.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the ad hoc mailing list (eligibility-discuss@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/eligibility-discuss/.¶
Source for this draft can be found at https://github.com/sftcd/elig.¶
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 5 May 2021.¶
Copyright (c) 2020 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.¶
According to [RFC8713], the IETF Nominating Committee is populated from a pool of volunteers with a specified record of attendance at IETF plenary meetings, assumed when that document was approved to be face-to-face meetings. 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 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.¶
The cancellation of the in-person IETF 107 through 110 meetings means that the current criteria are in any case seriously perturbed for the next two years. The experiment therefore needs to start as soon as possible. However, the experiment did not apply to the selection of the 2020-2021 Nominating Committee, which was performed according to [RFC8788].¶
The experiment will initially cover the IETF Nominating Committee cycle starting in 2021. As soon as the 2021-2022 Nominating Committee is seated, the IESG must consult the current and previous Nominating Committee chairs 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, and whether enough of those individuals have volunteered to produce a representative Nominating Committee with good knowledge of the IETF. 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:¶
The IESG will determine and announce the consensus of this discussion in good time for the 2022 Nominating Committee cycle to commence.¶
The goals of the modified and additional criteria are as follows:¶
There will be 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 counts as attendance. For the 2021-2022 Nominating Committee, 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/or based on being a registered person who logged in for at least one session of an online IETF meeting.¶
Notes:¶
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, so the rules of [RFC8713] apply.¶
If the IESG prolongs this experiment for a second year, as allowed by Section 2, the IESG will also clarify how Path 1 applies to IETF 111, 112 and 113.¶
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.¶
This document makes no request of IANA.¶
This document should not affect the security of the Internet.¶
Useful comments were received from Alissa Cooper, Lars Eggert, Adrian Farrel, Bron Gondwana, John Klensin, Victor Kuarsingh, Warren Kumari, Barry Leiba, Eric Rescorla, Michael Richardson, Rich Salz, and Martin Thomson.¶
The data analysis was mainly done by Robert Sparks. Carsten Bormann showed how to represent Venn diagrams in ASCII art.¶
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 Figure 1 to Figure 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 remote attendee lists 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.¶
Figure 3 and Figure 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 is also shown, as path "I".¶
This section is to be removed before publishing as an RFC.¶