idnits 2.17.00 (12 Aug 2021) /tmp/idnits32996/draft-haberman-iasa20dt-recs-03.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 -- The document date (November 27, 2018) is 1264 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission B. Haberman, Ed. 3 Internet-Draft Johns Hopkins University 4 Intended status: Informational J. Arkko 5 Expires: May 31, 2019 Ericsson Research 6 L. Daigle 7 Thinking Cat Enterprises LLC 8 J. Livingood 9 Comcast 10 JL. Hall 11 CDT 12 E. Rescorla 13 RTFM, Inc. 14 November 27, 2018 16 IASA 2.0 Design Team Recommendations 17 draft-haberman-iasa20dt-recs-03.txt 19 Abstract 21 The arrangements relating to administrative support for the IETF were 22 created more than ten years ago. Since then, there has been 23 considerable change in the tasks and in our own expectations. The 24 IETF community has discussed these changes and the problems they 25 cause. The community has some sense of the properties they expect 26 from future arrangements, including those related to structure, 27 organization, personnel, and transparency. 29 This document is a product of a design team, focused on providing 30 additional information to the community about solution options, as 31 well as supporting analysis of the implications of those options. 32 This document reflects the final snapshot of the design team 33 discussion and is published for historical posterity. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 31, 2019. 51 Copyright Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.2. Current IASA Arrangements . . . . . . . . . . . . . . . . 5 72 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1. Lack of Clarity . . . . . . . . . . . . . . . . . . . . . 7 74 3.1.1. Responsibility . . . . . . . . . . . . . . . . . . . 7 75 3.1.2. Representation . . . . . . . . . . . . . . . . . . . 7 76 3.1.3. Authority . . . . . . . . . . . . . . . . . . . . . . 8 77 3.1.4. Oversight . . . . . . . . . . . . . . . . . . . . . . 8 78 3.2. Lack of Resources . . . . . . . . . . . . . . . . . . . . 9 79 3.2.1. Volunteers . . . . . . . . . . . . . . . . . . . . . 9 80 3.2.2. Staff . . . . . . . . . . . . . . . . . . . . . . . . 9 81 3.3. Lack of Transparency . . . . . . . . . . . . . . . . . . 9 82 3.4. Funding/Operating Model Mismatch and Rising Costs . . . . 10 83 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 5. Reorganization Options . . . . . . . . . . . . . . . . . . . 13 85 5.1. Overall Structure . . . . . . . . . . . . . . . . . . . . 14 86 5.1.1. IASA++ . . . . . . . . . . . . . . . . . . . . . . . 14 87 5.1.2. ISOC Subsidiary . . . . . . . . . . . . . . . . . . . 15 88 5.1.3. Independent Organization . . . . . . . . . . . . . . 16 89 5.2. IETFAdminOrg and the Relationship with IETF . . . . . . . 17 90 5.3. Oversight for IETFAdminOrg . . . . . . . . . . . . . . . 18 91 5.3.1. Board Selection . . . . . . . . . . . . . . . . . . . 19 92 5.3.2. Advisory Council . . . . . . . . . . . . . . . . . . 20 93 5.3.3. Board Changes in IASA++ . . . . . . . . . . . . . . . 20 94 5.4. Transparency . . . . . . . . . . . . . . . . . . . . . . 21 95 5.5. Staff Structure . . . . . . . . . . . . . . . . . . . . . 21 96 5.6. Funding . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 5.6.1. One-time costs . . . . . . . . . . . . . . . . . . . 22 98 5.6.2. Sources and Stability . . . . . . . . . . . . . . . . 23 99 5.6.3. Level . . . . . . . . . . . . . . . . . . . . . . . . 24 100 6. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 6.1. Comparison to Goals . . . . . . . . . . . . . . . . . . . 26 102 6.2. Financial Impacts . . . . . . . . . . . . . . . . . . . . 28 103 6.3. Other Impacts . . . . . . . . . . . . . . . . . . . . . . 29 104 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 7.1. Transition Plan . . . . . . . . . . . . . . . . . . . . . 30 106 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 107 9. Informative References . . . . . . . . . . . . . . . . . . . 30 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 110 1. Introduction 112 The arrangements relating to administrative support for the IETF 113 (referred to as the "IETF Administrative Support Activity" (IASA) 114 [RFC4071]) were created more than ten years ago, when the IETF 115 initially took charge of its own administration. The arrangements 116 have served the IETF reasonably well, but there's been considerable 117 change in the necessary tasks, in the world around us, and our own 118 expectations since the creation of the IASA. What administrative 119 arrangements best support the IETF in the next ten years? 121 The system has experienced various challenges and frustrations along 122 the way, for instance around meeting arrangements. There are also 123 some bigger questions about how the organizations are structured, for 124 instance about the division of responsibilities between IETF and The 125 Internet Society (ISOC). 127 The IETF community has discussed and continues to discuss these 128 topics, most recently on the "IASA 2.0" mailing list and BOFs at 129 IETFs 98 and 99. Alissa Cooper, the Chair of the IETF, convened a 130 small design team to start evaluating potential options going 131 forward. The purpose of the design team is to provide material that 132 informs the community discussion, both in terms of providing a bit 133 more worked through solution ideas, as well as supporting analysis of 134 the implications of those options. This information, along with all 135 other input provided in the discussion, hopefully helps the community 136 and IETF leadership decide what next steps to take. 138 To be clear, the community is in charge of adopting any 139 recommendations or making any decisions. This draft, the final 140 output of the design team's considerations, has no particular 141 official standing. It should also be noted that IETF administrative 142 matters have been organized jointly with ISOC, and it is important 143 that ISOC continue to be involved in IETF's reorganization. 145 The design team seeks feedback particularly on three aspects: 147 o If the set of options outlined in this draft covers the options 148 that should be looked at. 150 o If the analysis of the implications of the options is correct. 152 o Which direction the community would like to take the work in 153 evolving IASA. 155 It should of course be acknowledged that there is no perfect, or even 156 great solution. Changing the IETF organizational structure will not 157 fix every problem and may bring new problems of its own. But it 158 seems that the current structure is brittle and the issues around 159 lack of staff and authority, clarity, and responsibility are 160 sufficiently serious to warrant exploring different options. 162 This document defines the goals of the IASA 2.0 effort in terms of an 163 abstract administrative structure, called IETFAdminOrg. Then, three 164 possible implementations of IETFAdminOrg are considered in the light 165 of how they could be used to address the goals. In no case does 166 IETFAdminOrg have anything to do with defining, changing, or 167 operating the IETF's standards process and structure (participants 168 (not members), WGs, IESG and so on), which remain as they stand 169 today. In particular, none of the options lead to the IETF becoming 170 a formal organisation of any sort. 172 As a base for this work there was a good articulation of the set of 173 problems we are facing in [I-D.hall-iasa20-workshops-report] and 174 [I-D.daigle-iasa-retrospective]. The community discussion seems have 175 indicated also some of the outcome properties that are expected. 177 The next two sections (Section 2 and Section 3) describe the 178 background and summarize the challenges noted in the community 179 discussion. The two sections after that (Section 4 and Section 5) 180 describe the goals and primary options for changes. The following 181 two sections (Section 6 and Section 7) focus on analysis of the 182 different options along with conclusions. 184 2. Background 186 2.1. Terminology 188 The following acronyms are used in this document: 190 o IASA - IETF Administrative Support Activity - An organized 191 activity that provides administrative support for the IETF, the 192 IAB, and the IESG. 194 o IAOC - IETF Administrative Oversight Committee in the current IASA 195 system - A largely IETF-selected committee that oversees and 196 directs IASA. Accountable to the IETF community. 198 o IAOC committees - Recognizing the need for specialized attention 199 for different branches of work requiring IAOC oversight, the IAOC 200 expanded its support by creating committees. Currently, the 201 committees do the heavy lifting on specific tasks, while the IAOC 202 is the one responsible for final decisions. 204 o ISOC - The Internet Society - The organizational home of the IETF, 205 and one that in the current IASA system assists the IETF with 206 legal, administrative, and funding tasks. 208 o IAD - IETF Administrative Director - In the current system, the 209 sole staff member responsible for carrying out the work of the 210 IASA. An ISOC employee. 212 o IETF Trust - In the current system, the IETF Trust acquires, 213 maintains, and licenses intellectual and other property used in 214 connection with the administration of the IETF. Same composition 215 as IAOC. 217 2.2. Current IASA Arrangements 219 The administrative support structure is intended to be responsive to 220 the administrative needs of the IETF technical community. 222 RFC 4071 [RFC4071] defines the current IETF Administrative Support 223 Activity (IASA). It is an activity housed within the Internet 224 Society (ISOC), as is the rest of the IETF. RFC 4071 defines the 225 roles and responsibilities of the IETF Administrative Oversight 226 Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in 227 the fiscal and administrative support of the IETF standards process. 228 It also defines the membership and selection rules for the IAOC. 230 As RFC 4071 notes, IASA is distinct from IETF-related technical 231 functions, such as the RFC Editor, the IANA, and the IETF standards 232 process itself. The IASA has no influence on the technical decisions 233 of the IETF or on the technical contents of IETF work. 235 Today, IASA's activities support a number of functions within the 236 IETF system: 238 o Meeting planning 240 o Budget and financial management 241 o Contracting with and overseeing the secretariat 243 o Contracting with and overseeing the RFC Editor (together with the 244 IAB) 246 o Contracting with and overseeing IANA (together with the IAB) 248 o Legal ownership of IETF materials, domain names and copyright 250 o Ownership of IANA-related domain names and copyright 252 o General legal support (including topics beyond domains and IPR) 254 o The IETF website 256 o IETF IT services 258 o Tooling support, maintenance, and development (together with 259 volunteers) 261 o Meeting network support 263 o Remote attendance support 265 o Communications assistance for the IETF 267 o Sponsorship and funding (together with ISOC) 269 3. Problem Statement 271 The purpose of this part of the document is to describe a few problem 272 areas with enough detail to allow the comparison of potential IASA 273 structure updates (among themselves, as well as comparison to the 274 status quo) that must be addressed by IETFAdminOrg. This is 275 intentionally illustrative, rather than an exhaustive enumeration of 276 all possible and perceived issues with the current structure and 277 implementation. Nevertheless, the examples are concrete and real. 278 (For a fuller description of the perceived issues with the current 279 IASA arrangements, see [I-D.daigle-iasa-retrospective], 280 [I-D.hall-iasa20-workshops-report], [I-D.arkko-ietf-iasa-thoughts], 281 and ongoing discussion on the iasa20@ietf.org mailing list. 283 In general, the range of IETF administrative tasks have grown 284 considerably, our organizational structure is not as clear, 285 efficient, or as fully resourced as it should be, the division of 286 responsibilities between the IETF and ISOC continues to evolve, 287 expectations on transparency have changed, and we face continued 288 challenges related to funding IETF activities on a background of 289 increasing costs and lack of predictability in our funding streams. 291 3.1. Lack of Clarity 293 In general, as the IETF has grown and aged, an increasing lack of 294 clarity exists in a number of specific areas. We discuss four areas 295 where this lack of clarity is specifically acute: responsibility, 296 representation, authority, and oversight. 298 3.1.1. Responsibility 300 The line between the IETF and ISOC is not organizationally clear-cut, 301 which has led to issues around transparency, allocation of staff time 302 and priorities, budgeting, and clarity of who is responsible for 303 what. 305 Often, it can be unclear what part of the IETF or ISOC is responsible 306 for a particular function. Things as simple as ensuring there is a 307 lanyard sponsor/coordinator, but also functions as important as 308 fundraising and sponsorship development have suffered from a lack of 309 clear responsibility. 311 IETFAdminOrg must have lines of responsibility that are clear enough 312 for non-IETFers to understand where responsibilities lie, and how to 313 make changes as necessary over time. 315 3.1.2. Representation 317 The respective roles of ISOC, the IETF chair, the IAOC, and the 318 secretariat in representing the IETF to sponsors and donors and 319 communicating with them are not clear. 321 Having ISOC represent the IETF to sponsors and donors: 323 o creates confusion about why the IETF does not represent itself, 325 o yields questions about why ISOC does not instead increase its IETF 326 support and how donations can be guaranteed to be dedicated to the 327 IETF, 329 o can result in those soliciting sponsorships and donations having a 330 lack of familiarity with IETF work, and 332 o creates a lack of an integrated and understandable representation 333 of the IETF. People not familiar with the IETF (e.g., potential 334 sponsors) must be able to recognize when or how an entity speaks 335 for the IETF. 337 3.1.3. Authority 339 Another significant problem concerns authority, and to what extent 340 can IETF make decisions on its own in the current structure compared 341 to decisions that require ISOC approval and agreement. 343 For example, due to IETF's lack of legal status, contractual 344 agreements must be signed by ISOC on behalf of the IETF. There are 345 occasions when a decision that is right for the IETF and desired by 346 IETF leadership cannot be executed due to constraints posed by what 347 ISOC can and cannot agree to itself. For example, when IETF sought 348 to acquire a recent piece of software for business purposes, ISOC 349 would initially not agree to entering into an agreement with the 350 software provider. Ideally, IETF could make decisions free from 351 operational and other constraints imposed by its relationship with 352 ISOC. 354 IETFAdminOrg must have enough and appropriate authority to carry out 355 the IETF's administrative requirements and activities in a timely 356 fashion, and as the IETF desires (within reason of normal business 357 and legal requirements). 359 3.1.4. Oversight 361 The IAOC is the primary oversight body in the current IASA model, but 362 there can be confusion or mismatches in roles. For example, to the 363 extent that ISOC staff besides the IAD become engaged in 364 administrative work for the IETF, to whom do they report? The IAOC, 365 the IAD, or their management at ISOC? Even if the reporting line for 366 such staff were more clear, clearly there are power dynamics in this 367 role that might pull an ISOC-assigned IETF staffer in directions that 368 might not be in the best interests of IETF, consciously or 369 unconsciously. 371 Furthermore, when we're in a position where we need more staff 372 support, it's not obvious what the most appropriate path is to obtain 373 that support and how the IAOC's oversight fits into the kind of 374 performance review and career planning that ISOC staff would expect. 375 We have used a variety of models for acquiring staff support from 376 ISOC in the past, ranging from the IAD informally soliciting help 377 from others at ISOC, to the IAOC establishing more formal staff 378 relationships with ISOC personnel, to ISOC taking responsibility for 379 finding staff with an internal-to-ISOC reporting chain. The role of 380 the IAOC with respect to such staff is not defined, nor is the 381 mechanism for reflecting the work that they do for the IETF back to 382 their ISOC management. 384 IETFAdminOrg's oversight functions must be complete and coherent. 385 For example, it might either take on full oversight responsibility 386 for staff employment functions (including reporting structures and 387 career development), or the oversight role must be limited to review 388 input submitted to the external sources responsible for employment. 390 3.2. Lack of Resources 392 IETF faces growing constraints on resources essential for IETF to 393 function, notably in volunteers and staff. 395 3.2.1. Volunteers 397 The IAD is the sole full-time employee for IETF, and the IASA 398 arrangement encompasses a series of volunteer committees that help to 399 work through issues such as finance, legal, meetings, technology 400 management, requests for proposals, and sponsorship. However, it is 401 becoming close to impossible to find qualified volunteers who are 402 willing to stand for open slots on the IAOC. In general, on both the 403 IAOC and the committees, the time that committee members have to 404 devote to the tasks at hand falls far short of what is required to do 405 much of anything beyond keeping the organization afloat. At a time 406 when the IETF is faced with administrative and financial challenges, 407 barely having enough volunteers and volunteer time to keep the 408 current operation running is not a sustainable model. 410 IETFAdminOrg must rely less on volunteers or be better assured of 411 engagement of willing and capable volunteers. 413 3.2.2. Staff 415 IETF faces serious constraints on staff capacity under the current 416 IASA model. The one IAD role and support from contractors have been 417 used to assure that capacity needed is for the most part in place. 418 However, it seems clear that the IAD role is overly complex and 419 taxing for a single human at this point, necessitating measures such 420 as providing an administrator for the IAOC to better run that body 421 and their meetings. IETFAdminOrg will require more paid employment 422 support dedicated to IETF work. 424 3.3. Lack of Transparency 426 The IAOC has sometimes been perceived to operate less transparently 427 than what is the norm for IETF processes and other IETF leadership 428 bodies. This can be observed, for example, in the failure to 429 publicly share agreed information in a timely fashion. The reasons 430 behind this vary but can sometimes be caused by lack of resources to 431 review and prepare material for community review, or even fear of 432 community reaction to potential administrative decisions. 434 Work to increase transparency has made progress, but we must continue 435 to address and improve this. At the same time, a balance must be 436 struck to reach the right level of transparency, so that certain 437 aspects of contracts, business terms, and negotiations can remain 438 confidential, according to legal and business practice norms. It 439 will be important for the community and any future IASA function to 440 better define this in order to better meet well-defined, balanced 441 community expectations on transparency and information sharing. 442 IETFAdminOrg will be required to operated in a transparent fashion 443 per community expectations set as part of this IASA 2.0 process. 445 3.4. Funding/Operating Model Mismatch and Rising Costs 447 Meeting fees are currently an important source of revenue, but the 448 emergence of more viable remote participation tools and other factors 449 are likely responsible for declining in-person meeting attendance 450 going forward. 452 While there has been a lot of sponsor support for, e.g., meeting 453 hosting, getting support for the full costs of operating the IETF is 454 not easy. The costs are quite large, the value to sponsors is not 455 always obvious, the IETF community is sometimes critical or 456 unappreciative, and the same sponsors get tapped again and again for 457 many related but different opportunities. 459 At this point we have one part-time contractor responsible for 460 sponsorship fundraising, and volunteers on the finance and 461 sponsorship committees with limited cycles to spend on re-envisioning 462 the fundraising model for the IETF. They are all putting in good 463 efforts, but ultimately we are unlikely to be able to meet the 464 present funding challenges if we do not have people with the cycles 465 available to dedicate the necessary time to figuring out how to do 466 that. 468 In addition, relying heavily on meeting-based revenue is somewhat at 469 odds with the fact that much of the IETF's work takes place outside 470 of in-person meetings. 472 The IETF is increasingly relying on professional services to support 473 its activities -- in order to more efficiently operate the IETF's 474 activities and better enable IETF participants to contribute to the 475 IETF's core technical work rather than administrative and supporting 476 activities work -- which is also causing expenses to grow. 477 IETFAdminOrg must have appropriate authority and tools to adapt the 478 funding model of the IETF to evolving realities. 480 4. Goals 482 The IASA redesign effort needs to address the main issues listed 483 above in Section 3. More specifically, the future organizational 484 structure needs to do at least the following: 486 o Protect the IETF's Culture and Technical Work: Ensure that the 487 future IASA organizational structure and processes preserve and 488 protect the IETF's unique culture of individual contribution, 489 clear separation of financial support from technical work, as well 490 as the "rough consensus and running code" approach to the 491 development of open Internet standards. 493 o Improve the IETF's Technical Environment: Undertake changes to 494 better enable technical contributors to focus more on that 495 technical work and less on administrative work or support 496 activities. This could for example mean directing more financial 497 resources towards the creation of new or improvement of existing 498 tools, which might be produced by contractors rather than solely 499 by volunteers. As a result, volunteers could instead focus on 500 developing the standards themselves. Thus, if the core competency 501 of IETF attendees and their reason for participating in the IETF 502 is to develop standards, then create an environment where they can 503 focus exclusively on that activity and delegate to contractors, 504 staff, or other resources the responsibility for creating and 505 maintaining tools and processes to support this activity. 507 o Clearly Define the IETF-ISOC Relationship: Define the roles of 508 IETF and ISOC in a way that helps the above structure be as clear 509 as possible, in terms of who does what, how are things accounted 510 for, and who is in charge of adjustments and control (e.g., staff 511 resources). This also includes consideration of a new funding 512 model that takes into account the historical responsibility for 513 the IETF that ISOC has had since its inception. 515 o Support a Re-Envisioned Funding Model: Provide the staff support 516 and resources needed to adapt the funding model of the IETF to 517 changes in the industry, participation, and expenses. The 518 structure should also allow for and be able to support new funding 519 streams or changes to the proportion of funds from various 520 sources. 522 o Provide Clarity About the IETF-ISOC Financial Arrangements: A 523 redesign needs to clear up ambiguities in the financial 524 arrangements between IETF and ISOC. It must also be clear to 525 people outside the IETF and ISOC organisations (e.g., sponsors) 526 what the arrangements are and what their contributions affect and 527 do not affect. 529 o Clarify Overall Roles and Responsibilities: Ensure that all staff, 530 contractor, and volunteer roles are clearly documented. This 531 necessarily includes documenting how each of these parties may 532 interact or interface with one another in order to conduct and 533 support the business of the IETF. This also includes documenting 534 key work processes, decision-making processes and authority (such 535 as pertaining to meeting venue selection), etc. A key objective 536 is to minimize ambiguity and uncertainty so that it is clear who 537 is responsible for what and who has the power to make certain 538 decisions. 540 There also needs to be a clear definition of what issues belong to 541 the IESG vs. the IASA organisation or staff. In many cases that 542 is not clear today. 544 o Define Support Staff Roles and Responsibilities: Clearly define 545 the roles of the oversight entities and staff/contractors to match 546 the expanded work scope facing the IETF. Ensure that any changes 547 create a structure that can adapt flexibly to future growth and 548 other changes (including changes in IETF community expectations, 549 such as increased transparency or more rapid decision-making). 551 o Re-Define the Role of the IETF Community in Relation to 552 Administrative Activities: As the roles and responsibilities for 553 support staff and volunteer roles are clarified more precisely, 554 the role of the IETF community in relation to those staff and 555 volunteer roles must be better defined. This should acknowledge 556 the limited time and availability of IETF volunteers, better 557 defining expectations around oversight of and involvement in 558 strategic, operational, and execution tasks within the 559 administrative efforts. 561 The new design needs to ensure that volunteers are not overloaded 562 in such things as low level operational decisions, which can be 563 delegated to and handled by staff, and can instead focus on 564 strategic changes, critical decisions, and so on. In particular, 565 this should focus on clearly documenting the lines between 566 responsibility, representation, authority, and oversight. 568 o Define Improved Transparency Requirements: The general level of 569 operational transparency and information-sharing between IETF 570 administrative staff and groups to the IETF community must be kept 571 at an acceptable level, and improved where it makes sense in the 572 future. This includes ensuring the timeliness of sharing of 573 information and decisions, as well as seeking comment on 574 prospective decisions. At the same time, we need to reset 575 expectations around delegated authority so that once staff or an 576 administrative support organization has been delegated certain 577 authority it is clear that they are empowered to proceed in a 578 particular area, so as to improve organizational efficiency, 579 reduce friction, and improve the pace of work and decision-making. 580 However, it is clear that enabling a group or staff to act within 581 their delegated authority depends upon a clearer definition of 582 roles and responsibilities, on improved transparency, on improved 583 communications, and on trust (which is built upon all of those 584 things over time). 586 o Define a Transition Plan: Determine what new IASA structure we 587 need and define a transition plan from the model the IETF has 588 today to the new structure. 590 5. Reorganization Options 592 The design team believes that there are three general approaches to 593 evolving the IASA function. The options generally focus on the 594 relationship between the IETF and ISOC. Changes to this relationship 595 directly affect how the IASA function gets carried out. 597 The first subsection that follows, Section 5.1, describes each of the 598 three re-organization options. 600 Section 5.2 discusses the relationship of the IETF administrative 601 organization to the IETF. Clear definition of this relationship is 602 particularly important in the reorganization options that involve the 603 creation of new entities (subsidiaries or independent organizations) 604 to house the administrative functions. The next section, Section 5.3 605 discusses the creation of appropriate oversight to a new entity. 606 Section 5.4 discusses the approach to transparency, which is largely 607 independent of other aspects of the reorganisation. 609 Section 5.5 outlines the needs for IASA staff, and Section 5.6 610 discusses what short term and long term funding arrangement changes 611 are needed. Both staffing and funding arrangements are relevant for 612 all reorganization options, but are of course affected by the chosen 613 option. 615 It should be noted that all three options require more administrative 616 budget per year than what is currently allocated for IASA functions. 617 In addition, they will most likely require a more predictable level 618 of ISOC funding, rather than the current model of a base funding 619 level combined with periodic infusions to cover shortfalls. 621 Section 6 highlights the pros and cons and effectiveness of the 622 options in comparison to the goals stated earlier. 624 5.1. Overall Structure 626 5.1.1. IASA++ 628 In the IASA++ option, IETFAdminOrg continues to be implemented as an 629 activity within ISOC. While addressing the requirements above, this 630 does mean that ISOC maintains funds and contracting authority on 631 behalf of the IETF, and all IASA staff are ISOC employees. 633 While the relationship remains the same, the IETF and ISOC will make 634 improvements to the relationship in order to enhance the 635 functionality of the IETF. The following are some potential 636 improvements that could be made under this approach: 638 o Provide clarity and transparency about authority, responsibility, 639 budgeting, and allocation of staff time for all IETF-related work 640 and activities. 642 o Add IASA staff to better reflect the increased workload on what is 643 now a single staff member. 645 o Provide clarity about authority of the IAOC in reviewing 646 performance of IASA staff. 648 o Re-structure the internal IETF organization and appointment 649 processes for the IAOC to address current challenges. IETF Trust 650 may be separated from IAOC. 652 o Drive IETF community consensus on roles and responsibilities for 653 administrative decision-making so it is completely clear what 654 people or group has authority to make decisions, and what type of 655 consultation, if any, should take place with the community in 656 advance so as to eliminate the current lack of clarity and 657 friction that exists today. 659 The key focus in implementing this option would be sorting out the 660 roles and responsibilities of the IAOC and ISOC. The IETF needs to 661 be able to make its own administrative decisions independent of ISOC. 662 Having a concrete separation of roles and responsibilities will allow 663 each organization to develop their own internal policies that meet 664 their different operational needs. It should be noted that the IETF 665 needs to keep abreast of changes to ISOC policies to ensure that the 666 working arrangement remains smooth. Some examples of where the IAOC 667 needs autonomy from ISOC policies include: 669 o Contract administration 671 o Spending authority limits 672 o Personnel decisions, including compensation 674 Some specific changes to make these improvements are discussed in 675 Section 5.3 regarding board and staff work divisions. While in this 676 option there is no need for a formal board, there is still a need to 677 redefine the role of the IAOC. The necessary staff changes are 678 discussed in Section 5.5. 680 It would also be necessary to improve IAOC transparency. In the 681 IASA++ option, in addition to the general improvement needs in this 682 area, there is an added need to continue the improvements relating to 683 accurate accounting of resources and actions on the ISOC side. This 684 relates directly to the delineation of roles and responsibilities 685 necessary for the IAOC to operate independent of ISOC. Improved 686 transparency will allow the IETF community to be more aware of IAOC 687 operations and decisions. Such changes to the IAOC will require 688 changes to [RFC4071]. 690 5.1.2. ISOC Subsidiary 692 In this option, IETFAdminOrg is implemented as an ISOC subsidiary, 693 which would be created as the new legal home of the IETF 694 administrative operation, similar to how the Public Interest Registry 695 (PIR) is an organized subsidiary within ISOC. A subsidiary can have 696 its own bank account, by-laws, charter, board, staff, and corporate 697 identity. As a subsidiary of ISOC, the IETF and ISOC can share 698 overhead and resources. The IETF would likely continue to rely 699 heavily on contractors for most administrative tasks. 701 In the subsidiary model, IETFAdminOrg would carry out the function in 702 ISOC's role of administratively supporting the IETF. ISOC itself 703 would no longer undertake specific actions to that end, other than 704 supporting IETFAdminOrg. In this model, ISOC's role would consist 705 primarily of committing to stable financial support for IETFAdminOrg. 706 Outside administrative matters, in this model ISOC may of course 707 still run other IETF-related programs, such as the IETF journal or 708 the IETF Fellows program. If this model is chosen, the detailed 709 design would have decide what current activities constitute 710 "administration" and are moved to the subsidiary. 712 As a subsidiary of ISOC, the IETF could eliminate the IAOC and 713 replace it with a board (see Section 5.3). Administrative decision- 714 making authority would rest primarily with the administrative staff, 715 with oversight provided by the board (see Section 5.3 and 716 Section 5.5.) Exception cases could be developed where board 717 approval would be required to authorize strategic decisions. 719 As IETFAdminOrg would be a subsidiary of ISOC, ISOC would retain the 720 ability to shut it down and re-absorb the functions at some future 721 date. The founding agreements would need to include provisions to 722 clarify the steps required in order to consult with the IETF 723 community, provide an opportunity for the organization to become 724 independent, etc. 726 During the transition between the current model and this model, we 727 would need to transfer all existing IETF administrative relationships 728 from ISOC to IETFAdminOrg: 730 o Transfer existing IETF-related contracts between ISOC and 731 contractors to be between the subsidiary and contractors. 733 o Transfer existing ISOC funds earmarked for the IETF to the 734 subsidiary's bank account(s), and have future IETF income held in 735 that subsidiary's bank account(s). 737 5.1.3. Independent Organization 739 In this option, a new non-profit organization (IETFAdminorg) is 740 created independent from ISOC as the new legal home of the IETF. 741 IETFAdminOrg would have its own bank account, by-laws, charter, 742 board, staff, and corporate identity. The administrative staff for 743 IETFAdminOrg could be kept lean and would likely rely on contractors 744 for the bulk of administrative tasks. Minimally, the IETFAdminOrg 745 staff would be responsible for administration, development/ 746 fundraising, communications, and personnel management. 748 In the independent organization model, IETFAdminOrg's continued 749 existence would not depend on the ISOC organization's choices about 750 its future. However, IETFAdminOrg would still depend on the ISOC's 751 support, for two reasons: 753 o ISOC's role in supporting the IETF, and 755 o As a practical matter, IETFAdminOrg is not financially viable 756 without ISOC's support. 758 In order to establish this model, IETFAdminOrg and ISOC would need an 759 explicit agreement that outlined expected levels of financial support 760 going forward, both in terms of founding endowments and in terms of 761 ongoing support. These agreements might also cover IETFAdminOrg's 762 obligations to ISOC, such as the level of reporting from IETFAdminOrg 763 to ISOC, and the expected structure of any liaisons. 765 As in the ISOC Subsidiary model, it would be necessary to transfer 766 the existing relationships to IETFAdminOrg. See the previous section 767 for details on this. 769 5.2. IETFAdminOrg and the Relationship with IETF 771 As noted above, currently the business side of the IETF is basically 772 done by ISOC with the only formal entity being the IAD, which is 773 itself a position within ISOC. In both the ISOC Subsidiary and the 774 Independent Organization models, we would create a new organization 775 ("IETFAdminOrg"), which would encapsulate the administrative 776 responsibilities of the IETF organization in a new business entity. 777 Its sole mission would be to ensure the IETF (standards) activities 778 are appropriately supported and administered. 780 "The IETF" would remain pretty much just as we know it today, i.e., 781 the IETF at large would not form any new organization, nor would 782 IETFAdminOrg take over any current IETF functions. The relationship 783 between IETF and IETFAdminOrg would be a more formalized version of 784 the relationship between IETF and the parts of ISOC which support 785 IETF. 787 Optionally, under the independent organization option, IETF Trust, 788 holding IPR on behalf of the IETF, could be kept separate from the 789 operational IETF administration aspects. This would provide some 790 separation between the copyright ownership functions from other 791 administrative functions, but both would still have to be funded from 792 the same sources. 794 o IETFAdminOrg would have as its mission the administrative support 795 of the IETF and would exist for the benefit of the IETF. 797 o The IETF would provide oversight into the governance of 798 IETFAdminOrg, including seating part of the board. 800 o IETFAdminOrg would not have a say over the material direction or 801 content of the IETF, except insofar as IETF Trust-related legal 802 implications and requirements, such as RFC boilerplates. 804 Beyond negotiation, administering and managing the contracts 805 necessary for the work to support the IETF, IETFAdminOrg would also 806 start with sponsorship and communications functions. Different 807 functions and services might be needed as the IETF evolves. The 808 implementation would be determined by the IETFAdminOrg Executive 809 Director, but the need and direction has to be provided by the IETF 810 (currently, through the IETF Chair, but one hopes the IETF might 811 evolve a broader base for making the kind of strategic determination 812 needed). 814 IETFAdminOrg would be staffed. It would be signatory to all IETF- 815 supporting contracts. It would collect financial support for the 816 IETF, and administer the financial resources. Its annual budgets 817 would be reviewed and approved by its own Board of Trustees, which 818 would be populated pretty much as any Board of Trustees (with the 819 additional requirements in the notes below). In all regards, it 820 would be a self-contained organization, evolving to meet its mission 821 based on its best governance choices to evolve, staff and execute. 823 5.3. Oversight for IETFAdminOrg 825 While IASA++ could continue to have an oversight structure populated 826 by members of the IETF community, either the Subsidiary or 827 Independent models involve the creation of an IETFAdminOrg which 828 would need to have its governance structure defined. This structure 829 needs to include the involvement of members with significant 830 nonprofit governance experience, while also ensuring accountability 831 to and involvement from the IETF Community. 833 In order to achieve these objectives, the design team proposes a 834 model similar to other nonprofits, in which IETFAdminOrg would be 835 governed by a Board of Trustees. This board, the IASA Board (IB), 836 acts to set strategic direction for IETF administrative matters, sets 837 budgets, provides fiscal oversight, provides high-level oversight 838 about major new projects, and so on. The board is also responsible 839 for hiring and assessing the performance of the Executive Director 840 (the highest-level staff director (see Section 5.5). 842 The board works with staff who is empowered to carry out the 843 operations as directed by the board. The staff is responsible for 844 operating within the limits set by the board, and are accountable to 845 the board. Including being hired and fired as needed. The staff's 846 responsibilities include: 848 o preparing for and making decisions on their agreed and budgeted 849 areas (for example, meeting venue decisions) 851 o operational execution of these decisions, including contracting 852 with vendors 854 o communicating with the community 856 o development of the IETF's administrative operation, in 857 consultation with the community 859 The general structure is that the board is responsible for setting 860 general policies about how the staff functions and making decisions 861 for the organization as a whole. For instance, the board would be 862 expected to sign off on the meeting locations and schedule, based on 863 recommendations from the staff. For some activities, the board would 864 organize subcommittees which would do work directly. Typical 865 examples would be auditing, hiring, and firing. The board might, for 866 instance, decide meetings were so important that it needed more 867 direct involvement. The board is accountable to the community and 868 would be expected to regularly consult with the advisory council (see 869 below) and consult with the community directly on especially 870 important matters. 872 By contrast, the staff is responsible for making day-to-day 873 operational decisions subject to the board's general policies. 874 Examples here would be vendor selection for smaller contracts, and 875 hiring of lower-level staff. These decisions are of course subject 876 to board oversight and matters over a given size (e.g., money limit) 877 would need board approval though would likely be recommended by the 878 staff. In no case would the staff or board have any input on 879 standards activities. 881 The composition of the board needs careful attention. It is 882 important to have regular IETF participants in the board, but at 883 least some of the board members need to have skills and experience 884 less common among IETF participants, namely non-profit management, 885 budget experience, and ability to help make connections to raise 886 money or provide advice about fundraising (all of which are typical 887 for a non-profit board). 889 5.3.1. Board Selection 891 Experience with selection for the IAOC and the ISOC Board shows the 892 difficulty of using the nomcom process to select a board with the 893 kind of business skills necessary to supervise an operation like 894 IETFAdminOrg. These skills are not common -- though also not non- 895 existent -- within the IETF community, which makes it hard to find 896 candidates as well as reducing the chance that nomcom members will 897 have the personal contacts to identify external candidates with the 898 appropriate skills. For this reason, the design team does not 899 believe that direct nomcom selection of the whole board will be 900 successful. In the ISOC Subsidiary model, ISOC might also nominate 901 some board members. Below we present two alternative mechanisms for 902 selecting the remaining board members, though there are others that 903 would perhaps be successful. Regardless of the nomination mechanism, 904 the entire board should be subject to confirmation by the IETF 905 leadership. 907 5.3.1.1. Self-Perpetuating Board 909 One common way to select board members is to have the existing board 910 select new members. The advantage of this structure is that the 911 existing members have the skills and connections to identify other 912 people with similar skills. For this reason, this is a common 913 structure for nonprofits. The design team recognizes that there are 914 concerns about the board drifting away from the IETF Community 915 interest, but believes these concerns would be adequately addressed 916 by having some of the board directly selected by nomcom and all 917 members subject to IETF confirmation. The details of how the initial 918 board is to be constituted would need to be determined, but one 919 possibility would be to draw from the existing IAOC and IETF-selected 920 ISOC BOT members, with the board replacing itself within a short 921 period. 923 5.3.1.2. Nomcom-Selected Nomcom 925 An alternative design would be to have the IETF nomcom select a 926 separate nominating committee which would then select the board 927 members. This suffers from some of the problems with direct nomcom 928 selection, but allows us to expand the scope of the pool to anyone at 929 the IETF with business skills or business contacts, not just those 930 who have time to be a board member. As before, the output of this 931 process would need to be confirmed in the IETF. 933 5.3.2. Advisory Council 935 The board and staff are also supported by an Advisory Council (AC). 936 The AC provides an interface to the community on matters that require 937 assessing community opinion. For instance, the current polling of 938 community feedback relating to potential future meeting locations 939 could be one such matter. An advisory council canvassing and pulling 940 for this information is expected to be a better approach than either 941 free-form mailing list discussion, or the relatively opaque process 942 that is currently used. 944 5.3.3. Board Changes in IASA++ 946 IASA++ continues to have an oversight structure populated by members 947 of the IETF community, but as discussed previously, the current IAOC 948 model has a number of weaknesses. Detailed design for this 949 alternative would have to specify how the board changes, but as a 950 starting point, it would be desirable to increase the number of board 951 members (particularly those without other roles) and re-specify the 952 role of the board vs. staff and other committees. With increased 953 number of staff, implementation would be more in the hands of the 954 staff than today, and the role of the board would be more on actual 955 oversight, budget and hiring decisions than the detailed daily 956 operations. 958 5.4. Transparency 960 Regardless of the chosen reorganization model, transparency deserves 961 attention. As discussed in Section 4, this includes improving the 962 timeliness of sharing of information and decisions, seeking comment 963 on forthcoming decisions, and a a "reset" of expectations around 964 delegated authority. 966 In addition, there needs to be an agreement between the IETF 967 community and the administrative entity about the where to draw the 968 line between community's need for information, and the need to keep 969 some business (or personnel) data confidential. 971 5.5. Staff Structure 973 The design team believes that staff resources need to increase and/or 974 be reorganized in order to move from one director to a few more 975 specialized roles (see growth in Section 3). In addition, the team 976 believes that future organization for IASA may benefit from 977 organizing all resources under the more clear and direct control of 978 the IETF (see division of responsibilities in Section 3 and roles in 979 Section 4). 981 The current arrangement involves one officially designated IASA 982 employee, but there are also many supporting employees. They are 983 less clearly assigned for the IETF, working as contractors or at 984 ISOC. 986 This document suggests a structure that involves the following roles: 988 o Executive Director. The person in this role is in charge of the 989 overall IASA effort, but can rely on other staff members below as 990 well as contractors. The Executive Director is accountable to the 991 Board. 993 o Director of Operations. This person is responsible for meeting 994 arrangements, IT, tools, managing contracts (including RFC Editor 995 and IANA), and day-to-day budget management. 997 o Director of Fundraising. This person is responsible for working 998 with IETF's sponsors and other partners, and his or her primary 999 responsibility is fundraising for the IETF. 1001 o Director of Communications. This person is responsible for 1002 working with IETF leadership (including the IETF Chair, IESG, and 1003 IAB) on communications matters (primarily but not exclusively 1004 external communications), assisting them in efficient 1005 communication and dealing with ongoing communications matters. 1007 Note: The Executive Director likely needs to be a full-time employee, 1008 as is likely the case for the other Director-level positions. 1010 These persons also need to rely on a number of contractors and 1011 outside specialists. For instance, a Legal Counsel, to assist the 1012 IASA on legal matters as well as contracting. 1014 It should be noted that we expect to retain the secretariat on 1015 contract for more or less the same responsibilities that they 1016 presently have. 1018 5.6. Funding 1020 This section discusses the overall changes to IETF funding sources, 1021 the level of funding, and how the level of funding is agreed with 1022 ISOC. And how the IETF can further develop its funding strategies 1023 over time. 1025 None of the administrative arrangements proposed in this document 1026 suggest that the fundamental funding arrangements change as a part of 1027 reorganization. ISOC will continue to support the IETF, though 1028 perhaps with means that provide better budgetary stability. There 1029 are also factors that affect the level of funding. Also, a better 1030 administrative organization will be more capable of adjusting its 1031 strategies in the future in all areas, including funding. Any 1032 significant future changes require a capability of the IASA to focus 1033 on such strategic initiatives, which IASA 2.0 will help enable. 1035 It is important to ensure that IETF funding is arranged in a manner 1036 that is satisfactory to the IETF and ISOC communities. Any changes 1037 to arrangements are something that should be mutually agreed with 1038 both organizations. Further comments and observations are welcome. 1040 5.6.1. One-time costs 1042 There are one time costs associated with an administrative change, 1043 regardless of which of the options discussed in this document are 1044 chosen. All the models in the draft will have associated costs - 1045 e.g., to hire additional staff, cover legal fees, etc. 1047 Transition expenses should be considered separately from ongoing 1048 expenses/funding needs. It should be noted that ISOC has promised to 1049 cover those costs [Camarillo]. 1051 5.6.2. Sources and Stability 1053 The key sources of IETF funding are unlikely to radically change in 1054 the short or medium term. This document suggests that ISOC continues 1055 as one of our primary funding sources, as it has been. Other primary 1056 sources of funding for an organization like the IETF are well known, 1057 and we are already tapping into all of the most common ones: 1058 corporations, individuals, and funds derived from the registration of 1059 domain names. It is possible that we could develop additional 1060 funding sources in the future (e.g., charitable foundations), but 1061 those will require strategic planning and staffing, for which we need 1062 to get IASA 2.0 in place first. 1064 It's worth considering short-term (3-5 years) and long-term (5-10+ 1065 years) plans differently. In the short term, we can continue to rely 1066 on our existing funding sources regardless of which organizational 1067 model we end up with for IASA 2.0, including the independent 1068 organization model. The role of ISOC as providing the funding to the 1069 IETF and agreeing to help us if we get to trouble should stay under 1070 all of the options, until or if a future funding model change changes 1071 that. 1073 While ISOC continues to support IETF financially as they have 1074 previously, the different reorganization options affect the legal, 1075 contractual, and accounting related details. While continuing as-is 1076 is possible, adopting a a more predictable allocation of funding is 1077 desirable (see Section 5.6.3), and in the subsidiary and independent 1078 options formal contracts about the funding are also necessary. The 1079 exact details of those contracts and contracting parties are for 1080 further study, but they do not need to change the fundamental 1081 arrangement that is in place today. 1083 More long-term, developing a sustainable funding plan for the IETF 1084 will be a key project during the early months and years post-IASA 1085 2.0. Ultimately a healthier funding model will require raising more 1086 funds from the organizations that benefit from IETF standards and 1087 whose employees participate in the IETF, and may result in less 1088 reliance on ISOC funds. Such a model might incorporate meeting-based 1089 sponsorships as we have traditionally had, other kinds of 1090 sponsorships, a fully funded endowment, a different registration fee 1091 structure, or other funding vehicles. But we are not in a position 1092 at present to develop such a model and carry out the fundraising. We 1093 do not have sufficient staff, skills, or resources to do it. We need 1094 to complete IASA 2.0 in order to be in a position to do it. We are 1095 fortunate that we can rely on additional funds from ISOC in the short 1096 term in order to bootstrap that process. As the old saying goes, you 1097 have to spend money to make money. 1099 This isn't to say that the IETF not already considering how to make 1100 the funding model more sustainable. The IAOC has new sponsorship 1101 staff this year, the the IAOC sponsorship committee was recently 1102 chartered, and it has been discussing new ideas for raising 1103 sponsorship funds. Changes to the present model will be adopted as 1104 those ideas mature. IETF can cut some costs. But we can not expect 1105 volunteers and folks working part-time on current fundraising targets 1106 to also take on the additional substantial project of revamping the 1107 entire funding model and having the additional funds show up on short 1108 order. 1110 5.6.3. Level 1112 Outside the discussion of sources, the level of funding has also been 1113 an issue. The IETF is well supported by ISOC who have ultimately 1114 also been the backstop when income has fallen below expectations. 1115 The IETF is also supported by a number of other sponsors, whose 1116 significant contributions provide a big part of the income. 1118 However, at the same time there is an overall rising cost level that 1119 affects the services IETF uses, there is community desire for 1120 supporting important new services, technology that enables more 1121 participants to choose to participate remotely, and industry 1122 pressures on optimizing their costs. As the organization matures, 1123 and as more of the services that IETF provides come from professional 1124 sources, it becomes more difficult to rely on significant fraction of 1125 any individual volunteer time. This is visible, for instance, in our 1126 tools efforts, which have become more commercially driven in the last 1127 years. 1129 It is fair to say that IETF continues to be underfunded in the face 1130 of these trends. In addition, IETF budgets have in recent years been 1131 relatively optimistic. IETF is fortunate that ISOC has been there to 1132 provide a backstop against surprises and the cost trends, but 1133 ideally, budgets should be realistic and exceptions more exceptional 1134 than they are today. 1136 To correct this, four things are needed: 1138 1. Improve the accounting of IETF-related costs 1140 The process that has gone on for several years to better reflect 1141 actual IETF-related costs in the IETF (and ISOC) budget will 1142 continue, and depending on the chosen model, reach a much more 1143 concrete and clear structure. This will not as such, however, 1144 change the actual amount of expenditure or income. 1146 Note that the IETF already accounts for the expenses related to 1147 key IETF support staff (e.g., IAD, communications, etc). 1149 2. Ensure realism in the budget. 1151 For a budget to be realistic, it must be based on correctly 1152 anticipated income and expenses. Since crystal balls are in 1153 short supply, flexibility and responsiveness are required in the 1154 process, as industry changes can impact both available 1155 contributions and number of participants at meetings (i.e., 1156 registration fee income). 1158 Further decisions may be necessary to be more conservative in 1159 future budgets, including appropriate decisions about what 1160 services are essential for the IETF community and which are not. 1162 Documenting and discussing the IETF financial model (expectations 1163 of sources of income, levels of support, as well as requirements 1164 for expenses and levels of service) has been a goal for 2018 and 1165 will continue to be a priority going forward. 1167 3. ISOC as a funder and backstop. 1169 ISOC continues to be the major IETF funding source, as well as 1170 the backstop against emergencies. But a different arrangement 1171 regarding these two roles would make the situation better 1172 manageable. 1174 Dedicated, realistically sufficient funds allocated to the IETF 1175 would allow the normal operations to be run based on that, and 1176 would leave only true emergencies such as cancellation of 1177 meetings due to local emergencies for the backstop. 1179 4. Appropriate funding level. 1181 The IETF operations and funding level obviously need to match. 1182 The specific level is, however, not related to the IASA 2.0 1183 related organizational changes. Those organizational changes 1184 only make it hopefully easier to manage both the IETF operations 1185 and the funding. 1187 6. Analysis 1189 This section provides a basic analysis of the effects of the 1190 different options. 1192 6.1. Comparison to Goals 1194 In the following, we analyze how the different options compare with 1195 respect to goals set in Section 4: 1197 o Protect the IETF's Culture and Technical Work: 1199 The changes under the IASA++ option are small enough that they 1200 clearly cannot have any undue effect on culture or actual IETF 1201 work. 1203 The ISOC subsidiary and independent organization models are bigger 1204 changes, but, still contained within the administrative support 1205 part. To be exact, the IETF will not become an organization even 1206 if the administrative support for it may. While one may have an 1207 opinion that administrative functions may grow or acquire more 1208 staff over time (and there is always some danger of that), keeping 1209 the IETF out of the organization for administration does provide a 1210 level of separation. This separation ensures that participant, 1211 working group, IESG, IETF Chair, and other similar roles should 1212 continue to operate as they are operating now. 1214 Sometimes even administrative decisions can impact the nature or 1215 culture of the IETF, such as when improvements in remote 1216 attendance support are adopted. A clear interface between the 1217 community and the IETFAdminOrg is helpful in specifying what role 1218 the community and other parts of the system play. The nomcom- 1219 appointed board members and the Advisory Council have clearer 1220 role, and have a more community-focused role in the new 1221 arrangements to ensure that the community has a strong voice. 1223 o Improve the IETF's Technical Environment: 1225 All organization options target improvements in this area. The 1226 options may differ in how much freedom or organization agility 1227 they provide. Clearly, in the independent organization option the 1228 IETF has most of these. 1230 o Clearly Define the IETF-ISOC Relationship: 1232 Again, all options are forced to define this relationship in a 1233 clearer way than it is defined today. 1235 However, the subsidiary and independent organization models have a 1236 better ability to reach a clear definition. A clear definition is 1237 not merely a matter of specification, it is also affected by 1238 practical and even legal constraints and organizations' goals. 1239 For instance, for obvious privacy and legal reasons, IETF may not 1240 have quite as much control and information about ISOC employees as 1241 it would on its own administrative unit's employees. 1243 o Support a Re-Envisioned Funding Model: 1245 The changes to the funding model are on purpose modest for the 1246 reorganization, with the intent provide more ability and freedom 1247 for the IETF to adjust its model later. However, the subsidiary 1248 and independent organization models also clearly provide more 1249 freedom for further evolution. 1251 In IASA++, leaving the responsibility for sponsorship fundraising 1252 up to ISOC, as BCP 101 does, means we will always be constrained 1253 by however ISOC is willing to staff and support IETF-specific 1254 fundraising. While ISOC has and wants to support the IETF, it is 1255 often the case that knowledge of what strategies work and the 1256 direct contacts to sponsoring organisations are on the IETF side. 1258 In the independent organization model, the ability for the IETF to 1259 rely on ISOC in the event of budget shortfalls may be more 1260 limited. This is a double-edged sword, however, as the current 1261 arrangements complicate planning and perceptions by the sponsors. 1263 o Provide Clarity About the IETF-ISOC Financial Arrangements: 1265 All reorganization options aim to provide clarity. But the 1266 subsidiary and independent organisation options provide an 1267 opportunity to define exactly what kind of agreements exist 1268 between the IETF and the new organization, in the form of a formal 1269 agreement between organizations or parts thereof. This is 1270 important in conveying the role of different parties to potential 1271 sponsors, for instance. 1273 In the IASA++ option, there is limited improvement on clarity of 1274 the financial arrangements. 1276 o Clarify Overall Roles and Responsibilities: 1278 The reorganization is an opportunity to rethink what staff roles 1279 are needed, staff levels, whether to organize a function as a 1280 staff function or as contracted service to a vendor. All options 1281 are likely to provide clarified roles and responsibilities. 1283 However, in IASA++, some of lack of clarity may remain, as lack of 1284 clarity inherent in two organizations controlling resources may 1285 remain. In general the subsidiary and independent organisation 1286 models ensure better tha the IETF community and the IETF 1287 administrative functions have authority to perform exactly the 1288 kind of adminstration they want. 1290 The independent organization model eliminates all ambiquity about 1291 the IETF having authority independent from ISOC over staff, funds, 1292 and decisions. 1294 o Define Support Staff Roles and Responsibilities: 1296 As above. 1298 o Re-Define the Role of the IETF Community in Relation to 1299 Administrative Activities: 1301 Again, this is necessary in all the reorganization options. It is 1302 particularly important for the discussion of transparency. 1304 o Improve Transparency: 1306 An improvement can be provided in any chosen option, but it will 1307 require (a) adopting the by default open model, (b) agreeing on a 1308 list of exceptions, as well as obviously clear definition of 1309 roles. 1311 These changes are easier on the subsidiary and independent 1312 organisation models, however, because we can start with more of a 1313 fresh slate. The IAOC and committees have been operating with 1314 their current structure, and, in some cases, current volunteers/ 1315 personnel, for a long time. It will be harder for them to change 1316 than to make staff-driven changes in an org with new staff. 1318 o Define a Transition Plan: 1320 This will also be necessary in all options. 1322 The IASA++ option is the easiest one to get going, and minimal 1323 transition cost, although of course it may not provide as much 1324 value in return, creating risk that the challenges present in 1325 current IASA structures will not be sufficiently solved. 1327 6.2. Financial Impacts 1329 There are several different classes of financially-relevant changes. 1330 Funding-related changes have been covered in Section 5.6, as have 1331 transition costs. 1333 All the suggested models imply some actual increases in expenditure 1334 and financial resources on an ongoing basis. The following applies 1335 generally to all chosen models: 1337 The increases are due to, for instance, shifting more work to staff 1338 and contractors. For the staff changes, the primary position 1339 actually being added is having both Executive Director and Operations 1340 Director, instead of one IAD. We've already had a Legal Counsel and 1341 roles similar to the Director of Fundraising and Communications 1342 Director. These chances coincide with other personnel changes in 1343 IASA, as the experienced, long-term IAD is retiring and a long-term 1344 IETF Legal Counsel is also changing. 1346 It is also expected that the role of the Legal Counsel will also 1347 increase, e.g., in terms of reviewing contracts. 1349 For both the subsidiary model or the independent organization model, 1350 there can be additional and potentially significant costs. For 1351 example, having a full-time communications director on staff means 1352 paying the person's full salary, health insurance, worker's 1353 compensation, sick pay, etc. In general, while under the ISOC model 1354 the IETF may have been able to take a particular percentage of a 1355 person's predicted base costs, under a more independent arrangements 1356 the IETF is an employer and liable for all associated costs at 100%. 1357 Similarly, some current contracted or volunteer roles, if turned to 1358 staff positions, can increase costs. 1360 Audits, payroll, HR, office space, equipment - these are things we do 1361 not currently account for in the IETF budget, that we wouldn't have 1362 to pay for as a subsidiary (assuming we can share overhead with ISOC, 1363 since that's part of the point), but that we would have to pay for as 1364 an independent org. 1366 6.3. Other Impacts 1368 Depending on the chosen option, volunteers are needed for either 1369 different roles than today (the board) or for both different roles 1370 and more volunteers (the board and the advisory council). 1372 It is for further study whether current IETF leadership (e.g., IAB 1373 Chair) should continue to be part of these boards or councils. 1375 7. Conclusions 1377 While there are some initial conclusions in the analysis in the 1378 previous sections, clearly more work is needed. In particular, we 1379 request and welcome thoughts and contributions from the IETF 1380 community, particularly regarding any potential missed options or the 1381 implications of options being considered here. 1383 7.1. Transition Plan 1385 Following feedback we receive before and during the IETF-100 meeting, 1386 we will develop a detailed transition plan and include that here. 1388 The transition plan should address items such as the following (and 1389 we seek suggestions on areas we may have missed): 1391 o Volunteer organization transition plan and timeframe 1393 o Legal, financial, and administrative actions 1395 o Staffing actions (e.g. job descriptions) 1397 o Documentation actions (e.g. roles and responsibilities, updates to 1398 RFCs) 1400 o Near-term goals for the new board (e.g. develop and release a 1401 budget within 90 days of formation) 1403 o Other 1405 8. Acknowledgments 1407 This text is the work of the design team, but greatly influenced by 1408 discussions in the IETF community. The team would in particular like 1409 to thank Alissa Cooper, Andrew Sullivan, Ray Pelletier, Ted Hardie, 1410 Gonzalo Camarillo, Brian Carpenter, Lucy Lynch, Stephen Farrell, Dave 1411 Crocker, Jon Peterson, Alexa Morris, Jonne Soininen, Michael 1412 Richardson, Olaf Kolkman, Kathy Brown, and Melinda Shore for 1413 interesting discussions in this problem space. 1415 9. Informative References 1417 [Camarillo] 1418 Camarillo, G., "ISOC to cover potential re-structuring 1419 costs related to IASA 2.0", September 2017 1420 (https://www.ietf.org/mail-archive/web/ietf/current/ 1421 msg104265.html). 1423 [I-D.arkko-ietf-iasa-thoughts] 1424 Arkko, J., "Thoughts on IETF Administrative Support 1425 Activities (IASA)", draft-arkko-ietf-iasa-thoughts-00 1426 (work in progress), March 2017. 1428 [I-D.daigle-iasa-retrospective] 1429 Daigle, L., "After the first decade: IASA Retrospective", 1430 draft-daigle-iasa-retrospective-01 (work in progress), 1431 June 2017. 1433 [I-D.hall-iasa20-workshops-report] 1434 Hall, J. and J. Mahoney, "Report from the IASA 2.0 Virtual 1435 Workshops", draft-hall-iasa20-workshops-report-00 (work in 1436 progress), March 2017. 1438 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 1439 IETF Administrative Support Activity (IASA)", BCP 101, 1440 RFC 4071, DOI 10.17487/RFC4071, April 2005, 1441 . 1443 Authors' Addresses 1445 Brian Haberman (editor) 1446 Johns Hopkins University 1448 Email: brian@innovationslab.net 1450 Jari Arkko 1451 Ericsson Research 1453 Email: jari.arkko@piuha.net 1455 Leslie Daigle 1456 Thinking Cat Enterprises LLC 1458 Email: ldaigle@thinkingcat.com 1460 Jason Livingood 1461 Comcast 1463 Email: Jason_Livingood@comcast.com 1465 Joseph Lorenzo Hall 1466 CDT 1468 Email: joe@cdt.org 1469 Eric Rescorla 1470 RTFM, Inc. 1472 Email: ekr@rtfm.com