Individual Submission B. Haberman, Ed. Internet-Draft Johns Hopkins University Intended status: Informational J. Arkko Expires: January 8, 2018 Ericsson Research L. Daigle Thinking Cat Enterprises LLC J. Livingood Comcast J. Hall CDT E. Rescorla RTFM, Inc. July 7, 2017 IASA 2.0 Design Team Recommendations draft-haberman-iasa20dt-recs-00 Abstract The arrangements relating to administrative support for the IETF were created more than ten years ago. Since then, there has been considerable change in the tasks and in our own expectations. 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 responsible for adopting any recommendations or making any final 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 8, 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 8, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Reorganisation Options . . . . . . . . . . . . . . . . . . . 8 5.1. Overall Structure . . . . . . . . . . . . . . . . . . . . 8 5.1.1. IASA++ . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.2. ISOC Subsidiary . . . . . . . . . . . . . . . . . . . 10 5.1.3. Independent Organization . . . . . . . . . . . . . . 10 5.2. Oversight . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Strategic Board . . . . . . . . . . . . . . . . . . . 12 5.2.2. Strategic Board and an Advisory Council . . . . . . . 13 5.3. Staff Structure . . . . . . . . . . . . . . . . . . . . . 13 6. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Criteria . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Overall Structure . . . . . . . . . . . . . . . . . . . . 15 6.2.1. Pros and Cons . . . . . . . . . . . . . . . . . . . . 15 6.2.2. Comparison to Criteria . . . . . . . . . . . . . . . 18 6.3. Oversight . . . . . . . . . . . . . . . . . . . . . . . . 20 6.4. Financial Impacts . . . . . . . . . . . . . . . . . . . . 21 6.5. Other Impacts . . . . . . . . . . . . . . . . . . . . . . 21 7. Conclusions and recommendations . . . . . . . . . . . . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. Informative References . . . . . . . . . . . . . . . . . . . 22 Haberman, et al. Expires January 8, 2018 [Page 2] Internet-Draft IASA 2.0 July 2017 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The arrangements relating to administrative support for the IETF (referred to as the "IETF Administrative Support Activity" (IASA) [RFC4071]) were created more than ten years ago, when the IETF initially took charge of its own administration. The arrangements have served the IETF reasonably well, 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, convened 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 Haberman, et al. Expires January 8, 2018 [Page 3] Internet-Draft IASA 2.0 July 2017 ISOC, and it is important that ISOC be involved in the process of looking at the reorganisation. 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 (Section 2 and Section 3) describe the background and summarise the challenges noted in the community discussion. The two sections after that (Section 4 and Section 5) explain what categories of changes were considered, and describe the primary options for structural changes. The following two sections (Section 6 and Section 7) focus on analysis of the different options along with conclusions and recommendations. 2. Background The administrative support structure is 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. Haberman, et al. Expires January 8, 2018 [Page 4] Internet-Draft IASA 2.0 July 2017 Today, IASA's activities support a number of functions within the IETF system: o Meeting planning o Budget and financial management o Contracting with and overseeing the secretariat o Contracting with and overseeing the RFC Editor (together with the IAB) o Contracting with and overseeing IANA (together with the IAB) o Legal ownership of IETF materials, domain names and copyright o Ownership of IANA-related domain names and copyright o General legal support (including topics beyond domains and IPR) 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 administrative 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. Haberman, et al. Expires January 8, 2018 [Page 5] Internet-Draft IASA 2.0 July 2017 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 specific tasks, while the IAOC is the one responsible for final decisions. o ISOC - The Internet Society - The organizational home of the IETF, and one that in the current IASA system assists the IETF with legal, administrative, and funding tasks. 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 have grown considerably; we must ensure that 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 have changed, 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 Community expectations of transparency of administrative actions and execution from the administration could be better aligned. Haberman, et al. Expires January 8, 2018 [Page 6] Internet-Draft IASA 2.0 July 2017 o Lack of predictably of funding levels combined with regular shortfalls. We face continued challenges related to funding IETF activities on a background of increasing costs. We must properly manage expectations about locations of meetings (broadening of IETF engagement, sponsor preferences) while balancing against operational practicalities. And we must 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. 4. Considering a Change Given that a change seems necessary, what might that change include? There seem to be three broad categories of IETF organisation that will be affected: 1. overall structure 2. oversight 3. interfaces and expectations to rest of the IETF The overall structure also includes questions such as whether IETF is an organisation and its relationship to ISOC. 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; a more independent, free-standing organisational model for IETF would imply new functions for the 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, independent organisational unit. Haberman, et al. Expires January 8, 2018 [Page 7] Internet-Draft IASA 2.0 July 2017 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 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 for, and who is in charge of adjustments and control (e.g., staff resources). A redesign needs to propose a starting point for the financial arrangements between IETF and ISOC, either as they are now or changed in some fashion. It must 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. 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 Accommodate strategic, operational, and execution tasks within the administrative efforts, and take into account the limited availability of IETF volunteers for performing administrative tasks. The new design needs to ensure that overload in such things as 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 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 year than what is currently allocated for IASA functions. In addition, they will most likely require a more predictable level Haberman, et al. Expires January 8, 2018 [Page 8] Internet-Draft IASA 2.0 July 2017 of ISOC funding, rather than the current model of a base funding level combined with periodic infusions to cover shortfalls. 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 to better reflect the increased workload on what is now a single staff member. 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. Some specific changes to make these improvements are discussed in Section 5.2 regarding board and staff work divisions. While in this option there is no need for a formal board, there is still a need to redefine the role of the IAOC. The necessary staff changes are discussed in Section 5.3. It would also be necessary to improve IAOC transparency. In the IASA++ option, in addition to the general improvement needs in this area, there is an added need to continue the improvements relating to accurate accounting of resources and actions on the ISOC side. Haberman, et al. Expires January 8, 2018 [Page 9] Internet-Draft IASA 2.0 July 2017 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 likely 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 (see Section 5.2). Administrative decision-making authority would rest primarily with the administrative staff, with oversight provided by the board (see Section 5.3. Exception cases could be developed where board approval would be required to authorize strategic decisions. Other likely changes could include: 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). There are also other possible changes that would need further discussion: o Eliminate the IETF Trust and have the IETF subsidiary assume responsibility for the IETF's intellectual property rights (IPR). This would simplify the overall structure, but would also bundle the IPR with the rest of the IETF operations. Note that the IETF Trust currently holds IPR also on behalf of the users of IANA. o Transfer existing ISOC funds earmarked for the IETF to the subsidiary's bank account, and have future IETF income held in that subsidiary's bank account. 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 likely rely on contractors for the bulk of administrative tasks. Minimally, the IETForg staff would be responsible for administration, development/fundraising, communications, and personnel management. Haberman, et al. Expires January 8, 2018 [Page 10] Internet-Draft IASA 2.0 July 2017 As an independent organization, the IETF could eliminate the IAOC and replace it with a board of directors/trustees. Administrative (day- to-day) decision-making authority would rest 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. Again, further detais regarding the board and staff changes are in Section 5.2 and Section 5.3. Other likely changes could include: 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 is 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). Other possible changes that may need more discussion would include possible change in the role of IETF Trust, as discussed in Section 5.1.2. 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 an IASA board to be designed for that. Nevertheless, some change in the role of an oversight body and the work division between it and staff is necessary in any case. Also, the design team believes the role of the community members serving in the IASA needs to be kept at a level appropriate for volunteer service (see community role in Section 3 and limits in Section 4.1). Beyond this, there are a number of choices in division of responsibilities and the structure of the organisation. The key decision points are: o Whether the community representative or board control of the IASA is at the level of individual administrative decisions (as it is today) or at a more traditional board level of control, i.e., strategic direction, budgets, and key personnel choices. Haberman, et al. Expires January 8, 2018 [Page 11] Internet-Draft IASA 2.0 July 2017 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, and so on. The board is also responsible for hiring and assessing the performance of the Executive Director (the highest-level staff director, see Section 5.3). This option is potentially valid for all overall structure choices outlined in Section 5. However, for the ISOC Subsidiary and Independent Organisation options, the board would have to be a formal board, typical of other non-profit organisations. 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. 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 8, 2018 [Page 12] Internet-Draft IASA 2.0 July 2017 money or provide advice about fundraising (all of which are 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 some other type of selection for 1/3 of the board members with a view for more independent, well-networked members. However, the responsibility of the board and the manner in which board members are selected are separable design matters. 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 might be a better approach than either free-form 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 last call results. Some IAOC site decisions have been done in this way, summarising feedback received, others with less information. 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 increase and/or be reorganised in order to move from one director to a few more specialised roles (see growth in Section 3). And In addition, the Haberman, et al. Expires January 8, 2018 [Page 13] Internet-Draft IASA 2.0 July 2017 team believes that future organisation for IASA may benefit from organising all resources under the more clear and 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 as contractors or at ISOC. This document suggests a structure that involves the following roles: o 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 Director of Operations. This person is responsible for meeting arrangements, IT, tools, managing contracts (including RFC Editor and IANA), and day-to-day budget management. o Director of Fundraising. This person is responsible for working with IETF's sponsors and other partners, and his or her primary responsibility is fundraising for the IETF. o Director of Communications. This person is responsible for working with IETF leadership (including the IETF Chair, IESG, and IAB) on communications matters (primarily but not exclusively external communications), assisting them in efficient communication and dealing with ongoing communications matters. Note: The Executive Director likely needs to be a full-time employee, as is likely the case for the other Director-level positions. These persons also need to rely on a number of contractors and outside specialists. For instance, a Legal Counsel, to assist the IASA on legal matters as well as contracting. 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 (Section 4.1): Haberman, et al. Expires January 8, 2018 [Page 14] Internet-Draft IASA 2.0 July 2017 o The arrangements match the scale of the task (SCALE) o The arrangements are designed to evolve as situations evolve (EVOLVE) 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 8, 2018 [Page 15] 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 the current IASA will | | additional staff | not 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 | Continuing confusion about | | rely on ISOC to somewhat | alignment between ISOC and IETF | | frictionlessly compensate for | on policy and standards matters. | | 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 8, 2018 [Page 16] 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 | | administrative 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 | Continuing confusion about | | leverage expertise of ISOC | alignment between ISOC and | | administrative personnel | IETF on policy and standards | | | matters. | +----------------------------------+--------------------------------+ Table 2: ISOC Subsidiary Pros and Cons Table 3 highlights the pros and cons of the independent organization option. Haberman, et al. Expires January 8, 2018 [Page 17] 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 | | | 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 | +-------------------------------------+-----------------------------+ | Removes need for alignment between | Requires IETF to assume | | ISOC and IETF on policy and | legal risk currently | | standards matters. | 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 8, 2018 [Page 18] 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 1) | | | | 1) | (Note 1) | | +-----------+-------------+----------+------------+-----------------+ | STRAT TSK | NO | NO (Note | YES | YES | | | | 1) | | | +-----------+-------------+----------+------------+-----------------+ | 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 2) | | | | (Note 2) | (Note 2) | | +-----------+-------------+----------+------------+-----------------+ Table 4: IETF-ISOC Relationship Implications Note 1: Evolution in the current system is more difficult than if IETF was either clearly a subsidiary or its own organisation. This is because changes need agreement from two organisations, and, in the current model, the control of IETF-dedicated resource is not as clear as it could be. A subsidiary or independent model 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. Note 2: 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 Haberman, et al. Expires January 8, 2018 [Page 19] Internet-Draft IASA 2.0 July 2017 there is a lack of trust and unclear models for what can or cannot be expected. 6.3. Oversight For the internal organisation, the implications of the current situation vs. a strategic board model is summarised in Table 5. +----------------+-------------------+-----------------+ | Criteria | Current Situation | Strategic Board | +----------------+-------------------+-----------------+ | SCALE | NO | YES | +----------------+-------------------+-----------------+ | EVOLVE | MAYBE (Note 1) | YES (Note 1) | +----------------+-------------------+-----------------+ | STRAT TSK | NO | YES (Note 2) | +----------------+-------------------+-----------------+ | OPS TSK | YES | YES (Note 2) | +----------------+-------------------+-----------------+ | OVERLOAD SEP | NO | YES (Note 2) | +----------------+-------------------+-----------------+ | CLEAR ISOC REL | n.a. | n.a. | +----------------+-------------------+-----------------+ | DIR CONTROL | n.a. | n.a. | +----------------+-------------------+-----------------+ | CULTURE | YES | YES | +----------------+-------------------+-----------------+ | WORK SEP | YES | YES | +----------------+-------------------+-----------------+ | IASA EXP | NO | MAYBE (Note 3) | +----------------+-------------------+-----------------+ Table 5: Internal Organization Implications Note 1: Given that the IASA is being reorganised, we acknowledge that the current structure 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 of the IASA, rather than being a normal task within the IASA to evolve their own model. A strategic board that is not deeply involved in the operations should be able to look at evolution more easily. Similarly, a dedicated advisory council can help determine community concerns, and might be able to do this even better than a board. However, lines of authority between a strategic board and advisory council would need to be clearly delineated. Note 2: There may be a difference between the strategic board with and without an advisory council, in how overload situations and the Haberman, et al. Expires January 8, 2018 [Page 20] Internet-Draft IASA 2.0 July 2017 separation of different tasks goes. The existence of an advisory council alleviates some workload on board or staff, particularly in dealing with community 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 oganisational model, see Note 2 under Section 6.2.2. 6.4. Financial Impacts There are two different classes of financially-relevant 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. That is, depending on the chosen overall organisation model, some items that are currently in ISOC budget may move to become IETF budget items, but the total amount of expenditure stays the same. Note that the IETF already accounts for the expenses related to key IETF support staff (e.g., IAD, communications, etc). Secondly,there are some actual increases in required financial resources. 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 staff changes, the primary position actually being added is having both Executive Director and Operations Director, instead of one IAD. We've already had a Legal Counsel and roles similar to the Director of Fundraising 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. It is important to ensure that IETF funding is arranged in a manner that is satisfactory to the IETF and ISOC communities. Further comments and observations are welcome. 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). Haberman, et al. Expires January 8, 2018 [Page 21] Internet-Draft IASA 2.0 July 2017 It is for further study whether current IETF leadership (e.g., IAB Chair) should continue to be part of these boards or councils. 7. Conclusions and recommendations While there are some initial conclusions in the analysis in the previous sections, clearly more work is needed. In particular, we request and welcome thoughts and contributions from the IETF community, particularly regarding any potential missed options or the implications of options being considered here. 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 Haberman, et al. Expires January 8, 2018 [Page 22] Internet-Draft IASA 2.0 July 2017 Brian Haberman (editor) Johns Hopkins University Email: brian@innovationslab.net Jari Arkko Ericsson Research Email: jari.arkko@piuha.net Leslie Daigle Thinking Cat Enterprises LLC Email: ldaigle@thinkingcat.com Jason Livingood Comcast Email: Jason_Livingood@comcast.com Joseph Lorenzo Hall CDT Email: joe@cdt.org Eric Rescorla RTFM, Inc. Email: ekr@rtfm.com Haberman, et al. Expires January 8, 2018 [Page 23]