idnits 2.17.1 draft-carpenter-community-leaders-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 (September 8, 2018) is 2057 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 September 8, 2018 5 Expires: March 12, 2019 7 Some Thoughts on IETF Community Leadership 8 draft-carpenter-community-leaders-00 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. 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 March 12, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Expectations . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 57 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 5 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1. Introduction 62 The IETF has a relatively open but not exactly democratic way of 63 choosing those who serve the community as Area Directors, members of 64 the Internet Architecture Board, and as IETF Chair. Job descriptions 65 are open and candidate lists are open. Feedback on individuals is 66 intentionally confidential to the NomCom, which in my opinion is 67 correct. We shouldn't be in the business of naming and shaming those 68 who are willing to serve us. As a community, we must not hesitate to 69 make a fuss about decisions we don't like, or to insist when we see a 70 technical error going uncorrected. We do have a formal appeals 71 mechanism, we do have the opportunity to send frank feedback to the 72 NomCom every year, and we do in theory have the ultimate weapon of a 73 recall procedure. 75 However, there's a gap in the above mechanisms. The job descriptions 76 mentioned above are written by the body where there is a vacancy: by 77 the IESG for Area Directors and the IETF Chair, and by the IAB for 78 its own membership. That's logical as far as it goes, but it doesn't 79 give the community as a whole the chance to say what we think we 80 expect of those who serve in leadership positions, beyond their 81 obligations to the IETF process rules and their technical expertise. 82 Also, even with the best of intentions, those bodies write job 83 descriptions to replicate themselves and what they see as a smooth- 84 running operation. There is little scope in the job descriptions for 85 describing desirable changes in the status quo. 87 To some extent this gap is filled by the formal documents that 88 describe the IETF process, in the IESG and IAB charters, and in the 89 Tao of the IETF. But there is little explicit description of how the 90 leadership is expected to behave. This draft is a personal version 91 of a more explicit approach. It's by no means definitive and has no 92 authority. Discussion (on ietf@ietf.org?) is welcome. 94 A personal note: I have served in the past on the IAB (including a 95 spell as Chair), and on the IESG as IETF Chair. I'm quite sure that 96 I didn't live up to the expectations that follow. The people who 97 serve on the IESG and IAB are fallible humans. But it seems 98 reasonable to tell them, and the NomCom, what we'd like. 100 The NomCom also has responsibilities to select members of the future 101 IETF Administration LLC Board and of the IETF Trust. Most of the 102 considerations below apply also to those positions, even though the 103 emphasis here is on the IESG and IAB. My request to the NomCom is to 104 consider the issues below when evaluating all candidates. 106 2. Expectations 108 First, we expect leadership. Although the IETF is basically an 109 organisation of equals, we need Area Directors, the IESG as a whole, 110 the IETF Chair, and the IAB to set directions and gently ensure that 111 we make progress in those directions. (Yes, the IETF has to move in 112 multiple directions at once.) So whatever else happens, we need the 113 ADs, the IAB members, and the IETF Chair to behave as leaders. In 114 this draft, I'll refer to them as "leaders" from now on. However, as 115 leaders, they are servants of the community, not autocrats. 117 But at the same time, the IETF is based on rough consensus. So we 118 expect the leaders to listen carefully to the community, and not just 119 to the loudest or most articulate voices in the community. We expect 120 them to be assiduous in seeking consensus, and in understanding the 121 reasons for dissent. In fact, we expect them to enquire carefully 122 into the reasons for dissent, and to treat dissenters respectfully. 123 Specifically, consensus in the IESG (or IAB) is not the same thing as 124 consensus in the IETF. We do expect the leaders to take decisions, 125 but only when it's time to do so: after the facts are in and the 126 community consensus is clear. Decisiveness is good. Arbitrary or 127 rushed decisions are bad. 129 Precisely because dissent is healthy and consensus is usually rough 130 rather than complete, we expect discussions among the leaders to be 131 as public, transparent and documented as much as is reasonably 132 possible. 134 We expect the leaders to question the way the IETF does business and 135 to change it if appropriate, subject of course to community debate 136 and consensus. 138 We naturally expect the leaders to leave their company and personal 139 loyalties at the door. More difficult, we expect them to set aside 140 their own technical biases and preferences. This is tricky, because 141 we need their technical expertise. But arbitrary decisions are bad. 143 We expect the leaders to remember that a much wider technical 144 community looks to the IETF (and to the IRTF, the IANA service, and 145 the RFC series) to serve and protect the technical future of the 146 Internet. So listening to the community is more than just listening 147 to the IETF. 149 The IAB and the IESG both have important responsibilities in 150 appointing community members to various positions, such as WG chairs, 151 specific oversight committees, and the like. We expect them to make 152 these appointments based on the good of the community as a whole, not 153 on their own preferences or biases. 155 We need our technical leaders to be patient with those who don't 156 understand. This isn't so much about technical issues, which we all 157 presumably know how to deal with, but about the reasons why some part 158 of IETF process is the way it is, or why a BOF proposal was refused, 159 or why a WG wasn't chartered, or why a topic belongs in the IRTF, or 160 why some work has been redirected to the Independent Stream, or 161 whatever. It's all very obvious to people who've been in the IETF 162 for years. Not so obvious to the rest of the world. 164 We expect the leaders not to work too hard. The IESG in particular 165 works just as hard as it makes itself work. More precisely, today's 166 IESG defines the work load for its successors, by approving WG 167 charters. If fewer WGs are approved or renewed today, there will be 168 fewer drafts to process in two years' time. We expect the IESG to 169 say "no" quite often. In the case of BOFs and workshops, we also 170 expect the IAB to recommend "no" quite often. Of course, the "no" 171 should be clearly explained, and rooted in community consensus and 172 technical evaluations 174 Of course, the leaders will follow IETF process rules and IETF 175 etiquette. But we also expect them to use common sense when the 176 rules turn out to be stupid, or simply inapplicable to a particular 177 situation. Either suggest a change in the rules, or make an 178 exception, while telling the community what's going on and asking for 179 feedback. (One of the historical strengths of the IETF relative to 180 competing bodies is our ability to put good sense over over-specific 181 rules.) 183 Finally, there is a well-known and very human side effect of serving 184 in a leadership position: hubris. The modern definition is 185 "excessive pride or self-confidence" but the ancient Greeks had a 186 more dramatic version: "excessive pride towards or defiance of the 187 gods, leading to nemesis." Whichever version you choose, it's bad. 188 We expect the leaders to remember that they are fallible and that, 189 after a few years, they will be ordinary members of the IETF 190 community again. 192 3. Security Considerations 194 Security considerations are not discussed in this memo. 196 4. IANA Considerations 198 This document makes no request of the IANA. 200 5. Acknowledgements 202 I decided to write this based, not only on my own observations, but 203 also on comments and suggestions from several members of the 204 community over the years. Of course I am solely responsible for the 205 current text. 207 Appendix A. Change log 209 draft-carpenter-community-leaders-00, 2018-09-08: 211 Initial version 213 Author's Address 215 Brian Carpenter 216 Department of Computer Science 217 University of Auckland 218 PB 92019 219 Auckland 1142 220 New Zealand 222 Email: brian.e.carpenter@gmail.com