Second Report on the RFC 8989 Experiment
statement-iesg-second-report-on-the-rfc-8989-experiment-20230315-00
Document | Type | Inactive IESG Statement | |
---|---|---|---|
Title | Second Report on the RFC 8989 Experiment | ||
Published | 2023-03-15 | ||
Metadata last updated | 2025-08-26 | ||
State | Inactive | ||
Send notices to | (None) |
Second Report on the RFC 8989 Experiment
15 Mar 2023
This is a report on the results of the experiment to temporarily make the criteria for qualifying volunteers to participate in the IETF Nominating Committee (NomCom) more flexible in view of increasing remote participation in the IETF and a reduction in face-to-face meetings.
IESG Note: This report was written by the 2022-23 NomCom chair, Rich Salz. The IESG thanks Rich for writing this report; we are publishing it as required by RFC 8989 Section 2.
For background, please see last year's report. As a reminder, since February 2021, there have been three paths for someone to qualify to be a voting member of NomCom:
- Path 1: attendance A person has attended three out of the last five IETF meetings, including meetings held entirely online.
- Path 2: WG leadership A person has been a Working Group Chair or Secretary within the past three years.
- Path 3: authorship A person has been a listed author or editor of at least two IETF Stream RFCs (or IESG-approved Internet-Drafts in the RFC Editor queue) within the past five years.
This year, there were 266 qualified volunteers (or pool) for NomCom. Last year, the pool was 116; this year's number is a new high-water mark in the history of NomCom selection. It is unclear why the pool size was so large this year1, but looking at the breakdown it is clear that the alternate paths did not contribute significantly:
2022-2023 IETF Nominating Committee volunteers by qualification path
Path | Count |
---|---|
Just Path 1 | 122 |
Path 1 and Path 2 (not Path 3) | 34 |
Path 1 and Path 3 (not Path 2) | 42 |
Path 1 and Path 2 and Path 3 | 60 |
Just Path 2 | 0 |
Path 2 and Path 3 (not Path 1) | 1 |
Just Path 3 | 7 |
It isn't surprising that none of the volunteers were qualified just with Path 2; Working Group (WG) leadership is hard to accomplish without attending meetings and doing it just via email. Path 2 could be removed without affecting the pool, but the RFC 8989-bis draft includes it, if only because there wasn't sufficient analysis to justify its removal.
Within the overall IETF community, there could have been 1438 qualified volunteers or just under 5.5 times as many who actually volunteered. The breakdown of the qualification paths is as follows:
Potential 2022-2023 IETF Nominating Committee volunteers by qualification path
Path | Count |
---|---|
Just Path 1 | 767 |
Path 1 and Path 2 (not Path 3) | 78 |
Path 1 and Path 3 (not Path 2) | 161 |
Path 1 and Path 2 and Path 3 | 121 |
Just Path 2 | 14 |
Path 2 and Path 3 (not Path 1) | 19 |
Just Path 3 | 278 |
Many more people qualified under Path 2 or Path 3, but essentially none of them volunteered. At any rate, nearly 80% of the potential volunteer pool qualified under at least Path 1.
NomCom Pool Diversity
Given the minuscule increase of Path 2 and Path 3 in the volunteer pool, it is not surprising that this year's committee saw little change. For the ten voting volunteers in this year's committee, all qualified under Path 1, three would have qualified under Path 2, three would have qualified under Path 3 and two would have qualified under either Path 2 or Path 3 (that is, they met the criteria for both paths).
If the IETF community believes that potential Path 2 and Path 3 volunteers should be encouraged to volunteer for future NomComs, it might be worthwhile to find out why none of them did this year.
Goal Accomplishment
The overall conclusion is that by expanding Path 1 to include remote attendance, and making it possible to determine qualification automatically, all of the goals in Section 3 of RFC 8989 were met. Details can be found in the Appendix.
Discussion
Based on the success of the experiment for the past two years, the IETF is finalizing issuance of a new RFC that codifies these methods into a BCP RFC that updates