doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc5633.txt b/doc/rfc/rfc5633.txt
new file mode 100644
index 0000000..b0c5434
--- /dev/null
+++ b/doc/rfc/rfc5633.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                    S. Dawkins, Ed.
+Request for Comments: 5633                                  Huawei (USA)
+BCP: 10                                                      August 2009
+Updates: 3777
+Category: Best Current Practice
+
+
+                     Nominating Committee Process:
+ Earlier Announcement of Open Positions and Solicitation of Volunteers
+
+Abstract
+   This document updates RFC 3777, Section 4, Bullet 13 to allow
+   announcement of open positions and solicitation of volunteers to be
+   issued before a Nominating and Recall Committee Chair has been named
+   by the Internet Society President.
+
+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 in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Background ......................................................2
+   3. Discussion ......................................................3
+   4. Updated Text from RFC 3777 ......................................4
+   5. Possible Topics for Later Discussion ............................4
+   6. Security Considerations .........................................5
+   7. Acknowledgements ................................................5
+   8. References ......................................................5
+      8.1. Normative References .......................................5
+      8.2. Informative References .....................................5
+
+
+
+
+
+
+Dawkins                  Best Current Practice                  [Page 1]
+
+RFC 5633                     NomCom Issues                   August 2009
+
+
+1.  Introduction
+
+   The Internet Engineering Steering Group (IESG), the Internet
+   Architecture Board (IAB), and the 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.
+
+   This document describes an issue with [RFC3777] that causes an
+   avoidable delay in the NomCom process and specifies a normative
+   update to resolve the issue.
+
+2.  Background
+
+   [RFC3777] is the latest in a series of revisions to the NomCom
+   process.  [RFC3777] has been updated once since 2004, but the update
+   ([RFC5078]) did not change normative text (it replaced a sample
+   timeline).
+
+   [RFC5078] identifies a serial delay in the process described in
+   [RFC3777], in Section 4 ("Nominating Committee Selection"), Bullet
+   13, which states:
+
+      The Chair obtains the list of IESG and IAB positions to be
+      reviewed and announces it along with a solicitation for names of
+      volunteers from the IETF community willing to serve on the
+      nominating committee.
+
+      The solicitation must permit the community at least 30 days during
+      which they may choose to volunteer to be selected for the
+      nominating committee.
+
+      The list of open positions is published with the solicitation to
+      facilitate community members choosing between volunteering for an
+      open position and volunteering for the nominating committee.
+
+   The result is that the Incoming NomCom Chair is the only person who
+   can announce the list of open positions and solicitation for names of
+   volunteers, a process that requires 30 days for public solicitation.
+
+   Since this is the first step in organizing the NomCom, delays in
+   selecting the Incoming NomCom Chair translate directly into delays in
+   issuing the solicitation and organizing the NomCom.
+
+   This proved problematic in practice in 2008-2009, when Joel Halpern
+   was named NomCom Chair less than 30 days prior to the second IETF
+   meeting of the year.  If the 30-day solicitation had already taken
+
+
+
+Dawkins                  Best Current Practice                  [Page 2]
+
+RFC 5633                     NomCom Issues                   August 2009
+
+
+   place, the NomCom could have conducted face-to-face interviews at the
+   second IETF meeting, but since the required 30-day solicitation
+   didn't start until Joel was named, Joel was unable to assemble his
+   NomCom before the second IETF meeting, and the NomCom had to carry
+   out these interviews using email and conference calls.
+
+   It is desirable to allow the solicitation and announcement to take
+   place in a timely manner so that when an Incoming NomCom Chair is
+   named, the NomCom Chair can immediately begin executing the NomCom
+   process.
+
+3.  Discussion
+
+   This document proposes that four weeks after the first IETF meeting
+   each year, the Internet Society President will either announce an
+   Incoming NomCom Chair, or will direct the IETF Executive Director to
+   issue the announcement of open positions and the solicitation for
+   names of volunteers on behalf of the Incoming NomCom Chair.  This
+   allows the search for the Incoming NomCom Chair and volunteers to
+   proceed in parallel.
+
+   This process change covers only the announcement of open positions
+   and solicitation for names of volunteers.  This process change does
+   not allow the NomCom process to move to completion without an
+   Incoming NomCom Chair; it is only to ensure that the Incoming NomCom
+   Chair can begin executing the NomCom process without an avoidable
+   delay and can use face-to-face time at the second IETF meeting
+   effectively for this purpose.
+
+   During discussions in the IETF 74 timeframe, it was suggested that we
+   also allow the Secretariat to perform other clerical tasks that
+   aren't called out specifically in the NomCom process but that clearly
+   do not require NomCom Chair judgment.  This document does not provide
+   guidance about specific clerical tasks that would be appropriate for
+   the Secretariat to carry out.  Instead, either the Incoming NomCom
+   Chair (if one has been selected) or the Outgoing NomCom Chair (if the
+   search for an Incoming NomCom Chair is still underway) may request
+   the Secretariat to perform these tasks, with appropriate notification
+   to the community.
+
+
+
+
+
+
+
+
+
+
+
+
+Dawkins                  Best Current Practice                  [Page 3]
+
+RFC 5633                     NomCom Issues                   August 2009
+
+
+4.  Updated Text from RFC 3777
+
+   [RFC3777], Section 4 ("Nominating Committee Selection"), Bullet 13,
+   states:
+
+      The Chair obtains the list of IESG and IAB positions to be
+      reviewed and announces it along with a solicitation for names of
+      volunteers from the IETF community willing to serve on the
+      nominating committee.
+
+   This text is replaced with the following text:
+
+      The Chair (or the IETF Executive Director, if no Chair has been
+      named four weeks after the first IETF meeting of the year) obtains
+      the list of positions to be reviewed and announces it along with a
+      solicitation for names of volunteers from the IETF community
+      willing to serve on the nominating committee.
+
+      If the IETF Executive Director issues the solicitation for
+      volunteers, the IETF Executive Director must also collect
+      responses to the solicitation and provide the names of volunteers
+      to the Incoming NomCom Chair when the Incoming NomCom Chair is
+      named.
+
+      At the Chair's request, the IETF Secretariat may perform other
+      clerical support tasks, as long as the task being performed does
+      not require NomCom Chair judgment, in the NomCom Chair's opinion,
+      and as long as the community is appropriately notified that this
+      request is being made.  This request may come from the Incoming
+      NomCom Chair (if one has been selected for this NomCom cycle) or
+      the Outgoing NomCom Chair (if the search for an Incoming NomCom
+      Chair is still underway).
+
+   Note: This text no longer specifies the list of bodies that NomCom
+   reviews, rather than adding IAOC to the list of bodies in the text,
+   so that this text need not change further when NomCom
+   responsibilities change.
+
+5.  Possible Topics for Later Discussion
+
+   This section contains topics that came up during discussion of this
+   document but were ruled out of scope, because the goal for this
+   document was incremental improvement, and these topics were more than
+   incremental changes.  They may be discussed further, or not, but
+   we're less likely to forget them completely if we write them down.
+
+
+
+
+
+
+Dawkins                  Best Current Practice                  [Page 4]
+
+RFC 5633                     NomCom Issues                   August 2009
+
+
+   [RFC3777] tightly couples the announcement of open positions and call
+   for volunteers, and this document didn't try to unravel these two
+   separate actions.  We had a request during discussion to separate
+   them, so that a NomCom could consider the management structure of the
+   IETF and the position descriptions that the leadership bodies
+   provide, before announcing the positions being reviewed.
+
+6.  Security Considerations
+
+   This specification describes issues with the current IETF Nominating
+   Committee process [RFC3777] and proposes an update to avoid a serial
+   delay.  No security considerations apply.
+
+7.  Acknowledgements
+
+   The editor thanks the following folks who have provided useful
+   observations and guidance on previous versions of this document:
+   Scott Bradner (who suggested that the IETF Secretariat have this
+   responsibility), Brian Carpenter, Ralph Droms, Jim Galvin, Joel
+   Halpern, Danny McPherson, and Pekka Savola.
+
+   The editor also thanks the Wednesday evening plenary session
+   participants during IETF 74 who provided useful feedback on previous
+   versions of this document [w74plen].
+
+8.  References
+
+8.1.  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.
+
+8.2.  Informative References
+
+   [RFC5078]  Dawkins, S., "IAB and IESG Selection, Confirmation, and
+              Recall Process: Revision of the Nominating and Recall
+              Committees Timeline", RFC 5078, October 2007.
+
+   [w74plen]  "IETF 74 Wednesday Evening Plenary Minutes", March 2009.
+
+Author's Address
+
+   Spencer Dawkins (editor)
+   Huawei Technologies (USA)
+
+   Phone: +1 214 755 3870
+   EMail: spencer@wonderhamster.org
+
+
+
+Dawkins                  Best Current Practice                  [Page 5]
+