Individual Submission B. Haberman, Ed. Internet-Draft Johns Hopkins University Intended status: Informational J. Arkko Expires: January 4, 2018 Ericsson Research L. Daigle Thinking Cat Enterprises LLC J. Hall CDT J. Livingood Comcast E. Rescorla RTFM, Inc. July 3, 2017 IASA 2.0 Design Team Recommendations draft-dt-iasa20-00.txt Abstract The arrangements relating to administrative support for the IETF were created more than ten years ago. There's been considerable change in the tasks and our own expectations since then. The IETF community has discussed these changes and the problems they cause. The community has some sense of the properties they expect from future arrangements, including structural and organizational changes, changes to volunteer and staff personnel resources, and transparency changes. This document is a product of a design team, focused on providing additional information to the community about solution options, as well as supporting analysis of the implications of those options. To be clear, the community is in charge of adopting any recommendations or making any decisions. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Haberman, et al. Expires January 4, 2018 [Page 1] Internet-Draft IASA 2.0 July 2017 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 4, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Considering a Change . . . . . . . . . . . . . . . . . . . . 7 4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Reorganisation Options . . . . . . . . . . . . . . . . . . . 8 5.1. Overall Structure . . . . . . . . . . . . . . . . . . . . 8 5.1.1. IASA++ . . . . . . . . . . . . . . . . . . . . . . . 8 5.1.2. ISOC Subsidiary . . . . . . . . . . . . . . . . . . . 9 5.1.3. Independent Organization . . . . . . . . . . . . . . 10 5.2. Oversight . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Strategic Board . . . . . . . . . . . . . . . . . . . 11 5.2.2. Strategic Board and an Advisory Council . . . . . . . 12 5.3. Staff Structure . . . . . . . . . . . . . . . . . . . . . 12 6. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Criteria . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Overall Structure . . . . . . . . . . . . . . . . . . . . 14 6.2.1. Pros and Cons . . . . . . . . . . . . . . . . . . . . 14 6.2.2. Comparison to Criteria . . . . . . . . . . . . . . . 17 6.3. Oversight . . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Financial Impacts . . . . . . . . . . . . . . . . . . . . 20 6.5. Other Impacts . . . . . . . . . . . . . . . . . . . . . . 20 7. Conclusions and recommendations . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Informative References . . . . . . . . . . . . . . . . . . . 21 Haberman, et al. Expires January 4, 2018 [Page 2] Internet-Draft IASA 2.0 July 2017 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction The arrangements relating to administrative support for the IETF (IASA [RFC4071]) were created more than ten years ago, when the IETF initially took charge of its own administration. The arrangements have reasonably served the IETF, but there's been considerable change in the necessary tasks, in the world around us, and our own expectations since the creation of the IASA. What administrative arrangements best support the IETF in the next ten years? The system has experienced various challenges and frustrations along the way, for instance around meeting arrangements. There are also some bigger questions about how the organisations are structured, for instance about the division of responsibilities between IETF and ISOC. The IETF community has discussed and continues to discuss these topics, most recently on the "IASA20" mailing list and BOF at IETF98. Alissa Cooper, the Chair of the IETF, asked a small design team to start evaluating potential options going forward. The purpose of the design team is to provide material that informs the community discussion, both in terms of providing a bit more worked through solution ideas, as well as supporting analysis of the implications of those options. This information, along with all other input provided in the discussion, hopefully helps the community and IETF leadership decide what next steps to take. To be clear, the community is in charge of adopting any recommendations or making any decisions. This draft, the output of the design team's considerations, has no particular official standing. Once an initial version of this draft is published, the authors would like to ask feedback particularly on two aspects: o If the set of options outlined in the draft covers the options that should be looked at. o If the analysis of the implications of the options is correct. Once this discussion completes, it becomes feasible to discuss what the conclusions or recommendations ought to be, and which recommendations the community should adopt. It should also be noted that IETF administrative matters have been organised jointly with ISOC, and it is important that ISOC is also involved in the process of looking at the reorganisation. Haberman, et al. Expires January 4, 2018 [Page 3] Internet-Draft IASA 2.0 July 2017 As a base for this work there was a good articulation of the set of problems we are facing in [I-D.hall-iasa20-workshops-report] and [I-D.daigle-iasa-retrospective]. The community discussion seems have indicated also some of the outcome properties that are expected. The scope of the solutions explored included: o Structural and organizational changes, both externally (with ISOC and contractors) and internally (within the IAOC and subcommittees) o Changes to personnel resources, both volunteer and paid o Transparency changes Changes to the funding model are out of scope to the extent they fall outside the categories above. The rest of the document is organised as follows. The next two sections describe the background and summarise the challenges noted in the community discussion. The two sections after that explain what categories of changes were considered, and describe the primary options for structural changes. The following section discusses other changes, followed by two sections on analysis of the different options along with a recommendation. 2. Background The administrative support structure intended to be responsive to the administrative needs of the IETF technical community. RFC 4071 [RFC4071] defines the current IETF Administrative Support Activity (IASA). It is an activity housed within the Internet Society (ISOC), as is the rest of the IETF. RFC 4071 defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. As RFC 4071 notes, IASA is distinct from IETF-related technical functions, such as the RFC Editor, the IANA, and the IETF standards process itself. The IASA has no influence on the technical decisions of the IETF or on the technical contents of IETF work. Today, IASA's activities support a number of functions within the IETF system: o Meeting planning Haberman, et al. Expires January 4, 2018 [Page 4] Internet-Draft IASA 2.0 July 2017 o Contracting with and overseeing the secretariat o Contracting with the overseeing the RFC Editor (together with IAB) o Contracting with and overseeing IANA (together with IAB) o Legal ownership of IETF materials, domain names and copyright o Ownership of IANA-related domain names and copyright o IETF website o IETF IT services o Tooling support, maintenance, and development (together with volunteers) o Meeting network support o Remote attendance support o Communications assistance for the IETF o Sponsorship and funding (together with ISOC) 2.1. Terminology The following acronyms are used in this document: o IASA - IETF Administrative Support Activity - An organized activity that provides a dministrative support for the IETF, the IAB and the IESG. o IAOC - IETF Administrative Oversight Committee in the current IASA system - A largely IETF-selected committee that oversees and directs IASA. Accountable to the IETF community. o IAOC committees - Recognizing the need for specialized attention for different branches of work requiring IAOC oversight, the IAOC expanded its support by creating committees. Currently, the committees do the heavy lifting on background work, while the IAOC is the one responsible for final decisions. o ISOC - The Internet Society - An organizational home of the IETF, and one that in the current IASA system assists the IETF with legal, administrative, and funding tasks. Haberman, et al. Expires January 4, 2018 [Page 5] Internet-Draft IASA 2.0 July 2017 o IAD - IETF Administrative Director - In the current system, the sole staff member responsible for carrying out the work of the IASA. An ISOC employee. o IETF Trust - In the current system the IETF Trust acquires, maintains, and licenses intellectual and other property used in connection with the administration of the IETF. Same composition as IAOC. 3. Challenges Discussion leading to this document has been framed by the issues discussed on IETF mailing lists and documented elsewhere [I-D.daigle-iasa-retrospective], [I-D.hall-iasa20-workshops-report], [I-D.arkko-ietf-iasa-thoughts]. The reader is referred to those documents and ongoing discussion on the IASA20@ietf.org mailing list for fuller details on the range of challenges facing the IETF in its handling of administrative matters. In summary, the key areas of challenge that have shaped this work are: o The range of IETF administrative tasks has grown considerably; ensure we have the right structure, community involvement and level of staffing to address them effectively and efficiently. o The relationship and division of responsibilities between the IETF and ISOC, as both organizations have grown considerably in the last decade. The joint organisation that supports the IETF has grown rather organically, and would benefit from re-assessment and possible reorganisation. o Alignment of community expectations of transparency of administrative actions and delivery from the administration. o Funding and sponsorships. Manage expectations about locations of meetings (broadening of IETF engagement, sponsor preferences), balanced against operational practicalities. Ensure that we continue to not be influenced by funding entities on the technical work of the IETF. Of the items above, the first two are largely to be addressed by structural updates, while the last two groups are more about discussing tradeoffs and updating documented expectations. Haberman, et al. Expires January 4, 2018 [Page 6] Internet-Draft IASA 2.0 July 2017 4. Considering a Change Given that a change seems necessary, what might that change include? There seems three broad categories of IETF organisation that are going to be affected: 1. overall structure, 2. oversight, and 3. interfaces and expectations to rest of the IETF. Overall structure includes also questions such as whether IETF is an organisation, and its the relationship to ISOC is. There are some interconnections between different aspects of reorganisation. For instance, how IETF defines its relationship to ISOC will have some implications on what kind of oversight structure is needed, for insance. And a more independent, free-standing organisational model for IETF would imply new functions at IASA. There are a number of choices to make within the reorganisation effort. In particular, IETF's relationship to ISOC could be arranged in a fundamentally similar manner than it is today, but improved, e.g., to make clear who is expected to control a particular part of the operation. But the relationship could also be arranged in a different way, for instance, as a subsidiary of ISOC or as a more free-standing, own organisational unit. 4.1. Goals The IASA redesign effort needs to address the main challenges listed above. More specifically, a new organisational structure needs to do at least the following: o Define the roles of the oversight entities and staff/contractors to match the grown size of the tasks. Ensure that we have a structure that can adapt to future growth and other changes. o Define the roles of IETF and ISOC in a way that helps the above structure be as clear as possible, in terms of who does what, how are things accounted, and who is in charge of adjustments and control (e.g., staff resources). Propose a starting point for the financial arrangements between IETF and ISOC, either as they are now or changed in some fashion. It shall also be clear to people outside the IETF and ISOC organisation (e.g., sponsors) what the arrangements are and what their contributions affect and do not affect. Haberman, et al. Expires January 4, 2018 [Page 7] Internet-Draft IASA 2.0 July 2017 o The new organisation needs to accommodate for strategic, operational, and execution of administrative tasks, and take into account the limited availability of IETF volunteers for performing administrative tasks. The new design needs to ensure that overload in, e.g., operational decisions does not affect the ability to drive strategic changes. o Set expectations and limits of those expectations on the different parts of the system. This includes, but is not limited to community expectations of transparency. o Ensure that future IASA organizational structure and processes preserves and protects the IETF's unique culture of individual contribution, clear separation of financial support from technical work, as well as rough consensus and running code. 5. Reorganisation Options 5.1. Overall Structure The design team, in discussion with the IETF chair, believes that there are three general approaches to evolving the IASA function. The options generally focus on the relationship between the IETF and ISOC. Changes to this relationship directly affect how the IASA function gets carried out. It should be noted that all three options require more administrative budget per annum than what is currently allocated for IASA functions. The following subsections describe each option. Section 6 highlights their pros and cons and effectiveness in comparison to the goals stated earlier. 5.1.1. IASA++ In the IASA++ option, the IETF and ISOC maintain the current structural relationship. This means that the IETF remains an organized activity of ISOC, ISOC maintains funds and contracting authority on behalf of the IETF, and all IASA staff are ISOC employees. While the relationship remains the same, the IETF and ISOC will make improvements to the relationship in order to enhance the functionality of the IETF. The following are some potential improvements that could be made under this approach: o Provide clarity and transparency about authority, responsibility, budgeting, and allocation of staff time for all IETF-related work and activities. o Add IASA staff. Haberman, et al. Expires January 4, 2018 [Page 8] Internet-Draft IASA 2.0 July 2017 o Provide clarity about authority of the IAOC in reviewing performance of IASA staff. o Re-structure the internal IETF organization and appointment processes for the IAOC and the IETF Trust to address current challenges. o Establish IETF community consensus about who has policy authority for administrative decisions where there is currently a lack of clarity. o Improve IAOC transparency. 5.1.2. ISOC Subsidiary In this option, an ISOC subsidiary would be created as the new legal home of the IETF. A subsidiary can have its own bank account, by- laws, charter, board of directors/trustees, staff, and corporate identity. As a subsidiary of ISOC, the IETF and ISOC can share overhead and resources. The IETF would rely heavily on contractors for most administrative tasks. As a subsidiary of ISOC, the IETF could eliminate the IAOC and replace it with a board of directors/trustees. Administrative decision-making authority would primarily with the administrative staff, with oversight provided by the board. Exception cases could be developed where board approval would be required to authorize strategic decisions. Other possible changes could include: o Eliminate the IETF Trust and have the IETF subsidiary assume responsibility for IETF IPR. o Transfer existing ISOC funds earmarked for the IETF to the subsidiary bank account, and have future IETF income held in subsidiary bank account. o Transfer existing IETF-related contracts between ISOC and contractors to be between the subsidiary and contractors. o Multiple options to structure community involvement in administrative decision-making (e.g., committees organized by subsidiary staff). Haberman, et al. Expires January 4, 2018 [Page 9] Internet-Draft IASA 2.0 July 2017 5.1.3. Independent Organization In this option, a new non-profit organization (e.g., IETForg) is created independent from ISOC as the new legal home of the IETF. IETForg would have its own bank account, by-laws, charter, board of directors/trustees, staff, and corporate identity. The administrative staff for IETForg could be kept lean and would rely on contractors for the bulk of administrative tasks. Minimally, the IETForg staff would be responsible for administration, development/ fundraising, communications, and personnel management. As an independent organization, the IETF could eliminate the IAOC and replace it with a board of directors/trustees. Administrative decision-making authority would primarily with IETForg staff and contractors, with oversight provided by the board. Exception cases could be developed where board approval would be required to authorize strategic decisions. Other possible changes could include: o Eliminate the IETF Trust and have IETForg assume responsibility for IETF IPR. o Transfer existing ISOC funds earmarked for the IETF to IETForg, and have future IETF income held by IETForg. ISOC would still be largest IETForg sponsor, if funding maintained at current projections. o Transfer existing IETF-related contracts between ISOC and contractors to be between IETForg and contractors. o Multiple options to structure community involvement in administrative decision-making (e.g., committees organized by subsidiary staff). 5.2. Oversight Oversight is obviously affected by what we decide to do with the relationship to ISOC. A bigger, more independent role for the IETF would require IASA boards to be designed for that. The design team believes the role of the community members serving in IASA needs to be kept at a level appropriate for volunteer service (see community role in Section 3 and limits in Section 4.1). But beyond this, there are a number of choices in division of responsibilities and the structure of the organisation. The key decision points are: Haberman, et al. Expires January 4, 2018 [Page 10] Internet-Draft IASA 2.0 July 2017 o Whether the community representative or board control of IASA is at the level of individual administrative decisions (as it is today) or at a more traditional board control, i.e., strategic direction, budgets, and key personnel choices. o Whether the interface to the community is via staff or a community representative or board function. 5.2.1. Strategic Board In this option, the current IAOC is disbanded and replaced by a traditional oversight board, common in most non-profit organisations. This board, the IASA Board (IB), acts to set strategic direction for IETF administrative matters, sets budgets, provides fiscal oversight, provides high-level oversight about major new projects. The board is also responsible for hiring and assessing the performance of the Executive Director (the highest-level staff director, see Section 5.3). The board works with staff who is empowered to carry out the operations as directed by the board. The staff is responsible for operating within the limits set by the board, and are accountable to the board. Including being hired and fired as needed. The staff's responsibilities include: o preparing for and making decisions on their agreed and budgeted areas (for example, meeting venue decisions) o operational execution of these decisions, including contracting with vendors o communicating with the community o development of the IETF's administrative operation, in consultation with the community The primary difference between this option and the current IAOC arrangements is that board acts at a higher decision level, and is not involved either in detailed decisions or discussions on individual topics with the community. These are tasks reserved for the staff, and the board's role is to oversee that staff performs appropriately in their role. The composition of the board needs careful attention. It is important to have regular IETF participants in the board, but at least some of the board members need to have skills and experience less common among IETF participants, namely non-profit management, budget experience, and ability to help make connections to raise Haberman, et al. Expires January 4, 2018 [Page 11] Internet-Draft IASA 2.0 July 2017 money or provide advice about fundraising (all of which are pretty typical for a non-profit board). One potential model for populating the board is a Nomcom-selection for 2/3 of the board members and selection by IETF and ISOC leadership for 1/3 of the board members with a view for more outside, well-networked members. 5.2.2. Strategic Board and an Advisory Council In this option, there is a board and staff just like in Section 5.2.1, but in addition, an Advisory Council (AC) provides an interface to the community on matters that require assessing community opinion. For instance, the current polling of community feedback relating to potential future meeting locations could be one such matter. An advisory council canvassing and pulling for this information is probably a better approach than either freeform mailing list discussion, or the relatively opaque process that is currently used. Advisory board results could be documented in the same fashion as IESG documents documents last call results. Some IAOC site decisions have been done in this way, but not all, possibly due to lack of time. The advisory council would be comprised of IETF community members and selected by Nomcom, and would benefit from having either the IETF Chair or another IESG member as a liaison. The advisory council would not make decisions about how the IETF should run, but it would be available for the staff to consult whenever they needed a view from the community, and it would also be available to run community discussion processes or to get input from the community to funnel back to the staff. The advisory council would have a well-defined interface to the IESG as well. The separation of the board and the advisory council, with some overlap between them, allows the allocation of people to tasks according to their skills. We can have experienced managers involved in hiring, firing, and reviewing the Executive Director and overseeing the budget, while we have experienced community people giving the perspective of the community. 5.3. Staff Structure The design team believes that staff resources need to increased or reorganised from one director to a few more specialised roles (see growth in Section 3). And In addition, the team believes that future organisation for IASA may benefit from organising all resources under Haberman, et al. Expires January 4, 2018 [Page 12] Internet-Draft IASA 2.0 July 2017 a clearer and more direct control of the IETF (see division of responsibilities in Section 3 and roles in Section 4.1). The current arrangement involves one officially designated IASA employee, but there are also many supporting employees. They are less clearly assigned for the IETF, working at contractors and at ISOC. This document suggests a structure that involves: o An Executive Director. The person in this role is in charge of the overall IASA effort, but can rely on other staff members below as well as contractors. The Executive Director is accountable to the Board. o Operations Director. This person is responsible for meeting arrangements, IT, tools, managing contracts (including RFC Editor and IANA), and day-to-day budget management. o Partner Director. This person is responsible for working with IETF's sponsors and other partners, and the primary responsible for fundraising. o Communications Director. This person is responsible for working with IETF leadership (incl. IETF Chair, IESG, and IAB) on communications matters, assisting them in efficient communication and dealing with ongoing communications matters. o Legal Counsel (likely an outside counsel, contracted). This person assists the IASA on legal matters as well as prepares and reviews all contracts that are needed with IETF's contractors. The Executive Director needs to be an employee, as are likely the other Director-level positions with the exception of the Legal Counsel. 6. Analysis This section provides a basic analysis of the effects of the different options. 6.1. Criteria We use the following criteria based on the goals stated earlier: o The arrangements match the scale of the task (SCALE) o The arrangements are designed to evolve as situations evolve (EVOLVE) Haberman, et al. Expires January 4, 2018 [Page 13] Internet-Draft IASA 2.0 July 2017 o Accommodates strategic tasks (STRAT TSK) o Accommodates operational and execution tasks (OPS TSK) o Avoids overload in one class of tasks preventing progress in other (OVERLOAD SEP) o Clarifies the relationship between IETF and ISOC (CLEAR ISOC REL) o Allows direct IETF control of resources (e.g., staff) working on a task (DIR CONTROL) o Preserves IETF culture and mode of operation (CULTURE) o Separates IETF technical work and administrative tasks and funding (WORK SEP) o Sets expectations on what can or can not be expected from IASA (IASA EXP) 6.2. Overall Structure 6.2.1. Pros and Cons Table 1 highlights the pros and cons of the IASA++ option. Haberman, et al. Expires January 4, 2018 [Page 14] Internet-Draft IASA 2.0 July 2017 +--------------------------------+----------------------------------+ | Pros | Cons | +--------------------------------+----------------------------------+ | Maintains familiar structures | Does not provide the IETF with | | and relationships | true independence of funding or | | | staff from ISOC | +--------------------------------+----------------------------------+ | Start-up costs limited to | Creates risk that challenges | | those associated with hiring | present in current IASA will not | | additional staff | actually be solved or will re- | | | emerge over time | +--------------------------------+----------------------------------+ | Does not require legal and | Potentially requires ISOC to | | administrative work to | cede more authority to the IETF | | incorporate a new entity | community or increase | | | transparency beyond ISOC's | | | comfort zone | +--------------------------------+----------------------------------+ | Allows IETF to continue to | | | rely on ISOC to somewhat | | | frictionlessly compensate for | | | budget shortfalls if necessary | | +--------------------------------+----------------------------------+ Table 1: IASA++ Pros and Cons Table 2 highlights the pros and cons of the ISOC subsidiary option. Haberman, et al. Expires January 4, 2018 [Page 15] Internet-Draft IASA 2.0 July 2017 +----------------------------------+--------------------------------+ | Pros | Cons | +----------------------------------+--------------------------------+ | Forces some delineation of | Leaves open some potential for | | responsibility, staff, and funds | continued lack of clarity | | between the IETF and ISOC | about authority and funding | | | between the IETF and ISOC | +----------------------------------+--------------------------------+ | Provides the IETF community with | Potentially requires ISOC to | | greater authority over IETF | cede more authority to the | | administration | IETF community or increase | | | transparency beyond ISOC's | | | comfort zone | +----------------------------------+--------------------------------+ | Can leverage existing ISOC legal | Requires legal and | | structures and personnel to keep | administrative work to | | administratie work required to | incorporate subsidiary | | incorporate subsidiary to a | | | minimum | | +----------------------------------+--------------------------------+ | Requires less IETF community | Vests more decision-making | | volunteer time commitment to | authority in paid staff than | | administrative matters than | under current IASA | | current IASA | | +----------------------------------+--------------------------------+ | Allows IETF to continue to rely | Start-up costs include costs | | on ISOC to somewhat | of incorporating the | | frictionlessly compensate for | subsidiary and re- | | budget shortfalls if necessary | organizing/hiring additional | | | staff | +----------------------------------+--------------------------------+ | Allows IETF to continue to | | | leverage expertise of ISOC | | | administrative personnel | | +----------------------------------+--------------------------------+ Table 2: ISOC Subsidiary Pros and Cons Table 3 highlights the pros and cons of the independent organization option. Haberman, et al. Expires January 4, 2018 [Page 16] Internet-Draft IASA 2.0 July 2017 +-------------------------------------+-----------------------------+ | Pros | Cons | +-------------------------------------+-----------------------------+ | Eliminates all ambiguity about IETF | Start-up costs include | | having authority independent from | legal and administrative | | ISOC over staff, funds, and | costs to incorporate a new | | decisions | entity, hire new staff, | | | transfer contracts and | | | funds | +-------------------------------------+-----------------------------+ | Provides the IETF community with | ISOC's financial support | | potentially complete authority over | for the IETF may be viewed | | IETF administration and funding | as more tenuous if the IETF | | | is a legally separate | | | entity from ISOC | +-------------------------------------+-----------------------------+ | Requires less IETF community | Ability for the IETF to | | volunteer time commitment to | rely on ISOC in the event | | administrative matters than current | of budget shortfalls may be | | IASA | more limited | +-------------------------------------+-----------------------------+ | Allows for direct investment in | Vests more decision-making | | small number of professional staff | authority in paid staff | | specifically tailored to the IETF's | than under current IASA | | needs and culture, while continuing | (i.e., risks of capture) | | to rely heavily on contractors | | +-------------------------------------+-----------------------------+ | Provides opportunity to structure | Requires more from board | | board in such a way to overcome | members than what is | | current challenges with IAOC | currently required of IAOC | | structure | insofar as hiring and | | | evaluating staff | +-------------------------------------+-----------------------------+ | | Requires IETF to assume | | | legal risk currently | | | assumed by ISOC | +-------------------------------------+-----------------------------+ Table 3: Independent Organization Pros and Cons 6.2.2. Comparison to Criteria For the overall structure, the implications of the current situation and the three options are summarized in Table 4. Haberman, et al. Expires January 4, 2018 [Page 17] Internet-Draft IASA 2.0 July 2017 +-----------+-------------+----------+------------+-----------------+ | Criteria | Current | IASA++ | ISOC | Independent | | | situation | | Subsidiary | Organization | +-----------+-------------+----------+------------+-----------------+ | SCALE | NO | NO | YES | YES | +-----------+-------------+----------+------------+-----------------+ | EVOLVE | NO | NO (Note | MAYBE | YES (Note 4) | | | | 4) | (Note 4) | | +-----------+-------------+----------+------------+-----------------+ | STRAT TSK | NO | NO (Note | YES | YES | | | | 4) | | | +-----------+-------------+----------+------------+-----------------+ | OPS TSK | YES | YES | YES | YES | +-----------+-------------+----------+------------+-----------------+ | OVERLOAD | YES | YES | YES | YES | | SEP | | | | | +-----------+-------------+----------+------------+-----------------+ | CLEAR | NO | NO | YES | YES | | ISOC REL | | | | | +-----------+-------------+----------+------------+-----------------+ | DIR | NO | NO | YES | YES | | CONTROL | | | | | +-----------+-------------+----------+------------+-----------------+ | CULTURE | YES | YES | YES | YES | +-----------+-------------+----------+------------+-----------------+ | WORK SEP | YES | YES | YES | YES | +-----------+-------------+----------+------------+-----------------+ | IASA EXP | NO | MAYBE | MAYBE | MAYBE (Note 3) | | | | (Note 3) | (Note 3) | | +-----------+-------------+----------+------------+-----------------+ Table 4: IETF-ISOC Relationship Implications Note 4: Evolution in the current system is more difficult than if IETF was either clearly a subsidiary or its own organisation. This would also ease driving any strategy that the IETF wants to drive, as decisions would be more on the IETF side than something that today would require negotiation with ISOC. 6.3. Oversight For the internal organisation, the implications of the current situation and the two options are summarised in Table 5. Haberman, et al. Expires January 4, 2018 [Page 18] Internet-Draft IASA 2.0 July 2017 +------------+--------------+------------+--------------------------+ | Criteria | Current | Strategic | Strategic Board and an | | | Situation | Board | Advisory Council | +------------+--------------+------------+--------------------------+ | SCALE | NO | YES | YES | +------------+--------------+------------+--------------------------+ | EVOLVE | MAYBE (Note | MAYBE | YES (Note 1) | | | 1) | (Note 1) | | +------------+--------------+------------+--------------------------+ | STRAT TSK | NO | YES (Note | YES | | | | 2) | | +------------+--------------+------------+--------------------------+ | OPS TSK | YES | YES (Note | YES | | | | 2) | | +------------+--------------+------------+--------------------------+ | OVERLOAD | NO | YES (Note | YES | | SEP | | 2) | | +------------+--------------+------------+--------------------------+ | CLEAR ISOC | n.a. | n.a. | n.a. | | REL | | | | +------------+--------------+------------+--------------------------+ | DIR | n.a. | n.a. | n.a. | | CONTROL | | | | +------------+--------------+------------+--------------------------+ | CULTURE | YES | YES | YES | +------------+--------------+------------+--------------------------+ | WORK SEP | YES | YES | YES | +------------+--------------+------------+--------------------------+ | IASA EXP | NO | MAYBE | MAYBE (Note 3) | | | | (Note 3) | | +------------+--------------+------------+--------------------------+ Table 5: Internal Organization Implications Note 1: Given that IASA is being reorganised, even the current system is capable of evolving. However, the operational focus and overload in the current arrangements are making this harder than is necessary. Change requires action from outside IASA, rather than being a normal task within IASA to evolve their own model. A strategic board without an advisory council maybe a bit weaker in evolution, given that a dedicated advisory council can help determine community concerns. Note 2: There may be a difference between the strategic board with and without an advisory councilin how overload situations and the separation of different tasks goes. The existence of an advisory board may take off some board or staff load to deal with community Haberman, et al. Expires January 4, 2018 [Page 19] Internet-Draft IASA 2.0 July 2017 opinion determination, freeing the board to do its strategic work and staff to concentrate on operations and execution. Note 3: Setting expectations is difficult merely based on an organisational model. Certainly a clear separation between roles of the board and staff helps. However, expectations are also a matter of documentation, which would have be created and communicated. Finally, expectations are a cultural matter, current IAOC arrangements and community views have ended up in a situation where there is a lack of trust and unclear models for what can or can not be expected. 6.4. Financial Impacts There are two different classes of changes. First, both the ISOC interface change and staff changes will imply changes in what is being accounted for in budgets and reports, even in cases where the actual work or the number of people stays the same. Secondly, there are actual increases. We expect all the alternatives to lead to somewhat higher funding needs, and in fact shifting more work to staff from volunteers is one of the goals. For the internal reorganisation, the primary position actually being added is having both Executive Director and Operations Director, instead of one IAD. We've already had Legal Counsel and Communications Director. These chances coincide with other personnel changes in IASA, as the experienced, long-term IAD is retiring. Even from a learning curve point of view more people will be needed, but in this case it also makes sense to have the organisation be less dependent on one central person. Given the learning curve effect, and a new organisation, it is expected that the role of the Legal Counsel will also increase, e.g., in terms of reviewing contracts. The effects of ISOC relationship changes to finance are for further study. 6.5. Other Impacts Depending on the chosen option, volunteers are needed for either different roles than today (the board) or for both different roles and more volunteers (the board and the advisory council). It is for further study whether current IETF leadership (e.g., IAB Chair) should continue to be part of these boards or councils. Haberman, et al. Expires January 4, 2018 [Page 20] Internet-Draft IASA 2.0 July 2017 7. Conclusions and recommendations While there are some initial conclusions in the analysis in the previous sections, clearly more work is needed. In particular, thoughts and contributions regarding either missed options or their implications is welcome. 8. Acknowledgments This text is the work of the design team, but greatly influenced by discussions in the IETF community. The team would in particular like to thank Alissa Cooper, Andrew Sullivan, Ray Pelletier, Ted Hardie, Gonzalo Camarillo, Brian Carpenter, Lucy Lynch, Stephen Farrell, Dave Crocker, Jon Peterson, Alexa Morris, Michael Richardson, Olaf Kolkman, Kathy Brown, and Melinda Shore for interesting discussions in this problem space. 9. Informative References [I-D.arkko-ietf-iasa-thoughts] Arkko, J., "Thoughts on IETF Administrative Support Activities (IASA)", draft-arkko-ietf-iasa-thoughts-00 (work in progress), March 2017. [I-D.daigle-iasa-retrospective] Daigle, L., "After the first decade: IASA Retrospective", draft-daigle-iasa-retrospective-01 (work in progress), June 2017. [I-D.hall-iasa20-workshops-report] Hall, J. and J. Mahoney, "Report from the IASA 2.0 Virtual Workshops", draft-hall-iasa20-workshops-report-00 (work in progress), March 2017. [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005, . Authors' Addresses Brian Haberman (editor) Johns Hopkins University Email: brian@innovationslab.net Haberman, et al. Expires January 4, 2018 [Page 21] Internet-Draft IASA 2.0 July 2017 Jari Arkko Ericsson Research Email: jari.arkko@piuha.net Leslie Daigle Thinking Cat Enterprises LLC Email: ldaigle@thinkingcat.com Joseph Lorenzo Hall CDT Email: joe@cdt.org Jason Livingood Comcast Email: Jason_Livingood@comcast.com Eric Rescorla RTFM, Inc. Email: ekr@rtfm.com Haberman, et al. Expires January 4, 2018 [Page 22]