idnits 2.17.1 draft-klensin-nomcom-term-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (October 22, 2021) is 914 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft October 22, 2021 4 Intended status: Best Current Practice 5 Expires: April 25, 2022 7 Terms of Appointments for Nomcom-selected IETF Leadership Positions 8 draft-klensin-nomcom-term-02 10 Abstract 12 A consensus is emerging in the IETF that very long tenure in 13 leadership roles is not in the best interests of the community. 14 While, in theory, that advice could simply be given to the Nomcom, 15 there is reason to believe that a different model for consideration 16 of renewal or replacement for members of the leadership would be more 17 efficient for the Nomcom and would impose less hardship on incumbents 18 and the community. This document outlines that alternate method. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 25, 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Mailing List . . . . . . . . . . . . . . . . . . . . . . 3 56 2. The Review and Clean Nomination Model . . . . . . . . . . . . 3 57 2.1. Phase 1: Review of Incumbents . . . . . . . . . . . . . . 4 58 2.2. Phase 2: Nomination and Selection of New Candidates . . . 5 59 2.3. Revised schedule . . . . . . . . . . . . . . . . . . . . 5 60 3. Previous Discussion Points . . . . . . . . . . . . . . . . . 5 61 3.1. IESG-only, or all Nomcom appointments? . . . . . . . . . 6 62 3.2. Justification for third terms? . . . . . . . . . . . . . 6 63 3.3. Guidance, or hard limit on service length? . . . . . . . 6 64 4. Internationalization Considerations . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security considerations . . . . . . . . . . . . . . . . . . . 7 67 7. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 70 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 71 A.1. Changes from draft-klensin-Nomcom-term-01 (2006-06-24) 72 to -03 . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Context and Note in Draft: This Internet-Draft is a small update of a 78 version with the same name that was last posted and discussed in 79 2006. The problems it identified still exist in 2021 and the 80 proposed solution still seems relevant. However, the original was 81 written more as a discussion piece than as a formal proposal and this 82 revision continues in that form. Should the idea get traction, much 83 of the style will need to be modified and it will need to be adapted 84 to formally update RFC 8713. 86 A consensus is emerging in the IETF that very long tenure in 87 leadership roles is not in the best interests of the community. 88 While, in theory, that advice could simply be given to the Nomcom, 89 there is reason to believe that a different model for consideration 90 of renewal or replacement for members of the leadership would be more 91 efficient for the Nomcom and would impose less hardship on incumbents 92 and the community. This document outlines that alternate method. 94 1.1. Mailing List 96 This proposal is under discussion on the gendispatch@ietf.org list. 98 2. The Review and Clean Nomination Model 100 The current nomination process pits incumbents, incumbent 101 performance, and questions of stability in the IESG against potential 102 other candidates. It also gives incumbents and the nomcom no 103 explicit guidance about how many terms someone should serve. This is 104 undesirable for a number of reasons. It creates the notion of 105 incumbents being "fired" rather than honorably retired to the 106 citizenry after a brief period of contributing to the community by 107 assuming a leadership role. And, while there is significant value in 108 treating stability as a goal, it can also create distortions about 109 the degree of support various ideas have in the community and the 110 impression of in-groups. 112 This specification changes the current model by reintroducing some 113 principles that the authors believe are widely held in the community 114 and optimizing the selection process to support those principles. 115 The principles include: 117 o Service in the IETF's leadership bodies is a short-term 118 contribution to the community, not a career. Indeed, assuming 119 those positions may be considered a responsibility to the 120 community. 122 o It takes long enough to learn the job of being an effective AD 123 that, in general, having someone retire after a single two-year 124 term is uneconomic for the community. 126 o Just as retirement of an AD after one term should be considered a 127 major step because of the inefficiencies of the learning period, 128 the six-month or more period in which an incumbent is uncertain 129 about whether work should be planned that spans the "first meeting 130 of the next year" introduces inefficiencies that should be 131 minimized to the degree possible. 133 o A demonstrated shortage of people willing to do work in the IETF 134 should be taken as an indication that there is insufficient real 135 community interest in the work to reach a meaningful consensus 136 about high-quality results. While that position appears to be 137 reasonably well-understood with regard to the number of active 138 IETF participants interested in putting a working group together, 139 and in finding leadership for working groups, the same principle 140 probably should be applied to ADs and areas: if there are only one 141 or two people willing and qualified to do the AD job, that may be 142 an indication that the IETF should review the appropriateness of 143 that area's existence or definition. 145 To deal effectively with these problems, the Nomcom consideration and 146 evaluation process is divided into two phases. 148 2.1. Phase 1: Review of Incumbents 150 Incumbent performance should be evaluated, not compared to potential 151 other candidates or replacements. The incumbent will always have 152 more experience. An AD who has done his or her job well, will have 153 accumulated strong proponents and probably strong detractors. Other 154 candidates are always risks, and direct comparison is inevitably 155 difficult. 157 In Phase 1, the Nomcom will evaluate the performance of incumbents, 158 collecting information from the community as needed to do that. The 159 Nomcom is instructed that an incumbent should be returned once (i.e., 160 permitted/encouraged to serve two terms) unless there is strong 161 evidence of problems (e.g., incompetence, inability to work with WGs, 162 inability to work with other ADs, non-feasance, or malfeasance). 163 Conversely, the Nomcom should assume that it is better to return an 164 incumbent who has served two terms to the community and active WG 165 work unless some special circumstances apply. 167 While this process allows flexibility, the Nomcom is instructed that 168 "special circumstances" should be a rare occurance, based on what is 169 best for the affected area, the IESG, and the IETF as a whole. 170 Simply doing an outstanding job as an AD should not constitute 171 "special circumstances" that would justify a third term. 173 The level of special circumstances required for a fourth, or 174 subsequent, term should be required to be much higher than that for a 175 third: the intent is to make more than three terms a rare and nearly 176 impossible event without formally prohibiting that through a term 177 limit: it is important that the Nomcom retain flexibility and the 178 opportunity to judge special circumstances. 180 Discussions between the Nomcom and a candidate as to whether that 181 candidate is willing to serve again should be covered by the Nomcom's 182 normal privacy rules except as mutually agreed. If the Nomcom 183 chooses to not return a candidate who is willing to serve, the 184 expectation is that this will be indistinguishable to the community 185 from the candidate voluntarily stepping down. Under normal 186 circumstances, the Nomcom is expected to conduct informational 187 evaluations of even those candidates who have chosen to step down 188 (the evaluations may inform later choices), but such candidates may 189 negotiate with the Nomcom as appropriate, perhaps supplying in-depth 190 analysis of the relevant Area and its status and issues as an 191 alternative. 193 At the end of this phase, the Nomcom submits the list of returning 194 candidates to the IAB as usual. The IAB makes its decision and the 195 choices are announced to the community. The list of (remaining) open 196 slots is then announced to the community and nominations and 197 recommendations sought. Any incumbent who is not returned in this 198 phase is not eligible for the relevant position in the second phase. 200 2.2. Phase 2: Nomination and Selection of New Candidates 202 This procedure works exactly as described in [RFC8713], with the 203 understanding that no incumbent will ever be a candidate for the same 204 position under this process. As a side-effect, the process makes it 205 more difficult than it has traditionally been to shift people around 206 within the IESG: it is considered an explicit corollary to the 207 principles above that an incumbent AD is one area should normally 208 have working experience within one or more WGs in a new area before 209 being considered as a candidate for AD in that area. 211 2.3. Revised schedule 213 [[to be supplied]] 215 The authors are aware of other proposals that would also affect the 216 Nomcom timeline. Rather than trying to develop a revised schedule on 217 a per-proposal basis, we suggest that one Nomcom schedule revision be 218 considered, based on this and other proposals that would be 219 accommodated. 221 3. Previous Discussion Points 223 In informal discussions before the initial version of this draft was 224 completed and posted, there was considerable discussion on three 225 points - whether this proposal should apply only to IESG 226 appointments, or to all Nomcom appointments, whether "doing an 227 outstanding job" is justification for third terms, and whether this 228 proposal should contain a statement of guidance, or hard term limits. 230 Reasonable people disagreed on both of these points, but the proposal 231 authors made choices. 233 The community will need to discuss, and decide upon, these issues. 235 3.1. IESG-only, or all Nomcom appointments? 237 This specification has been written to apply to the IESG only, since 238 the IESG's operational role and observed rates of AD burnout make it 239 most obviously important there. 241 It is possible that consideration should be given as to whether a 242 similar or identical model should be applied to the IAB and/or other 243 appointments made by the Nomcom. 245 3.2. Justification for third terms? 247 This specification is written to allow Nomcom to return ADs for third 248 terms, and beyond, due to "special circumstances". One question 249 we've been asked is whether "doing an outstanding job" should be 250 included in "special circumstances". 252 While our intention is to provide guidance to Nomcom, rather than 253 rules, this specification proposes that this guidance be "no". 255 o The community is better served by having former ADs returning to 256 technical work. A consistent criticism of the current working 257 group process is that specifications often lack sufficient cross- 258 area review when they are forwarded for publication. ADs provide 259 this type of review, but currently-serving ADs don't have time to 260 provide reviews early in the development of a draft, where it is 261 most useful and most likely to have a positive impact. 263 o Allowing "doing an outstanding job" to constitute "special 264 circumstances" removes deterministic benefits of this model. The 265 intention is that ADs return to the community after two terms. It 266 is desired that all ADs "do an outstanding job" - this proposal 267 would remove the ADs who do not, after their first term - but Only 268 in Lake Woebegon are all the children above average, and Lake 269 Wobegon is a fictitious place. 271 o We also note that former ADs are often asked to serve as working 272 group chairs in difficult situations, to help with BOFs and WG 273 charter discussions, and to carry out assignments that benefit 274 from AD experience but do not require the assignee to be a serving 275 AD. 277 3.3. Guidance, or hard limit on service length? 279 There was considerable discussion about whether it was better to 280 offer the Nomcom the guidance above, discouraging terms beyond the 281 second, or whether to flatly prohibit more than two terms. One group 282 believed that giving the Nomcom a little extra flexibility was a good 283 idea; the other believed that any additional flexibility would likely 284 lead to very long terms since there would always be a reason to make 285 an exception. 287 The authors of this proposal prefer to offer Nomcom guidance, rather 288 than rules. To take one example - if the Nomcom believes that 289 returning a third-term AD is appropriate (due, perhaps, to serving 290 area directors stepping down before the end of second terms), we 291 prefer to allow Nomcom this flexibility, rather than restrict them to 292 a course of action that seems ill-advised. 294 4. Internationalization Considerations 296 This specification is about IETF Procedures. It has no impact on 297 internationalization issues. 299 5. IANA Considerations 301 This specification is about IETF Procedures. It has no impact on 302 IANA issues and does not contemplate any IANA actions. 304 6. Security considerations 306 This specification is about IETF Procedures for leadership selection. 307 It has no impact on Internet security issues. 309 7. Contributor 311 Spencer Dawson was co-author of the 2005-2006 versions of this draft 312 and contributed very significantly to the thinking that went into 313 them. It was not possible to contact him and get his review and 314 assent before posting this version, so his is identified him as a 315 Contributor but may be moved back to authorship in the future. 317 8. Acknowledgements 319 [[ to be supplied ]] 321 9. Normative References 323 [RFC8713] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, 324 Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection, 325 Confirmation, and Recall Process: Operation of the IETF 326 Nominating and Recall Committees", BCP 10, RFC 8713, 327 DOI 10.17487/RFC8713, February 2020, 328 . 330 Appendix A. Change Log 332 [[RFC Editor: Please remove this section before publication.]] 334 A.1. Changes from draft-klensin-Nomcom-term-01 (2006-06-24) to -03 336 o Updated contact information, a reference, and changed needed to 337 get from xml2rfc v1 to v2. 339 o Added introductory note and updated target mailing list. 341 o Moved Spencer (I hope temporarily) to "Contributor". 343 Author's Address 345 John C Klensin 346 1770 Massachusetts Ave, #322 347 Cambridge, MA 02140 348 USA 350 Phone: +1 617 491 5735 351 Email: john-ietf@jck.com