]> NYU

mallory.knodel@nyu.edu

Independent

me@tarakiyee.com

GENART gender This document extends the existing limit on nomcom representation by organization (, Section 4.17) so that not all voting members of the IETF Nominating Committee (nomcom) belong to the same gender. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The nomcom is, in every functional sense, a hiring committee: it solicits candidates, reviews their qualifications, interviews them, and selects who will fill the IETF's most senior leadership roles. This document extends 's limit on nomcom representation by organization to ensure no nomcom is ever composed of one gender. This is because the literature supports the claims that lack of gender diversity in hiring teams reinforces under representation of gender minorities in leadership positions and that lack of gender diversity in leadership perpetuates gender discrimination . This document does not address the nomcom's comportment once seated. A future revision might extend with conduct standards for non-discrimination, personal conflict of interest, and consistent candidate evaluation, drawing on precedent such as ICANN's Nominating Committee Code of Conduct .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. "Dominant gender" means the gender held by the majority of eligible nomcom volunteers in a given year. "Opt-in pool" means the pool defined in Section 4.1.

Gender Representation in the IETF Nomcom already limits nomcom representation by organization: Section 4.17 provides that no more than two voting volunteers may share the same primary affiliation. This safeguard addresses one axis of nomcom capture and imbalance, but it does not address gender. The IETF considers influence and weaknesses in nomcom selection in . The rationale for the two-per-organization limit, as documented in the "Oral Tradition" appendix of , is to avoid the appearance of improper bias in choosing IETF leadership: rather than defining precise rules for what counts as "affiliation," the IETF community relies on the honor and integrity of participants to make the limit work in practice. Likewise, gender diversity in IETF leadership should be considered a community strengthening exercise insofar as gender diversity has been shown to lead to more productivity, creativity and reinforces a culture of respect and value for all participants. If we consider the nomcom as a "team", it will itself benefit from having more gender diversity among its voting members. The nomcom itself conventionally asks candidates some form of the question, 'Describe your perspective on what diversity should mean for the IETF, and the degree to which existing IETF participation meets those expectations. What have you done in the past to encourage participation by those who might otherwise not have considered engaging with the IETF?' implying diversity is regarded in the IETF. To address gender representation in the IETF nomcom, at a minimum we can ensure that all voting members are not of the same gender. All attempts to ensure gender representation in the nomcom should include: a. increase participation in the community from women and non-binary individuals so that the eligible pool is more gender diverse. b. encourage eligible women and non-binary members of the community to accept selection to the nomcom. While the IETF does not routinely confirm the gender of volunteers, we have committed to improving gender diversity in the community by way of measuring it and identifying concrete steps to mitigate imbalance.

Suggested Remedy Section 4.17 of constrains nomcom composition by primary affiliation. This document adds a second composition constraint, applied at the same point in the process, in the form of a stratified selection over two pools, a mixed gender pool and an opt-in non-dominant genders pool.

Opt-in Pool An eligible volunteer MAY opt into a self-declared pool of volunteers who do not identify as members of the dominant gender (the "opt-in pool"). Membership in the opt-in pool is the only information disclosed. Volunteers in the opt-in pool may also opt into the mixed gender pool.

Reserved Seats Let n be the number of voting volunteer slots, p the size of the opt-in pool, and t the size of the mixed gender pool. The number of reserved seats r is determined as follows:

• If p is 0, no seats are reserved, and the IETF community MUST be notified that all n voting volunteers may share one gender that year for this reason.
• Otherwise, r = min(p, max(3, min(floor(n/2), floor(n * p / t)))).

Selection The r reserved seats MUST be selected first, by an selection over the published opt-in pool list. The remaining n - r seats MUST then be selected by a second selection over the general pool, excluding volunteers already selected. Both selections MAY use the same publicly announced seed material and be conducted as a single ceremony. The limit in Section 4.17 of continues to apply across both selections.

Rationale Each selection is an ordinary draw over a list published in advance, and no seat is conditional on information absent from that list, so every seat remains independently verifiable. A rule that skips candidates mid-draw does not have this property: it requires volunteers' genders to be known at selection time, which either breaks verifiability if that data is private or forces disclosure if it is not. The proportional cap ensures the mechanism never produces a composition the volunteer pool does not already support. It removes the variance of a flat draw rather than adding preference. The floor of three is deliberately super-proportional when the pool is skewed. The literature on tokenism finds that a lone minority member of a deliberative body carries a visibility burden and is treated as a category representative rather than as an individual , and that this shifts at around three members KonradKramerErkut2008. Stratified selection over declared strata is established practice in bodies constituted by lot , and compositional constraints are the norm rather than the exception among comparable nominating bodies: ICANN's Nominating Committee is constituted from designated seats . This section would update Section 4.17 of .

Privacy Considerations Serving on the nomcom is voluntary. Public disclosure of one's gender and pronouns in the IETF Datatracker should remain voluntary. Disclosure of one's gender during meeting registration for the purposes of tracking communty diversity should remain voluntary and non-public. Under Section 4, no volunteer is asked to state a gender, and no gender is inferred from pronouns used in mailing list discussion, recorded meetings, or the Datatracker. The only disclosure is opt-in pool membership. Because verifiability requires each pool to be published in advance, membership in the opt-in pool is public. Volunteers MUST be told this at the point of declaration. Gender data collected for community measurement, whether at meeting registration or in the Datatracker, MUST NOT be used to construct the opt-in pool.

Security Considerations Self-declaration is not verified. As with the affiliation limit in Section 4.17 of , the mechanism relies on the honour and integrity of participants rather than on precise rules.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. This memo provides information for the Internet community. Informative References The 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. The IETF Nominating Committee (NomCom) appoints candidates to several IETF leadership committees. RFC 8713 provides criteria for NomCom membership that attempt to ensure NomCom volunteers are members of the loosely defined IETF community, by requiring in-person attendance in three of the past five in-person meetings. In 2020 and 2021, the IETF had six consecutive fully online plenary meetings that drove rapid advancement in remote meeting technologies and procedures, including an experiment that included remote attendance for NomCom eligibility. This document updates RFC 8713 by defining a new set of eligibility criteria from first principles, with consideration to the increased salience of remote attendance. This document obsoletes RFCs 8788 and 8989. ICANN ICANN OECD

Acknowledgments Thanks to Martin Thomson and Suresh Krishnan for informed initial thoughts on bringing this idea to the community.