summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5078.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc5078.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc5078.txt')
-rw-r--r--doc/rfc/rfc5078.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc5078.txt b/doc/rfc/rfc5078.txt
new file mode 100644
index 0000000..dedd533
--- /dev/null
+++ b/doc/rfc/rfc5078.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group S. Dawkins
+Request for Comments: 5078 Huawei (USA)
+Updates: 3777 October 2007
+Category: Informational
+
+
+ IAB and IESG Selection, Confirmation, and Recall Process:
+ Revision of the Nominating and Recall Committees Timeline
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Abstract
+
+ RFC 3777 defines the Nominations and Recall Committee's (NomCom's)
+ operation, and includes a sample timeline for major steps in the
+ NomCom process that meets the minimum normative requirements for the
+ process. Recent NomComs have been scheduling based on the sample
+ timeline, and the chairs of the last three NomComs -- Danny McPherson
+ (2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) --
+ have all reported that this timeline is very aggressive and suggested
+ starting earlier. This document restructures the sample timeline,
+ but makes no normative process changes.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Interaction with IETF Face-to-Face Meeting Schedule . . . . . . 3
+ 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 3
+ 5. Sample Timeline for 2008-2009 NomCom Schedule . . . . . . . . . 4
+ 6. Some Observations from the 2007-2008 NomCom Experience . . . . 6
+ 7. Out-of-Scope Suggestions Requiring Normative Text Changes . . . 6
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
+ 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+Dawkins Informational [Page 1]
+
+RFC 5078 NomCom Starting Earlier October 2007
+
+
+1. Introduction
+
+ RFC 3777 ([RFC3777]) is a complete specification of the process by
+ which members of the IAB and IESG are selected, confirmed, and
+ recalled as of the date of its approval. [RFC3777] includes
+ normative requirements for timing allowed for the various steps, and
+ also includes an informative appendix, Appendix B, that contains a
+ timeline based on the normative text.
+
+ The normative time requirements in [RFC3777] are end-of-task, so
+ adjusting the informative timeline to get an earlier start does not
+ require changes to the normative text in [RFC3777].
+
+ In IETF 68, IETF 65, and IETF 62 plenary reports, NomCom chairs
+ suggested starting the NomCom cycle earlier. This document describes
+ a timeline that meets this need, replacing RFC 3777, Appendix B, and
+ makes no other changes to [RFC3777].
+
+2. The Problem
+
+ There are several reasons that have been cited for the schedule
+ pressures reported by recent NomComs.
+
+ o A few common practices are not accounted for in the Appendix B
+ timeline [RFC3777]. For example, it is common to allow a week for
+ notifying unsuccessful nominees before the formal announcement is
+ made. This is not included in the timeline.
+
+ o Some tasks just seem to take longer than the minimum interval.
+ For example, a public "call for volunteers" must be open for 30
+ days, but the list of voting NomCom participants probably isn't
+ announced at midnight on the 30th day. Anecdotal evidence is that
+ allowing about 6 weeks is more consistent with recent experience.
+
+ o The NomCom, and the community it serves, tends to celebrate a
+ variety of holidays between the third IETF and the first IETF of
+ the next year, so people may be out of the office, may wait to
+ respond, etc.
+
+ o The Appendix B timeline does not provide flexibility in case of
+ problems. For example, the NomCom chair "reset" the random
+ selection of volunteers for the 2006-2007 NomCom, requiring
+ another seven-day delay for the announcement of the date of random
+ selection.
+
+ All of these reasons can be accommodated by simply starting earlier
+ than is absolutely required.
+
+
+
+
+Dawkins Informational [Page 2]
+
+RFC 5078 NomCom Starting Earlier October 2007
+
+
+3. Interaction with IETF Face-to-Face Meeting Schedule
+
+ In addition to these reasons for schedule pressure, it's worth noting
+ that the NomCom schedule and the IETF face-to-face meeting cycle
+ don't complement each other.
+
+ o When the NomCom volunteers are selected after the second IETF,
+ they don't have an opportunity to meet face-to-face and "get
+ organized" until the third IETF, when they should be winding up
+ their deliberations. This missed opportunity forces them to use
+ teleconferences and other less efficient means of communications
+ to get organized.
+
+ o The NomCom volunteers don't have a chance to conduct interviews
+ with the community, or with nominees, until the third IETF, during
+ the height of the NomCom effort. If the NomCom effort took place
+ before the third IETF, the NomCom could work on difficult
+ nominations, and meet face-to-face with nominees under
+ consideration.
+
+ o If the NomCom is able to start interviews during the second IETF
+ meeting, starting earlier than is absolutely required may also
+ help NomCom be more effective.
+
+4. Proposed Solution
+
+ The high-level description of the proposal is, of course, "start
+ earlier", but more precision would be helpful.
+
+ A sample, hypothetical timeline that meets these guidelines is shown
+ in Section 5. Please note that, like Appendix B in [RFC3777], this
+ timeline is not normative, but it meets the normative requirements
+ stated in [RFC3777].
+
+ Other timelines are certainly possible, including timelines that
+ allow the NomCom to report its results more than one month before the
+ first IETF, where the slate of nominees is announced. Finishing
+ early may be a good thing.
+
+ It's worth noting that the first step in the timeline is "ISOC
+ president appoints NomCom chair". This doesn't happen as an IETF
+ responsibility, but the reality is that the ISOC president needs to
+ identify NomCom chair candidates around the time of the first IETF;
+ she needs to have a shortlist 3 or 4 weeks after the first IETF.
+ This document suggests (but does not add a normative requirement to
+ [RFC3777]) that the outgoing NomCom Chair should verify that this
+ process is triggered during the first IETF.
+
+
+
+
+Dawkins Informational [Page 3]
+
+RFC 5078 NomCom Starting Earlier October 2007
+
+
+ 1. One week is allowed for the NomCom chair to publish milestones.
+
+ 2. Six weeks are allowed for solicitation of NomCom participants.
+
+ 3. One week is allowed for confirmation of the selection of voting
+ members -- to allow at least some time for resolution if there is
+ a problem.
+
+ 4. The recommended time for NomCom self-organization is increased to
+ six weeks.
+
+ 5. One week is allowed for NomCom establishing milestones.
+
+ 6. In the sample timeline (Table 1), an additional five weeks is
+ allowed for the nominating bodies to select candidates.
+
+ 7. The timeline is adjusted to allow one week at the end of the
+ process for notification of unsuccessful candidates.
+
+ This significantly increases the amount of time available for NomCom
+ to select candidates while still meeting the normative requirements
+ of [RFC3777].
+
+5. Sample Timeline for 2008-2009 NomCom Schedule
+
+ The following table shows a sample timeline for the 2008-2009 NomCom
+ schedule, based on the IETF dates for the second IETF (72nd IETF,
+ held July 27 - August 1, 2008), third IETF (73rd IETF, held November
+ 16-21, 2008), and first IETF (74 IETF, held March 22-27, 2009).
+
+ Note that the duration of each milestone step is adjusted as
+ necessary for each NomCom, since the scheduled dates for IETF
+ meetings vary from year to year. This timeline allows the NomCom to
+ begin self organizing at the Second IETF (this is what "on time")
+ means in the table).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawkins Informational [Page 4]
+
+RFC 5078 NomCom Starting Earlier October 2007
+
+
+ +------------+-----------------+----------+--------------+----------+
+ | RFC 3777 | What happens | new | start date | old |
+ | Appendix B | | duration | (YYYY/MM/DD) | duration |
+ | reference | | (weeks) | | (weeks) |
+ +------------+-----------------+----------+--------------+----------+
+ | 1 | ISOC president | 0 | 2008/05/25 | 0 |
+ | | appoints NomCom | | | |
+ | | chair | | | |
+ | 2 | NomCom chair | 1 | 2008/05/25 | 0 |
+ | | publishes | | | |
+ | | milestones | | | |
+ | 3 | Solicitation of | 6 | 2008/06/01 | 30 days |
+ | | NomCom | | | |
+ | | participants | | | |
+ | 4 | Announce date | 1 | 2008/07/13 | 1 |
+ | | of random | | | |
+ | | selection | | | |
+ | 5 | Announce NomCom | 1 | 2008/07/20 | 1 |
+ | | membership, | | | |
+ | | challenge | | | |
+ | | period | | | |
+ | 6 | Verify NomCom | 0 | 2008/07/27 | 0 |
+ | | membership | | | |
+ | | during | | | |
+ | | challenge | | | |
+ | | period | | | |
+ | 7 | Confirm NomCom | 1 | 2008/07/27 | 0 |
+ | | membership | | | |
+ | 8 | NomCom self | 6 | 2008/08/03 | 4 |
+ | | organizes (on | | | |
+ | | time) | | | |
+ | 9 | END | 0 | 2008/09/14 | 0 |
+ | | organization, | | | |
+ | | BEGIN selection | | | |
+ | 10 | NomCom | 1 | 2008/09/14 | 0 |
+ | | establishes | | | |
+ | | milestones | | | |
+ | 11 | Nominating | 17 | 2008/09/21 | 12 |
+ | | bodies select | | | |
+ | | candidates | | | |
+ | 12 | END selection, | 0 | 2009/01/18 | 0 |
+ | | BEGIN | | | |
+ | | confirmation of | | | |
+ | | candidates | | | |
+ | 13 | Present slate | 0 | 2009/01/18 | 0 |
+ | | of candidates | | | |
+ | | to confirming | | | |
+ | | bodies | | | |
+
+
+
+Dawkins Informational [Page 5]
+
+RFC 5078 NomCom Starting Earlier October 2007
+
+
+ | 14 | Confirming | 4 | 2009/01/18 | 4 |
+ | | bodies accept | | | |
+ | | or reject | | | |
+ | (added | Notify | 1 | 2009/02/15 | |
+ | step) | unsuccessful | | | |
+ | | nominees | | | |
+ | 15 | Slate announced | 4 | 2009/02/22 | 4 |
+ | | 1 month before | | | |
+ | | 1st IETF | | | |
+ | | 1st IETF | | 2009/03/22 | |
+ +------------+-----------------+----------+--------------+----------+
+
+ New Step 1 Date: 2008/05/25, Old Step 1 Date: 2008/08/29
+
+ Table 1
+
+6. Some Observations from the 2007-2008 NomCom Experience
+
+ Since the timeline described in this specification makes no normative
+ changes to [RFC3777], the 2007-2008 NomCom process started using the
+ new timeline to gain experience and shake out unexpected
+ consequences. We discovered the following things:
+
+ 1. It is worth pointing out that the [RFC3777] requirement for
+ eligibility, "Members of the IETF community must have attended at
+ least 3 of the last 5 IETF meetings in order to volunteer.", is
+ affected when the NomCom chair issues an earlier call for
+ volunteers. For example, using the 2008-2009 NomCom example in
+ the doc: under the old schedule, a prospective member would need
+ to have attended three of IETF meetings 68-72. Under the new
+ schedule, that becomes three of IETF meetings 67-71.
+
+ 2. It's worth noting that when NomCom uses the earlier timeline,
+ incumbents under review who were appointed to one-year terms have
+ only one IETF meeting cycle to establish a track record before
+ NomCom begins considering whether they should be retained. This
+ situation is rare but not unknown. The recent split of the RAI
+ area out of TSV created two one-year terms (one in RAI, and one
+ in TSV), and this can also happens if an IESG or IAB member
+ resigns with more than one year remaining in the member's term.
+
+7. Out-of-Scope Suggestions Requiring Normative Text Changes
+
+ While there are very few avoidable serialized delays in [RFC3777], we
+ note that the minimum 30-day delay for volunteers is serialized after
+ the NomCom chair is named. This delay accounts for more than half
+ the elapsed time between the NomCom chair being named and the NomCom
+ itself forming. If a future normative revision to [RFC3777] changed
+
+
+
+Dawkins Informational [Page 6]
+
+RFC 5078 NomCom Starting Earlier October 2007
+
+
+ the mechanics for this call for volunteers, this call could be issued
+ while the NomCom chair is still being selected. This would allow the
+ new NomCom chair to begin work by announcing the date of random
+ selection, instead of just waiting for the volunteers to volunteer.
+
+ One possible trigger would be to have the outgoing NomCom chair issue
+ the call for volunteers on behalf of the successor NomCom chair, who
+ may not yet be identified, at the first IETF meeting each year.
+
+8. Security Considerations
+
+ The NomCom timeline changes suggested in this document do not
+ directly affect the security of the Internet.
+
+9. Acknowledgements
+
+ This draft is based on conversations with the chairs of the last
+ three NomComs: Danny McPherson (2004-2005), Ralph Droms (2005-2006),
+ and Andrew Lange (2006-2007), and on their corresponding plenary
+ NomCom Report presentations at IETF 62, IETF 65, and IETF 68,
+ respectively.
+
+ The 2007 IESG discussed Andrew Lange's report at their face-to-face
+ retreat and requested a proposal that adjusted the informative
+ timeline with no normative changes.
+
+ Thanks to Russ Housley, current General Area director, for reviewing
+ an early version of this draft.
+
+ Thanks to Brian Carpenter, who pointed out that the IETF NomCom
+ portion of the timeline depends on the ISOC president appointing the
+ NomCom chair soon after the first IETF ("NomCom chairs don't appear
+ magically"), and provided a suggestion for ensuring that this happens
+ in a timeframe that allows NomCom to begin self organizing at the
+ Second IETF meeting each year.
+
+ Thanks to Sam Weiler, who pointed out the shift in meeting attendance
+ requirements described in Section 6.
+
+ We should also thank the editors of previous NomCom procedures for
+ developing a specification that we could "speed up" without changing
+ normative text.
+
+10. 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.
+
+
+
+Dawkins Informational [Page 7]
+
+RFC 5078 NomCom Starting Earlier October 2007
+
+
+Author's Address
+
+ Spencer Dawkins
+ Huawei Technologies (USA)
+ 1547 Rivercrest Blvd.
+ Allen, TX 75002
+ USA
+
+ Phone: +1 469 229 5397
+ EMail: spencer@mcsr-labs.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawkins Informational [Page 8]
+
+RFC 5078 NomCom Starting Earlier October 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Dawkins Informational [Page 9]
+