RFC 5680

RFC 5680 🎀 The Nominating Committee Process: Open Disclosure of Willing Nominees

Okay bestie, first the paperwork 📋✨. This one lives in the Network Working Group and it's written by S. Dawkins, Ed. from Huawei (USA). It came out in October 2009 and it's a Best Current Practice (that's BCP: 10 💅). It updates RFC 3777, so it's basically a plot twist for an earlier doc.

---

Abstract

The tea ☕: this doc updates RFC 3777, Section 3, Bullet 6, so a Nominating and Recall Committee can disclose the list of nominees who are willing to be considered for the positions it's responsible for filling 🌸.

Status of This Memo

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited 🦋.

Copyright Notice

Copyright (c) 2009 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 (http://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 BSD License 📜.

Table of Contents

1. Introduction ....................................................2
2. Current Rules on Confidentiality ................................2
3. Problems with Existing Rules ....................................3
4. Asking the Entire Community for Feedback ........................4
5. Disclosing a Nominee List .......................................4
6. Updated Text from RFC 3777 ......................................5
7. Security Considerations .........................................6
8. Acknowledgements ................................................6
9. Normative References ............................................6
Appendix A.  Concerns about Open Nominee Lists .....................6

---

1. Introduction ✨

Okay so the Internet Engineering Steering Group (IESG), the Internet Architecture Board (IAB), and the at-large IETF reps to the IETF Administrative Oversight Committee (IAOC) all get picked by a "Nominating and Recall Committee" (everyone just calls it the NomCom 🫶). [RFC3777] is the doc that explains how the NomCom gets selected, and the processes it follows when it picks candidates for these spots.

The NomCom is in charge of filling positions across the whole Internet Engineering Task Force (IETF) 🌈. It needs real info about the nominees being considered, but the confidentiality requirements in the current [RFC3777] make it hard for the NomCom to ask for that info 😭. This process change lets the NomCom openly ask the community for info about nominees who are willing to be considered. Iconic glow-up 💖.

2. Current Rules on Confidentiality 🔒

[RFC3777] is the latest in a series of revisions to the NomCom process. It describes how confidential NomCom deliberations are in Section 3, "General", bullet 6, which says:

All deliberations and supporting information that relates to specific nominees, candidates, and confirmed candidates are confidential. The nominating committee and confirming body members will be exposed to confidential information as a result of their deliberations, their interactions with those they consult, and from those who provide requested supporting information. All members and all other participants are expected to handle this information in a manner consistent with its sensitivity. It is consistent with this rule for current nominating committee members who have served on prior nominating committees to advise the current committee on deliberations and results of the prior committee, as necessary and appropriate.

3. Problems with Existing Rules 🧐

So there are two problems with how things work now 💀. Nominee lists aren't as confidential as [RFC3777] would have you believe, but they also aren't visible to the entire IETF community. Double whammy 🙈.

Since at least 1996, most NomComs have sent out a "short list" of nominees under consideration to a bunch of different audiences 📬. The target audiences change from year to year, but they've included members of specific leadership bodies, working group chairs in a specific area (for IESG positions), all working group chairs (for IAB and IAOC positions), and all document authors. Put together, the combined audience for all the short lists is hundreds of people. Recent NomComs have sent out about 1500 requests for short list feedback, which is a LOT of inboxes 📨.

This practice is unavoidable, honestly, because most NomCom members won't have personal experience with most nominees for most positions 🤷‍♀️. But it keeps getting challenged, because it's not explicitly allowed as an exception to the blanket confidentiality requirement. Not me getting called out for something that's basically necessary 💅.

To try to keep up the required level of confidentiality, past NomComs have also added "ringers" (as "padding") to the short list. Ringers are nominees who are NOT under active consideration for a specific position 🎭. Since anyone who sees the short list doesn't know who the ringers are, conscientious IETF participants also give feedback on nominees who have already declined. That's a total waste of precious IETF-participant cycles 😤, and there are widespread reports that strict confidentiality about which candidates are "real" and which are "padding" isn't really maintained in practice. The padding is leaking, bestie 🫠.

Even when confidentiality about the padding is maintained, the community knows that some nominees on the short list aren't under active consideration. Sometimes people guess wrong that an actual nominee is part of the padding, and then they don't give the NomCom the feedback it needed about a nominee who was actively being considered 💔.

We also note that disclosing a "short list" penalizes IETF participants who aren't members of one of the target audiences being surveyed 🥺. Apart from the incumbent(s), they have no way of knowing who is being considered, and they have very little incentive to give feedback to the NomCom about people who might not even be nominees.

8. Acknowledgements 🫶

Okay, big thank-yous to the editor's crew of brilliant humans who gave useful observations and guidance on earlier versions of this doc: Fred Baker, Ross Callon, Brian Carpenter, Leslie Daigle, Lars Eggert, Robert Elz, Joel Halpern, Bernie Hoeneisen, John Klensin, Barry Leiba, Danny McPherson, S. Moonesamy, and Thomas Narten. You all are literally the reason this slaps 💖

The editor also thanks the IETF plenary meeting participants who gave feedback on earlier versions. Y'all showed up and made it better, and that's so iconic 🌸

9. Normative References 📚

Here's the reference you need to read this one properly 🤓

[RFC3777]  Galvin, J., "IAB and IESG Selection, Confirmation, and
           Recall Process: Operation of the Nominating and Recall
           Committees", BCP 10, RFC 3777, June 2004.

Appendix A. Concerns about Open Nominee Lists 🦋

Okay so this appendix is where the document gets real and admits that some people had worries about publishing open nominee lists in earlier NomCom discussions. Huge thanks to Leslie Daigle for handing this set of concerns to the document editor. Being upfront about the tricky stuff is so mature of them, no cap 🙌

One concern is that nominees who would be happy to be considered when the nominee list is not disclosed might not feel the same way once it is disclosed. ngl this could come from cultural norms, from personal pride, or from being scared of retribution, like if a nominee got considered as a replacement for the nominee's own managing Area Director. The retribution worry usually pops up in an IESG context, so that's where you'll see it most 😬

Another concern is that publishing the nominee list publicly would lead to "lobbying", meaning public statements supporting nominees on the IETF mailing list and stuff like that. Totally understandable to flag it, bestie 💅

Author's Address 💌

Spencer Dawkins (editor)
Huawei Technologies (USA)

Phone: +1 214 755 3870
EMail: spencer@wonderhamster.org