idnits 2.17.1 draft-haberman-iasa20dt-recs-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 -- The document date (July 7, 2017) is 2484 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: January 8, 2018 Ericsson Research 6 L. Daigle 7 Thinking Cat Enterprises LLC 8 J. Livingood 9 Comcast 10 J. Hall 11 CDT 12 E. Rescorla 13 RTFM, Inc. 14 July 7, 2017 16 IASA 2.0 Design Team Recommendations 17 draft-haberman-iasa20dt-recs-00 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 structural and organizational 27 changes, changes to volunteer and staff personnel resources, and 28 transparency changes. 30 This document is a product of a design team, focused on providing 31 additional information to the community about solution options, as 32 well as supporting analysis of the implications of those options. To 33 be clear, the community is responsible for adopting any 34 recommendations or making any final decisions. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 8, 2018. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4. Considering a Change . . . . . . . . . . . . . . . . . . . . 7 75 4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5. Reorganisation Options . . . . . . . . . . . . . . . . . . . 8 77 5.1. Overall Structure . . . . . . . . . . . . . . . . . . . . 8 78 5.1.1. IASA++ . . . . . . . . . . . . . . . . . . . . . . . 9 79 5.1.2. ISOC Subsidiary . . . . . . . . . . . . . . . . . . . 10 80 5.1.3. Independent Organization . . . . . . . . . . . . . . 10 81 5.2. Oversight . . . . . . . . . . . . . . . . . . . . . . . . 11 82 5.2.1. Strategic Board . . . . . . . . . . . . . . . . . . . 12 83 5.2.2. Strategic Board and an Advisory Council . . . . . . . 13 84 5.3. Staff Structure . . . . . . . . . . . . . . . . . . . . . 13 85 6. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 6.1. Criteria . . . . . . . . . . . . . . . . . . . . . . . . 14 87 6.2. Overall Structure . . . . . . . . . . . . . . . . . . . . 15 88 6.2.1. Pros and Cons . . . . . . . . . . . . . . . . . . . . 15 89 6.2.2. Comparison to Criteria . . . . . . . . . . . . . . . 18 90 6.3. Oversight . . . . . . . . . . . . . . . . . . . . . . . . 20 91 6.4. Financial Impacts . . . . . . . . . . . . . . . . . . . . 21 92 6.5. Other Impacts . . . . . . . . . . . . . . . . . . . . . . 21 93 7. Conclusions and recommendations . . . . . . . . . . . . . . . 22 94 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 95 9. Informative References . . . . . . . . . . . . . . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 98 1. Introduction 100 The arrangements relating to administrative support for the IETF 101 (referred to as the "IETF Administrative Support Activity" (IASA) 102 [RFC4071]) were created more than ten years ago, when the IETF 103 initially took charge of its own administration. The arrangements 104 have served the IETF reasonably well, but there's been considerable 105 change in the necessary tasks, in the world around us, and our own 106 expectations since the creation of the IASA. What administrative 107 arrangements best support the IETF in the next ten years? 109 The system has experienced various challenges and frustrations along 110 the way, for instance around meeting arrangements. There are also 111 some bigger questions about how the organisations are structured, for 112 instance about the division of responsibilities between IETF and 113 ISOC. 115 The IETF community has discussed and continues to discuss these 116 topics, most recently on the "IASA20" mailing list and BOF at IETF98. 117 Alissa Cooper, the Chair of the IETF, convened a small design team to 118 start evaluating potential options going forward. The purpose of the 119 design team is to provide material that informs the community 120 discussion, both in terms of providing a bit more worked through 121 solution ideas, as well as supporting analysis of the implications of 122 those options. This information, along with all other input provided 123 in the discussion, hopefully helps the community and IETF leadership 124 decide what next steps to take. 126 To be clear, the community is in charge of adopting any 127 recommendations or making any decisions. This draft, the output of 128 the design team's considerations, has no particular official 129 standing. 131 Once an initial version of this draft is published, the authors would 132 like to ask feedback particularly on two aspects: 134 o If the set of options outlined in the draft covers the options 135 that should be looked at. 137 o If the analysis of the implications of the options is correct. 139 Once this discussion completes, it becomes feasible to discuss what 140 the conclusions or recommendations ought to be, and which 141 recommendations the community should adopt. It should also be noted 142 that IETF administrative matters have been organised jointly with 143 ISOC, and it is important that ISOC be involved in the process of 144 looking at the reorganisation. 146 As a base for this work there was a good articulation of the set of 147 problems we are facing in [I-D.hall-iasa20-workshops-report] and 148 [I-D.daigle-iasa-retrospective]. The community discussion seems have 149 indicated also some of the outcome properties that are expected. The 150 scope of the solutions explored included: 152 o Structural and organizational changes, both externally (with ISOC 153 and contractors) and internally (within the IAOC and 154 subcommittees) 156 o Changes to personnel resources, both volunteer and paid 158 o Transparency changes 160 Changes to the funding model are out of scope to the extent they fall 161 outside the categories above. 163 The rest of the document is organised as follows. The next two 164 sections (Section 2 and Section 3) describe the background and 165 summarise the challenges noted in the community discussion. The two 166 sections after that (Section 4 and Section 5) explain what categories 167 of changes were considered, and describe the primary options for 168 structural changes. The following two sections (Section 6 and 169 Section 7) focus on analysis of the different options along with 170 conclusions and recommendations. 172 2. Background 174 The administrative support structure is intended to be responsive to 175 the administrative needs of the IETF technical community. 177 RFC 4071 [RFC4071] defines the current IETF Administrative Support 178 Activity (IASA). It is an activity housed within the Internet 179 Society (ISOC), as is the rest of the IETF. RFC 4071 defines the 180 roles and responsibilities of the IETF Administrative Oversight 181 Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in 182 the fiscal and administrative support of the IETF standards process. 183 It also defines the membership and selection rules for the IAOC. 185 As RFC 4071 notes, IASA is distinct from IETF-related technical 186 functions, such as the RFC Editor, the IANA, and the IETF standards 187 process itself. The IASA has no influence on the technical decisions 188 of the IETF or on the technical contents of IETF work. 190 Today, IASA's activities support a number of functions within the 191 IETF system: 193 o Meeting planning 195 o Budget and financial management 197 o Contracting with and overseeing the secretariat 199 o Contracting with and overseeing the RFC Editor (together with the 200 IAB) 202 o Contracting with and overseeing IANA (together with the IAB) 204 o Legal ownership of IETF materials, domain names and copyright 206 o Ownership of IANA-related domain names and copyright 208 o General legal support (including topics beyond domains and IPR) 210 o IETF website 212 o IETF IT services 214 o Tooling support, maintenance, and development (together with 215 volunteers) 217 o Meeting network support 219 o Remote attendance support 221 o Communications assistance for the IETF 223 o Sponsorship and funding (together with ISOC) 225 2.1. Terminology 227 The following acronyms are used in this document: 229 o IASA - IETF Administrative Support Activity - An organized 230 activity that provides administrative support for the IETF, the 231 IAB and the IESG. 233 o IAOC - IETF Administrative Oversight Committee in the current IASA 234 system - A largely IETF-selected committee that oversees and 235 directs IASA. Accountable to the IETF community. 237 o IAOC committees - Recognizing the need for specialized attention 238 for different branches of work requiring IAOC oversight, the IAOC 239 expanded its support by creating committees. Currently, the 240 committees do the heavy lifting on specific tasks, while the IAOC 241 is the one responsible for final decisions. 243 o ISOC - The Internet Society - The organizational home of the IETF, 244 and one that in the current IASA system assists the IETF with 245 legal, administrative, and funding tasks. 247 o IAD - IETF Administrative Director - In the current system, the 248 sole staff member responsible for carrying out the work of the 249 IASA. An ISOC employee. 251 o IETF Trust - In the current system the IETF Trust acquires, 252 maintains, and licenses intellectual and other property used in 253 connection with the administration of the IETF. Same composition 254 as IAOC. 256 3. Challenges 258 Discussion leading to this document has been framed by the issues 259 discussed on IETF mailing lists and documented elsewhere 260 [I-D.daigle-iasa-retrospective], [I-D.hall-iasa20-workshops-report], 261 [I-D.arkko-ietf-iasa-thoughts]. The reader is referred to those 262 documents and ongoing discussion on the IASA20@ietf.org mailing list 263 for fuller details on the range of challenges facing the IETF in its 264 handling of administrative matters. 266 In summary, the key areas of challenge that have shaped this work 267 are: 269 o The range of IETF administrative tasks have grown considerably; we 270 must ensure that we have the right structure, community 271 involvement and level of staffing to address them effectively and 272 efficiently. 274 o The relationship and division of responsibilities between the IETF 275 and ISOC have changed, as both organizations have grown 276 considerably in the last decade. 278 The joint organisation that supports the IETF has grown rather 279 organically, and would benefit from re-assessment and possible 280 reorganisation. 282 o Community expectations of transparency of administrative actions 283 and execution from the administration could be better aligned. 285 o Lack of predictably of funding levels combined with regular 286 shortfalls. 288 We face continued challenges related to funding IETF activities on 289 a background of increasing costs. We must properly manage 290 expectations about locations of meetings (broadening of IETF 291 engagement, sponsor preferences) while balancing against 292 operational practicalities. And we must ensure that we continue 293 to not be influenced by funding entities on the technical work of 294 the IETF. 296 Of the items above, the first two are largely to be addressed by 297 structural updates, while the last two groups are more about 298 discussing tradeoffs and updating documented expectations. 300 4. Considering a Change 302 Given that a change seems necessary, what might that change include? 303 There seem to be three broad categories of IETF organisation that 304 will be affected: 306 1. overall structure 308 2. oversight 310 3. interfaces and expectations to rest of the IETF 312 The overall structure also includes questions such as whether IETF is 313 an organisation and its relationship to ISOC. 315 There are some interconnections between different aspects of 316 reorganisation. For instance, how IETF defines its relationship to 317 ISOC will have some implications on what kind of oversight structure 318 is needed; a more independent, free-standing organisational model for 319 IETF would imply new functions for the IASA. 321 There are a number of choices to make within the reorganisation 322 effort. In particular, IETF's relationship to ISOC could be arranged 323 in a fundamentally similar manner than it is today, but improved, 324 e.g., to make clear who is expected to control a particular part of 325 the operation. But the relationship could also be arranged in a 326 different way, for instance, as a subsidiary of ISOC or as a more 327 free-standing, independent organisational unit. 329 4.1. Goals 331 The IASA redesign effort needs to address the main challenges listed 332 above. More specifically, a new organisational structure needs to do 333 at least the following: 335 o Define the roles of IETF and ISOC in a way that helps the above 336 structure be as clear as possible, in terms of who does what, how 337 are things accounted for, and who is in charge of adjustments and 338 control (e.g., staff resources). A redesign needs to propose a 339 starting point for the financial arrangements between IETF and 340 ISOC, either as they are now or changed in some fashion. It must 341 also be clear to people outside the IETF and ISOC organisation 342 (e.g., sponsors) what the arrangements are and what their 343 contributions affect and do not affect. 345 o Define the roles of the oversight entities and staff/contractors 346 to match the grown size of the tasks. Ensure that we have a 347 structure that can adapt to future growth and other changes. 349 o Accommodate strategic, operational, and execution tasks within the 350 administrative efforts, and take into account the limited 351 availability of IETF volunteers for performing administrative 352 tasks. The new design needs to ensure that overload in such 353 things as operational decisions does not affect the ability to 354 drive strategic changes. 356 o Set expectations and limits of those expectations on the different 357 parts of the system. This includes but is not limited to 358 community expectations of transparency. 360 o Ensure that future IASA organizational structure and processes 361 preserves and protects the IETF's unique culture of individual 362 contribution, clear separation of financial support from technical 363 work, as well as rough consensus and running code. 365 5. Reorganisation Options 367 5.1. Overall Structure 369 The design team believes that there are three general approaches to 370 evolving the IASA function. The options generally focus on the 371 relationship between the IETF and ISOC. Changes to this relationship 372 directly affect how the IASA function gets carried out. 374 It should be noted that all three options require more administrative 375 budget per year than what is currently allocated for IASA functions. 376 In addition, they will most likely require a more predictable level 377 of ISOC funding, rather than the current model of a base funding 378 level combined with periodic infusions to cover shortfalls. 380 The following subsections describe each option. Section 6 highlights 381 their pros and cons and effectiveness in comparison to the goals 382 stated earlier. 384 5.1.1. IASA++ 386 In the IASA++ option, the IETF and ISOC maintain the current 387 structural relationship. This means that the IETF remains an 388 organized activity of ISOC, ISOC maintains funds and contracting 389 authority on behalf of the IETF, and all IASA staff are ISOC 390 employees. 392 While the relationship remains the same, the IETF and ISOC will make 393 improvements to the relationship in order to enhance the 394 functionality of the IETF. The following are some potential 395 improvements that could be made under this approach: 397 o Provide clarity and transparency about authority, responsibility, 398 budgeting, and allocation of staff time for all IETF-related work 399 and activities. 401 o Add IASA staff to better reflect the increased workload on what is 402 now a single staff member. 404 o Provide clarity about authority of the IAOC in reviewing 405 performance of IASA staff. 407 o Re-structure the internal IETF organization and appointment 408 processes for the IAOC and the IETF Trust to address current 409 challenges. 411 o Establish IETF community consensus about who has policy authority 412 for administrative decisions where there is currently a lack of 413 clarity. 415 Some specific changes to make these improvements are discussed in 416 Section 5.2 regarding board and staff work divisions. While in this 417 option there is no need for a formal board, there is still a need to 418 redefine the role of the IAOC. The necessary staff changes are 419 discussed in Section 5.3. 421 It would also be necessary to improve IAOC transparency. In the 422 IASA++ option, in addition to the general improvement needs in this 423 area, there is an added need to continue the improvements relating to 424 accurate accounting of resources and actions on the ISOC side. 426 5.1.2. ISOC Subsidiary 428 In this option, an ISOC subsidiary would be created as the new legal 429 home of the IETF. A subsidiary can have its own bank account, by- 430 laws, charter, board of directors/trustees, staff, and corporate 431 identity. As a subsidiary of ISOC, the IETF and ISOC can share 432 overhead and resources. The IETF would likely rely heavily on 433 contractors for most administrative tasks. 435 As a subsidiary of ISOC, the IETF could eliminate the IAOC and 436 replace it with a board of directors/trustees (see Section 5.2). 437 Administrative decision-making authority would rest primarily with 438 the administrative staff, with oversight provided by the board (see 439 Section 5.3. Exception cases could be developed where board approval 440 would be required to authorize strategic decisions. 442 Other likely changes could include: 444 o Transfer existing IETF-related contracts between ISOC and 445 contractors to be between the subsidiary and contractors. 447 o Multiple options to structure community involvement in 448 administrative decision-making (e.g., committees organized by 449 subsidiary staff). 451 There are also other possible changes that would need further 452 discussion: 454 o Eliminate the IETF Trust and have the IETF subsidiary assume 455 responsibility for the IETF's intellectual property rights (IPR). 456 This would simplify the overall structure, but would also bundle 457 the IPR with the rest of the IETF operations. Note that the IETF 458 Trust currently holds IPR also on behalf of the users of IANA. 460 o Transfer existing ISOC funds earmarked for the IETF to the 461 subsidiary's bank account, and have future IETF income held in 462 that subsidiary's bank account. 464 5.1.3. Independent Organization 466 In this option, a new non-profit organization (e.g., IETForg) is 467 created independent from ISOC as the new legal home of the IETF. 468 IETForg would have its own bank account, by-laws, charter, board of 469 directors/trustees, staff, and corporate identity. The 470 administrative staff for IETForg could be kept lean and would likely 471 rely on contractors for the bulk of administrative tasks. Minimally, 472 the IETForg staff would be responsible for administration, 473 development/fundraising, communications, and personnel management. 475 As an independent organization, the IETF could eliminate the IAOC and 476 replace it with a board of directors/trustees. Administrative (day- 477 to-day) decision-making authority would rest primarily with IETForg 478 staff and contractors, with oversight provided by the board. 479 Exception cases could be developed where board approval would be 480 required to authorize strategic decisions. Again, further detais 481 regarding the board and staff changes are in Section 5.2 and 482 Section 5.3. 484 Other likely changes could include: 486 o Transfer existing ISOC funds earmarked for the IETF to IETForg, 487 and have future IETF income held by IETForg. ISOC would still be 488 largest IETForg sponsor, if funding is maintained at current 489 projections. 491 o Transfer existing IETF-related contracts between ISOC and 492 contractors to be between IETForg and contractors. 494 o Multiple options to structure community involvement in 495 administrative decision-making (e.g., committees organized by 496 subsidiary staff). 498 Other possible changes that may need more discussion would include 499 possible change in the role of IETF Trust, as discussed in 500 Section 5.1.2. 502 5.2. Oversight 504 Oversight is obviously affected by what we decide to do with the 505 relationship to ISOC. A bigger, more independent role for the IETF 506 would require an IASA board to be designed for that. Nevertheless, 507 some change in the role of an oversight body and the work division 508 between it and staff is necessary in any case. 510 Also, the design team believes the role of the community members 511 serving in the IASA needs to be kept at a level appropriate for 512 volunteer service (see community role in Section 3 and limits in 513 Section 4.1). 515 Beyond this, there are a number of choices in division of 516 responsibilities and the structure of the organisation. The key 517 decision points are: 519 o Whether the community representative or board control of the IASA 520 is at the level of individual administrative decisions (as it is 521 today) or at a more traditional board level of control, i.e., 522 strategic direction, budgets, and key personnel choices. 524 o Whether the interface to the community is via staff or a community 525 representative or board function. 527 5.2.1. Strategic Board 529 In this option, the current IAOC is disbanded and replaced by a 530 traditional oversight board, common in most non-profit organisations. 531 This board, the IASA Board (IB), acts to set strategic direction for 532 IETF administrative matters, sets budgets, provides fiscal oversight, 533 provides high-level oversight about major new projects, and so on. 534 The board is also responsible for hiring and assessing the 535 performance of the Executive Director (the highest-level staff 536 director, see Section 5.3). 538 This option is potentially valid for all overall structure choices 539 outlined in Section 5. However, for the ISOC Subsidiary and 540 Independent Organisation options, the board would have to be a formal 541 board, typical of other non-profit organisations. 543 The board works with staff who is empowered to carry out the 544 operations as directed by the board. The staff is responsible for 545 operating within the limits set by the board, and are accountable to 546 the board. Including being hired and fired as needed. The staff's 547 responsibilities include: 549 o preparing for and making decisions on their agreed and budgeted 550 areas (for example, meeting venue decisions) 552 o operational execution of these decisions, including contracting 553 with vendors 555 o communicating with the community 557 o development of the IETF's administrative operation, in 558 consultation with the community 560 The primary difference between this option and the current IAOC 561 arrangements is that board acts at a higher decision level, and is 562 not involved either in detailed decisions. These are tasks reserved 563 for the staff, and the board's role is to oversee that staff performs 564 appropriately in their role. 566 The composition of the board needs careful attention. It is 567 important to have regular IETF participants in the board, but at 568 least some of the board members need to have skills and experience 569 less common among IETF participants, namely non-profit management, 570 budget experience, and ability to help make connections to raise 571 money or provide advice about fundraising (all of which are typical 572 for a non-profit board). 574 One potential model for populating the board is a Nomcom-selection 575 for 2/3 of the board members and some other type of selection for 1/3 576 of the board members with a view for more independent, well-networked 577 members. However, the responsibility of the board and the manner in 578 which board members are selected are separable design matters. 580 5.2.2. Strategic Board and an Advisory Council 582 In this option, there is a board and staff just like in 583 Section 5.2.1, but in addition, an Advisory Council (AC) provides an 584 interface to the community on matters that require assessing 585 community opinion. For instance, the current polling of community 586 feedback relating to potential future meeting locations could be one 587 such matter. 589 An advisory council canvassing and pulling for this information might 590 be a better approach than either free-form mailing list discussion, 591 or the relatively opaque process that is currently used. Advisory 592 board results could be documented in the same fashion as IESG 593 documents last call results. Some IAOC site decisions have been done 594 in this way, summarising feedback received, others with less 595 information. 597 The advisory council would be comprised of IETF community members and 598 selected by Nomcom, and would benefit from having either the IETF 599 Chair or another IESG member as a liaison. The advisory council 600 would not make decisions about how the IETF should run, but it would 601 be available for the staff to consult whenever they needed a view 602 from the community, and it would also be available to run community 603 discussion processes or to get input from the community to funnel 604 back to the staff. The advisory council would have a well-defined 605 interface to the IESG as well. 607 The separation of the board and the advisory council, with some 608 overlap between them, allows the allocation of people to tasks 609 according to their skills. We can have experienced managers involved 610 in hiring, firing, and reviewing the Executive Director and 611 overseeing the budget, while we have experienced community people 612 giving the perspective of the community. 614 5.3. Staff Structure 616 The design team believes that staff resources need to increase and/or 617 be reorganised in order to move from one director to a few more 618 specialised roles (see growth in Section 3). And In addition, the 619 team believes that future organisation for IASA may benefit from 620 organising all resources under the more clear and direct control of 621 the IETF (see division of responsibilities in Section 3 and roles in 622 Section 4.1). 624 The current arrangement involves one officially designated IASA 625 employee, but there are also many supporting employees. They are 626 less clearly assigned for the IETF, working as contractors or at 627 ISOC. 629 This document suggests a structure that involves the following roles: 631 o Executive Director. The person in this role is in charge of the 632 overall IASA effort, but can rely on other staff members below as 633 well as contractors. The Executive Director is accountable to the 634 Board. 636 o Director of Operations. This person is responsible for meeting 637 arrangements, IT, tools, managing contracts (including RFC Editor 638 and IANA), and day-to-day budget management. 640 o Director of Fundraising. This person is responsible for working 641 with IETF's sponsors and other partners, and his or her primary 642 responsibility is fundraising for the IETF. 644 o Director of Communications. This person is responsible for 645 working with IETF leadership (including the IETF Chair, IESG, and 646 IAB) on communications matters (primarily but not exclusively 647 external communications), assisting them in efficient 648 communication and dealing with ongoing communications matters. 650 Note: The Executive Director likely needs to be a full-time employee, 651 as is likely the case for the other Director-level positions. 653 These persons also need to rely on a number of contractors and 654 outside specialists. For instance, a Legal Counsel, to assist the 655 IASA on legal matters as well as contracting. 657 6. Analysis 659 This section provides a basic analysis of the effects of the 660 different options. 662 6.1. Criteria 664 We use the following criteria based on the goals stated earlier 665 (Section 4.1): 667 o The arrangements match the scale of the task (SCALE) 669 o The arrangements are designed to evolve as situations evolve 670 (EVOLVE) 672 o Accommodates strategic tasks (STRAT TSK) 674 o Accommodates operational and execution tasks (OPS TSK) 676 o Avoids overload in one class of tasks preventing progress in other 677 (OVERLOAD SEP) 679 o Clarifies the relationship between IETF and ISOC (CLEAR ISOC REL) 681 o Allows direct IETF control of resources (e.g., staff) working on a 682 task (DIR CONTROL) 684 o Preserves IETF culture and mode of operation (CULTURE) 686 o Separates IETF technical work and administrative tasks and funding 687 (WORK SEP) 689 o Sets expectations on what can or can not be expected from IASA 690 (IASA EXP) 692 6.2. Overall Structure 694 6.2.1. Pros and Cons 696 Table 1 highlights the pros and cons of the IASA++ option. 698 +--------------------------------+----------------------------------+ 699 | Pros | Cons | 700 +--------------------------------+----------------------------------+ 701 | Maintains familiar structures | Does not provide the IETF with | 702 | and relationships | true independence of funding or | 703 | | staff from ISOC | 704 +--------------------------------+----------------------------------+ 705 | Start-up costs limited to | Creates risk that challenges | 706 | those associated with hiring | present in the current IASA will | 707 | additional staff | not actually be solved or will | 708 | | re-emerge over time | 709 +--------------------------------+----------------------------------+ 710 | Does not require legal and | Potentially requires ISOC to | 711 | administrative work to | cede more authority to the IETF | 712 | incorporate a new entity | community or increase | 713 | | transparency beyond ISOC's | 714 | | comfort zone | 715 +--------------------------------+----------------------------------+ 716 | Allows IETF to continue to | Continuing confusion about | 717 | rely on ISOC to somewhat | alignment between ISOC and IETF | 718 | frictionlessly compensate for | on policy and standards matters. | 719 | budget shortfalls if necessary | | 720 +--------------------------------+----------------------------------+ 722 Table 1: IASA++ Pros and Cons 724 Table 2 highlights the pros and cons of the ISOC subsidiary option. 726 +----------------------------------+--------------------------------+ 727 | Pros | Cons | 728 +----------------------------------+--------------------------------+ 729 | Forces some delineation of | Leaves open some potential for | 730 | responsibility, staff, and funds | continued lack of clarity | 731 | between the IETF and ISOC | about authority and funding | 732 | | between the IETF and ISOC | 733 +----------------------------------+--------------------------------+ 734 | Provides the IETF community with | Potentially requires ISOC to | 735 | greater authority over IETF | cede more authority to the | 736 | administration | IETF community or increase | 737 | | transparency beyond ISOC's | 738 | | comfort zone | 739 +----------------------------------+--------------------------------+ 740 | Can leverage existing ISOC legal | Requires legal and | 741 | structures and personnel to keep | administrative work to | 742 | administrative work required to | incorporate subsidiary | 743 | incorporate subsidiary to a | | 744 | minimum | | 745 +----------------------------------+--------------------------------+ 746 | Requires less IETF community | Vests more decision-making | 747 | volunteer time commitment to | authority in paid staff than | 748 | administrative matters than | under current IASA | 749 | current IASA | | 750 +----------------------------------+--------------------------------+ 751 | Allows IETF to continue to rely | Start-up costs include costs | 752 | on ISOC to somewhat | of incorporating the | 753 | frictionlessly compensate for | subsidiary and re- | 754 | budget shortfalls if necessary | organizing/hiring additional | 755 | | staff | 756 +----------------------------------+--------------------------------+ 757 | Allows IETF to continue to | Continuing confusion about | 758 | leverage expertise of ISOC | alignment between ISOC and | 759 | administrative personnel | IETF on policy and standards | 760 | | matters. | 761 +----------------------------------+--------------------------------+ 763 Table 2: ISOC Subsidiary Pros and Cons 765 Table 3 highlights the pros and cons of the independent organization 766 option. 768 +-------------------------------------+-----------------------------+ 769 | Pros | Cons | 770 +-------------------------------------+-----------------------------+ 771 | Eliminates all ambiguity about IETF | Start-up costs include | 772 | having authority independent from | legal and administrative | 773 | ISOC over staff, funds, and | costs to incorporate a new | 774 | decisions | entity, hire new staff, | 775 | | transfer contracts and | 776 | | funds | 777 +-------------------------------------+-----------------------------+ 778 | Provides the IETF community with | ISOC's financial support | 779 | potentially complete authority over | for the IETF may be viewed | 780 | IETF administration and funding | as more tenuous if the IETF | 781 | | is a legally separate | 782 | | entity from ISOC | 783 +-------------------------------------+-----------------------------+ 784 | Requires less IETF community | Ability for the IETF to | 785 | volunteer time commitment to | rely on ISOC in the event | 786 | administrative matters than current | of budget shortfalls may be | 787 | IASA | more limited | 788 +-------------------------------------+-----------------------------+ 789 | Allows for direct investment in | Vests more decision-making | 790 | small number of professional staff | authority in paid staff | 791 | specifically tailored to the IETF's | than under current IASA | 792 | needs and culture, while continuing | | 793 | to rely heavily on contractors | | 794 +-------------------------------------+-----------------------------+ 795 | Provides opportunity to structure | Requires more from board | 796 | board in such a way to overcome | members than what is | 797 | current challenges with IAOC | currently required of IAOC | 798 | structure | insofar as hiring and | 799 | | evaluating staff | 800 +-------------------------------------+-----------------------------+ 801 | Removes need for alignment between | Requires IETF to assume | 802 | ISOC and IETF on policy and | legal risk currently | 803 | standards matters. | assumed by ISOC | 804 +-------------------------------------+-----------------------------+ 806 Table 3: Independent Organization Pros and Cons 808 6.2.2. Comparison to Criteria 810 For the overall structure, the implications of the current situation 811 and the three options are summarized in Table 4. 813 +-----------+-------------+----------+------------+-----------------+ 814 | Criteria | Current | IASA++ | ISOC | Independent | 815 | | situation | | Subsidiary | Organization | 816 +-----------+-------------+----------+------------+-----------------+ 817 | SCALE | NO | NO | YES | YES | 818 +-----------+-------------+----------+------------+-----------------+ 819 | EVOLVE | NO | NO (Note | MAYBE | YES (Note 1) | 820 | | | 1) | (Note 1) | | 821 +-----------+-------------+----------+------------+-----------------+ 822 | STRAT TSK | NO | NO (Note | YES | YES | 823 | | | 1) | | | 824 +-----------+-------------+----------+------------+-----------------+ 825 | OPS TSK | YES | YES | YES | YES | 826 +-----------+-------------+----------+------------+-----------------+ 827 | OVERLOAD | YES | YES | YES | YES | 828 | SEP | | | | | 829 +-----------+-------------+----------+------------+-----------------+ 830 | CLEAR | NO | NO | YES | YES | 831 | ISOC REL | | | | | 832 +-----------+-------------+----------+------------+-----------------+ 833 | DIR | NO | NO | YES | YES | 834 | CONTROL | | | | | 835 +-----------+-------------+----------+------------+-----------------+ 836 | CULTURE | YES | YES | YES | YES | 837 +-----------+-------------+----------+------------+-----------------+ 838 | WORK SEP | YES | YES | YES | YES | 839 +-----------+-------------+----------+------------+-----------------+ 840 | IASA EXP | NO | MAYBE | MAYBE | MAYBE (Note 2) | 841 | | | (Note 2) | (Note 2) | | 842 +-----------+-------------+----------+------------+-----------------+ 844 Table 4: IETF-ISOC Relationship Implications 846 Note 1: Evolution in the current system is more difficult than if 847 IETF was either clearly a subsidiary or its own organisation. This 848 is because changes need agreement from two organisations, and, in the 849 current model, the control of IETF-dedicated resource is not as clear 850 as it could be. A subsidiary or independent model would also ease 851 driving any strategy that the IETF wants to drive, as decisions would 852 be more on the IETF side than something that today would require 853 negotiation with ISOC. 855 Note 2: Setting expectations is difficult merely based on an 856 organisational model. Certainly a clear separation between roles of 857 the board and staff helps. However, expectations are also a matter 858 of documentation, which would have be created and communicated. 859 Finally, expectations are a cultural matter, current IAOC 860 arrangements and community views have ended up in a situation where 861 there is a lack of trust and unclear models for what can or cannot be 862 expected. 864 6.3. Oversight 866 For the internal organisation, the implications of the current 867 situation vs. a strategic board model is summarised in Table 5. 869 +----------------+-------------------+-----------------+ 870 | Criteria | Current Situation | Strategic Board | 871 +----------------+-------------------+-----------------+ 872 | SCALE | NO | YES | 873 +----------------+-------------------+-----------------+ 874 | EVOLVE | MAYBE (Note 1) | YES (Note 1) | 875 +----------------+-------------------+-----------------+ 876 | STRAT TSK | NO | YES (Note 2) | 877 +----------------+-------------------+-----------------+ 878 | OPS TSK | YES | YES (Note 2) | 879 +----------------+-------------------+-----------------+ 880 | OVERLOAD SEP | NO | YES (Note 2) | 881 +----------------+-------------------+-----------------+ 882 | CLEAR ISOC REL | n.a. | n.a. | 883 +----------------+-------------------+-----------------+ 884 | DIR CONTROL | n.a. | n.a. | 885 +----------------+-------------------+-----------------+ 886 | CULTURE | YES | YES | 887 +----------------+-------------------+-----------------+ 888 | WORK SEP | YES | YES | 889 +----------------+-------------------+-----------------+ 890 | IASA EXP | NO | MAYBE (Note 3) | 891 +----------------+-------------------+-----------------+ 893 Table 5: Internal Organization Implications 895 Note 1: Given that the IASA is being reorganised, we acknowledge that 896 the current structure is capable of evolving. However, the 897 operational focus and overload in the current arrangements are making 898 this harder than is necessary. Change requires action from outside 899 of the IASA, rather than being a normal task within the IASA to 900 evolve their own model. A strategic board that is not deeply 901 involved in the operations should be able to look at evolution more 902 easily. Similarly, a dedicated advisory council can help determine 903 community concerns, and might be able to do this even better than a 904 board. However, lines of authority between a strategic board and 905 advisory council would need to be clearly delineated. 907 Note 2: There may be a difference between the strategic board with 908 and without an advisory council, in how overload situations and the 909 separation of different tasks goes. The existence of an advisory 910 council alleviates some workload on board or staff, particularly in 911 dealing with community opinion determination, freeing the board to do 912 its strategic work and staff to concentrate on operations and 913 execution. 915 Note 3: Setting expectations is difficult merely based on an 916 oganisational model, see Note 2 under Section 6.2.2. 918 6.4. Financial Impacts 920 There are two different classes of financially-relevant changes. 921 First, both the ISOC interface change and staff changes will imply 922 changes in what is being accounted for in budgets and reports, even 923 in cases where the actual work or the number of people stays the 924 same. That is, depending on the chosen overall organisation model, 925 some items that are currently in ISOC budget may move to become IETF 926 budget items, but the total amount of expenditure stays the same. 927 Note that the IETF already accounts for the expenses related to key 928 IETF support staff (e.g., IAD, communications, etc). 930 Secondly,there are some actual increases in required financial 931 resources. We expect all the alternatives to lead to somewhat higher 932 funding needs, and in fact shifting more work to staff from 933 volunteers is one of the goals. For the staff changes, the primary 934 position actually being added is having both Executive Director and 935 Operations Director, instead of one IAD. We've already had a Legal 936 Counsel and roles similar to the Director of Fundraising and 937 Communications Director. These chances coincide with other personnel 938 changes in IASA, as the experienced, long-term IAD is retiring. Even 939 from a learning curve point of view more people will be needed, but 940 in this case it also makes sense to have the organisation be less 941 dependent on one central person. 943 Given the learning curve effect, and a new organisation, it is 944 expected that the role of the Legal Counsel will also increase, e.g., 945 in terms of reviewing contracts. 947 It is important to ensure that IETF funding is arranged in a manner 948 that is satisfactory to the IETF and ISOC communities. Further 949 comments and observations are welcome. 951 6.5. Other Impacts 953 Depending on the chosen option, volunteers are needed for either 954 different roles than today (the board) or for both different roles 955 and more volunteers (the board and the advisory council). 957 It is for further study whether current IETF leadership (e.g., IAB 958 Chair) should continue to be part of these boards or councils. 960 7. Conclusions and recommendations 962 While there are some initial conclusions in the analysis in the 963 previous sections, clearly more work is needed. In particular, we 964 request and welcome thoughts and contributions from the IETF 965 community, particularly regarding any potential missed options or the 966 implications of options being considered here. 968 8. Acknowledgments 970 This text is the work of the design team, but greatly influenced by 971 discussions in the IETF community. The team would in particular like 972 to thank Alissa Cooper, Andrew Sullivan, Ray Pelletier, Ted Hardie, 973 Gonzalo Camarillo, Brian Carpenter, Lucy Lynch, Stephen Farrell, Dave 974 Crocker, Jon Peterson, Alexa Morris, Michael Richardson, Olaf 975 Kolkman, Kathy Brown, and Melinda Shore for interesting discussions 976 in this problem space. 978 9. Informative References 980 [I-D.arkko-ietf-iasa-thoughts] 981 Arkko, J., "Thoughts on IETF Administrative Support 982 Activities (IASA)", draft-arkko-ietf-iasa-thoughts-00 983 (work in progress), March 2017. 985 [I-D.daigle-iasa-retrospective] 986 Daigle, L., "After the first decade: IASA Retrospective", 987 draft-daigle-iasa-retrospective-01 (work in progress), 988 June 2017. 990 [I-D.hall-iasa20-workshops-report] 991 Hall, J. and J. Mahoney, "Report from the IASA 2.0 Virtual 992 Workshops", draft-hall-iasa20-workshops-report-00 (work in 993 progress), March 2017. 995 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 996 IETF Administrative Support Activity (IASA)", BCP 101, 997 RFC 4071, DOI 10.17487/RFC4071, April 2005, 998 . 1000 Authors' Addresses 1001 Brian Haberman (editor) 1002 Johns Hopkins University 1004 Email: brian@innovationslab.net 1006 Jari Arkko 1007 Ericsson Research 1009 Email: jari.arkko@piuha.net 1011 Leslie Daigle 1012 Thinking Cat Enterprises LLC 1014 Email: ldaigle@thinkingcat.com 1016 Jason Livingood 1017 Comcast 1019 Email: Jason_Livingood@comcast.com 1021 Joseph Lorenzo Hall 1022 CDT 1024 Email: joe@cdt.org 1026 Eric Rescorla 1027 RTFM, Inc. 1029 Email: ekr@rtfm.com