idnits 2.17.1 draft-carpenter-community-leaders-01.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 (June 20, 2019) is 1743 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational June 20, 2019 5 Expires: December 22, 2019 7 Some Thoughts on IETF Community Leadership 8 draft-carpenter-community-leaders-01 10 Abstract 12 This is a personal view of what the IETF community might expect of 13 its members who serve in leadership positions such as Area Directors 14 and IAB members. It is intended as personal input to the Nominating 15 Committee, but posted as a draft since there is nothing private about 16 it. A particular emphasis is placed on the need for such members to 17 be responsive to the community as a whole rather than to impose 18 personal opinions. 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 December 22, 2019. 37 Copyright Notice 39 Copyright (c) 2019 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 2. Expectations . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 The IETF has a relatively open but hardly democratic way of choosing 65 those who serve the community as Area Directors, members of the 66 Internet Architecture Board, and as IETF Chair. Job descriptions are 67 open and candidate lists are open. Feedback on individuals is 68 intentionally confidential to the NomCom, which tends to limit 69 transparent discussion of both abilities and potential problems. 70 Indeed, we shouldn't be in the business of naming and shaming those 71 who are willing to serve us. However, as a community, we must make a 72 fuss about decisions we don't like, and persist when we see a 73 technical error going uncorrected. In particular we should make a 74 fuss about failures to adequately consult the community about 75 important decisions, when leaders appear to impose personal opinions. 76 We do have a formal appeals mechanism, we do have the opportunity to 77 send frank feedback to the NomCom every year, and we do in theory 78 have the ultimate weapon of a recall procedure. But ultimately, if 79 the NomCom appoints someone, they are normally there for several 80 years. 82 However, there's a gap in the above mechanisms. The job descriptions 83 mentioned above are written by the body where there is a vacancy: by 84 the IESG for Area Directors and the IETF Chair, and by the IAB for 85 its own membership. That's logical as far as it goes, but it doesn't 86 give the community as a whole the chance to say what we think we 87 expect of those who serve in leadership positions, beyond their 88 obligations to the IETF process rules and their technical expertise. 89 Also, even with the best of intentions, those bodies write job 90 descriptions to replicate themselves and what they see as a smooth- 91 running operation. There is little scope in the job descriptions for 92 describing desirable changes in the status quo. 94 To some extent this gap is filled by the formal documents that 95 describe the IETF process, in the IESG and IAB charters, and in the 96 Tao of the IETF. But there is little explicit description of how the 97 leadership is expected to behave. This draft is a personal version 98 of a more explicit approach. It's by no means definitive and has no 99 authority. Discussion (on ietf@ietf.org?) is welcome. 101 A personal note: I have served in the past on the IAB (including a 102 spell as Chair), and on the IESG as IETF Chair. I'm quite sure that 103 I didn't live up to the expectations that follow. The people who 104 serve on the IESG and IAB are fallible humans. But it seems 105 reasonable to tell them, and the NomCom, what we'd like. 107 The NomCom also has responsibilities to select members of the IETF 108 LLC Board and of the IETF Trust. Most of the considerations below 109 apply also to those positions, even though the emphasis here is on 110 the IESG and IAB. My request to the NomCom is to consider the issues 111 below when evaluating all candidates. 113 2. Expectations 115 First, we expect leadership. Although the IETF is basically an 116 organisation of equals, we need Area Directors, the IESG as a whole, 117 the IETF Chair, and the IAB to set directions and gently ensure that 118 we make progress in those directions. (Yes, the IETF has to move in 119 multiple directions at once.) So whatever else happens, we need the 120 ADs, the IAB members, and the IETF Chair to behave as leaders. In 121 this draft, I'll refer to them as "leaders" from now on. However, as 122 leaders, they are servants of the community, not autocrats. They are 123 not in charge and must not imagine that they are in charge; they 124 should not impose personal opinions. People who think they are being 125 appointed to be in charge hould not be appointed. 127 The IETF is based on rough consensus. So we expect the leaders to 128 consult and listen carefully to the community, and not just to the 129 loudest or most articulate voices in the community. We expect them 130 to be assiduous in seeking consensus, and in understanding the 131 reasons for dissent. In fact, we expect them to enquire carefully 132 into the reasons for dissent, and to treat dissenters respectfully. 133 Specifically, consensus in the IESG (or IAB) is not the same thing as 134 consensus in the IETF. We do expect the leaders to take decisions, 135 but only when it's time to do so: after consultations, after the 136 facts are in and the community consensus is clear. Decisiveness is 137 good. Arbitrary or rushed decisions are bad. 139 Precisely because dissent is healthy and consensus is usually rough 140 rather than complete, we expect discussions among the leaders to be 141 as public, transparent and documented as much as is reasonably 142 possible. Fuzzy explanations of decisions are not good enough. 144 We expect the leaders to question the way the IETF does business and 145 to change it if appropriate, subject of course to community debate 146 and consensus. 148 We naturally expect the leaders to leave their company and personal 149 loyalties at the door. More difficult, we expect them to set aside 150 their own technical biases and preferences. This is tricky, because 151 we need their technical expertise. But arbitrary decisions are bad. 153 We expect the leaders to remember that a much wider technical 154 community looks to the IETF (and to the IRTF, the IANA service, and 155 the RFC series) to serve and protect the technical future of the 156 Internet. So listening to the community is more than just listening 157 to the IETF. 159 The IAB and the IESG both have important responsibilities in 160 appointing community members to various positions, such as WG chairs, 161 specific oversight committees, liaisons, and the like. We expect 162 them to make these appointments based on the good of the community as 163 a whole, not on their own preferences or biases. In some cases, such 164 as the RFC Series, the IETF Trust, or IANA, the community is much 165 wider than the IETF: it is the entire Internet technical community. 167 We need our technical leaders to be patient with those who don't 168 understand. This isn't so much about technical issues, which we all 169 hopefully know how to deal with, but about the reasons why some part 170 of IETF process is the way it is, or why a BOF proposal was refused, 171 or why a WG wasn't chartered, or why a topic belongs in the IRTF, or 172 why some work has been redirected to the Independent Stream, or 173 whatever. It's all very obvious to people who've been in the IETF 174 for years. Not so obvious to the rest of the world. 176 We expect the leaders not to work too hard. The IESG in particular 177 works just as hard as it makes itself work. More precisely, today's 178 IESG defines the work load for its successors, by approving WG 179 charters. If fewer WGs are approved or renewed today, there will be 180 fewer drafts to process in two years' time. We expect the IESG to 181 say "no" quite often. In the case of BOFs and workshops, we also 182 expect the IAB to recommend "no" quite often. Of course, the "no" 183 should be clearly explained, and rooted in community consensus and 184 technical evaluations 186 Of course, the leaders will follow IETF process rules and IETF 187 etiquette. But we also expect them to use common sense when the 188 rules turn out to be stupid, or simply inapplicable to a particular 189 situation. Either suggest a change in the rules, or make an 190 exception, while telling the community what's going on and asking for 191 feedback. (One of the historical strengths of the IETF relative to 192 competing bodies was our ability to put good sense over over-specific 193 rules. We need to regain that.) 195 Finally, there is a well-known and very human side effect of serving 196 in a leadership position: hubris. The modern definition is 197 "excessive pride or self-confidence" but the ancient Greeks had a 198 more dramatic version: "excessive pride towards or defiance of the 199 gods, leading to nemesis." Whichever version you choose, it's bad. 200 We expect the leaders to remember that they are fallible and that, 201 after a few years, they will be ordinary members of the IETF 202 community again. If they become arbitrary or peremptory in their 203 temporary leadership roles, they may well regret it later. 205 3. Security Considerations 207 Security considerations are not discussed in this memo. 209 4. IANA Considerations 211 This document makes no request of the IANA. 213 5. Acknowledgements 215 I decided to write this based, not only on my own observations, but 216 also on comments and suggestions from several members of the 217 community over the years. Of course I am solely responsible for the 218 current text. 220 Appendix A. Change log 222 draft-carpenter-community-leaders-00, 2018-09-08: 224 Initial version 226 draft-carpenter-community-leaders-01, 2019-06-20: 228 Update for 2019-20 NomCom 230 Author's Address 232 Brian Carpenter 233 Department of Computer Science 234 University of Auckland 235 PB 92019 236 Auckland 1142 237 New Zealand 239 Email: brian.e.carpenter@gmail.com