idnits 2.17.1 draft-arkko-ietf-iasa-thoughts-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 182 has weird spacing: '...ing the model...' -- The document date (March 26, 2017) is 2587 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3935' is defined on line 288, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-daigle-iasa-retrospective-00 -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational March 26, 2017 5 Expires: September 27, 2017 7 Thoughts on IETF Administrative Support Activities (IASA) 8 draft-arkko-ietf-iasa-thoughts-00.txt 10 Abstract 12 This short memo outlines the author's thoughts about the challenges 13 and opportunities with the IETF's administrative support activities, 14 currently organised as part of the IETF Administrative Support 15 Activities (IASA), IETF Administrative Oversight Committee (IAOC), 16 and IETF Trust. 18 This memo is just input for discussion that the IETF community should 19 have. The memo is a part of the author's goal to document the status 20 and various challenges and opportunities in the context of the so 21 called "IASA 2.0" project. 23 The memo has no particular official standing, nor does it claim to 24 represent more than the authors' thinking at the time of writing. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 14, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Changes, Challenges, and Opportunities . . . . . . . . . . . 3 62 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Informative References . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 The arrangements relating to administrative support for the IETF 69 (IASA, RFC 4071 [RFC4071]) were created more than ten years ago, when 70 the IETF initially took charge of its own administration. The 71 arrangements have served the IETF well, but there's been considerable 72 change in the necessary tasks, in the world around us, and our own 73 expectations since the creation of the IASA. Looking forward, this 74 is a good time to ask what administrative arrangements best support 75 the IETF in the next ten years. 77 Background for this analysis are the various challenges and 78 frustrations we have experienced along the way, for instance around 79 meeting arrangements. But we also need to ask the bigger questions 80 about how the organisations are structured. What kind of support we 81 need in the coming years, from the point of view of the community, 82 IESG, IAB, IAOC, Trust, and our partners such as ISOC, meeting hosts 83 or contractors? Areas to look at include structure, financing and 84 sponsorship arrangements, organisation, and ways of working. This is 85 the context of the so called "IASA 2.0" project [IASA20]. 87 This document gives the author's view on structure and ways of 88 working in the current IASA arrangements. This memo is just input 89 for discussion that the IETF community should have. The memo is a 90 part of the author's goal to document the status and various 91 challenges and opportunities in IASA. 93 The memo has no particular official standing, nor does it claim to 94 represent more than the author's thinking at the time of writing. 96 The authors's views on financing aspects have been discussed in 97 [I-D.arkko-ietf-finance-thoughts]. A collection of early views from 98 a community process on IASA issues has been published in 99 [I-D.hall-iasa20-workshops-report]. 101 2. Changes, Challenges, and Opportunities 103 It is useful to understand the evolution of the IASA arrangements 104 over time. Leslie Daigle's memo discusses the changes from the 105 initial IASA arrangements to today [I-D.daigle-iasa-retrospective]. 107 But it is also necessary to understand how far along we have come 108 from even the early 2000s. As Leslie's draft notes: 110 A first priority was to establish meeting dates, locations and 111 contracts more than a year in advance, to improve contract 112 negotiating positions, costs, and provide clarity for attendee 113 planning. (Historical data point: the early 2004 Seoul IETF 114 meeting did not have a hotel contract booked in December of 2003). 116 So, while there are a number of challenges, overall the system has 117 served the IETF well. 119 Section 5 of Leslie's draft covers some of issues: 121 o Do current arrangements match the tasks and organisation that have 122 grown larger? 124 o Today's IETF is international and diverse, which poses challenges 125 to meeting site selection. 127 o Too many sponsorship and other aspects of the organisation are 128 focused around the meetings. 130 o The line between IETF and ISOC organisation has not been clear- 131 cut, which has lead to issues around transparency, budgeting, and, 132 perhaps more importantly, clarity of control. 134 o The role of ISOC in representing IETF towards sponsors and donors 135 is sometimes unclear. 137 o Staffing that in practice extends beyond one employee, with 138 structure and control that was designed for one. 140 o IAOC membership is structurally challenged, with a significant 141 fraction of members having full-time IETF responsibilities 142 elsewhere. 144 o The IAOC also has a limited ability to pick chairpersons, given 145 that some of the members are not eligible for being a chair. 147 o Community participation centers on meeting arrangements, with only 148 a small number of volunteers willing to be a part of the board. 150 In addition, there have been issues around transparency, particularly 151 relating to the meeting location selection process. A change in 152 spring 2016 led to the early release of cities under consideration, 153 to help spot potential issues early. However, other issues remain in 154 discussion, for instance relating to publishing future hotel 155 contracts. 157 There are also many issues that are not visible externally. For 158 instance, the IAOC is a board for oversight, but the lines between 159 oversight and execution are blurred. Particularly when staff is 160 overloaded. Almost anything that the board does needs staff 161 assistance, so any effort in helping move topics forward adds to the 162 overload situation. This situation is particlarly exacerbated when 163 something unexpected happens, such as was the case with the Zika- 164 virus concerns. 166 But many of the specific issues are by-products of the way that we 167 have structured the activities at IETF. Specifically, the author 168 believes that the following issues are root causes of many of the 169 difficulties: 171 Internal organisational structure 173 There is obviously a need for a central entity to keep the full 174 picture of budget and activities, but the current organisation was 175 designed at a time when we expected to have a board and one 176 administrative director. While the organisation has grown, and 177 for instance IAOC committees taking on more responsibility, we 178 still operate largely on this simple model but having to deal with 179 many more vendors and topics than before. The author's opinion is 180 that the IETF would benefit from looking at evolving the structure 181 and practices, for instance, relating to division and delegation 182 of responsibilities, and making the model less dependent on 183 a single director. 185 Bundling the IAOC with IETF Trust 187 While the IETF Trust has a budget and regularly deals with IETF 188 lawyer and the legal team, the schedule and nature of the work in 189 the Trust and the rest of the IASA is quite different. The 190 bundling of these organisations with the same members and same 191 meeting slots has hurt our ability to deal with both as 192 effectively as we should. And it certainly adds to the workload 193 and volunteer problems. The Trust is a stable, long-term entity 194 that deals mostly with legal questions, and typically has low 195 workload. Trust decisions have a very long-lasting effect on 196 IETF, however. The IAOC deals with a large financial 197 responsibility, and is a more high-activity entity. 199 Expertise and willigness to work on administration 201 IETF participants are naturally more interested in technology 202 evolution than details of administration or meeting arrangements, 203 unless those arrangements lead to problems. While there are many 204 highly capable persons in the IETF, with a lot of experience of 205 managing budgets and contracts, it generally has not been easy to 206 find volunteers for IASA-related tasks. 208 This would point to a need to re-evaluate division of work between 209 volunteer boards and contracted, professional services. 211 Meeting planning processes 213 Another area where some re-thinking would be useful are the 214 meeting planning processes. Involving community earlier in the 215 location choices and writing a community-specified mandatory 216 requirements for meeting sites seem like obviously useful things, 217 but have started only recently, and have not yet found their 218 perfect forms. 220 Re-thinking what we as community do and how much we contract out 221 would also be useful here, of course as long as the community has 222 full visibility and ability to affect the decisions. 224 On a more practical level, a big fraction of the effort within the 225 IASA is spent on meeting arrangements. Community input indicates 226 that while some new locations are necessary, repeat visits are 227 desirable. Indeed, 5 out of 6 future meetings are to locations 228 that the IETF has been to recently (and that one new location was 229 the subject of much controversy). 231 Given the repetitive schedule, one would assume that this helps 232 meeting planning. While some groundwork (such as site visits) are 233 not unnecessarily repeated, and while contracts often have to 234 renegotiated, much of the rest of the process is run through as if 235 we were making completely independent decisions. This seems like 236 a missed opportunity for rationalisation, or further delegation to 237 vendors specialising in meeting organisation. Further use of 238 repeats with multi-meeting agreements would also seem to be 239 sensible. 241 Note: no organisation can rely on a very small number of possible 242 meeting sites, due to the danger of becoming unable to attain 243 competitive pricing. So the pool of possible meeting sites has to 244 be still large enough, and be occasionally refreshed. 246 Further clarity of roles between the IETF and ISOC 248 The interface between the IETF and ISOC has evolved in natural 249 ways over the years. For instance, improvements in properly 250 accounting for in-kind contributions have made budgeting clearer. 251 And ISOC's support activities such as sponsorship acquisition are 252 obviously very important and useful for the IETF. Budgeting 253 clarity is only one part of an interface, however, and further 254 work is needed, for instance, in the area of how the different 255 support activities are managed. It might even be useful to 256 refactor the responsibilities between IETF and ISOC. As an 257 example, there's a very clear relationship between the IAOC and 258 the IAD, but it is less clear how ISOC and IETF co-operate in 259 managing a particular support activity. 261 3. Acknowledgements 263 The author would like to thank Kathy Brown, Andrew Sullivan, Ray 264 Pelletier, Leslie Daigle, Alissa Cooper, Ted Hardie, Tobias Gondrom, 265 and Gonzalo Camarillo for interesting discussions in this space. 267 4. Informative References 269 [I-D.arkko-ietf-finance-thoughts] 270 Arkko, J., "Thoughts on IETF Finance Arrangements", draft- 271 arkko-ietf-finance-thoughts-00 (work in progress), 272 February 2017. 274 [I-D.daigle-iasa-retrospective] 275 Daigle, L., "After the first decade: IASA Retrospective", 276 draft-daigle-iasa-retrospective-00 (work in progress), 277 October 2016. 279 [I-D.hall-iasa20-workshops-report] 280 Hall, J. and J. Mahoney, "Report from the IASA 2.0 Virtual 281 Workshops", draft-hall-iasa20-workshops-report-00 (work in 282 progress), March 2017. 284 [IASA20] Arkko, J., "Proposed Project: IETF Administrative Support 285 2.0", November 2016 (https://www.ietf.org/blog/2016/11/ 286 proposed-project-ietf-administrative-support-2-0/). 288 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 289 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 290 . 292 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 293 IETF Administrative Support Activity (IASA)", BCP 101, 294 RFC 4071, DOI 10.17487/RFC4071, April 2005, 295 . 297 Author's Address 299 Jari Arkko 300 Ericsson 301 Kauniainen 02700 302 Finland 304 Email: jari.arkko@piuha.net