idnits 2.17.1 draft-dawkins-nomcom-start-earlier-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 390. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3777, but the abstract doesn't seem to directly say this. It does mention RFC3777 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3777, updated by this document, for RFC5378 checks: 2002-06-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2007) is 6162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Dawkins 3 Internet-Draft Huawei (USA) 4 Updates: 3777 (if approved) May 2007 5 Intended status: Informational 6 Expires: November 2, 2007 8 IAB and IESG Selection, Confirmation, and Recall Process: Revision of 9 the Nominating and Recall Committees Timeline 10 draft-dawkins-nomcom-start-earlier-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 2, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 RFC 3777 defines the Nominations and Recall Committee's operation, 44 and includes a sample timeline for major steps in the NomCom process 45 that meets the minimum normative requirements for the process. 46 Recent NomComs have been scheduling based on the sample timeline, and 47 the chairs of the last three NomComs, Danny McPherson (2004-2005), 48 Ralph Droms (2005-2006), and Andrew Lange (2006-2007) have all 49 reported that this timeline is very aggressive and have all suggested 50 starting earlier. This document restructures the sample timeline, 51 but makes no normative process changes. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Interaction with IETF Face-to-face Meeting Schedule . . . . . 4 58 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Sample Timeline for 2008-2009 NomCom Schedule . . . . . . . . 5 60 6. Some Observations from the 2007-2008 NomCom Experience . . . . 7 61 7. Out-of-scope Suggestions Requiring Normative Text Changes . . 7 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 11. Normative References . . . . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 RFC 3777 ([RFC3777]) is a complete specification of the process by 72 which members of the IAB and IESG are selected, confirmed, and 73 recalled as of the date of its approval. [RFC3777] includes 74 normative requirements for timing allowed for the various steps, and 75 also includes an informative appendix, Appendix B, that contains a 76 timeline based on the normative text. 78 The normative time requirements in [RFC3777] are end-of-task, so 79 adjusting the informative timeline to get an earlier start does not 80 require changes to the normative text in [RFC3777]. 82 In IETF 68, IETF 65, and IETF 62 plenary reports, NomCom chairs 83 suggested starting the NomCom cycle earlier. This document describes 84 a timeline that meets this need, replacing RFC 3777 Appendix B, and 85 makes no other changes to [RFC3777]. 87 2. The Problem 89 There are several reasons that have been cited for the schedule 90 pressures reported by recent NomComs. 92 o A few common practices are not accounted for in the Appendix B 93 timeline [RFC3777]. For example, it is common to allow a week for 94 notifying unsuccessful nominees before the formal announcement is 95 made. This is not included in the timeline. 96 o Some tasks just seem to take longer than the minimum interval. 97 For example, a public "call for volunteers" must be open for 30 98 days, but the list of voting NomCom participants probably isn't 99 announced on at midnight on the 30th day. Anecdotal evidence is 100 that allowing about 6 weeks is more consistent with recent 101 experience. 102 o The NomCom, and the community it serves, tends to celebrate a 103 variety of holidays between the Third IETF and the First IETF of 104 the next year, so people may be out of the office, may wait to 105 respond, etc. 106 o The Appendix B timeline does not provide flexibility in case of 107 problems. For example, the NomCom chair "reset" the random 108 selection of volunteers for the 2006-2007 NomCom, requiring 109 another seven-day delay for the announcement of the date of random 110 selection. 112 All of these reasons can be accommodated by simply starting earlier 113 than is absolutely required. 115 3. Interaction with IETF Face-to-face Meeting Schedule 117 In addition to these reasons for schedule pressure, it's worth noting 118 that the NomCom schedule and the IETF face-to-face meeting cycle 119 don't complement each other. 121 o When the NomCom volunteers are selected after the Second IETF, 122 they don't have an opportunity to meet face-to-face and "get 123 organized" until the Third IETF, when they should be winding up 124 their deliberations. This missed opportunity forces them to use 125 teleconferences and other less efficient means of communications 126 to get organized. 127 o The NomCom volunteers don't have a chance to conduct interviews 128 with the community, or with nominees, until the third IETF, during 129 the height of the NomCom effort. If the NomCom effort took place 130 before the Third IETF, the NomCom could work on difficult 131 nominations, and to meet with nominees under consideration, face 132 to face. 133 o If the NomCom is able to start interviews during the Second IETF 134 meeting, starting earlier than is absolutely required may also 135 help NomCom be more effective. 137 4. Proposed Solution 139 The high-level description of the proposal is, of course, "start 140 earlier", but more precision would be helpful. 142 A sample, hypothetical timeline that meets these guidelines is shown 143 in Section 5. Please note that, like Appendix B in [RFC3777], this 144 timeline is not normative, but it meets the normative requirements 145 stated in [RFC3777]. 147 Other timelines are certainly possible, including timelines that 148 allow the NomCom to report its results more than one month before the 149 First IETF where the slate of nominees is announced. Finishing early 150 may be a good thing. 152 It's worth noting that the first step in the timeline is "ISOC 153 president appoints NomCom chair". This doesn't happen as an IETF 154 responsibility, but the reality is that the ISOC President needs to 155 identify NomCom Chair candidates around the time of the First IETF; 156 and she needs to have a shortlist 3 or 4 weeks after the First IETF. 157 This document suggests (but does not add a normative requirement to 158 [RFC3777]) that the outgoing NomCom Chair should verify that this 159 process is triggered during the First IETF. 161 1. One week is allowed for the NomCom chair to publish milestones. 162 2. Six weeks are allowed for solicitation of NomCom participants. 163 3. One week is allowed for confirmation of the selection of voting 164 members, to allow at least some time for resolution if there is a 165 problem. 166 4. The recommended time for NomCom self-organization is increased to 167 six weeks. 168 5. One week is allowed for NomCom establishing milestones. 169 6. In this case, an additional four weeks is allowed for the 170 Nominating bodies to select candidates. 171 7. The timeline is adjusted to allow one week at the end of the 172 process for notification of unsuccessful candidates. 174 This significantly increases the amount of time available for NomCom 175 to select candidates while still meeting the normative requirements 176 of [RFC3777]. 178 5. Sample Timeline for 2008-2009 NomCom Schedule 180 The following table shows a sample timeline for the 2008-2009 NomCom 181 schedule, based on the IETF dates for Second IETF (72nd IETF, held 182 July 27 - August 1, 2008), Third IETF (73rd IETF, held November 183 16-21, 2008), and First IETF (74 IETF, held March 22-27, 2009). 185 Note that the duration of each milestone step is adjusted as 186 necessary for each NomCom, since the scheduled dates for IETF 187 meetings vary from year to year. This timeline allows the NomCom to 188 begin self organizing at the Second IETF (this is what "on time") 189 means in the table). 191 +------------+-----------------+----------+--------------+----------+ 192 | RFC 3777 | What happens | new | start date | old | 193 | Appendix B | | duration | (YYYY/MM/DD) | duration | 194 | reference | | (weeks) | | (weeks) | 195 +------------+-----------------+----------+--------------+----------+ 196 | 1 | ISOC president | 0 | 2008/05/25 | 0 | 197 | | appoints NomCom | | | | 198 | | chair | | | | 199 | 2 | NomCom chair | 1 | 2008/05/25 | 0 | 200 | | publishes | | | | 201 | | milestones | | | | 202 | 3 | Solicitation of | 6 | 2008/06/01 | 30 days | 203 | | NomCom | | | | 204 | | participants | | | | 205 | 4 | Announce date | 1 | 2008/07/13 | 1 | 206 | | of random | | | | 207 | | selection | | | | 208 | 5 | Announce NomCom | 1 | 2008/07/20 | 1 | 209 | | membership, | | | | 210 | | challenge | | | | 211 | | period | | | | 212 | 6 | Verify NomCom | 0 | 2008/07/27 | 0 | 213 | | membership | | | | 214 | | during | | | | 215 | | challenge | | | | 216 | | period | | | | 217 | 7 | Confirm NomCom | 1 | 2008/07/27 | 0 | 218 | | membership | | | | 219 | 8 | NomCom Self | 6 | 2008/08/03 | 4 | 220 | | Organizes (on | | | | 221 | | time) | | | | 222 | 9 | END | 0 | 2008/09/14 | 0 | 223 | | organization, | | | | 224 | | BEGIN selection | | | | 225 | 10 | NomCom | 1 | 2008/09/14 | 0 | 226 | | establishes | | | | 227 | | milestones | | | | 228 | 11 | Nominating | 17 | 2008/09/21 | 12 | 229 | | bodies select | | | | 230 | | candidates | | | | 231 | 12 | END selection, | 0 | 2009/01/18 | 0 | 232 | | BEGIN | | | | 233 | | confirmation of | | | | 234 | | candidates | | | | 235 | 13 | Present slate | 0 | 2009/01/18 | 0 | 236 | | of candidates | | | | 237 | | to confirming | | | | 238 | | bodies | | | | 239 | 14 | Confirming | 4 | 2009/01/18 | 4 | 240 | | bodies accept | | | | 241 | | or reject | | | | 242 | (added | Notify | 1 | 2009/02/15 | | 243 | step) | unsuccessful | | | | 244 | | nominees | | | | 245 | 15 | Slate announced | 4 | 2009/02/22 | 4 | 246 | | 1 month before | | | | 247 | | 1st IETF | | | | 248 | | 1st IETF | | 2009/03/22 | | 249 +------------+-----------------+----------+--------------+----------+ 251 New Step 1 Date: 2008/05/25, Old Step 1 Date: 2008/08/29 253 Table 1 255 6. Some Observations from the 2007-2008 NomCom Experience 257 Since the timeline described in this specification makes no normative 258 changes to [RFC3777], the 2007-2008 NomCom process started using the 259 new timeline, to gain experience and shake out unexpected 260 consequences. We discovered the following things: 262 1. It is worth pointing out that the [RFC3777] requirement for 263 eligibility, "Members of the IETF community must have attended at 264 least 3 of the last 5 IETF meetings in order to volunteer.", is 265 affected when the NomCom chair issues an earlier call for 266 volunteers. For example, using the the 2008-2009 NomCom example 267 in the doc: under the old schedule, a prospective member would 268 need to have attented three of IETF meetings 68-72. Under the 269 new schedule, that becomes three of IETF meetings 67-71. 270 2. It's worth noting that when NomCom uses the earlier timeline, 271 incumbents under review who were appointed to one-year terms have 272 only one IETF meeting cycle to establish a track record before 273 NomCom begins considering whether they should be retained. This 274 situation is rare but not unknown. The recent split of the RAI 275 area out of TSV created two one-year terms (one in RAI, and one 276 in TSV), and this can also happens if an IESG or IAB member 277 resigns with more than one year remaining in the member's term. 279 7. Out-of-scope Suggestions Requiring Normative Text Changes 281 While there are very few avoidable serialized delays in [RFC3777], we 282 note that the minimum 30-day delay for volunteers is serialized after 283 the NomCom chair is named. This delay accounts for more than half 284 the elapsed time between the NomCom chair being named and the NomCom 285 itself forming. If a future normative revision to [RFC3777] changed 286 the mechanics for this call for volunteers, this call could be issued 287 while the NomCom chair is still being selected. This would allow the 288 new NomCom chair to begin work by announcing the date of random 289 selection, instead of just waiting for the volunteers to volunteer. 291 One possible trigger would be to have the outgoing NomCom chair issue 292 the call for volunteers on behalf of the successor NomCom chair, who 293 may not yet be identified, at the First IETF meeting each year. 295 8. Security Considerations 297 The NomCom timeline changes suggested in this document do not 298 directly affect the security of the Internet. 300 9. IANA Considerations 302 This document requests no action by the IANA. 304 {{{ RFC Editor: Please remove this section prior to publication. }}} 306 10. Acknowledgements 308 This draft is based on conversations with the chairs of the last 309 three NomComs, Danny McPherson (2004-2005), Ralph Droms (2005-2006), 310 and Andrew Lange (2006-2007), and on their corresponding plenary 311 NomCom Report presentations at IETF 62, IETF 65, and IETF 68 312 (respectively). 314 The 2007 IESG discussed Andrew Lange's report at their face-to-face 315 retreat and requested a proposal that adjusted the informative 316 timeline with no normative changes. 318 Thanks to Russ Housley, current General Area director, for reviewing 319 an early version of this draft. 321 Thanks to Brian Carpenter, who pointed out that the IETF NomCom 322 portion of the timeline depends on the ISOC president appointing the 323 NomCom chair soon after the First IETF ("NomCom chairs don't appear 324 magically"), and provided a suggestion for ensuring that this happens 325 in a timeframe that allows NomCom to begin self organizing at the 326 Second IETF meeting each year. 328 Thanks to Sam Weiler, who pointed out the shift in meeting attendance 329 requirements described in Section 6. 331 We should also thank the editors of previous NomCom procedures for 332 developing a specification that we could "speed up" without changing 333 normative text. 335 11. Normative References 337 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 338 Recall Process: Operation of the Nominating and Recall 339 Committees", BCP 10, RFC 3777, June 2004. 341 Author's Address 343 Spencer Dawkins 344 Huawei Technologies (USA) 345 1547 Rivercrest Blvd. 346 Allen, TX 75002 347 USA 349 Phone: +1 469 229 5397 350 Email: spencer@mcsr-labs.org 352 Full Copyright Statement 354 Copyright (C) The IETF Trust (2007). 356 This document is subject to the rights, licenses and restrictions 357 contained in BCP 78, and except as set forth therein, the authors 358 retain all their rights. 360 This document and the information contained herein are provided on an 361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 363 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 364 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 365 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 368 Intellectual Property 370 The IETF takes no position regarding the validity or scope of any 371 Intellectual Property Rights or other rights that might be claimed to 372 pertain to the implementation or use of the technology described in 373 this document or the extent to which any license under such rights 374 might or might not be available; nor does it represent that it has 375 made any independent effort to identify any such rights. Information 376 on the procedures with respect to rights in RFC documents can be 377 found in BCP 78 and BCP 79. 379 Copies of IPR disclosures made to the IETF Secretariat and any 380 assurances of licenses to be made available, or the result of an 381 attempt made to obtain a general license or permission for the use of 382 such proprietary rights by implementers or users of this 383 specification can be obtained from the IETF on-line IPR repository at 384 http://www.ietf.org/ipr. 386 The IETF invites any interested party to bring to its attention any 387 copyrights, patents or patent applications, or other proprietary 388 rights that may cover technology that may be required to implement 389 this standard. Please address the information to the IETF at 390 ietf-ipr@ietf.org. 392 Acknowledgment 394 Funding for the RFC Editor function is provided by the IETF 395 Administrative Support Activity (IASA).