Skip to main content

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)
statement-iesg-second-report-on-the-rfc-8989-experiment-20230315-00

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:

  1. Path 1: attendance A person has attended three out of the last five IETF meetings, including meetings held entirely online.
  2. Path 2: WG leadership A person has been a Working Group Chair or Secretary within the past three years.
  3. 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