idnits 2.17.00 (12 Aug 2021) /tmp/idnits39401/draft-leiba-term-limit-guidance-00.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 date (21 October 2021) is 205 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Leiba 3 Internet-Draft Futurewei Technologies 4 Intended status: Best Current Practice 21 October 2021 5 Expires: 24 April 2022 7 Guidance to the IETF Nominating Committee About Term Limits 8 draft-leiba-term-limit-guidance-00 10 Abstract 12 In order to encourage more turnover in the IETF management bodies, 13 this document provides strong guidance to the IETF Nominating 14 Committee with regard to limiting the number of consecutive terms a 15 given participant should be selected to serve in NomCom-appointed 16 positions. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 24 April 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Specific Guidance to the NomCom . . . . . . . . . . . . . . . 4 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 57 7. Informative References . . . . . . . . . . . . . . . . . . . 5 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1. Introduction 62 In order to encourage more turnover in the IETF management bodies, 63 this document provides strong guidance to the IETF Nominating 64 Committee (NomCom)[RFC8713] with regard to limiting the number of 65 consecutive terms a given participant should be selected to serve in 66 NomCom-appointed positions. 68 // The following paragraph is for draft discussion only and will be 69 // changed or removed before publication. 71 For convenience, this document will refer to NomCom-appointed 72 positions on the Internet Engineering Steering Group (IESG), the 73 Internet Architecture Board (IAB), and the IETF Administration LLC 74 Board of Directors (LLC) collectively as "leadership positions", or 75 just "leadership". We can decide on final nomenclature for that 76 after we've hashed out the other details in this proposal. 78 2. Background 80 The IETF community is best served when leadership changes at regular 81 intervals, leading to greater diversity of thought, vision, and 82 perspective, and avoiding "burnout" that can result from someone 83 serving in time-consuming and stressful positions for an extended 84 time. There have been occasional proposals for hard term limits, and 85 many in the community support that approach, but there is concern 86 about the effect of limiting NomComs too strictly. This document 87 takes an alternative approach of using clear and strong guidance to 88 NomComs, which they are expected to follow, while still giving them 89 the flexibility to evaluate specific situations and to "do the right 90 thing" when strict rules would be problematic. 92 This section lays out some principles that inform the guidance given 93 here. 95 The IESG comprises the Area Directors (ADs) from each of the IETF 96 technical areas, the IETF Chair (AD of the General Area), and the IAB 97 Chair (ex-officio). It is widely considered that much of an AD's 98 first year is spent learning the role and finding one's way. Because 99 of that, ADs who are doing well in the second year of their first 100 terms are generally re-appointed for a second term, taking advantage 101 of their experience and allowing them to use what they have learned. 102 Third terms are less common, and four terms or more are unusual, as 103 the role of an Area Director is a busy and stressful one. Burnout is 104 a danger, but even without that consideration the community thinks it 105 important to bring new vision and perspective into the AD position 106 regularly. 108 A complication often arises with respect to finding ADs: There are 109 frequently few -- sometimes only one or two -- volunteers to stand 110 for a particular AD position. Sometimes a NomCom has only an 111 incumbent candidate, and no other volunteers to choose from. While 112 some participants can serve -- and have served -- as ADs in more than 113 one area, AD positions are not readily interchangeable, making the 114 NomCom's work more difficult when these situations arise. 116 The IAB comprises members across the IETF technical areas. Because 117 its members are appointed "at large", rather than from specific 118 areas, there tends to be a broader pool of IAB candidates, giving 119 NomComs a greater abundance of choices than they have when selecting 120 Area Directors. 122 A challenge in selecting the IAB is that ADs who step down often 123 immediately vie for positions as IAB members. While the IAB is a 124 different body, with different roles and needs, this situation 125 nevertheless does not contribute to diversity in leadership, 126 revitalization of a stressed AD, or fresh perspectives on the IAB. 127 The community is particularly concerned with a pattern of ADs making 128 immediate transitions to the IAB. 130 The IETF Chair role is the busiest and most stressful, and benefits 131 strongly from recent experience on the IESG. "Recent", here, 132 requires judgment, of course, and a good candidate for IETF Chair 133 might be just finishing a term as a technical AD or might have held 134 such a role within the last few years. It is not desirable for term 135 limits to rule out IETF Chair candidates because they have been on 136 the IESG "too recently". 138 (This document is not covering the LLC just yet...) 140 The community considers it important that participants who take on 141 leadership positons return to the community (outside of leadership) 142 periodically, to serve as working group participants, document 143 editors, working group chairs, and directorate members. This allows 144 the community to benefit from what those in leadership have learned 145 and the experience they have developed. It also provides 146 opportunities for others in the community to step into leadership, 147 and benefits the individuals involved by allowing them to revitalize 148 and regenerate, developing a new set of perspectives, before they 149 consider additional terms in other leadership positions. 151 3. Specific Guidance to the NomCom 153 In general, an individual should be expected to serve no more than 154 two terms in *any* collective NomCom-appointed positions before 155 returning to the community for at least one year. As an example, if 156 a participant is selected for the IAB in 2020 and becomes an AD in 157 2022, that participant would be expected to take a "gap year" in 158 2024. NomComs should consider a third consecutive term with no gap 159 to be unusual, and should consider a fourth term to be exceptional, 160 only to be used in exceptional circumstances. The IESG and IAB 161 should consider such exceptional situations as needing analysis and 162 possible action to see that they do not persist. 164 An exception to the general guidance above is for appointment to IETF 165 Chair: It is expected that the individual selected as IETF Chair 166 might be a sitting AD or IAB member, or one who is just stepping down 167 from one of those roles, and that there might not be a gap year in 168 this case. 170 NomComs are, given this guidance, tasked with doing the right thing 171 and making the best choices for the IETF, with the understanding that 172 situations arise where firm rules do not work well and judgment is 173 critical. If a NomCom makes an appointment that this guidance 174 considers unusual or exceptional, it is important that the situation 175 be explained in the NomCom Chair's report to the confirming body, as 176 the confirmation process needs to consider the NomCom's choice to 177 deviate from this guidance, and needs to understand the situation 178 that has arisen. The NomCom Chair should also include an explanation 179 in the report to the community, to the extent possible within NomCom 180 confidentiality rules. 182 4. IANA Considerations 184 This document makes no request of IANA. 186 5. Security Considerations 188 This document is purely procedural, and there are no related security 189 considerations. 191 6. Acknowledgments 193 Thanks to Rich Salz for kicking off the discussion of term limits, 194 and to John Klensin, Brian Carpenter, Keith Moore, Mark Nottingham, 195 Kyle Rose, Eric Rescorla, Rob Sayre, Bob Hinden, Jaren Mauch, John 196 Levine, Joel Halpern, Michael Richardson, and others who participated 197 in the discussion and prompted the writing of this proposal. 199 7. Informative References 201 [RFC8713] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, 202 Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection, 203 Confirmation, and Recall Process: Operation of the IETF 204 Nominating and Recall Committees", BCP 10, RFC 8713, 205 DOI 10.17487/RFC8713, February 2020, 206 . 208 Author's Address 210 Barry Leiba 211 Futurewei Technologies 213 Email: barryleiba@computer.org 214 URI: http://internetmessagingtechnology.org/