The Nominating Committee Process: Open Disclosure of Willing Nominees
Allows the IETF Nominating Committee to disclose the list of volunteers willing to serve in leadership positions.
Dawkins, S., Ed., "The Nominating Committee Process: Open Disclosure of Willing Nominees", RFC 5680, DOI 10.17487/RFC5680, October 2009, <https://www.rfc-editor.org/info/rfc5680>.
@misc{rfc5680,
series = {Request for Comments},
number = 5680,
howpublished = {RFC 5680},
publisher = {RFC Editor},
doi = {10.17487/RFC5680},
url = {https://www.rfc-editor.org/info/rfc5680},
author = {S. Dawkins},
title = {{The Nominating Committee Process: Open Disclosure of Willing Nominees}},
pagetotal = 7,
year = 2009,
month = oct,
} RFC text
Contents
Network Working Group S. Dawkins, Ed. Request for Comments: 5680 Huawei (USA) BCP: 10 October 2009 Updates: 3777 Category: Best Current Practice The Nominating Committee Process: Open Disclosure of Willing Nominees Abstract This document updates RFC 3777, Section 3, Bullet 6 to allow a Nominating and Recall Committee to disclose the list of nominees who are willing to be considered to serve in positions the committee is 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 The Internet Engineering Steering Group (IESG), the Internet Architecture Board (IAB), and at-large IETF representatives to the IETF Administrative Oversight Committee (IAOC) are selected by a "Nominating and Recall Committee" (universally abbreviated as "NomCom"). [RFC3777] defines how the NomCom is selected, and the processes it follows as it selects candidates for these positions. The NomCom is responsible for filling positions across the breadth of the Internet Engineering Task Force (IETF). The NomCom needs relevant information about nominees being considered for these positions, but current [RFC3777] requirements for confidentiality limit the ability of the NomCom to solicit that information. The process change described in this document allows the NomCom to openly solicit information about nominees who are willing to be considered. 2. Current Rules on Confidentiality [RFC3777] is the latest in a series of revisions to the NomCom process, and it describes the confidential nature of NomCom deliberations in Section 3, "General", bullet 6, which states: 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 There are two problems with existing practice -- nominee lists aren't as confidential as [RFC3777] would lead the reader to believe, but they aren't visible to the entire IETF community, either. Since at least 1996, most NomComs have sent out a "short list" of nominees under consideration to a variety of audiences. The target audiences differ from year to year, but have 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. The combined target audience for all short lists includes hundreds of recipients -- recent NomComs have sent out about 1500 requests for short list feedback. This practice is unavoidable, because most NomCom members will not have personal experience with most nominees for most positions, but it is periodically challenged because it's not explicitly allowed as an exception to the blanket requirement for confidentiality. In an attempt to maintain the required level of confidentiality, past NomComs have also included "ringers" (as "padding") on the short list -- nominees who are NOT under active consideration for a specific position. Since anyone who sees the short list does not know who the ringers are, conscientious IETF participants also provide feedback on nominees who have already declined. This is a waste of precious IETF-participant cycles, and there are widespread reports that strict confidentiality about which candidates are "real", and which are included as "padding", is not successfully maintained in practice. Even if confidentiality about padding is maintained, the community is aware that some nominees on the short list aren't under active consideration. In some cases, people have guessed incorrectly that an actual nominee is part of the padding, and didn't provide needed feedback to the NomCom about a nominee who was actively being considered. We also note that the practice of disclosing a "short list" penalizes IETF participants who aren't members of one of the target audiences being surveyed -- they have no way of knowing who is being considered, except for incumbent(s), and have little incentive to provide feedback to the NomCom on individuals who might not even be nominees. 4. Asking the Entire Community for Feedback NomComs are not required to ask for community input at all, but at the current IETF scale, many NomComs do request community input, because members do not have personal experience with all nominees for all positions under review. We assume that asking the larger community for feedback about these nominees is preferable to NomCom members without personal experience simply deferring to the members of the NomCom who do have personal experience with specific nominees. We assume that asking for feedback from the entire community is preferable to asking for feedback from large segments of the community, while keeping the rest of the community "in the dark". 5. Disclosing a Nominee List In proposing that a nominee list be disclosed as part of the NomCom's request for feedback from the community, we considered three possibilities: 1. Asking for feedback on all nominees, whether or not they are willing to be considered. 2. Asking for feedback on all nominees who are willing to be considered. 3. Asking for feedback on the nominees that the NomCom is seriously considering (the "short list"). Asking for feedback on nominees who are not willing to be considered is a waste of precious IETF-participant cycles, and may make it less likely that the NomCom would receive feedback on some nominees who ARE willing to be considered. Asking for feedback on all nominees who are willing to be considered allows the community to point out specific strengths and weaknesses of all willing nominees, and this feedback should be useful to the NomCom in deciding which nominees to seriously consider. It also allows the NomCom to receive feedback on nominees who might not appear on a "short list" initially, in the event that a strong nominee is suddenly unwilling or unable to serve. We also note that the list of willing nominees will include incumbents who are willing to be considered for an additional term. 6. Updated Text from RFC 3777 At the end of the three paragraphs in [RFC3777], Section 3, "General", bullet 6, which are currently: 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. add the following paragraphs: The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential. The NomCom may disclose a list of names of nominees who are willing to be considered for positions under review to the community, in order to obtain feedback from the community on these nominees. The list of nominees disclosed for a specific position should contain only the names of nominees who are willing to be considered for the position under review. The NomCom may choose not to include some names in the disclosed list, at their discretion. The NomCom may disclose an updated list, at their discretion. For example, the NomCom might disclose an updated list if the NomCom identifies errors/omissions in a previously disclosed version of the disclosed list, or if the NomCom finds it necessary to call for additional nominees, and these nominees indicate a willingness to be considered before the NomCom has completed its deliberations. Nominees may choose to ask people to provide feedback to the NomCom, but should not encourage any public statements of support. NomComs should consider nominee-encouraged lobbying and campaigning to be unacceptable behavior. IETF community members are encouraged to provide feedback on nominees to the NomCom, but should not post statements of support/ non-support for nominees in any public forum. 7. Security Considerations This specification describes issues with the current IETF Nominating Committee process ([RFC3777]) and proposes an update to allow the NomCom to solicit feedback from the entire community on nominees under consideration. No security considerations apply. 8. Acknowledgements The editor thanks the following folks who have provided useful observations and guidance on previous versions of this document: 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. The editor also thanks IETF plenary meeting participants who have provided useful feedback on previous versions of this document. 9. Normative References [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 This section acknowledges possible concerns about disclosing open nominee lists in previous NomCom-related discussions. Thanks to Leslie Daigle for providing this set of concerns to the document editor. One concern is that nominees who are willing to be considered if the nominee list is not disclosed would not be willing to be considered if the nominee list is disclosed. This reluctance might be cultural, the result of personal pride, or the result of the fear of retribution for a nominee being considered as a replacement for the nominee's managing Area Director (this concern is usually raised in an IESG context). Another concern is that publishing the nominee list publicly would lead to "lobbying", public statements supporting nominees on the IETF mailing list, etc. Author's Address Spencer Dawkins (editor) Huawei Technologies (USA) Phone: +1 214 755 3870 EMail: spencer@wonderhamster.org
AI ELI5
On this page
§1Why Transparency Helps
The Nominating and Recall Committee (NomCom) selects leaders for the Internet Engineering Steering Group (IESG), the Internet Architecture Board (IAB), and IETF administrative positions. RFC 3777 requires that NomCom deliberations and nominee information remain confidential.
However, NomCom members do not personally know all the candidates for every position, so they need feedback from the broader IETF community. Past NomComs quietly sent shortlists to hundreds of selected experts—working group chairs, area directors, document authors—but this practice violated the strict confidentiality rule and excluded many community members who could have provided useful input.
A committee needs to know what people think of volunteer leaders. They used to secretly ask a few experts, but that wasn't fair to everyone else and was against the rules anyway.
§2The Old Problem and New Solution
The old practice had two problems. First, it was not official, so conscientious committee members worried about breaking confidentiality rules. Second, because some nominees on the shortlist were 'padding' (not real candidates), the community wasted time giving feedback on people who had already declined. Also, the secrecy meant some IETF participants had no way to know who was being considered and could not offer relevant input.
This RFC changes the rule explicitly: NomCom may now publish the list of willing nominees—people who have said they are open to being considered. By disclosing only willing nominees and not the real vs. padding distinction, NomCom can solicit feedback from the entire community without wasting effort on people who declined and without needing to secretly break confidentiality rules.
Instead of secretly asking a few people, they can now openly say 'here are the people who said yes to being considered' and ask everyone what they think. That's fair and wastes less time.
§3How Disclosure Works
NomCom discloses the list of willing nominees for each position. Committee members can ask the entire IETF community for feedback on those candidates. The published list contains only names of willing nominees; it does not identify who is on the shortlist for serious consideration, preserving some confidentiality of deliberations.
NomCom may choose which willing nominees to include in the disclosed list and may update the list if the committee identifies errors or receives new willing nominees partway through the process. Nominees themselves should not lobby publicly for support, and the community should provide feedback to NomCom rather than making public endorsements or criticisms.
NomCom says 'here are the volunteers we're looking at' and asks everyone to comment. They don't say who their top picks are. People should tell the committee privately what they think, not argue on the mailing list.
§4Status and Context
This document is a Best Current Practice and updates RFC 3777, the definitive NomCom process document. The change reflects what leading NomComs were already doing unofficially, making the practice explicit and adding structure to prevent abuse. The RFC acknowledges concerns that nominees might be reluctant if their names are public or that published lists might invite unwanted lobbying, but concludes that broad, transparent feedback outweighs these risks.
RFC 7437 later obsoletes this document with further refinements to the NomCom process.
This is official guidance, and a newer RFC later updated it with more improvements.