Skip to main content

IASA 2.0 Design Team Recommendations
draft-haberman-iasa20dt-recs-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Brian Haberman , Jari Arkko , Leslie Daigle , Jason Livingood , Joseph Lorenzo Hall , Eric Rescorla
Last updated 2017-10-17
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-haberman-iasa20dt-recs-01
Individual Submission                                   B. Haberman, Ed.
Internet-Draft                                  Johns Hopkins University
Intended status: Informational                                  J. Arkko
Expires: April 20, 2018                                Ericsson Research
                                                               L. Daigle
                                            Thinking Cat Enterprises LLC
                                                            J. Livingood
                                                                 Comcast
                                                                JL. Hall
                                                                     CDT
                                                             E. Rescorla
                                                              RTFM, Inc.
                                                        October 17, 2017

                  IASA 2.0 Design Team Recommendations
                  draft-haberman-iasa20dt-recs-01.txt

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 those related to structure,
   organization, personnel, and transparency.

   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 https://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
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Haberman, et al.         Expires April 20, 2018                 [Page 1]
Internet-Draft                  IASA 2.0                    October 2017

   This Internet-Draft will expire on April 20, 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
   (https://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 . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Current IASA Arrangements . . . . . . . . . . . . . . . .   5
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Lack of Clarity . . . . . . . . . . . . . . . . . . . . .   7
       3.1.1.  Responsibility  . . . . . . . . . . . . . . . . . . .   7
       3.1.2.  Representation  . . . . . . . . . . . . . . . . . . .   7
       3.1.3.  Authority . . . . . . . . . . . . . . . . . . . . . .   8
       3.1.4.  Oversight . . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Lack of Resources . . . . . . . . . . . . . . . . . . . .   9
       3.2.1.  Volunteers  . . . . . . . . . . . . . . . . . . . . .   9
       3.2.2.  Staff . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.3.  Lack of Transparency  . . . . . . . . . . . . . . . . . .   9
     3.4.  Funding/Operating Model Mismatch and Rising Costs . . . .  10
   4.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Reorganization Options  . . . . . . . . . . . . . . . . . . .  13
     5.1.  Overall Structure . . . . . . . . . . . . . . . . . . . .  14
       5.1.1.  IASA++  . . . . . . . . . . . . . . . . . . . . . . .  14
       5.1.2.  ISOC Subsidiary . . . . . . . . . . . . . . . . . . .  15
       5.1.3.  Independent Organization  . . . . . . . . . . . . . .  16
     5.2.  IETFAdminOrg and the Relationship with IETF . . . . . . .  17
     5.3.  Oversight for IETFAdminOrg  . . . . . . . . . . . . . . .  18
       5.3.1.  Board Selection . . . . . . . . . . . . . . . . . . .  19
       5.3.2.  Advisory Council  . . . . . . . . . . . . . . . . . .  20
       5.3.3.  Board Changes in IASA++ . . . . . . . . . . . . . . .  20
     5.4.  Transparency  . . . . . . . . . . . . . . . . . . . . . .  21
     5.5.  Staff Structure . . . . . . . . . . . . . . . . . . . . .  21
     5.6.  Funding . . . . . . . . . . . . . . . . . . . . . . . . .  22

Haberman, et al.         Expires April 20, 2018                 [Page 2]
Internet-Draft                  IASA 2.0                    October 2017

       5.6.1.  One-time costs  . . . . . . . . . . . . . . . . . . .  22
       5.6.2.  Sources and Stability . . . . . . . . . . . . . . . .  23
       5.6.3.  Level . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
     6.1.  Comparison to Goals . . . . . . . . . . . . . . . . . . .  26
     6.2.  Financial Impacts . . . . . . . . . . . . . . . . . . . .  28
     6.3.  Other Impacts . . . . . . . . . . . . . . . . . . . . . .  29
   7.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  29
     7.1.  Transition Plan . . . . . . . . . . . . . . . . . . . . .  30
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  30
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  30
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

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 organizations are structured, for
   instance about the division of responsibilities between IETF and The
   Internet Society (ISOC).

   The IETF community has discussed and continues to discuss these
   topics, most recently on the "IASA 2.0" mailing list and BOFs at
   IETFs 98 and 99.  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.  It should also be noted that IETF administrative matters
   have been organized jointly with ISOC, and it is important that ISOC
   continue to be involved in IETF's reorganization.

Haberman, et al.         Expires April 20, 2018                 [Page 3]
Internet-Draft                  IASA 2.0                    October 2017

   The design team seeks feedback particularly on three aspects:

   o  If the set of options outlined in this draft covers the options
      that should be looked at.

   o  If the analysis of the implications of the options is correct.

   o  Which direction the community would like to take the work in
      evolving IASA.

   It should of course be acknowledged that there is no perfect, or even
   great solution.  Changing the IETF organizational structure will not
   fix every problem and may bring new problems of its own.  But it
   seems that the current structure is brittle and the issues around
   lack of staff and authority, clarity, and responsibility are
   sufficiently serious to warrant exploring different options.

   This document defines the goals of the IASA 2.0 effort in terms of an
   abstract administrative structure, called IETFAdminOrg.  Then, three
   possible implementations of IETFAdminOrg are considered in the light
   of how they could be used to address the goals.  In no case does
   IETFAdminOrg have anything to do with defining, changing, or
   operating the IETF's standards process and structure (participants
   (not members), WGs, IESG and so on), which remain as they stand
   today.  In particular, none of the options lead to the IETF becoming
   a formal organisation of any sort.

   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 next two sections (Section 2 and Section 3) describe the
   background and summarize the challenges noted in the community
   discussion.  The two sections after that (Section 4 and Section 5)
   describe the goals and primary options for changes.  The following
   two sections (Section 6 and Section 7) focus on analysis of the
   different options along with conclusions.

2.  Background

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.

Haberman, et al.         Expires April 20, 2018                 [Page 4]
Internet-Draft                  IASA 2.0                    October 2017

   o  IAOC - IETF Administrative Oversight Committee in the current IASA
      system - A largely IETF-selected committee that oversees and
      directs IASA.  Accountable to the IETF community.

   o  IAOC committees - Recognizing the need for specialized attention
      for different branches of work requiring IAOC oversight, the IAOC
      expanded its support by creating committees.  Currently, the
      committees do the heavy lifting on 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.

2.2.  Current IASA Arrangements

   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.

   Today, IASA's activities support a number of functions within the
   IETF system:

   o  Meeting planning

   o  Budget and financial management

Haberman, et al.         Expires April 20, 2018                 [Page 5]
Internet-Draft                  IASA 2.0                    October 2017

   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  The 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)

3.  Problem Statement

   The purpose of this part of the document is to describe a few problem
   areas with enough detail to allow the comparison of potential IASA
   structure updates (among themselves, as well as comparison to the
   status quo) that must be addressed by IETFAdminOrg.  This is
   intentionally illustrative, rather than an exhaustive enumeration of
   all possible and perceived issues with the current structure and
   implementation.  Nevertheless, the examples are concrete and real.
   (For a fuller description of the perceived issues with the current
   IASA arrangements, see [I-D.daigle-iasa-retrospective],
   [I-D.hall-iasa20-workshops-report], [I-D.arkko-ietf-iasa-thoughts],
   and ongoing discussion on the iasa20@ietf.org mailing list.

   In general, the range of IETF administrative tasks have grown
   considerably, our organizational structure is not as clear,
   efficient, or as fully resourced as it should be, the division of
   responsibilities between the IETF and ISOC continues to evolve,
   expectations on transparency have changed, and we face continued

Haberman, et al.         Expires April 20, 2018                 [Page 6]
Internet-Draft                  IASA 2.0                    October 2017

   challenges related to funding IETF activities on a background of
   increasing costs and lack of predictability in our funding streams.

3.1.  Lack of Clarity

   In general, as the IETF has grown and aged, an increasing lack of
   clarity exists in a number of specific areas.  We discuss four areas
   where this lack of clarity is specifically acute: responsibility,
   representation, authority, and oversight.

3.1.1.  Responsibility

   The line between the IETF and ISOC is not organizationally clear-cut,
   which has led to issues around transparency, allocation of staff time
   and priorities, budgeting, and clarity of who is responsible for
   what.

   Often, it can be unclear what part of the IETF or ISOC is responsible
   for a particular function.  Things as simple as ensuring there is a
   lanyard sponsor/coordinator, but also functions as important as
   fundraising and sponsorship development have suffered from a lack of
   clear responsibility.

   IETFAdminOrg must have lines of responsibility that are clear enough
   for non-IETFers to understand where responsibilities lie, and how to
   make changes as necessary over time.

3.1.2.  Representation

   The respective roles of ISOC, the IETF chair, the IAOC, and the
   secretariat in representing the IETF to sponsors and donors and
   communicating with them are not clear.

   Having ISOC represent the IETF to sponsors and donors:

   o  creates confusion about why the IETF does not represent itself,

   o  yields questions about why ISOC does not instead increase its IETF
      support and how donations can be guaranteed to be dedicated to the
      IETF,

   o  can result in those soliciting sponsorships and donations having a
      lack of familiarity with IETF work, and

   o  creates a lack of an integrated and understandable representation
      of the IETF.  People not familiar with the IETF (e.g., potential
      sponsors) must be able to recognize when or how an entity speaks
      for the IETF.

Haberman, et al.         Expires April 20, 2018                 [Page 7]
Internet-Draft                  IASA 2.0                    October 2017

3.1.3.  Authority

   Another significant problem concerns authority, and to what extent
   can IETF make decisions on its own in the current structure compared
   to decisions that require ISOC approval and agreement.

   For example, due to IETF's lack of legal status, contractual
   agreements must be signed by ISOC on behalf of the IETF.  There are
   occasions when a decision that is right for the IETF and desired by
   IETF leadership cannot be executed due to constraints posed by what
   ISOC can and cannot agree to itself.  For example, when IETF sought
   to acquire a recent piece of software for business purposes, ISOC
   would initially not agree to entering into an agreement with the
   software provider.  Ideally, IETF could make decisions free from
   operational and other constraints imposed by its relationship with
   ISOC.

   IETFAdminOrg must have enough and appropriate authority to carry out
   the IETF's administrative requirements and activities in a timely
   fashion, and as the IETF desires (within reason of normal business
   and legal requirements).

3.1.4.  Oversight

   The IAOC is the primary oversight body in the current IASA model, but
   there can be confusion or mismatches in roles.  For example, to the
   extent that ISOC staff besides the IAD become engaged in
   administrative work for the IETF, to whom do they report?  The IAOC,
   the IAD, or their management at ISOC?  Even if the reporting line for
   such staff were more clear, clearly there are power dynamics in this
   role that might pull an ISOC-assigned IETF staffer in directions that
   might not be in the best interests of IETF, consciously or
   unconsciously.

   Furthermore, when we're in a position where we need more staff
   support, it's not obvious what the most appropriate path is to obtain
   that support and how the IAOC's oversight fits into the kind of
   performance review and career planning that ISOC staff would expect.
   We have used a variety of models for acquiring staff support from
   ISOC in the past, ranging from the IAD informally soliciting help
   from others at ISOC, to the IAOC establishing more formal staff
   relationships with ISOC personnel, to ISOC taking responsibility for
   finding staff with an internal-to-ISOC reporting chain.  The role of
   the IAOC with respect to such staff is not defined, nor is the
   mechanism for reflecting the work that they do for the IETF back to
   their ISOC management.

Haberman, et al.         Expires April 20, 2018                 [Page 8]
Internet-Draft                  IASA 2.0                    October 2017

   IETFAdminOrg's oversight functions must be complete and coherent.
   For example, it might either take on full oversight responsibility
   for staff employment functions (including reporting structures and
   career development), or the oversight role must be limited to review
   input submitted to the external sources responsible for employment.

3.2.  Lack of Resources

   IETF faces growing constraints on resources essential for IETF to
   function, notably in volunteers and staff.

3.2.1.  Volunteers

   The IAD is the sole full-time employee for IETF, and the IASA
   arrangement encompasses a series of volunteer committees that help to
   work through issues such as finance, legal, meetings, technology
   management, requests for proposals, and sponsorship.  However, it is
   becoming close to impossible to find qualified volunteers who are
   willing to stand for open slots on the IAOC.  In general, on both the
   IAOC and the committees, the time that committee members have to
   devote to the tasks at hand falls far short of what is required to do
   much of anything beyond keeping the organization afloat.  At a time
   when the IETF is faced with administrative and financial challenges,
   barely having enough volunteers and volunteer time to keep the
   current operation running is not a sustainable model.

   IETFAdminOrg must rely less on volunteers or be better assured of
   engagement of willing and capable volunteers.

3.2.2.  Staff

   IETF faces serious constraints on staff capacity under the current
   IASA model.  The one IAD role and support from contractors have been
   used to assure that capacity needed is for the most part in place.
   However, it seems clear that the IAD role is overly complex and
   taxing for a single human at this point, necessitating measures such
   as providing an administrator for the IAOC to better run that body
   and their meetings.  IETFAdminOrg will require more paid employment
   support dedicated to IETF work.

3.3.  Lack of Transparency

   The IAOC has sometimes been perceived to operate less transparently
   than what is the norm for IETF processes and other IETF leadership
   bodies.  This can be observed, for example, in the failure to
   publicly share agreed information in a timely fashion.  The reasons
   behind this vary but can sometimes be caused by lack of resources to

Haberman, et al.         Expires April 20, 2018                 [Page 9]
Internet-Draft                  IASA 2.0                    October 2017

   review and prepare material for community review, or even fear of
   community reaction to potential administrative decisions.

   Work to increase transparency has made progress, but we must continue
   to address and improve this.  At the same time, a balance must be
   struck to reach the right level of transparency, so that certain
   aspects of contracts, business terms, and negotiations can remain
   confidential, according to legal and business practice norms.  It
   will be important for the community and any future IASA function to
   better define this in order to better meet well-defined, balanced
   community expectations on transparency and information sharing.
   IETFAdminOrg will be required to operated in a transparent fashion
   per community expectations set as part of this IASA 2.0 process.

3.4.  Funding/Operating Model Mismatch and Rising Costs

   Meeting fees are currently an important source of revenue, but the
   emergence of more viable remote participation tools and other factors
   are likely responsible for declining in-person meeting attendance
   going forward.

   While there has been a lot of sponsor support for, e.g., meeting
   hosting, getting support for the full costs of operating the IETF is
   not easy.  The costs are quite large, the value to sponsors is not
   always obvious, the IETF community is sometimes critical or
   unappreciative, and the same sponsors get tapped again and again for
   many related but different opportunities.

   At this point we have one part-time contractor responsible for
   sponsorship fundraising, and volunteers on the finance and
   sponsorship committees with limited cycles to spend on re-envisioning
   the fundraising model for the IETF.  They are all putting in good
   efforts, but ultimately we are unlikely to be able to meet the
   present funding challenges if we do not have people with the cycles
   available to dedicate the necessary time to figuring out how to do
   that.

   In addition, relying heavily on meeting-based revenue is somewhat at
   odds with the fact that much of the IETF's work takes place outside
   of in-person meetings.

   The IETF is increasingly relying on professional services to support
   its activities -- in order to more efficiently operate the IETF's
   activities and better enable IETF participants to contribute to the
   IETF's core technical work rather than administrative and supporting
   activities work -- which is also causing expenses to grow.
   IETFAdminOrg must have appropriate authority and tools to adapt the
   funding model of the IETF to evolving realities.

Haberman, et al.         Expires April 20, 2018                [Page 10]
Internet-Draft                  IASA 2.0                    October 2017

4.  Goals

   The IASA redesign effort needs to address the main issues listed
   above in Section 3.  More specifically, the future organizational
   structure needs to do at least the following:

   o  Protect the IETF's Culture and Technical Work: Ensure that the
      future IASA organizational structure and processes preserve and
      protect the IETF's unique culture of individual contribution,
      clear separation of financial support from technical work, as well
      as the "rough consensus and running code" approach to the
      development of open Internet standards.

   o  Improve the IETF's Technical Environment: Undertake changes to
      better enable technical contributors to focus more on that
      technical work and less on administrative work or support
      activities.  This could for example mean directing more financial
      resources towards the creation of new or improvement of existing
      tools, which might be produced by contractors rather than solely
      by volunteers.  As a result, volunteers could instead focus on
      developing the standards themselves.  Thus, if the core competency
      of IETF attendees and their reason for participating in the IETF
      is to develop standards, then create an environment where they can
      focus exclusively on that activity and delegate to contractors,
      staff, or other resources the responsibility for creating and
      maintaining tools and processes to support this activity.

   o  Clearly Define the IETF-ISOC Relationship: 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).  This also includes consideration of a new funding
      model that takes into account the historical responsibility for
      the IETF that ISOC has had since its inception.

   o  Support a Re-Envisioned Funding Model: Provide the staff support
      and resources needed to adapt the funding model of the IETF to
      changes in the industry, participation, and expenses.  The
      structure should also allow for and be able to support new funding
      streams or changes to the proportion of funds from various
      sources.

   o  Provide Clarity About the IETF-ISOC Financial Arrangements: A
      redesign needs to clear up ambiguities in the financial
      arrangements between IETF and ISOC.  It must also be clear to
      people outside the IETF and ISOC organisations (e.g., sponsors)
      what the arrangements are and what their contributions affect and
      do not affect.

Haberman, et al.         Expires April 20, 2018                [Page 11]
Internet-Draft                  IASA 2.0                    October 2017

   o  Clarify Overall Roles and Responsibilities: Ensure that all staff,
      contractor, and volunteer roles are clearly documented.  This
      necessarily includes documenting how each of these parties may
      interact or interface with one another in order to conduct and
      support the business of the IETF.  This also includes documenting
      key work processes, decision-making processes and authority (such
      as pertaining to meeting venue selection), etc.  A key objective
      is to minimize ambiguity and uncertainty so that it is clear who
      is responsible for what and who has the power to make certain
      decisions.

      There also needs to be a clear definition of what issues belong to
      the IESG vs. the IASA organisation or staff.  In many cases that
      is not clear today.

   o  Define Support Staff Roles and Responsibilities: Clearly define
      the roles of the oversight entities and staff/contractors to match
      the expanded work scope facing the IETF.  Ensure that any changes
      create a structure that can adapt flexibly to future growth and
      other changes (including changes in IETF community expectations,
      such as increased transparency or more rapid decision-making).

   o  Re-Define the Role of the IETF Community in Relation to
      Administrative Activities: As the roles and responsibilities for
      support staff and volunteer roles are clarified more precisely,
      the role of the IETF community in relation to those staff and
      volunteer roles must be better defined.  This should acknowledge
      the limited time and availability of IETF volunteers, better
      defining expectations around oversight of and involvement in
      strategic, operational, and execution tasks within the
      administrative efforts.

      The new design needs to ensure that volunteers are not overloaded
      in such things as low level operational decisions, which can be
      delegated to and handled by staff, and can instead focus on
      strategic changes, critical decisions, and so on.  In particular,
      this should focus on clearly documenting the lines between
      responsibility, representation, authority, and oversight.

   o  Define Improved Transparency Requirements: The general level of
      operational transparency and information-sharing between IETF
      administrative staff and groups to the IETF community must be kept
      at an acceptable level, and improved where it makes sense in the
      future.  This includes ensuring the timeliness of sharing of
      information and decisions, as well as seeking comment on
      prospective decisions.  At the same time, we need to reset
      expectations around delegated authority so that once staff or an
      administrative support organization has been delegated certain

Haberman, et al.         Expires April 20, 2018                [Page 12]
Internet-Draft                  IASA 2.0                    October 2017

      authority it is clear that they are empowered to proceed in a
      particular area, so as to improve organizational efficiency,
      reduce friction, and improve the pace of work and decision-making.
      However, it is clear that enabling a group or staff to act within
      their delegated authority depends upon a clearer definition of
      roles and responsibilities, on improved transparency, on improved
      communications, and on trust (which is built upon all of those
      things over time).

   o  Define a Transition Plan: Determine what new IASA structure we
      need and define a transition plan from the model the IETF has
      today to the new structure.

5.  Reorganization Options

   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.

   The first subsection that follows, Section 5.1, describes each of the
   three re-organization options.

   Section 5.2 discusses the relationship of the IETF administrative
   organization to the IETF.  Clear definition of this relationship is
   particularly important in the reorganization options that involve the
   creation of new entities (subsidiaries or independent organizations)
   to house the administrative functions.  The next section, Section 5.3
   discusses the creation of appropriate oversight to a new entity.
   Section 5.4 discusses the approach to transparency, which is largely
   independent of other aspects of the reorganisation.

   Section 5.5 outlines the needs for IASA staff, and Section 5.6
   discusses what short term and long term funding arrangement changes
   are needed.  Both staffing and funding arrangements are relevant for
   all reorganization options, but are of course affected by the chosen
   option.

   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
   of ISOC funding, rather than the current model of a base funding
   level combined with periodic infusions to cover shortfalls.

   Section 6 highlights the pros and cons and effectiveness of the
   options in comparison to the goals stated earlier.

Haberman, et al.         Expires April 20, 2018                [Page 13]
Internet-Draft                  IASA 2.0                    October 2017

5.1.  Overall Structure

5.1.1.  IASA++

   In the IASA++ option, IETFAdminOrg continues to be implemented as an
   activity within ISOC.  While addressing the requirements above, this
   does mean that 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 to address current challenges.  IETF Trust
      may be separated from IAOC.

   o  Drive IETF community consensus on roles and responsibilities for
      administrative decision-making so it is completely clear what
      people or group has authority to make decisions, and what type of
      consultation, if any, should take place with the community in
      advance so as to eliminate the current lack of clarity and
      friction that exists today.

   The key focus in implementing this option would be sorting out the
   roles and responsibilities of the IAOC and ISOC.  The IETF needs to
   be able to make its own administrative decisions independent of ISOC.
   Having a concrete separation of roles and responsibilities will allow
   each organization to develop their own internal policies that meet
   their different operational needs.  It should be noted that the IETF
   needs to keep abreast of changes to ISOC policies to ensure that the
   working arrangement remains smooth.  Some examples of where the IAOC
   needs autonomy from ISOC policies include:

   o  Contract administration

   o  Spending authority limits

Haberman, et al.         Expires April 20, 2018                [Page 14]
Internet-Draft                  IASA 2.0                    October 2017

   o  Personnel decisions, including compensation

   Some specific changes to make these improvements are discussed in
   Section 5.3 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.5.

   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.  This
   relates directly to the delineation of roles and responsibilities
   necessary for the IAOC to operate independent of ISOC.  Improved
   transparency will allow the IETF community to be more aware of IAOC
   operations and decisions.  Such changes to the IAOC will require
   changes to [RFC4071].

5.1.2.  ISOC Subsidiary

   In this option, IETFAdminOrg is implemented as an ISOC subsidiary,
   which would be created as the new legal home of the IETF
   administrative operation, similar to how the Public Interest Registry
   (PIR) is an organized subsidiary within ISOC.  A subsidiary can have
   its own bank account, by-laws, charter, board, staff, and corporate
   identity.  As a subsidiary of ISOC, the IETF and ISOC can share
   overhead and resources.  The IETF would likely continue to rely
   heavily on contractors for most administrative tasks.

   In the subsidiary model, IETFAdminOrg would carry out the function in
   ISOC's role of administratively supporting the IETF.  ISOC itself
   would no longer undertake specific actions to that end, other than
   supporting IETFAdminOrg.  In this model, ISOC's role would consist
   primarily of committing to stable financial support for IETFAdminOrg.
   Outside administrative matters, in this model ISOC may of course
   still run other IETF-related programs, such as the IETF journal or
   the IETF Fellows program.  If this model is chosen, the detailed
   design would have decide what current activities constitute
   "administration" and are moved to the subsidiary.

   As a subsidiary of ISOC, the IETF could eliminate the IAOC and
   replace it with a board (see Section 5.3).  Administrative decision-
   making authority would rest primarily with the administrative staff,
   with oversight provided by the board (see Section 5.3 and
   Section 5.5.)  Exception cases could be developed where board
   approval would be required to authorize strategic decisions.

Haberman, et al.         Expires April 20, 2018                [Page 15]
Internet-Draft                  IASA 2.0                    October 2017

   As IETFAdminOrg would be a subsidiary of ISOC, ISOC would retain the
   ability to shut it down and re-absorb the functions at some future
   date.  The founding agreements would need to include provisions to
   clarify the steps required in order to consult with the IETF
   community, provide an opportunity for the organization to become
   independent, etc.

   During the transition between the current model and this model, we
   would need to transfer all existing IETF administrative relationships
   from ISOC to IETFAdminOrg:

   o  Transfer existing IETF-related contracts between ISOC and
      contractors to be between the subsidiary and contractors.

   o  Transfer existing ISOC funds earmarked for the IETF to the
      subsidiary's bank account(s), and have future IETF income held in
      that subsidiary's bank account(s).

5.1.3.  Independent Organization

   In this option, a new non-profit organization (IETFAdminorg) is
   created independent from ISOC as the new legal home of the IETF.
   IETFAdminOrg would have its own bank account, by-laws, charter,
   board, staff, and corporate identity.  The administrative staff for
   IETFAdminOrg could be kept lean and would likely rely on contractors
   for the bulk of administrative tasks.  Minimally, the IETFAdminOrg
   staff would be responsible for administration, development/
   fundraising, communications, and personnel management.

   In the independent organization model, IETFAdminOrg's continued
   existence would not depend on the ISOC organization's choices about
   its future.  However, IETFAdminOrg would still depend on the ISOC's
   support, for two reasons:

   o  ISOC's role in supporting the IETF, and

   o  As a practical matter, IETFAdminOrg is not financially viable
      without ISOC's support.

   In order to establish this model, IETFAdminOrg and ISOC would need an
   explicit agreement that outlined expected levels of financial support
   going forward, both in terms of founding endowments and in terms of
   ongoing support.  These agreements might also cover IETFAdminOrg's
   obligations to ISOC, such as the level of reporting from IETFAdminOrg
   to ISOC, and the expected structure of any liaisons.

Haberman, et al.         Expires April 20, 2018                [Page 16]
Internet-Draft                  IASA 2.0                    October 2017

   As in the ISOC Subsidiary model, it would be necessary to transfer
   the existing relationships to IETFAdminOrg.  See the previous section
   for details on this.

5.2.  IETFAdminOrg and the Relationship with IETF

   As noted above, currently the business side of the IETF is basically
   done by ISOC with the only formal entity being the IAD, which is
   itself a position within ISOC.  In both the ISOC Subsidiary and the
   Independent Organization models, we would create a new organization
   ("IETFAdminOrg"), which would encapsulate the administrative
   responsibilities of the IETF organization in a new business entity.
   Its sole mission would be to ensure the IETF (standards) activities
   are appropriately supported and administered.

   "The IETF" would remain pretty much just as we know it today, i.e.,
   the IETF at large would not form any new organization, nor would
   IETFAdminOrg take over any current IETF functions.  The relationship
   between IETF and IETFAdminOrg would be a more formalized version of
   the relationship between IETF and the parts of ISOC which support
   IETF.

   Optionally, under the independent organization option, IETF Trust,
   holding IPR on behalf of the IETF, could be kept separate from the
   operational IETF administration aspects.  This would provide some
   separation between the copyright ownership functions from other
   administrative functions, but both would still have to be funded from
   the same sources.

   o  IETFAdminOrg would have as its mission the administrative support
      of the IETF and would exist for the benefit of the IETF.

   o  The IETF would provide oversight into the governance of
      IETFAdminOrg, including seating part of the board.

   o  IETFAdminOrg would not have a say over the material direction or
      content of the IETF, except insofar as IETF Trust-related legal
      implications and requirements, such as RFC boilerplates.

   Beyond negotiation, administering and managing the contracts
   necessary for the work to support the IETF, IETFAdminOrg would also
   start with sponsorship and communications functions.  Different
   functions and services might be needed as the IETF evolves.  The
   implementation would be determined by the IETFAdminOrg Executive
   Director, but the need and direction has to be provided by the IETF
   (currently, through the IETF Chair, but one hopes the IETF might
   evolve a broader base for making the kind of strategic determination
   needed).

Haberman, et al.         Expires April 20, 2018                [Page 17]
Internet-Draft                  IASA 2.0                    October 2017

   IETFAdminOrg would be staffed.  It would be signatory to all IETF-
   supporting contracts.  It would collect financial support for the
   IETF, and administer the financial resources.  Its annual budgets
   would be reviewed and approved by its own Board of Trustees, which
   would be populated pretty much as any Board of Trustees (with the
   additional requirements in the notes below).  In all regards, it
   would be a self-contained organization, evolving to meet its mission
   based on its best governance choices to evolve, staff and execute.

5.3.  Oversight for IETFAdminOrg

   While IASA++ could continue to have an oversight structure populated
   by members of the IETF community, either the Subsidiary or
   Independent models involve the creation of an IETFAdminOrg which
   would need to have its governance structure defined.  This structure
   needs to include the involvement of members with significant
   nonprofit governance experience, while also ensuring accountability
   to and involvement from the IETF Community.

   In order to achieve these objectives, the design team proposes a
   model similar to other nonprofits, in which IETFAdminOrg would be
   governed by a Board of Trustees.  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.5).

   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 general structure is that the board is responsible for setting
   general policies about how the staff functions and making decisions
   for the organization as a whole.  For instance, the board would be

Haberman, et al.         Expires April 20, 2018                [Page 18]
Internet-Draft                  IASA 2.0                    October 2017

   expected to sign off on the meeting locations and schedule, based on
   recommendations from the staff.  For some activities, the board would
   organize subcommittees which would do work directly.  Typical
   examples would be auditing, hiring, and firing.  The board might, for
   instance, decide meetings were so important that it needed more
   direct involvement.  The board is accountable to the community and
   would be expected to regularly consult with the advisory council (see
   below) and consult with the community directly on especially
   important matters.

   By contrast, the staff is responsible for making day-to-day
   operational decisions subject to the board's general policies.
   Examples here would be vendor selection for smaller contracts, and
   hiring of lower-level staff.  These decisions are of course subject
   to board oversight and matters over a given size (e.g., money limit)
   would need board approval though would likely be recommended by the
   staff.  In no case would the staff or board have any input on
   standards activities.

   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
   money or provide advice about fundraising (all of which are typical
   for a non-profit board).

5.3.1.  Board Selection

   Experience with selection for the IAOC and the ISOC Board shows the
   difficulty of using the nomcom process to select a board with the
   kind of business skills necessary to supervise an operation like
   IETFAdminOrg.  These skills are not common -- though also not non-
   existent -- within the IETF community, which makes it hard to find
   candidates as well as reducing the chance that nomcom members will
   have the personal contacts to identify external candidates with the
   appropriate skills.  For this reason, the design team does not
   believe that direct nomcom selection of the whole board will be
   successful.  In the ISOC Subsidiary model, ISOC might also nominate
   some board members.  Below we present two alternative mechanisms for
   selecting the remaining board members, though there are others that
   would perhaps be successful.  Regardless of the nomination mechanism,
   the entire board should be subject to confirmation by the IETF
   leadership.

Haberman, et al.         Expires April 20, 2018                [Page 19]
Internet-Draft                  IASA 2.0                    October 2017

5.3.1.1.  Self-Perpetuating Board

   One common way to select board members is to have the existing board
   select new members.  The advantage of this structure is that the
   existing members have the skills and connections to identify other
   people with similar skills.  For this reason, this is a common
   structure for nonprofits.  The design team recognizes that there are
   concerns about the board drifting away from the IETF Community
   interest, but believes these concerns would be adequately addressed
   by having some of the board directly selected by nomcom and all
   members subject to IETF confirmation.  The details of how the initial
   board is to be constituted would need to be determined, but one
   possibility would be to draw from the existing IAOC and IETF-selected
   ISOC BOT members, with the board replacing itself within a short
   period.

5.3.1.2.  Nomcom-Selected Nomcom

   An alternative design would be to have the IETF nomcom select a
   separate nominating committee which would then select the board
   members.  This suffers from some of the problems with direct nomcom
   selection, but allows us to expand the scope of the pool to anyone at
   the IETF with business skills or business contacts, not just those
   who have time to be a board member.  As before, the output of this
   process would need to be confirmed in the IETF.

5.3.2.  Advisory Council

   The board and staff are also supported by an Advisory Council (AC).
   The AC provides an interface to the community on matters that require
   assessing community opinion.  For instance, the current polling of
   community feedback relating to potential future meeting locations
   could be one such matter.  An advisory council canvassing and pulling
   for this information is expected to be a better approach than either
   free-form mailing list discussion, or the relatively opaque process
   that is currently used.

5.3.3.  Board Changes in IASA++

   IASA++ continues to have an oversight structure populated by members
   of the IETF community, but as discussed previously, the current IAOC
   model has a number of weaknesses.  Detailed design for this
   alternative would have to specify how the board changes, but as a
   starting point, it would be desirable to increase the number of board
   members (particularly those without other roles) and re-specify the
   role of the board vs. staff and other committees.  With increased
   number of staff, implementation would be more in the hands of the
   staff than today, and the role of the board would be more on actual

Haberman, et al.         Expires April 20, 2018                [Page 20]
Internet-Draft                  IASA 2.0                    October 2017

   oversight, budget and hiring decisions than the detailed daily
   operations.

5.4.  Transparency

   Regardless of the chosen reorganization model, transparency deserves
   attention.  As discussed in Section 4, this includes improving the
   timeliness of sharing of information and decisions, seeking comment
   on forthcoming decisions, and a a "reset" of expectations around
   delegated authority.

   In addition, there needs to be an agreement between the IETF
   community and the administrative entity about the where to draw the
   line between community's need for information, and the need to keep
   some business (or personnel) data confidential.

5.5.  Staff Structure

   The design team believes that staff resources need to increase and/or
   be reorganized in order to move from one director to a few more
   specialized roles (see growth in Section 3).  In addition, the team
   believes that future organization for IASA may benefit from
   organizing all resources under the more clear and direct control of
   the IETF (see division of responsibilities in Section 3 and roles in
   Section 4).

   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

Haberman, et al.         Expires April 20, 2018                [Page 21]
Internet-Draft                  IASA 2.0                    October 2017

      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.

   It should be noted that we expect to retain the secretariat on
   contract for more or less the same responsibilities that they
   presently have.

5.6.  Funding

   This section discusses the overall changes to IETF funding sources,
   the level of funding, and how the level of funding is agreed with
   ISOC.  And how the IETF can further develop its funding strategies
   over time.

   None of the administrative arrangements proposed in this document
   suggest that the fundamental funding arrangements change as a part of
   reorganization.  ISOC will continue to support the IETF, though
   perhaps with means that provide better budgetary stability.  There
   are also factors that affect the level of funding.  Also, a better
   administrative organization will be more capable of adjusting its
   strategies in the future in all areas, including funding.  Any
   significant future changes require a capability of the IASA to focus
   on such strategic initiatives, which IASA 2.0 will help enable.

   It is important to ensure that IETF funding is arranged in a manner
   that is satisfactory to the IETF and ISOC communities.  Any changes
   to arrangements are something that should be mutually agreed with
   both organizations.  Further comments and observations are welcome.

5.6.1.  One-time costs

   There are one time costs associated with an administrative change,
   regardless of which of the options discussed in this document are
   chosen.  All the models in the draft will have associated costs -
   e.g., to hire additional staff, cover legal fees, etc.

   Transition expenses should be considered separately from ongoing
   expenses/funding needs.  It should be noted that ISOC has promised to
   cover those costs [Camarillo].

Haberman, et al.         Expires April 20, 2018                [Page 22]
Internet-Draft                  IASA 2.0                    October 2017

5.6.2.  Sources and Stability

   The key sources of IETF funding are unlikely to radically change in
   the short or medium term.  This document suggests that ISOC continues
   as one of our primary funding sources, as it has been.  Other primary
   sources of funding for an organization like the IETF are well known,
   and we are already tapping into all of the most common ones:
   corporations, individuals, and funds derived from the registration of
   domain names.  It is possible that we could develop additional
   funding sources in the future (e.g., charitable foundations), but
   those will require strategic planning and staffing, for which we need
   to get IASA 2.0 in place first.

   It's worth considering short-term (3-5 years) and long-term (5-10+
   years) plans differently.  In the short term, we can continue to rely
   on our existing funding sources regardless of which organizational
   model we end up with for IASA 2.0, including the independent
   organization model.  The role of ISOC as providing the funding to the
   IETF and agreeing to help us if we get to trouble should stay under
   all of the options, until or if a future funding model change changes
   that.

   While ISOC continues to support IETF financially as they have
   previously, the different reorganization options affect the legal,
   contractual, and accounting related details.  While continuing as-is
   is possible, adopting a a more predictable allocation of funding is
   desirable (see Section 5.6.3), and in the subsidiary and independent
   options formal contracts about the funding are also necessary.  The
   exact details of those contracts and contracting parties are for
   further study, but they do not need to change the fundamental
   arrangement that is in place today.

   More long-term, developing a sustainable funding plan for the IETF
   will be a key project during the early months and years post-IASA
   2.0.  Ultimately a healthier funding model will require raising more
   funds from the organizations that benefit from IETF standards and
   whose employees participate in the IETF, and may result in less
   reliance on ISOC funds.  Such a model might incorporate meeting-based
   sponsorships as we have traditionally had, other kinds of
   sponsorships, a fully funded endowment, a different registration fee
   structure, or other funding vehicles.  But we are not in a position
   at present to develop such a model and carry out the fundraising.  We
   do not have sufficient staff, skills, or resources to do it.  We need
   to complete IASA 2.0 in order to be in a position to do it.  We are
   fortunate that we can rely on additional funds from ISOC in the short
   term in order to bootstrap that process.  As the old saying goes, you
   have to spend money to make money.

Haberman, et al.         Expires April 20, 2018                [Page 23]
Internet-Draft                  IASA 2.0                    October 2017

   This isn't to say that the IETF not already considering how to make
   the funding model more sustainable.  The IAOC has new sponsorship
   staff this year, the the IAOC sponsorship committee was recently
   chartered, and it has been discussing new ideas for raising
   sponsorship funds.  Changes to the present model will be adopted as
   those ideas mature.  IETF can cut some costs.  But we can not expect
   volunteers and folks working part-time on current fundraising targets
   to also take on the additional substantial project of revamping the
   entire funding model and having the additional funds show up on short
   order.

5.6.3.  Level

   Outside the discussion of sources, the level of funding has also been
   an issue.  The IETF is well supported by ISOC who have ultimately
   also been the backstop when income has fallen below expectations.
   The IETF is also supported by a number of other sponsors, whose
   significant contributions provide a big part of the income.

   However, at the same time there is an overall rising cost level that
   affects the services IETF uses, there is community desire for
   supporting important new services, technology that enables more
   participants to choose to participate remotely, and industry
   pressures on optimizing their costs.  As the organization matures,
   and as more of the services that IETF provides come from professional
   sources, it becomes more difficult to rely on significant fraction of
   any individual volunteer time.  This is visible, for instance, in our
   tools efforts, which have become more commercially driven in the last
   years.

   It is fair to say that IETF continues to be underfunded in the face
   of these trends.  In addition, IETF budgets have in recent years been
   relatively optimistic.  IETF is fortunate that ISOC has been there to
   provide a backstop against surprises and the cost trends, but
   ideally, budgets should be realistic and exceptions more exceptional
   than they are today.

   To correct this, four things are needed:

   1.  Improve the accounting of IETF-related costs

       The process that has gone on for several years to better reflect
       actual IETF-related costs in the IETF (and ISOC) budget will
       continue, and depending on the chosen model, reach a much more
       concrete and clear structure.  This will not as such, however,
       change the actual amount of expenditure or income.

Haberman, et al.         Expires April 20, 2018                [Page 24]
Internet-Draft                  IASA 2.0                    October 2017

       Note that the IETF already accounts for the expenses related to
       key IETF support staff (e.g., IAD, communications, etc).

   2.  Ensure realism in the budget.

       For a budget to be realistic, it must be based on correctly
       anticipated income and expenses.  Since crystal balls are in
       short supply, flexibility and responsiveness are required in the
       process, as industry changes can impact both available
       contributions and number of participants at meetings (i.e.,
       registration fee income).

       Further decisions may be necessary to be more conservative in
       future budgets, including appropriate decisions about what
       services are essential for the IETF community and which are not.

       Documenting and discussing the IETF financial model (expectations
       of sources of income, levels of support, as well as requirements
       for expenses and levels of service) has been a goal for 2018 and
       will continue to be a priority going forward.

   3.  ISOC as a funder and backstop.

       ISOC continues to be the major IETF funding source, as well as
       the backstop against emergencies.  But a different arrangement
       regarding these two roles would make the situation better
       manageable.

       Dedicated, realistically sufficient funds allocated to the IETF
       would allow the normal operations to be run based on that, and
       would leave only true emergencies such as cancellation of
       meetings due to local emergencies for the backstop.

   4.  Appropriate funding level.

       The IETF operations and funding level obviously need to match.
       The specific level is, however, not related to the IASA 2.0
       related organizational changes.  Those organizational changes
       only make it hopefully easier to manage both the IETF operations
       and the funding.

6.  Analysis

   This section provides a basic analysis of the effects of the
   different options.

Haberman, et al.         Expires April 20, 2018                [Page 25]
Internet-Draft                  IASA 2.0                    October 2017

6.1.  Comparison to Goals

   In the following, we analyze how the different options compare with
   respect to goals set in Section 4:

   o  Protect the IETF's Culture and Technical Work:

      The changes under the IASA++ option are small enough that they
      clearly cannot have any undue effect on culture or actual IETF
      work.

      The ISOC subsidiary and independent organization models are bigger
      changes, but, still contained within the administrative support
      part.  To be exact, the IETF will not become an organization even
      if the administrative support for it may.  While one may have an
      opinion that administrative functions may grow or acquire more
      staff over time (and there is always some danger of that), keeping
      the IETF out of the organization for administration does provide a
      level of separation.  This separation ensures that participant,
      working group, IESG, IETF Chair, and other similar roles should
      continue to operate as they are operating now.

      Sometimes even administrative decisions can impact the nature or
      culture of the IETF, such as when improvements in remote
      attendance support are adopted.  A clear interface between the
      community and the IETFAdminOrg is helpful in specifying what role
      the community and other parts of the system play.  The nomcom-
      appointed board members and the Advisory Council have clearer
      role, and have a more community-focused role in the new
      arrangements to ensure that the community has a strong voice.

   o  Improve the IETF's Technical Environment:

      All organization options target improvements in this area.  The
      options may differ in how much freedom or organization agility
      they provide.  Clearly, in the independent organization option the
      IETF has most of these.

   o  Clearly Define the IETF-ISOC Relationship:

      Again, all options are forced to define this relationship in a
      clearer way than it is defined today.

      However, the subsidiary and independent organization models have a
      better ability to reach a clear definition.  A clear definition is
      not merely a matter of specification, it is also affected by
      practical and even legal constraints and organizations' goals.
      For instance, for obvious privacy and legal reasons, IETF may not

Haberman, et al.         Expires April 20, 2018                [Page 26]
Internet-Draft                  IASA 2.0                    October 2017

      have quite as much control and information about ISOC employees as
      it would on its own administrative unit's employees.

   o  Support a Re-Envisioned Funding Model:

      The changes to the funding model are on purpose modest for the
      reorganization, with the intent provide more ability and freedom
      for the IETF to adjust its model later.  However, the subsidiary
      and independent organization models also clearly provide more
      freedom for further evolution.

      In IASA++, leaving the responsibility for sponsorship fundraising
      up to ISOC, as BCP 101 does, means we will always be constrained
      by however ISOC is willing to staff and support IETF-specific
      fundraising.  While ISOC has and wants to support the IETF, it is
      often the case that knowledge of what strategies work and the
      direct contacts to sponsoring organisations are on the IETF side.

      In the independent organization model, the ability for the IETF to
      rely on ISOC in the event of budget shortfalls may be more
      limited.  This is a double-edged sword, however, as the current
      arrangements complicate planning and perceptions by the sponsors.

   o  Provide Clarity About the IETF-ISOC Financial Arrangements:

      All reorganization options aim to provide clarity.  But the
      subsidiary and independent organisation options provide an
      opportunity to define exactly what kind of agreements exist
      between the IETF and the new organization, in the form of a formal
      agreement between organizations or parts thereof.  This is
      important in conveying the role of different parties to potential
      sponsors, for instance.

      In the IASA++ option, there is limited improvement on clarity of
      the financial arrangements.

   o  Clarify Overall Roles and Responsibilities:

      The reorganization is an opportunity to rethink what staff roles
      are needed, staff levels, whether to organize a function as a
      staff function or as contracted service to a vendor.  All options
      are likely to provide clarified roles and responsibilities.

      However, in IASA++, some of lack of clarity may remain, as lack of
      clarity inherent in two organizations controlling resources may
      remain.  In general the subsidiary and independent organisation
      models ensure better tha the IETF community and the IETF

Haberman, et al.         Expires April 20, 2018                [Page 27]
Internet-Draft                  IASA 2.0                    October 2017

      administrative functions have authority to perform exactly the
      kind of adminstration they want.

      The independent organization model eliminates all ambiquity about
      the IETF having authority independent from ISOC over staff, funds,
      and decisions.

   o  Define Support Staff Roles and Responsibilities:

      As above.

   o  Re-Define the Role of the IETF Community in Relation to
      Administrative Activities:

      Again, this is necessary in all the reorganization options.  It is
      particularly important for the discussion of transparency.

   o  Improve Transparency:

      An improvement can be provided in any chosen option, but it will
      require (a) adopting the by default open model, (b) agreeing on a
      list of exceptions, as well as obviously clear definition of
      roles.

      These changes are easier on the subsidiary and independent
      organisation models, however, because we can start with more of a
      fresh slate.  The IAOC and committees have been operating with
      their current structure, and, in some cases, current volunteers/
      personnel, for a long time.  It will be harder for them to change
      than to make staff-driven changes in an org with new staff.

   o  Define a Transition Plan:

      This will also be necessary in all options.

      The IASA++ option is the easiest one to get going, and minimal
      transition cost, although of course it may not provide as much
      value in return, creating risk that the challenges present in
      current IASA structures will not be sufficiently solved.

6.2.  Financial Impacts

   There are several different classes of financially-relevant changes.
   Funding-related changes have been covered in Section 5.6, as have
   transition costs.

Haberman, et al.         Expires April 20, 2018                [Page 28]
Internet-Draft                  IASA 2.0                    October 2017

   All the suggested models imply some actual increases in expenditure
   and financial resources on an ongoing basis.  The following applies
   generally to all chosen models:

   The increases are due to, for instance, shifting more work to staff
   and contractors.  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 and a long-term
   IETF Legal Counsel is also changing.

   It is also expected that the role of the Legal Counsel will also
   increase, e.g., in terms of reviewing contracts.

   For both the subsidiary model or the independent organization model,
   there can be additional and potentially significant costs.  For
   example, having a full-time communications director on staff means
   paying the person's full salary, health insurance, worker's
   compensation, sick pay, etc.  In general, while under the ISOC model
   the IETF may have been able to take a particular percentage of a
   person's predicted base costs, under a more independent arrangements
   the IETF is an employer and liable for all associated costs at 100%.
   Similarly, some current contracted or volunteer roles, if turned to
   staff positions, can increase costs.

   Audits, payroll, HR, office space, equipment - these are things we do
   not currently account for in the IETF budget, that we wouldn't have
   to pay for as a subsidiary (assuming we can share overhead with ISOC,
   since that's part of the point), but that we would have to pay for as
   an independent org.

6.3.  Other Impacts

   Depending on the chosen option, volunteers are needed for either
   different roles than today (the board) or for both different roles
   and more volunteers (the board and the advisory council).

   It is for further study whether current IETF leadership (e.g., IAB
   Chair) should continue to be part of these boards or councils.

7.  Conclusions

   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

Haberman, et al.         Expires April 20, 2018                [Page 29]
Internet-Draft                  IASA 2.0                    October 2017

   community, particularly regarding any potential missed options or the
   implications of options being considered here.

7.1.  Transition Plan

   Following feedback we receive before and during the IETF-100 meeting,
   we will develop a detailed transition plan and include that here.

   The transition plan should address items such as the following (and
   we seek suggestions on areas we may have missed):

   o  Volunteer organization transition plan and timeframe

   o  Legal, financial, and administrative actions

   o  Staffing actions (e.g. job descriptions)

   o  Documentation actions (e.g. roles and responsibilities, updates to
      RFCs)

   o  Near-term goals for the new board (e.g. develop and release a
      budget within 90 days of formation)

   o  Other

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, Jonne Soininen, Michael
   Richardson, Olaf Kolkman, Kathy Brown, and Melinda Shore for
   interesting discussions in this problem space.

9.  Informative References

   [Camarillo]
              Camarillo, G., "ISOC to cover potential re-structuring
              costs related to IASA 2.0", September 2017
              (https://www.ietf.org/mail-archive/web/ietf/current/
              msg104265.html).

   [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.

Haberman, et al.         Expires April 20, 2018                [Page 30]
Internet-Draft                  IASA 2.0                    October 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,
              <https://www.rfc-editor.org/info/rfc4071>.

Authors' Addresses

   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

Haberman, et al.         Expires April 20, 2018                [Page 31]
Internet-Draft                  IASA 2.0                    October 2017

   Eric Rescorla
   RTFM, Inc.

   Email: ekr@rtfm.com

Haberman, et al.         Expires April 20, 2018                [Page 32]