idnits 2.17.1 draft-klensin-nomcom-incumbents-first-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (July 13, 2009) is 5394 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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) -- Obsolete informational reference (is this intentional?): RFC 1602 (Obsoleted by RFC 2026) -- Obsolete informational reference (is this intentional?): RFC 2027 (Obsoleted by RFC 2282) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 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 Updates: 3777 (if approved) S. Dawkins 5 Intended status: BCP Huawei 6 Expires: January 14, 2010 July 13, 2009 8 Nominating Committee Process: Incumbent Review Model 9 draft-klensin-nomcom-incumbents-first-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 14, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The traditional IETF Nomcom model treats incumbents and new nominees 48 (for the same and other positions) as equivalent. This has not 49 proven realistic in practice and has had a number of undesirable side 50 effects. This document reviews the issues and the specific changes 51 to the model that take advantage of the differences between 52 incumbents and new nominees. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Mailing List . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Separating Review and Nominations for Open Positions . . . . . 4 59 2.1. Phase 1: Review of Incumbents . . . . . . . . . . . . . . 6 60 2.2. Phase 2: Nomination and Selection of New Candidates . . . 7 61 2.3. Revised schedule . . . . . . . . . . . . . . . . . . . . . 8 62 2.4. Other Nomcom Appointments . . . . . . . . . . . . . . . . 8 63 3. Issues with Public Nominations and Incumbents . . . . . . . . 8 64 4. Summary of Changes to RFC 3777 . . . . . . . . . . . . . . . . 9 65 5. Internationalization Considerations . . . . . . . . . . . . . 10 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. Security considerations . . . . . . . . . . . . . . . . . . . 10 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 73 A.1. Changes in version -01 . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 The IETF Nomcom model [RFC3777], going back to the origins of the 79 Nomcom as described in [RFC1602] and [RFC2027], assumes that all 80 nominees are to be treated identically, e.g., that there are no 81 differences between incumbents who are willing to serve an additional 82 term and new nominees. That assumption has proven unrealistic in 83 practice. The differences make the current selection model for 84 leadership roles inefficient for the community, for incumbents and 85 potential alternate nominees and for the Nomcom itself. People are 86 reluctant to "run against" incumbents and Nomcom members inevitably 87 have difficulty comparing unknown alternate nominees against 88 incumbents (sometimes to the advantage of the incumbents and 89 sometimes to the advantage of the nominees). Recent proposals for 90 changes to the Nomcom's practices about revealing nominee names 91 [Dawkins-Openlist] may exacerbate the problem by making a challenge 92 to an incumbent even more public than it is under the procedure of 93 RFC 3777 as it has been interpreted in recent years. 95 In evaluating an incumbent, the Nomcom should be able to consider 96 actual performance in the role as well as the delicate balance 97 between the advantages and disadvantages of longer tenure (including 98 the disadvantages of removing someone who has done a reasonable job 99 in a role for which a significant fraction of the first term is often 100 spent learning to function smoothly) and to do so independently of a 101 wider field of potential alternatives for which there is less role- 102 specific data available. 104 Consequently, there is reason to believe that a different model for 105 consideration of renewal or replacement for members of the leadership 106 would be more efficient for the Nomcom, would impose less hardship on 107 incumbents and the community, would avoid the problems associated 108 with trying to compete directly with an incumbent for a role, and 109 would lead to better comparisons and perhaps better choices. This 110 document outlines that alternate method. 112 Somewhat different considerations apply to IESG, where multiple 113 selections are made in a given year but for positions that are fairly 114 specific as to technical skill requirements, and other positions 115 selected by the Nomcom. Initially, this procedure is to be applied 116 only to IESG positions even though other bodies and positions are 117 discussed below. Once experience accumulates, it will be appropriate 118 to review it for applicability to other Nomcom appointments (see 119 Section 2.4). The Nomcom may apply its discretion, as usual, to 120 details of the process. 122 For clarity, this document uses the term "incumbent" to refer to 123 someone occupying a particular position at the time the Nomcom 124 process begins and "nominee" to refer to someone nominated for a 125 position who is not the incumbent in that position. This terminology 126 differs slightly from that of 3777, which does not make a distinction 127 between the two groups and refers to both as "nominees". 129 1.1. Mailing List 131 [[anchor2: RFC Editor: Please remove this section.]] 133 This proposal should be discussed on the ietf-nomcom@ietf.com list. 135 2. Separating Review and Nominations for Open Positions 137 The current nomination process pits incumbents, incumbent 138 performance, and questions of stability in relevant bodies against 139 other potential nominees. This is undesirable for a number of 140 reasons. It creates the notion of incumbents being "fired" rather 141 than honorably retired to the citizenry after a brief period of 142 contributing to the community by assuming a leadership role. And, 143 while there is significant value in treating stability as a goal, 144 too-low turnover in a decision-making body can contribute to that 145 body's having an incomplete impression of the views of the community. 147 It is worth noting that the trend in recent years (since at least 148 2002, the earliest year for which data or conveniently available) has 149 been to return, rather than replace incumbents (see the table below 150 for the data). If the Nomcom is going to return about half the 151 incumbents in each cycle, time considering other nominees is time 152 that could have been spent in more carefully considering nominees 153 that hadn't served previously. The separation proposed here should 154 promote more effective consideration of whether a given incumbent 155 should be returned. If a decision is made to do so, no other 156 nominees need be recruited, asked to submit information, evaluated, 157 and so on, and there is no need to poll the community about possible 158 replacements that aren't needed in this NomCom cycle. In addition to 159 producing better results, the change is likely to reduce Nomcom 160 workload, possibly encouraging a larger and more diverse pool of 161 volunteers for the Nomcom itself. 163 +-----------+-----------------+-------------------+-----------------+ 164 | NomCom | Reviewed | Returned | Percent | 165 | | Positions | Incumbents | Returned | 166 +-----------+-----------------+-------------------+-----------------+ 167 | 2008-2009 | 15 | 6 | 40 | 168 | 2007-2008 | 14 | 9 | 64 | 169 | 2006-2007 | 15 | 9 | 60 | 170 | 2005-2006 | 13 | 4 | 31 | 171 | 2004-2005 | 13 | 6 | 46 | 172 | 2003-2004 | 12 | 8 | 67 | 173 | 2002-2003 | 13 | 7 | 54 | 174 +-----------+-----------------+-------------------+-----------------+ 176 Table 1: Returned Incumbents per NomCom - IAB, IESG, and IAOC 178 +-----------+-----------------+-------------------+-----------------+ 179 | NomCom | Reviewed | Returned | Percent | 180 | | Positions | Incumbents | Returned | 181 +-----------+-----------------+-------------------+-----------------+ 182 | 2008-2009 | 6 | 2 | 33 | 183 | 2007-2008 | 6 | 2 | 33 | 184 | 2006-2007 | 6 | 4 | 67 | 185 | 2005-2006 | 6 | 2 | 33 | 186 | 2004-2005 | 6 | 1 | 17 | 187 | 2003-2004 | 6 | 3 | 50 | 188 | 2002-2003 | 6 | 3 | 50 | 189 +-----------+-----------------+-------------------+-----------------+ 191 Table 2: Returned Incumbents per NomCom - IAB only 193 +-----------+-----------------+-------------------+-----------------+ 194 | NomCom | Reviewed | Returned | Percent | 195 | | Positions | Incumbents | Returned | 196 +-----------+-----------------+-------------------+-----------------+ 197 | 2008-2009 | 8 | 4 | 50 | 198 | 2007-2008 | 7 | 6 | 86 | 199 | 2006-2007 | 8 | 4 | 50 | 200 | 2005-2006 | 6 | 1 | 17 | 201 | 2004-2005 | 7 | 5 | 71 | 202 | 2003-2004 | 6 | 5 | 83 | 203 | 2002-2003 | 7 | 4 | 57 | 204 +-----------+-----------------+-------------------+-----------------+ 206 Table 3: Returned Incumbents per NomCom - IESG only 208 This specification changes the current model by reintroducing some 209 principles that the authors believe are widely held in the community 210 and optimizing the selection process to support those principles. 212 The principles include: 214 o Service in the IETF's leadership bodies is a short-term 215 contribution to the community, not a career. Indeed, willingness 216 to assume those positions may be considered a responsibility to 217 the community. 219 o It takes long enough to learn the job of being effective in an 220 IAB, IESG, or IAOC role (and most other roles that can be 221 anticipated as being designated for Nomcom selection) that, in 222 general, having someone retire after a single term is uneconomic 223 for the community. 225 o Just as retirement of an incumbent after one term should be 226 considered a major step because of the inefficiencies of the 227 learning period, the six-month or more period in which an 228 incumbent is uncertain about whether work should be planned that 229 spans the "first meeting of the next year" (or some other term 230 cutoff) introduces inefficiencies that should be minimized to the 231 degree possible. 233 o While the issue lies largely outside the scope of this document, 234 it is worth considering that a demonstrated shortage of people 235 willing to do work in the IETF should be taken as an indication 236 that there is insufficient real community interest in the work, 237 and an appropriate level of resources, to reach meaningful 238 consensus and produce high-quality results. While that position 239 appears to be reasonably well-understood with regard to the number 240 of active IETF participants interested in putting a working group 241 together and in finding leadership for working groups, the same 242 principle probably should be applied to ADs, Areas, and IAB seats: 243 if there are only one or two people willing and qualified to do a 244 particular job, that may be an indication that the IETF should 245 review the appropriateness of that role (in the case of the IESG, 246 the existence or definition of the area) or should reconsider the 247 time and other requirements of the roles involved. 249 To deal effectively with these problems, the Nomcom consideration and 250 evaluation process is divided into two phases. 252 2.1. Phase 1: Review of Incumbents 254 Incumbent performance should be evaluated, rather than being compared 255 to potential other nominees to serve as replacements. The incumbent 256 will always have more experience. An incumbent who has done his or 257 her job well will have accumulated strong proponents and probably 258 strong detractors. Direct comparison between the actual performance 259 of incumbents and the potential performance of nominees is inevitably 260 difficult. 262 In Phase 1, the Nomcom will evaluate the performance of incumbents, 263 collecting information from the community as needed to do that. It 264 is worth noting that names of incumbents are known to the community 265 regardless of any Nomcom action or decisions. The Nomcom is advised 266 that an incumbent who is willing to serve an additional term should 267 be returned at least once (i.e., permitted/encouraged to serve two 268 terms) unless there is strong evidence of problems (e.g., 269 incompetence, inability to work with WGs, inability to work with 270 other incumbents, non-feasance, or malfeasance). For incumbents who 271 are completing their second or subsequent terms, the Nomcom should 272 balance the advantages and disadvantages of long tenure as Nomcoms 273 have done in the past. 275 Discussions between the Nomcom and an incumbent as to whether that 276 incumbent is willing to serve again should be covered by the Nomcom's 277 normal confidentiality rules except as mutually agreed (e.g., if an 278 incumbent wishes to make a public announcement that he or she is 279 unwilling to serve an additional term, there is nothing for the 280 Nomcom to keep confidential). If the Nomcom chooses to not return a 281 incumbent who is willing to serve, the expectation is that this will 282 be indistinguishable to the community (and to outside observers) from 283 the incumbent voluntarily stepping down. Under normal circumstances, 284 the Nomcom is expected to conduct informational evaluations of even 285 those incumbents who have chosen to step down (the evaluations may 286 inform later choices), but such incumbents may work with the Nomcom 287 on the style of evaluation as appropriate, perhaps supplying in-depth 288 analysis of the relevant Area and its status and issues as an 289 alternative to an in-depth evaluation of the incumbent's performance. 291 At the end of this phase, the Nomcom submits the list of returning 292 incumbents as candidates to the relevant confirming body as usual. 293 The confirming body makes its decision and the choices are announced 294 to the community. The list of (remaining) open slots is then 295 announced to the community before the nominal closing date for 296 nominations and recommendations. Any incumbent who is not returned 297 in this phase is not eligible for the relevant position in the second 298 phase, so no one ever "runs against" an incumbent. 300 2.2. Phase 2: Nomination and Selection of New Candidates 302 This procedure works exactly as described in RFC 3777, as amended 303 [RFC3777], with the understanding that no incumbent will ever be a 304 candidate for the same position under this process. As a side- 305 effect, the process specified in this document makes it more 306 difficult than it has traditionally been to shift people around 307 within the IESG and possibly between the IAB and IESG. 309 2.3. Revised schedule 311 Because of other proposals to alter the Nomcom timeline, it is 312 inappropriate to propose a separate timeline here. However, it is 313 worth noting that one interesting side-effect of this proposal is 314 that consideration and evaluation of incumbents could occur in 315 parallel with the beginning of calls for nominations. Of course a 316 nomination for a slot held by an incumbent who was returned would 317 become a no-op. There would be some advantages to guaranteeing 318 confidentiality, even from Nomcom members, for the identities of 319 anyone applying for such slots until the decision with regard to the 320 incumbent was public and silently discarding the nominations if the 321 incumbent were returned (see Section 3). 323 2.4. Other Nomcom Appointments 325 In general, the model specified here is obviously much more 326 applicable to selection environments in which nominees are matched to 327 particular slots and specific job descriptions. It may still be 328 useful when the selection involves a pool of positions that are not 329 differentiated with regard to particular technical (or other) 330 specialties. Consequently, the procedure will apply to IESG 331 selections only in the first year of application. Once experience is 332 accumulated from that year and the Nomcom and community have had the 333 opportunity to observe its effectiveness, extension of the procedure 334 to the IAB and/or IAOC should be considered. 336 If positions are added in the future to those that the Nomcom 337 selects, the documents that create those positions should specify 338 whether they fall under this "incumbents first" model or not. 340 3. Issues with Public Nominations and Incumbents 342 Over the years, there have been many discussions of the degree of 343 confidentiality that is appropriate for the Nomcom, especially with 344 regard to identification of the names of nominees being considered. 345 That discussion surfaced most recently in conjunction with 346 [Dawkins-Openlist]. The arguments against having the names be 347 completely open focus on two main cases: 349 o Some people fear publicly competing with incumbents. They are 350 concerned that it would be interpreted as an attack or statement 351 of lack of confidence in the incumbent and that the incumbent, if 352 returned, would resent those actions and retaliate by making it 353 more difficult for the challenger (or his organization) to 354 progress documents. 356 o Relationships within or among organizations might make such 357 nominations problematic even though the organizations might be 358 willing to tolerate any problems if the nominee were actually 359 selected (especially if it were not known whether the incumbent 360 stepped down voluntarily). An individual might be reluctant to be 361 nominated against her boss. A company might find it difficult to 362 permit a nomination when the incumbent (or another nominee) was in 363 a visible position with another company with which the first one 364 had very close linkages. And so on. 366 It is important to note that, regardless of whether these concerns 367 are actually valid or not, they are perceived as valid and that the 368 perception may reduce the number of people who are available as 369 nominees for a given position. 371 Having decisions made about incumbents and whether they were begin 372 returned made, and made public, before the target cutoff date for 373 nominations would eliminate the first of these problems and 374 significantly reduce the second. 376 4. Summary of Changes to RFC 3777 378 Some of the procedures described in this document could be put in 379 place without updating the current NomCom process, but [RFC3777] must 380 be updated to provide for the following actions: 382 1. Section 4, bullet 13 of [RFC3777] ties the announcement of 383 positions being reviewed to the call for NomCom volunteers ("The 384 Chair obtains the list of IESG and IAB positions to be reviewed 385 and announces it along with a solicitation for names of 386 volunteers from the IETF community willing to serve on the 387 nominating committee"). This document calls for the NomCom to be 388 selected and seated, and to evaluate relevant incumbents, before 389 announcing a list of positions that are unambiguously "open". 391 2. Section 5, bullet 14 of [RFC3777] calls for the NomCom to forward 392 candidates to the confirming bodies as a group ("specifying a 393 single candidate for each open position"). This document calls 394 for a two-stage forwarding - first, renewed incumbent candidates 395 are forwarded for confirmation, and then non-incumbent candidates 396 are forwarded for confirmation. 398 3. Given that the notion of "partial-slate confirmation" has been 399 contentious in past NomComs, it is probably best to insert 400 language that calls for confirming bodies to confirm renewed 401 incumbent candidates without waiting for a complete slate of 402 candidates. 404 5. Internationalization Considerations 406 This specification is about IETF Procedures. It has no effect on 407 internationalization issues. 409 6. IANA Considerations 411 This specification is about IETF Procedures. It has no effect on 412 IANA issues and does not contemplate any IANA actions. 414 7. Security considerations 416 This specification is about IETF Procedures for leadership selection. 417 It has no direct consequences for Internet security issues although 418 it is possible that it might produce a better IAB or IESG that might, 419 in turn, be more effective in dealing with those issues. 421 8. Acknowledgements 423 This draft is derived from, and draws on, a 2005 draft by the same 424 authors titled "Mode of Selection for Nomcom-selected IETF Leadership 425 Positions" [Nomcom-term]. That document mixed the specification in 426 this document with term-duration recommendations and was originally 427 written to apply to the IESG only. 429 9. References 431 9.1. Normative References 433 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 434 Recall Process: Operation of the Nominating and Recall 435 Committees", BCP 10, RFC 3777, June 2004. 437 9.2. Informative References 439 [Dawkins-Openlist] 440 Dawkins, S., "Nominating Committee Process: Open 441 Disclosure of Willing Nominees", May 2009, . 445 [Nomcom-term] 446 Klensin, J. and S. Dawkins, "Terms of Appointments for 447 NomCom-selected IETF Leadership Positions", June 2006. 449 [RFC1602] Huitema, C. and P. Gross, "The Internet Standards Process 450 -- Revision 2", RFC 1602, March 1994. 452 [RFC2027] Galvin, J., "IAB and IESG Selection, Confirmation, and 453 Recall Process: Operation of the Nominating and Recall 454 Committees", BCP 10, RFC 2027, October 1996. 456 Appendix A. Change Log 458 A.1. Changes in version -01 460 o The document has been modified to apply only to the IESG, making 461 other bodies matters for future determination. 463 o More detailed historical tables have been included. 465 o Minor editorial corrections have been applied. 467 Authors' Addresses 469 John C Klensin 470 1770 Massachusetts Ave, #322 471 Cambridge, MA 02140 472 USA 474 Phone: +1 617 491 5735 475 Email: john-ietf@jck.com 477 Spencer Dawkins 478 Huawei Technologies (USA) 479 1700 Alma Drive, Suite 100 480 Plano, TX 75075 481 US 483 Phone: +1 972 509 0309 484 Fax: +1 469 229 5397 485 Email: spencer@wonderhamster.org