summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5680.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5680.txt')
-rw-r--r--doc/rfc/rfc5680.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc5680.txt b/doc/rfc/rfc5680.txt
new file mode 100644
index 0000000..38b0dbc
--- /dev/null
+++ b/doc/rfc/rfc5680.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawkins Best Current Practice [Page 1]
+
+RFC 5680 NomCom Issues October 2009
+
+
+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.
+
+
+
+
+
+Dawkins Best Current Practice [Page 2]
+
+RFC 5680 NomCom Issues October 2009
+
+
+ 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.
+
+
+
+Dawkins Best Current Practice [Page 3]
+
+RFC 5680 NomCom Issues October 2009
+
+
+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.
+
+
+
+
+
+Dawkins Best Current Practice [Page 4]
+
+RFC 5680 NomCom Issues October 2009
+
+
+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.
+
+
+
+Dawkins Best Current Practice [Page 5]
+
+RFC 5680 NomCom Issues October 2009
+
+
+ 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.
+
+
+
+
+
+Dawkins Best Current Practice [Page 6]
+
+RFC 5680 NomCom Issues October 2009
+
+
+Author's Address
+
+ Spencer Dawkins (editor)
+ Huawei Technologies (USA)
+
+ Phone: +1 214 755 3870
+ EMail: spencer@wonderhamster.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawkins Best Current Practice [Page 7]
+