idnits 2.17.00 (12 Aug 2021) /tmp/idnits29175/draft-dt-iasa20-proposal-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 (April 05, 2018) is 1500 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Diagrams' is defined on line 855, but no explicit reference was found in the text == Unused Reference: 'Diagrams-no-trust' is defined on line 859, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-haberman-iasa20dt-recs-01 == Outdated reference: A later version (-04) exists of draft-hall-iasa2-struct-01 -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hall, Ed. 3 Internet-Draft CDT 4 Intended status: Informational B. Haberman, Ed. 5 Expires: October 7, 2018 Johns Hopkins University 6 J. Arkko 7 Ericsson Research 8 L. Daigle 9 Thinking Cat Enterprises LLC 10 J. Livingood 11 Comcast 12 E. Rescorla 13 RTFM, Inc. 14 April 05, 2018 16 Proposed Structure of the IETF Administrative Organization 17 draft-dt-iasa20-proposal-00 19 Abstract 21 The IETF Administrative Support Activity (IASA) was originally 22 established in 2005. In the intervening years, the needs of the IETF 23 have evolved in ways that require changes to its administrative 24 structure. The IETF Chair started an effort in November of 2016 to 25 begin the process of changing the IETF administrative structure, 26 starting with a set of virtual workshops to get input from the IETF 27 community, and then encompassing a series of BOF sessions at IETF 28 meetings to define the problem, develop requirements, explore 29 potential options for changes, and a Design Team - the authors of 30 this document - that would make recommendations. The purpose of this 31 document is to collect all of the various materials that have lead up 32 to the Design Team recommendation that IETF be a Disregarded Limited 33 Liability Company (LLC) of the Internet Society. 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 http://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 October 7, 2018. 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 (http://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 . . . . . . . . . . . . . . . . . . 10 82 3.4. Funding/Operating Model Mismatch and Rising Costs . . . . 10 83 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 5. Legal Options for IETF Organizational Change . . . . . . . . 13 85 5.1. Option 1 - Independent 501(c)(3) . . . . . . . . . . . . 13 86 5.2. Option 2 - Type 1 Supporting Organization . . . . . . . . 14 87 5.3. Option 3 - Disregarded LLC . . . . . . . . . . . . . . . 15 88 5.4. Option 4 - Activity of Internet Society . . . . . . . . . 16 89 6. Design Team Recommendation (Option 3) . . . . . . . . . . . . 17 90 7. Important Remaining Issues . . . . . . . . . . . . . . . . . 17 91 7.1. Transparency . . . . . . . . . . . . . . . . . . . . . . 17 92 7.2. IAO Board . . . . . . . . . . . . . . . . . . . . . . . . 18 93 7.3. Input from the IETF Community . . . . . . . . . . . . . . 18 94 7.4. Non-US incorporation . . . . . . . . . . . . . . . . . . 18 95 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 96 9. Informative References . . . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 The arrangements relating to administrative support for the IETF 102 (referred to as the "IETF Administrative Support Activity" (IASA) 103 ([RFC4071]) were created more than ten years ago, when the IETF 104 initially took charge of its own administration. The arrangements 105 have served the IETF reasonably well, but there's been considerable 106 change in the necessary tasks, in the world around us, and our own 107 expectations since the creation of the IASA. 109 The system has experienced various challenges and frustrations along 110 the way. IETF participants have experienced some questions over 111 administrative choices made for the organization (e.g., meeting venue 112 selections, hotel availability and costs), and then voiced concerns 113 about the seeming lack of transparency and responsiveness from the 114 components of IASA, or even clarity about who is responsible for the 115 decisions, or who to follow up with to address stated concerns. 117 The IETF community has discussed and continues to discuss these 118 topics, most recently on the "IASA 2.0" mailing list and BOFs at 119 IETFs 98, 99, 100, and 101. The IETF Chair convened a small design 120 team (the authors of this document) in 2017 to start evaluating 121 potential options. The purpose of the design team is to provide 122 material that informs the community discussion, both in terms of 123 providing a bit more worked through solution ideas, as well as 124 supporting analysis of the implications of those options. 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, merely collects the activities 129 around IASA 2.0 and the Design Team's work into one place. It should 130 also be noted that IETF administrative matters have been organized 131 jointly with ISOC, and it is important that ISOC continue to be 132 involved in IETF's reorganization. 134 It should of course be acknowledged that there is no perfect, or even 135 great solution. Changing the IETF organizational structure will not 136 fix every problem and may bring new problems of its own. But it 137 seems that the current structure is brittle and the issues around 138 lack of staff and authority, clarity, and responsibility are 139 sufficiently serious to explore different options. 141 This document defines a problem statement and a set of goals for the 142 IASA 2.0 effort in terms of an abstract administrative structure, 143 called IETFAdminOrg (or IAO). Then, it discusses four possible legal 144 structures of IAO and describes specifically how the LLC model (what 145 this document refers to as Option 3) addresses the goals. In no case 146 does IAO have anything to do with defining, changing, or operating 147 the IETF's standards process and structure (participants (not 148 members), WGs, IESG and so on), which remain as they stand today. 150 As a base for this document, there was a good articulation of the set 151 of problems we are facing after an initial set of virtual workshops 152 in early 2017 in [I-D.hall-iasa20-workshops-report] and a number of 153 drafts describing problems from specific perspectives: 154 [I-D.daigle-iasa-retrospective], [I-D.arkko-ietf-iasa-thoughts], 155 [I-D.arkko-ietf-finance-thoughts]. The Design Team specified the 156 types of organizational models and recommendations in 157 [I-D.haberman-iasa20dt-recs] for IETF 100, and proposed elements of a 158 specific structure in [I-D.hall-iasa2-struct] for discussion at IETF 159 101. Some of the content from these documents has been incorporated 160 into this document. 162 The next two sections (Section 2 and Section 3) describe the 163 background and summarize the challenges noted in the community 164 discussion. The two sections after that (Section 4 and Section 5) 165 describe the goals and discuss the primary legal options for changes. 166 The following two sections (Section 6 and Section 7) discuss, 167 respectively, the Design Team's rationale for recommending the LLC 168 option (Option 3) and issues that will need to be carefully 169 considered by a Working Group established to further specify the new 170 organizational structure. 172 2. Background 174 2.1. Terminology 176 The following acronyms are used in this document: 178 o IASA - IETF Administrative Support Activity - An organized 179 activity that provides administrative support for the IETF, the 180 IAB, and the IESG. 182 o IAOC - IETF Administrative Oversight Committee in the current IASA 183 system - A largely IETF-selected committee that oversees and 184 directs IASA. Accountable to the IETF community. 186 o IAOC committees - Recognizing the need for specialized attention 187 for different branches of work requiring IAOC oversight, the IAOC 188 expanded its support by creating committees. Currently, the 189 committees do the heavy lifting on specific tasks, while the IAOC 190 is the one responsible for final decisions. 192 o IAO - An abbreviation referring to the new IETF administrative 193 organization (called "IETFAdminOrg" in past documents). 195 o ISOC - The Internet Society - The organizational home of the IETF, 196 and one that in the current IASA system assists the IETF with 197 legal, administrative, and funding tasks. 199 o IAD - IETF Administrative Director - In the current system, the 200 sole staff member responsible for carrying out the work of the 201 IASA. An ISOC employee. 203 o IETF Trust - In the current system, the IETF Trust acquires, 204 maintains, and licenses intellectual and other property used in 205 connection with the administration of the IETF. Same composition 206 as IAOC. 208 2.2. Current IASA Arrangements 210 The administrative support structure is intended to be responsive to 211 the administrative needs of the IETF technical community. 213 RFC 4071 [RFC4071] defines the current IETF Administrative Support 214 Activity (IASA). It is an activity housed within the Internet 215 Society (ISOC), as is the rest of the IETF. RFC 4071 defines the 216 roles and responsibilities of the IETF Administrative Oversight 217 Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in 218 the fiscal and administrative support of the IETF standards process. 219 It also defines the membership and selection rules for the IAOC. 221 As RFC 4071 notes, IASA is distinct from IETF-related technical 222 functions, such as the RFC Editor, the IANA, and the IETF standards 223 process itself. The IASA has no influence on the technical decisions 224 of the IETF or on the technical contents of IETF work. 226 Today, IASA's activities support a number of functions within the 227 IETF system: 229 o Meeting planning 231 o Budget and financial management 233 o Contracting with and overseeing the secretariat 235 o Contracting with and overseeing the RFC Editor (together with the 236 IAB) 238 o Contracting with and overseeing IANA (together with the IAB) 239 o Legal ownership of IETF materials, domain names and copyright 241 o Ownership of IANA-related domain names and copyright 243 o General legal support (including topics beyond domains and IPR) 245 o The IETF website 247 o IETF IT services 249 o Tooling support, maintenance, and development (together with 250 volunteers) 252 o Meeting network support 254 o Remote attendance support 256 o Communications assistance for the IETF 258 o Sponsorship and funding (together with ISOC) 260 3. Problem Statement 262 The purpose of this part of the document is to describe a few problem 263 areas with enough detail to allow the comparison of potential IASA 264 structure updates (among themselves, as well as comparison to the 265 status quo) that must be addressed by IAO. This is intentionally 266 illustrative, rather than an exhaustive enumeration of all possible 267 and perceived issues with the current structure and implementation. 268 Nevertheless, the examples are concrete and real. (For a fuller 269 description of the perceived issues with the current IASA 270 arrangements, see [I-D.daigle-iasa-retrospective], 271 [I-D.hall-iasa20-workshops-report], [I-D.arkko-ietf-iasa-thoughts], 272 [I-D.arkko-ietf-finance-thoughts], and ongoing discussion on the 273 iasa20@ietf.org mailing list.) 275 In general, the range of IETF administrative tasks have grown 276 considerably, our organizational structure is not as clear, 277 efficient, or as fully resourced as it should be, the division of 278 responsibilities between the IETF and ISOC continues to evolve, 279 expectations on transparency have changed, and we face continued 280 challenges related to funding IETF activities on a background of 281 increasing costs and lack of predictability in our funding streams. 283 3.1. Lack of Clarity 285 In general, as the IETF has grown and aged, an increasing lack of 286 clarity exists in a number of specific areas. We discuss four areas 287 where this lack of clarity is specifically acute: responsibility, 288 representation, authority, and oversight. 290 3.1.1. Responsibility 292 The line between the IETF and ISOC is not organizationally clear-cut, 293 which has led to issues around transparency, allocation of staff time 294 and priorities, budgeting, and clarity of who is responsible for 295 what. 297 Often, it can be unclear what part of the IETF or ISOC is responsible 298 for a particular function. Things as simple as ensuring there is a 299 lanyard sponsor/coordinator, but also functions as important as 300 fundraising and sponsorship development have suffered from a lack of 301 clear responsibility. 303 IAO must have lines of responsibility that are clear enough for non- 304 IETFers to understand where responsibilities lie, and how to make 305 changes as necessary over time. 307 3.1.2. Representation 309 The respective roles of ISOC, the IETF chair, the IAOC, and the 310 secretariat in representing the IETF to sponsors and donors and 311 communicating with them are not clear. 313 Having ISOC represent the IETF to sponsors and donors: 315 o creates confusion about why the IETF does not represent itself, 317 o yields questions about why ISOC does not instead increase its IETF 318 support and how donations can be guaranteed to be dedicated to the 319 IETF, 321 o can result in those soliciting sponsorships and donations having a 322 lack of familiarity with IETF work, and 324 o creates a lack of an integrated and understandable representation 325 of the IETF. People not familiar with the IETF (e.g., potential 326 sponsors) must be able to recognize when or how an entity speaks 327 for the IETF. 329 3.1.3. Authority 331 Another significant problem concerns authority, and to what extent 332 can IETF make decisions on its own in the current structure compared 333 to decisions that require ISOC approval and agreement. 335 For example, due to IETF's lack of legal status, contractual 336 agreements must be signed by ISOC on behalf of the IETF. There are 337 occasions when a decision that is right for the IETF and desired by 338 IETF leadership cannot be executed due to constraints posed by what 339 ISOC can and cannot agree to itself. For example, when IETF sought 340 to acquire a recent piece of software for business purposes, ISOC 341 would initially not agree to entering into an agreement with the 342 software provider. Ideally, IETF could make decisions free from 343 operational and other constraints imposed by its relationship with 344 ISOC. 346 IAO must have enough and appropriate authority to carry out the 347 IETF's administrative requirements and activities in a timely 348 fashion, and as the IETF desires (within reason of normal business 349 and legal requirements). 351 3.1.4. Oversight 353 The IAOC is the primary oversight body in the current IASA model, but 354 there can be confusion or mismatches in roles. For example, to the 355 extent that ISOC staff besides the IAD become engaged in 356 administrative work for the IETF, to whom do they report? The IAOC, 357 the IAD, or their management at ISOC? Ultimately, any employee will 358 recognize their primary responsibility to their employer (i.e,. ISOC, 359 and specifically to their ISOC management chain). Even in a well- 360 balanced relationship between the IETF and ISOC, this leads to 361 conflicting priorities and availability, with the ISOC staff person 362 having to continuously explain and validate IETF priorities within 363 the ISOC reporting chain. 365 Furthermore, when we're in a position where we need more staff 366 support, it's not obvious what the most appropriate path is to obtain 367 that support and how the IAOC's oversight fits into the kind of 368 performance review and career planning that ISOC staff would expect. 369 We have used a variety of models for acquiring staff support from 370 ISOC in the past, ranging from the IAD informally soliciting help 371 from others at ISOC, to the IAOC establishing more formal staff 372 relationships with ISOC personnel, to ISOC taking responsibility for 373 finding staff with an internal-to-ISOC reporting chain. The role of 374 the IAOC with respect to such staff is not defined, nor is the 375 mechanism for reflecting the work that they do for the IETF back to 376 their ISOC management. 378 IAO's oversight and management functions must be complete and 379 coherent. For example, it might either take on full oversight 380 responsibility for staff employment functions (including reporting 381 structures for management reporting and career development), or the 382 oversight role must be limited to review input submitted to the 383 external sources responsible for employment, leaving the question of 384 competing priorities unsolved. 386 3.2. Lack of Resources 388 IETF faces growing constraints on resources essential for IETF to 389 function, notably in volunteers and staff. 391 3.2.1. Volunteers 393 The IAD is the sole full-time employee for IETF, and the IASA 394 arrangement encompasses a series of volunteer committees that help to 395 work through issues such as finance, legal, meetings, technology 396 management, requests for proposals, and sponsorship. These 397 responsibilities are expanding in both time requirements, and scope. 398 In some cases, the IETF is verging on requiring volunteers to take on 399 actual work items -- which is beyond the scope of what is reasonable 400 to ask of a volunteer. As a result, it is becoming close to 401 impossible to find qualified volunteers who are willing to stand for 402 open slots on the IAOC. In general, on both the IAOC and the 403 committees, the time that committee members have to devote to the 404 tasks at hand falls far short of what is required to do much of 405 anything beyond keeping the organization afloat. At a time when the 406 IETF is faced with administrative and financial challenges, barely 407 having enough volunteers and volunteer time to keep the current 408 operation running is not a sustainable model. 410 IAO must rely less on volunteers or be better assured of engagement 411 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. IAO will require more paid employment support 422 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. IAO 442 will be required to operated in a transparent fashion per community 443 expectations set as part of this IASA 2.0 process. 445 3.4. Funding/Operating Model Mismatch and Rising Costs 447 The IETF is facing a changing financial landscape, and is ill- 448 equipped to set itself up for the future. 450 Meeting fees are currently an important source of revenue, but the 451 emergence of more viable remote participation tools and other factors 452 are likely responsible for declining in-person meeting attendance 453 going forward. 455 While there has been a lot of sponsor support for, e.g., meeting 456 hosting, getting support for the full costs of operating the IETF is 457 not easy. The costs are quite large, the value to sponsors is not 458 always obvious, the IETF community is sometimes critical or 459 unappreciative, and the same sponsors get tapped again and again for 460 many related but different opportunities. 462 In addition, relying heavily on meeting-based revenue is somewhat at 463 odds with the fact that much of the IETF's work takes place outside 464 of in-person meetings. 466 Further exacerbating the situation, the IETF is increasingly relying 467 on professional services to support its activities - in order to more 468 efficiently operate the IETF's activities and better enable IETF 469 participants to contribute to the IETF's core technical work rather 470 than administrative and supporting activities work - which is also 471 causing expenses to grow. 473 IAO must have appropriate expertise/resource to identify better 474 funding models for the future for the IETF to deal with its evolving 475 realities, as well as the authority and tools to implement them. 477 4. Goals 479 The IASA redesign effort needs to address the main issues listed 480 above in {problem-statement}. More specifically, the future 481 organizational structure needs to do at least the following: 483 o Protect the IETF's Culture and Technical Work: Ensure that the 484 future IASA organizational structure and processes preserve and 485 protect the IETF's unique culture of individual contribution, 486 clear separation of financial support from technical work, as well 487 as the "rough consensus and running code" approach to the 488 development of open Internet standards. 490 o Improve the IETF's Technical Environment: Undertake changes to 491 better enable technical contributors to focus more on that 492 technical work and less on administrative work or support 493 activities. This could for example mean directing more financial 494 resources towards the creation of new or improvement of existing 495 tools, which might be produced by contractors rather than solely 496 by volunteers. As a result, volunteers could instead focus on 497 developing the standards themselves. Thus, if the core competency 498 of IETF attendees and their reason for participating in the IETF 499 is to develop standards, then create an environment where they can 500 focus exclusively on that activity and delegate to contractors, 501 staff, or other resources the responsibility for creating and 502 maintaining tools and processes to support this activity. 504 o Clearly Define the IETF-ISOC Relationship: Define the roles of 505 IETF and ISOC in a way that helps the above structure be as clear 506 as possible, in terms of who does what, how are things accounted 507 for, and who is in charge of adjustments and control (e.g., staff 508 resources). This also includes consideration of a new funding 509 model that takes into account the historical responsibility for 510 the IETF that ISOC has had since its inception. 512 o Support a Re-Envisioned Funding Model: Provide the staff support 513 and resources needed to adapt the funding model of the IETF to 514 changes in the industry, participation, and expenses. The 515 structure should also allow for and be able to support new funding 516 streams or changes to the proportion of funds from various 517 sources. 519 o Provide Clarity About the IETF-ISOC Financial Arrangements: A 520 redesign needs to clear up ambiguities in the financial 521 arrangements between IETF and ISOC. It must also be clear to 522 people outside the IETF and ISOC organizations (e.g., sponsors) 523 what the arrangements are and what their contributions affect and 524 do not affect. 526 o Clarify Overall Roles and Responsibilities: Ensure that all staff, 527 contractor, and volunteer roles are clearly documented. This 528 necessarily includes documenting how each of these parties may 529 interact or interface with one another in order to conduct and 530 support the business of the IETF. This also includes documenting 531 key work processes, decision-making processes and authority (such 532 as pertaining to meeting venue selection), etc. A key objective 533 is to minimize ambiguity and uncertainty so that it is clear who 534 is responsible for what and who has the power to make certain 535 decisions. 537 There also needs to be a clear definition of what issues belong to 538 the IESG or IETF Chair vs. the IASA organization or staff. In 539 many cases that is not clear today, and the IETF Chair role 540 includes a lot of administrative leadership responsibility beyond 541 a rational scope for the position. 543 o Define Support Staff Roles and Responsibilities: Clearly define 544 the roles of the oversight entities and staff/contractors to match 545 the expanded work scope facing the IETF. Ensure that any changes 546 create a structure that can adapt flexibly to future growth and 547 other changes (including changes in IETF community expectations, 548 such as increased transparency or more rapid decision-making). 550 o Re-Define the Role of the IETF Community in Relation to 551 Administrative Activities: As the roles and responsibilities for 552 support staff and volunteer roles are clarified more precisely, 553 the role of the IETF community in relation to those staff and 554 volunteer roles must be better defined. This should acknowledge 555 the limited time and availability of IETF volunteers, better 556 defining expectations around oversight of and involvement in 557 strategic, operational, and execution tasks within the 558 administrative efforts. 560 The new design needs to ensure that volunteers are not overloaded 561 in such things as low level operational decisions, which are 562 properly the responsibility of staff, and volunteers can instead 563 focus on strategic changes, critical decisions, and so on. In 564 particular, this should focus on clearly documenting the lines 565 between responsibility, representation, authority, and oversight. 567 o Define Improved Transparency Requirements: The general level of 568 operational transparency and information-sharing between IETF 569 administrative staff and groups to the IETF community must be kept 570 at an acceptable level, and improved where it makes sense in the 571 future. This includes ensuring the timeliness of sharing of 572 information and decisions, as well as seeking comment on 573 prospective decisions. At the same time, we need to reset 574 expectations around responsibility and authority so that once 575 staff or an administrative support organization has been delegated 576 certain authority by the definition of the new structure, it is 577 clear that they are empowered to proceed in a particular area . 578 This will improve organizational efficiency, reduce friction, and 579 improve the pace of work and decision-making. However, it is 580 clear that enabling a group or staff to act within their 581 proscribed authority depends upon a clearer definition of roles 582 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. Legal Options for IETF Organizational Change 592 After IETF 100 in November of 2017, the IETF community clearly wanted 593 more input on the various legal options available for IETF 594 restructuring as well as the trade-offs among the various options. 595 The Design Team working with the IETF Chair asked the Internet 596 Society's tax law attorneys to outline a series of options based on 597 the requirements developed in this process. The result is a 598 memorandum [ML-memo] that outlines the various options and their 599 trade-offs. In this section, we summarize those options. We also 600 include a tabular summary for each option of the legal analysis from 601 Morgan Lewis. 603 5.1. Option 1 - Independent 501(c)(3) 605 On one end of the spectrum is complete independence from ISOC. The 606 natural choice for this would be for IETF to incorporate as an 607 independent organization, incorporating as a non-profit in a 608 particular state and then applying at the federal level to the IRS 609 for tax exemption to achieve 501(c)(3) status. In this case, all 610 functions of IAO would be legally independent of ISOC, including 611 board appointments, hiring and firing, etc. IAO would face increased 612 one-time and ongoing administrative complexities, including 613 maintenance of tax-exempt status, separate audits, financial 614 statements, and tax filing. ISOC could continue to provide funding 615 to the IAO and ISOC could set the terms of funding through a grant 616 agreement or contract. 618 +--------------------------------------------+-----+ 619 | Governance: 501(c)(3) | | 620 +--------------------------------------------+-----+ 621 | Is ISOC involved in appointing IAO Board? | No | 622 | | | 623 | Can IAO Board hire and fire the IAO ED? | Yes | 624 | | | 625 | ISOC liable for IAO debts and obligations? | No | 626 +--------------------------------------------+-----+ 628 +--------------------------------------------------+-----+ 629 | Finance and Fundraising: 501(c)(3) | | 630 +--------------------------------------------------+-----+ 631 | Can IAO have separate bank account from ISOC? | Yes | 632 | | | 633 | Can donors write checks to IAO? | Yes | 634 | | | 635 | IAO needs to maintain its own non-profit status? | Yes | 636 +--------------------------------------------------+-----+ 638 +-------------------------------------------------------+-----+ 639 | Administration/Staffing: 501(c)(3) | | 640 +-------------------------------------------------------+-----+ 641 | Would IAO need to conduct its own audit? | Yes | 642 | | | 643 | Would IAO need to file its own tax return? | Yes | 644 | | | 645 | IAO ED can hire/fire, contract without ISOC approval? | Yes | 646 +-------------------------------------------------------+-----+ 648 5.2. Option 2 - Type 1 Supporting Organization 650 IAO could be set up as a Type 1 Supporting Organization of ISOC. In 651 this model, IAO would be set up a 501(c)(3) organization but then 652 list ISOC as the named supported organization, essentially specifying 653 that it's a separate entity but one that works to support ISOC's 654 mission. In this model ISOC would have to be the sole controlling 655 parent entity, with ISOC retaining formal control of the IAO Board. 656 This would require incorporation as a non-profit, filing for federal 657 and state tax exemption, filing separate taxes, but audits and 658 financial statements would be consolidated with those of ISOC. 660 +--------------------------------------------+--------+ 661 | Governance: Type 1 Supporting Org. | | 662 +--------------------------------------------+--------+ 663 | Is ISOC involved in appointing IAO Board? | Yes(1) | 664 | | | 665 | Can IAO Board hire and fire the IAO ED? | Yes | 666 | | | 667 | ISOC liable for IAO debts and obligations? | No | 668 +--------------------------------------------+--------+ 670 +--------------------------------------------------+-----+ 671 | Finance and Fundraising: Type 1 Supporting Org. | | 672 +--------------------------------------------------+-----+ 673 | Can IAO have separate bank account from ISOC? | Yes | 674 | | | 675 | Can donors write checks to IAO? | Yes | 676 | | | 677 | IAO needs to maintain its own non-profit status? | Yes | 678 +--------------------------------------------------+-----+ 680 +-------------------------------------------------------+-----+ 681 | Administration/Staffing: Type 1 Supporting Org. | | 682 +-------------------------------------------------------+-----+ 683 | Would IAO need to conduct its own audit? | Yes | 684 | | | 685 | Would IAO need to file its own tax return? | Yes | 686 | | | 687 | IAO ED can hire/fire, contract without ISOC approval? | Yes | 688 +-------------------------------------------------------+-----+ 690 (1) ISOC would be required to appoint majority of the IAO Board, 691 perhaps upon IETF recommendations. 693 5.3. Option 3 - Disregarded LLC 695 IAO could form a Limited Liability Company (LLC) that is a 696 disregarded entity of ISOC, essentially treating it as a branch or 697 division of ISOC for most tax purposes. The term "disregarded" here 698 means that the LLC is disregarded by ISOC for some purposes; that is, 699 while ISOC's non-profit status and tax exemption applies downward to 700 the LLC, legal liability and financial impacts do not apply upwards 701 from the LLC to ISOC. In contrast to the previous option, ISOC in 702 this case could delegate the appointment of the IAO Board to a 703 nominating committee within the IAO. This option would not require 704 tax exemption filing, filing separate taxes, or separate audits or 705 financial statements. 707 +---------------------------------------------+-------+ 708 | Governance: Disregarded LLC + | | 709 +---------------------------------------------+-------+ 710 | Is ISOC involved in appointing IAO Board? | No(2) | 711 | | | 712 | Can IAO Board hire and fire the IAO ED? | Yes | 713 | | | 714 | ISOC liable for IAO debts and obligations? | No | 715 +---------------------------------------------+-------+ 717 +--------------------------------------------------+-----+ 718 | Finance and Fundraising: Disregarded LLC | | 719 +--------------------------------------------------+-----+ 720 | Can IAO have separate bank account from ISOC? | Yes | 721 | | | 722 | Can donors write checks to IAO? | Yes | 723 | | | 724 | IAO needs to maintain its own non-profit status? | No | 725 +--------------------------------------------------+-----+ 727 +-------------------------------------------------------+-----+ 728 | Administration/Staffing: Disregarded LLC | | 729 +-------------------------------------------------------+-----+ 730 | Would IAO need to conduct its own audit? | No | 731 | | | 732 | Would IAO need to file its own tax return? | No | 733 | | | 734 | IAO ED can hire/fire, contract without ISOC approval? | Yes | 735 +-------------------------------------------------------+-----+ 737 (2) ISOC can delegate responsibility for appointing all IAO Board 738 members to IETF bodies, but must retain ultimate control of the LLC. 740 5.4. Option 4 - Activity of Internet Society 742 IASA is currently an activity of ISOC, so this option was included in 743 the analysis to give a baseline for comparison of the other options. 745 +--------------------------------------------+---------------+ 746 | Governance: Activity of ISOC | | 747 +--------------------------------------------+---------------+ 748 | Is ISOC involved in appointing IAO Board? | Yes, as today | 749 | | | 750 | Can IAO Board hire and fire the IAO ED? | No | 751 | | | 752 | ISOC liable for IAO debts and obligations? | Yes | 753 +--------------------------------------------+---------------+ 754 +--------------------------------------------------+-----+ 755 | Finance and Fundraising: Activity of ISOC | | 756 +--------------------------------------------------+-----+ 757 | Can IAO have separate bank account from ISOC? | Yes | 758 | | | 759 | Can donors write checks to IAO? | No | 760 | | | 761 | IAO needs to maintain its own non-profit status? | No | 762 +--------------------------------------------------+-----+ 764 +-------------------------------------------------------+----+ 765 | Administration/Staffing: Activity of ISOC | | 766 +-------------------------------------------------------+----+ 767 | Would IAO need to conduct its own audit? | No | 768 | | | 769 | Would IAO need to file its own tax return? | No | 770 | | | 771 | IAO ED can hire/fire, contract without ISOC approval? | No | 772 +-------------------------------------------------------+----+ 774 6. Design Team Recommendation (Option 3) 776 After discussion and consideration, the design team recommended at 777 the IASA 2.0 BOF session at IETF 101 that we pursue Option 3, the 778 disregarded LLC option. 780 In our view, this option gives increased independence without the 781 full administrative complexity of the other options. Notably, this 782 option is easier to set up than the non-profit corporation options 783 and also has simpler annual reporting requirements; that is, the LLC 784 option does not require state-level incorporation, does not require 785 filing for state and federal tax exempt status, and it allows IETF to 786 continue to benefit from ISOC's tax exempt status and financial 787 reporting and auditing. IAO will be a legal entity that can have and 788 control its own bank accounts and sign contracts without involving 789 ISOC. Crucially, this option allows the operating agreement to 790 delegate the task of appointing a board to a committee (likely the 791 IAB) of IETF. 793 7. Important Remaining Issues 795 7.1. Transparency 797 The issue of increased transparency was important throughout the IASA 798 2.0 process, with little to no dissent. It was recognized that there 799 will naturally be a confidentiality requirement about hotel 800 contracting, personnel matters, and other narrow areas. At IETF 101 801 in the IASA 2.0 BOF, the design team proposed the following default 802 transparency rule: 804 Whatever doesn't have a specific justification for being kept 805 confidential, should be made public. There must exist a public 806 list of confidential items, describing the nature of the 807 information and the reason for confidentiality. 809 7.2. IAO Board 811 The composition of the IAO Board requires careful thought and 812 deliberation. An earlier draft from the design team discussed a 813 small 5-member board, and list discussion saw proposals that included 814 7 and 9 members, with some mix of the IETF Chair, IETF-appointed ISOC 815 Board members, NOMCOM-appointed members. Discussion of composition, 816 term lengths, types of experience needed, liaisons, officers, are all 817 details the design team will leave in the hands of a chartered IETF 818 working group in the near future. 820 7.3. Input from the IETF Community 822 The current IAOC also involves a structure of 7 substantive 823 committees (Finance, Legal, Meetings, Technology, RFPs, Sponsorship, 824 and Venue Review) where IETF community volunteers can contribute to 825 the administrative work of the IETF. Under a new structure, much of 826 this activity will be performed by paid IAO staff, potentially 827 limiting the nature and quantity of feedback that the IAO gets from 828 the IETF community. One option discussed heavily and mostly rejected 829 was the potential notion of an Advisory Council, that could be a 830 venue for directly marshaling community feedback into the IAO 831 structure. 833 It is unclear what kind of feedback mechanism - other than email sent 834 in response to an ietf@ietf.org mailing list post - would be 835 important to ensure that IAO has a good, ongoing sense of the 836 community, so we leave this to future deliberation. 838 7.4. Non-US incorporation 840 Finally, the community rightly challenged the design team in terms of 841 exploring organizational options in non-US venues, e.g., non-profit 842 incorporation in Europe or Asia. However, given that ISOC even under 843 a complete independence model will still need to be heavily involved 844 in the business of IAO, there were no clear options that seemed 845 strictly better given the problem statement and goals outlined above. 847 8. Acknowledgments 849 Thanks to Richard Barnes, Alissa Cooper, John Levine, and Sean Turner 850 for discussions of possible structures, and to the attorneys of 851 Morgan Lewis for their advice on possible legal impacts. 853 9. Informative References 855 [Diagrams] 856 Barnes, R., "IASA 2.0 Strawman Diagram", February 2018, 857 . 859 [Diagrams-no-trust] 860 Barnes, R., "IASA 2.0 Strawman Diagram, IETF Trust Not 861 Shown", February 2018, . 864 [I-D.arkko-ietf-finance-thoughts] 865 Arkko, J., "Thoughts on IETF Finance Arrangements", draft- 866 arkko-ietf-finance-thoughts-00 (work in progress), 867 February 2017. 869 [I-D.arkko-ietf-iasa-thoughts] 870 Arkko, J., "Thoughts on IETF Administrative Support 871 Activities (IASA)", draft-arkko-ietf-iasa-thoughts-00 872 (work in progress), March 2017. 874 [I-D.daigle-iasa-retrospective] 875 Daigle, L., "After the first decade: IASA Retrospective", 876 draft-daigle-iasa-retrospective-01 (work in progress), 877 June 2017. 879 [I-D.haberman-iasa20dt-recs] 880 Haberman, B., Arkko, J., Daigle, L., Livingood, J., Hall, 881 J., and E. Rescorla, "IASA 2.0 Design Team 882 Recommendations", draft-haberman-iasa20dt-recs-01 (work in 883 progress), October 2017. 885 [I-D.hall-iasa2-struct] 886 Haberman, B., Hall, J., and J. Livingood, "Proposed 887 Structure of the IETF Administrative Support Activity 888 (IASA), Version 2.0 (for Discussion)", draft-hall- 889 iasa2-struct-01 (work in progress), March 2018. 891 [I-D.hall-iasa20-workshops-report] 892 Hall, J. and J. Mahoney, "Report from the IASA 2.0 Virtual 893 Workshops", draft-hall-iasa20-workshops-report-00 (work in 894 progress), March 2017. 896 [ML-memo] Morgan Lewis, "Options for New Organization to Conduct 897 IETF Administrative Support Activities", February 2018, 898 . 901 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 902 IETF Administrative Support Activity (IASA)", BCP 101, 903 RFC 4071, DOI 10.17487/RFC4071, April 2005, 904 . 906 Authors' Addresses 908 Joseph Lorenzo Hall (editor) 909 CDT 911 Email: joe@cdt.org 913 Brian Haberman (editor) 914 Johns Hopkins University 916 Email: brian@innovationslab.net 918 Jari Arkko 919 Ericsson Research 921 Email: jari.arkko@piuha.net 923 Leslie Daigle 924 Thinking Cat Enterprises LLC 926 Email: ldaigle@thinkingcat.com 928 Jason Livingood 929 Comcast 931 Email: Jason_Livingood@comcast.com 933 Eric Rescorla 934 RTFM, Inc. 936 Email: ekr@rtfm.com