idnits 2.17.1 draft-klensin-nomcom-term-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 348. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 24, 2006) is 6517 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft 4 Expires: December 26, 2006 S. Dawkins 5 Huawei 6 June 24, 2006 8 Terms of Appointments for NomCom-selected IETF Leadership Positions 9 draft-klensin-nomcom-term-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 26, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 A consensus is emerging in the IETF that very long tenure in 43 leadership roles is not in the best interests of the community. 44 While, in theory, that advice could simply be given to the NomCom, 45 there is reason to believe that a different model for consideration 46 of renewal or replacement for members of the leadership would be more 47 efficient for the NomCom and would impose less hardship on incumbents 48 and the community. This document outlines that alternate method. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Mailing List . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. The Review and Clean Nomination Model . . . . . . . . . . . . 3 55 2.1. Phase 1: Review of Incumbents . . . . . . . . . . . . . . 4 56 2.2. Phase 2: Nomination and Selection of New Candidates . . . 5 57 2.3. Revised schedule . . . . . . . . . . . . . . . . . . . . . 5 58 3. Previous Discussion Points . . . . . . . . . . . . . . . . . . 5 59 3.1. IESG-only, or all NomCom appointments? . . . . . . . . . . 6 60 3.2. "Doing an excellent job" as justification for third 61 term? . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.3. Guidance, or hard limit on service length? . . . . . . . . 7 63 4. Internationalization Considerations . . . . . . . . . . . . . 7 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security considerations . . . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Intellectual Property and Copyright Statements . . . . . . . . . . 10 73 1. Introduction 75 A consensus is emerging in the IETF that very long tenure in 76 leadership roles is not in the best interests of the community. 77 While, in theory, that advice could simply be given to the NomCom, 78 there is reason to believe that a different model for consideration 79 of renewal or replacement for members of the leadership would be more 80 efficient for the NomCom and would impose less hardship on incumbents 81 and the community. This document outlines that alternate method. 83 1.1. Mailing List 85 This proposal should be discussed on the main ietf list at ietf.org. 87 2. The Review and Clean Nomination Model 89 The current nomination process pits incumbents, incumbent 90 performance, and questions of stability in the IESG against potential 91 other candidates. This is undesirable for a number of reasons. It 92 creates the notion of incumbents being "fired" rather than honorably 93 retired to the citizenry after a brief period of contributing to the 94 community by assuming a leadership role. And, while there is 95 significant value in treating stability as a goal, it can also create 96 distortions about the degree of support various ideas have in the 97 community. 99 This specification changes the current model by reintroducing some 100 principles that the author believes are widely held in the community 101 and optimizing the selection process to support those principles. 102 The principles include: 103 o Service in the IETF's leadership bodies is a short-term 104 contribution to the community, not a career. Indeed, assuming 105 those positions may be considered a responsibility to the 106 community. 107 o It takes long enough to learn the job of being an effective AD 108 that, in general, having someone retire after a single two-year 109 term is uneconomic for the community. 110 o Just as retirement of an AD after one term should be considered a 111 major step because of the inefficiencies of the learning period, 112 the six-month or more period in which an incumbent is uncertain 113 about whether work should be planned that spans the "first meeting 114 of the next year" introduces inefficiencies that should be 115 minimized to the degree possible. 116 o A demonstrated shortage of people willing to do work in the IETF 117 should be taken as an indication that there is insufficient real 118 community interest in the work to reach a meaningful consensus 119 about high-quality results. While that position appears to be 120 reasonably well-understood with regard to the number of active 121 IETF participants interested in putting a working group together, 122 and in finding leadership for working groups, the same principle 123 probably should be applied to ADs and areas: if there are only one 124 or two people willing and qualified to do the AD job, that may be 125 an indication that the IETF should review the appropriateness of 126 that area's existence or definition. 128 To deal effectively with these problems, the NomCom consideration and 129 evaluation process is divided into two phases. 131 2.1. Phase 1: Review of Incumbents 133 Incumbent performance should be evaluated, not compared to potential 134 other candidates or replacements. The incumbent will always have 135 more experience. An AD who has done his or her job well, will have 136 accumulated strong proponents and probably strong detractors. Other 137 candidates are always risks, and direct comparison is inevitably 138 difficult. 140 In Phase 1, the NomCom will evaluate the performance of incumbents, 141 collecting information from the community as needed to do that. The 142 NomCom is instructed that an incumbent should be returned once (i.e., 143 permitted/encouraged to serve two terms) unless there is strong 144 evidence of problems (e.g., incompetence, inability to work with WGs, 145 inability to work with other ADs, non-feasance, or malfeasance). 146 Conversely, the NomCom should assume that it is better to return an 147 incumbent who has served two terms to the community and active WG 148 work unless some special circumstances apply. 150 While this process allows flexibility, the NomCom is instructed that 151 "special circumstances" should be a rare occurrence, based on what is 152 best for the affected area, the IESG, and the IETF as a whole. 153 Simply doing an outstanding job as an AD should not constitute 154 "special circumstances" that would justify a third term. 156 The level of special circumstances required for a fourth, or 157 subsequent, term should be required to be much higher than that for a 158 third: the intent is to make more than three terms a rare and nearly 159 impossible event without formally prohibiting that through a term 160 limit: it is important that the NomCom retain flexibility and the 161 opportunity to judge special circumstances. 163 Discussions between the NomCom and a candidate as to whether that 164 candidate is willing to serve again should be covered by the NomCom's 165 normal privacy rules except as mutually agreed. If the NomCom 166 chooses to not return a candidate who is willing to serve, the 167 expectation is that this will be indistinguishable to the community 168 from the candidate voluntarily stepping down. Under normal 169 circumstances, the NomCom is expected to conduct informational 170 evaluations of even those candidates who have chosen to step down 171 (the evaluations may inform later choices), but such candidates may 172 negotiate with the NomCom as appropriate, perhaps supplying in-depth 173 analysis of the relevant Area and its status and issues as an 174 alternative. 176 At the end of this phase, the NomCom submits the list of returning 177 candidates to the IAB as usual. The IAB makes its decision and the 178 choices are announced to the community. The list of (remaining) open 179 slots is then announced to the community and nominations and 180 recommendations sought. Any incumbent who is not returned in this 181 phase is not eligible for the relevant position in the second phase. 183 2.2. Phase 2: Nomination and Selection of New Candidates 185 This procedure works exactly as described in [RFC3777], with the 186 understanding that no incumbent will ever be a candidate for the same 187 position under this process. As a side-effect, the process makes it 188 more difficult than it has traditionally been to shift people around 189 within the IESG: it is considered an explicit corollary to the 190 principles above that an incumbent AD is one area should normally 191 have working experience within one or more WGs in a new area before 192 being considered as a candidate for AD in that area. 194 2.3. Revised schedule 196 [[to be supplied]] 198 The authors are aware of other proposals that would also affect the 199 NomCom timeline. Rather than trying to develop a revised schedule on 200 a per-proposal basis, we suggest that one NomCom schedule revision be 201 considered, based on this and other proposals that would be 202 accommodated. 204 3. Previous Discussion Points 206 In informal discussions before the initial version of this draft was 207 completed and posted, there was considerable discussion on three 208 points: 209 o Whether this proposal should apply only to IESG appointments, or 210 to all NomCom appointments, 211 o Whether "doing an outstanding job" is justification for third 212 terms, and 214 o Whether this proposal should contain a statement of guidance, or 215 hard term limits. 217 Reasonable people spoke in support of both sides on each of these 218 points, but the proposal authors had to make choices. The community 219 will need to discuss, and decide upon, these issues. 221 3.1. IESG-only, or all NomCom appointments? 223 This specification has been written to apply to the IESG only, since 224 the IESG's operational role and observed rates of AD burnout make it 225 most obviously important there. 227 It is possible that consideration should be given as to whether a 228 similar or identical model should be applied to the IAB and/or other 229 appointments made by the NomCom. 231 3.2. "Doing an excellent job" as justification for third term? 233 This specification is written to allow NomCom to return ADs for third 234 terms, and beyond, due to "special circumstances". One question 235 we've been asked is whether "doing an outstanding job" should be 236 included in "special circumstances". 238 While our intention is to provide guidance to NomCom, rather than 239 rules, this specification proposes that this guidance be "no". 240 o The community is better served by having former ADs returning to 241 technical work. A consistent criticism of the current working 242 group process is that specifications often lack sufficient cross- 243 area review when they are forwarded for publication. ADs provide 244 this type of review, but currently-serving ADs don't have time to 245 provide reviews early in the development of a draft, where it is 246 most useful and most likely to have a positive impact. 247 o Allowing "doing an outstanding job" to constitute "special 248 circumstances" removes deterministic benefits of this model. The 249 intention is that ADs return to the community after two terms. It 250 is desired that all ADs "do an outstanding job" - this proposal 251 would remove ADs who aren't headed for "outstanding", after their 252 first term - but Only in Lake Woebegon are all the children above 253 average, and Lake Wobegon is a fictitious place. 254 o We also note that former ADs are often asked to serve as working 255 group chairs in difficult situations, to help with BOFs and WG 256 charter discussions, and to carry out assignments that benefit 257 from AD experience but do not require the assignee to be a serving 258 AD. It is unlikely that an outstanding AD who wants to continue 259 to serve the community will be overlooked after leaving the IESG. 261 3.3. Guidance, or hard limit on service length? 263 There was considerable discussion about whether it was better to 264 offer the NomCom the guidance above, discouraging terms beyond the 265 second, or whether to flatly prohibit more than two terms. One group 266 believed that giving the NomCom a little extra flexibility was a good 267 idea; the other believed that any additional flexibility would likely 268 lead to very long terms since there would always be a reason to make 269 an exception. 271 The authors of this proposal prefer to offer NomCom guidance, rather 272 than rules. To take one example - if the NomCom believes that 273 returning a third-term AD is appropriate (due, perhaps, to the other 274 serving co-area director stepping down before the end of a second 275 term), we prefer to allow NomCom this flexibility, rather than 276 restrict them to a course of action that seems ill-advised. 278 4. Internationalization Considerations 280 This specification is about IETF Procedures. It has no impact on 281 internationalization issues. 283 5. IANA Considerations 285 This specification is about IETF Procedures. It has no impact on 286 IANA issues and does not contemplate any IANA actions. 288 6. Security considerations 290 This specification is about IETF Procedures for leadership selection. 291 It has no impact on Internet security issues. 293 7. Acknowledgements 295 [[ to be supplied ]] 297 8. References 299 8.1. Normative References 301 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 302 Recall Process: Operation of the Nominating and Recall 303 Committees", BCP 10, RFC 3777, June 2004. 305 8.2. Informative References 306 Authors' Addresses 308 John C Klensin 309 1770 Massachusetts Ave, #322 310 Cambridge, MA 02140 311 USA 313 Phone: +1 617 491 5735 314 Email: john-ietf@jck.com 316 Spencer Dawkins 317 Huawei Technologies (USA) 318 1700 Alma Drive, Suite 100 319 Plano, TX 75075 320 US 322 Phone: +1 469 229 5397 323 Fax: +1 972 509 0309 324 Email: spencer@mcsr-labs.org 326 Intellectual Property Statement 328 The IETF takes no position regarding the validity or scope of any 329 Intellectual Property Rights or other rights that might be claimed to 330 pertain to the implementation or use of the technology described in 331 this document or the extent to which any license under such rights 332 might or might not be available; nor does it represent that it has 333 made any independent effort to identify any such rights. Information 334 on the procedures with respect to rights in RFC documents can be 335 found in BCP 78 and BCP 79. 337 Copies of IPR disclosures made to the IETF Secretariat and any 338 assurances of licenses to be made available, or the result of an 339 attempt made to obtain a general license or permission for the use of 340 such proprietary rights by implementers or users of this 341 specification can be obtained from the IETF on-line IPR repository at 342 http://www.ietf.org/ipr. 344 The IETF invites any interested party to bring to its attention any 345 copyrights, patents or patent applications, or other proprietary 346 rights that may cover technology that may be required to implement 347 this standard. Please address the information to the IETF at 348 ietf-ipr@ietf.org. 350 Disclaimer of Validity 352 This document and the information contained herein are provided on an 353 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 354 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 355 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 356 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 357 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 358 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 360 Copyright Statement 362 Copyright (C) The Internet Society (2006). This document is subject 363 to the rights, licenses and restrictions contained in BCP 78, and 364 except as set forth therein, the authors retain all their rights. 366 Acknowledgment 368 Funding for the RFC Editor function is currently provided by the 369 Internet Society.