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