[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
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
                                                                 J. Hall
                                                             E. Rescorla
                                                              RTFM, Inc.
                                                            July 7, 2017

                  IASA 2.0 Design Team Recommendations


   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

   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

   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

   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

   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

   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

   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

   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

   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

      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

   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

   o  Establish IETF community consensus about who has policy authority
      for administrative decisions where there is currently a lack of

   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

   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

   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

   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

   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

   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

   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

   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

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

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

   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

              Arkko, J., "Thoughts on IETF Administrative Support
              Activities (IASA)", draft-arkko-ietf-iasa-thoughts-00
              (work in progress), March 2017.

              Daigle, L., "After the first decade: IASA Retrospective",
              draft-daigle-iasa-retrospective-01 (work in progress),
              June 2017.

              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

   Email: Jason_Livingood@comcast.com

   Joseph Lorenzo Hall

   Email: joe@cdt.org

   Eric Rescorla
   RTFM, Inc.

   Email: ekr@rtfm.com

Haberman, et al.         Expires January 8, 2018               [Page 23]