Request for Comments: 4089 IAB and IESG
Category: Informational May 2005
IAB and IESG Recommendation for IETF Administrative Restructuring
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a joint recommendation of the Internet
Architecture Board and the Internet Engineering Steering Group for
administrative restructuring of the Internet Engineering Task Force.
The IETF Chair declared that the IETF had consensus to follow this
recommendation on November 11, 2004. Further work has been done to
revise and refine the structures proposed. The recommendation is
being published for the record.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Process That Produced This Recommendation . . . . . . . . 2
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Arguments That Had Particular Weight in the Discussions . . . 4
4.1. Focusing on Scenarios C and O . . . . . . . . . . . . . 4
4.2. Why We Chose Scenario O . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix: Scenario C . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix: Scenario O . . . . . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction
The Internet Engineering Task Force (IETF) has a need for
administrative support functions. The debate and dialogue of 2003
and 2004 has led to the belief that the way these functions are
provided needs to be changed.
This document gives the recommendation of the Internet Engineering
Steering Group (IESG) and Internet Architecture Board (IAB) on what
the next step in that change process should be, and some of the
background and reasoning behind this recommendation.
2. The Process That Produced This Recommendation
During several months in 2004, the Internet Architecture Board (IAB)
and the Internet Engineering Steering Group (IESG) worked together to
consider several different options for restructuring the Internet
Engineering Task Force (IETF) administrative functions. The goal of
this effort was to produce a recommendation for consideration by and
approval of the IETF community. The rationale for this effort is
described in RFC 3716 [1]. Much background work and several detailed
proposals for community consideration are provided in a report
prepared by a consultant titled "IETF Administrative Support
Functions" [2].
The consultant’s report included several possible scenarios for
administrative restructuring (named scenario A, B, C, and D). As
discussion took place within the IETF community, it became clear that
some of the scenarios had features that appeared more promising than
others, but that we did not have enough of a concrete proposal to
crystallize opinions into a consensus for action. Members of the
IESG and IAB took on the task of working out more complete
descriptions of two of the scenarios. They were:
o Scenario C (section 4.4 of the report) describes when
"administrative support functions for the IETF are legally housed
in a focused, incorporated institution" with close ties to the
Internet Society (ISOC). Scenario C is included here as the first
appendix.
o A new scenario, called Scenario O, that includes features derived
from scenarios A and B (sections 4.2 and 4.3 of the report),
focusing on the formalization of the ISOC/IETF relationship while
housing administrative support functions for the IETF within ISOC.
Scenario O is included here as the second appendix.
These descriptions were not intended to close off discussion of other
scenarios, but to focus discussion on what appeared to be two
independent loci of support.
Both scenarios were presented to the IETF community as mail notes
(Scenario C [3], Scenario O [4]) sent to the IETF discussion list.
IETF participants’ opinions, while quite divided on the subject,
seemed to indicate a preference for Scenario O as a "lower risk
operation", but some participants indicated that they felt unable to
give an informed opinion, disagreed with the process, or declared the
subject out of their field of competence. This discussion garnered
perhaps 40 participants who contributed on the list.
The IETF Chair then requested an informal poll of IETF opinion.
People interested in participating in the poll were directed to a web
site where their opinions could be noted, including whether they
wanted to state an opinion or not. The raw poll results [5] were
also shared with the community via a mail note to the IETF discussion
list.
The poll sparked additional discussion on the list, and not all
participants agreed with the methodology of the poll. Taken with the
discussion, though, the IESG and IAB members believe that there is a
stronger indication of community support for change based on Scenario
O than on other scenarios. The IESG and IAB members believe that
Scenario O can be a workable basis for further progress, even if it
is not the first preference for all members. Taken together, this
has led to the IESG/IAB recommendation given below.
3. Recommendation
The collective recommendation of the IAB and IESG was presented to
the IETF community of Friday 8 October 2004 via a mail note [6] sent
to the IETF mailing list:
"IETF folks,
The IESG and IAB have been considering the input from the IETF
community on the next steps going forward in IETF administrative
restructuring.
It appears clear to us that the community mostly sees scenario O
as the lower-risk scenario, and the one that gives us the greatest
probability of successfully doing what we have to do.
Based on this, the IESG and the IAB make the following
recommendation:
We recommend that the IETF pursue scenario O, with the
understanding that further work is needed to define the
roles and responsibilities of the IETF, the IAOC and the
ISOC BoT under this scenario.
The "BCP section" of the scenario O note will be pulled out and
published as an internet-draft. We’d like to put this description
to the IETF community for a formal Last Call before the November
IETF meeting, if possible.
Also, as noted in the recommendation above, there are a number of
points where we need to work out in more detail how the system is
going to work - who takes decisions, who accepts those decisions,
and what conflict resolution mechanisms may be necessary, and so
on. The IAB and IESG are drafting a document that will describe
the finer level of detail as to the respective roles and
responsibilities of each of the players. We will publish this as
an internet-draft shortly.
We will continue to work intensely on this!"
4. Arguments That Had Particular Weight in the Discussions
4.1. Focusing on Scenarios C and O
The IETF list was presented with four scenarios in the consultant
report [2], which should be read for the full context. In slogan
form, they might be rendered as
o A: Leave it to ISOC.
o B: Increase IETF control of ISOC, and use ISOC to do it.
o C: Isolate the functions, let ISOC gather money, share control.
o D: Cut the IETF off from ISOC and do it ourselves.
On the list, there seemed to be very few who were comfortable with
the idea that "we" (for some version of "we") could "do it ourselves"
as envisioned in Scenario D. There was also considerable worry about
the risk associated with Scenario C, especially with regard to
financial stability, and that the perceived danger of problems would
cause sponsors to withhold funding, thus precipitating problems even
if there was no other reason for them. Scenario C spoke strongly to
those who worried about a possible conflict of interest between ISOC
and the IETF community at some future date - "we don’t know what ISOC
will turn into" was the capsule summary.
Scenario A worried people because it did not seem to acknowledge the
IETF community’s ability to determine if its needs were being met and
what could be done if they were not. The phrase "replace existing
problematic structures by ISOC" was perhaps a capsule summary.
However, Scenario B’s list of possible mechanisms for involving IETF
community directly in ISOC’s operations was not viewed as acceptable
or in balance with the full scope of ISOC’s activities. Members of
the IAB & IESG developed Scenario O, a solution scenario that put the
administrative activity within ISOC, but aimed to provide a means for
the IETF to provide oversight and control of that specific activity
within ISOC. Its name is derived from the classification of blood
types -- "neither A nor B".
Thus, the decision to focus on C and O as "alternatives to be worked
out in detail" was made.
4.2. Why We Chose Scenario O
Capsule summary: It might be possible to make either scenario work.
But Scenario O could be made to work faster, and less painfully.
The ISOC Board of Trustees was significantly worried that scenario C
would make fundraising more difficult, which would necessarily affect
its ability to support the IETF.
The question of tax status for the new corporation was debated at
some length on the list; legal counsel indicated that a corporation
that did the IETF work (Scenario D) would probably be easy to get
classified as 501(c)(3) (a type of non-profit corporation defined by
U.S. Internal Revenue Service (IRS) regulations). However, a
corporation that did only administrative support functions, as
scenario C envisioned, would have more problems. In all cases, the
process of determining this would take months, and could be dragged
out longer if we were unlucky.
The community feedback, in addition to contributing many well-formed
and well-argued points to the discussion, gave a powerful indication
on where it was possible to get IETF consensus:
o It seemed possible to garner IETF consensus around Scenario O; the
people arguing for Scenario C indicated that they "could live
with" the alternative.
o It seemed much more difficult to garner IETF consensus around
Scenario C; many people arguing against it indicated that they
were firmly convinced that it was the wrong choice for the IETF.
The IETF is based on the idea that the consensus process, when it
works, comes up with reasonable decisions. We concluded that the
apparent drift of community consensus was a reasonable basis for the
IESG/IAB recommendations.
5. IANA Considerations
This document does not require any IANA actions. However, the IETF
administrative restructuring process is likely to affect how the
relationship between the IETF and the IANA is managed.
6. Security Considerations
This document does not introduce any security considerations for the
operation of the Internet. However, administrative restructuring
introduces several areas of risk to the future of the IETF. The
risks and their mitigation strategies are described in the scenarios
as appended to this document.
7. Acknowledgements
This document is a collective work of the members of the IAB and the
IESG. Members of the IAB at the time of this writing include Bernard
Aboba, Harald Alvestrand, Rob Austein, Leslie Daigle, Patrik
Faltstrom, Sally Floyd, Mark Handley, Bob Hinden, Geoff Huston, Jun-
ichiro Itojun Hagano, Eric Rescorla, Pete Resnick, and Jonathan
Rosenberg. Members of the IESG at the time of this writing include
Harald Alvestrand, Steve Bellovin, Bill Fenner, Ted Hardie, Scott
Hollenbeck, Russ Housley, David Kessens, Allison Mankin, Thomas
Narten, Jon Peterson, Margaret Wasserman, Bert Wijnen, and Alex
Zinin.
The administrative restructuring effort cannot succeed without
community support and participation. Thus, the IAB and IESG wish to
acknowledge the collective contributions of members of the IETF
community who have participated in the discussion of this topic.
Appendix: Scenario C
This Appendix reproduces the contents of an Internet-Draft defining
Scenario C, as it was posted on 20 September 2004. A table of
contents has been removed from this copy and the text has been
reformatted to fit within IETF publication guidelines. Each line is
prefixed with "C>>".
C>> B. Wijnen
C>> LucentTechnologies
C>> H. Alvestrand
C>> Cisco Systems
C>> P. Resnick
C>> QUALCOMM Incorporated
C>> September 20, 2004
C>>
C>> AdminRest Scenario C: An IETF Administrative Support Foundation as
C>> an Independent Nonprofit Corporation
C>>
C>> Abstract
C>>
C>> This document defines a proposal for an IETF Administrative
C>> Support Foundation (IASF) as an independent not-for-profit
C>> corporation as a means for providing focused support for IETF
C>> community activities. It proposes the creation of an IASF Board
C>> of Trustees (BoT) that is mainly selected by and accountable to
C>> the IETF community and would provide oversight for the IETF
C>> Administrative Support Foundation. The IASF will also establish
C>> and maintain a strong relationship with the Internet Society
C>> (ISOC) and the current relationships between IETF and ISOC will
C>> basically be left unchanged.
C>>
C>> In order to allow the community to properly evaluate this
C>> scenario, some draft Articles of Incorporation and draft Bylaws
C>> for the IASF are included. Some draft BCP wording for the IASF,
C>> IETF and ISOC relationships is also included.
C>>
C>> 1. Overview of Scenario C
C>>
C>> This document follows from two previous documents. [RFC3716]
C>> defined the overall parameters and criteria for an administrative
C>> restructuring. [I-D.malamud-consultant-report] provided an
C>> analysis of the implications of several of the suggested
C>> strategies. This document picks one strategy and develops it
C>> further.
C>>
C>> In order to provide the most focused and effective administrative
C>> support to the IETF community, this updated scenario C proposes a
C>> new and well-defined legal entity to support the IETF
C>> administrative functions. The name of that new entity is "The
C>> IETF Administrative Support Foundation" (IASF).
C>>
C>> First, it is important to understand that the IETF has been
C>> organized as an Activity of the Internet Society (ISOC) and as
C>> such represents the "Standards and Protocols" pillar of ISOC.
C>> Under this proposal, the IETF would continue to be an integral
C>> part of the Standards and Protocols pillar of ISOC. ISOC
C>> currently provides these important functions to the IETF:
C>>
C>> 1. Standards Process Functions. ISOC plays a fundamental role in
C>> the IETF Standards Process, including appointment of the
C>> Nominating Committee (Nomcom) chair, confirmation of IAB
C>> members, confirmation of documents that describe the
C>> standards processes, and acting as the last resort in the
C>> appeals process. These Standards Process Functions are
C>> defined in [RFC2026], [RFC2028], [RFC2031], and [RFC3677].
C>>
C>> 2. IETF Fund Raising Functions. ISOC provides the fund raising
C>> function as one source for financial support the IETF.
C>>
C>> 3. Administration Functions. ISOC provides administrative and
C>> financial functions, managing the contract with the RFC
C>> Editor, providing insurance for selected IETF participants,
C>> and administering a discretionary fund for use by the IAB and
C>> the IETF Chairs.
C>>
C>> The administrative restructuring of the IETF proposed in this
C>> document keeps that basic relationship between IETF and ISOC.
C>> Specifically, the recommendation does not propose any changes to
C>> the "Standards Process Functions" or to the "IETF Fund Raising
C>> Functions".
C>>
C>> Under the "Administration Functions", ISOC both funds and
C>> administers some (as stated above) parts of the IETF
C>> Administrative Support Functions. Some of the funds (like for
C>> the RFC-Editor) go directly to the contractor who executes the
C>> administrative function. The streamlining of the administrative
C>> support for the IETF ultimately intends to put the complete
C>> Administrative Support Functions under the newly recommended
C>> IASF. This means that we recommend that ultimately, ISOC funds
C>> for the IETF will be transferred to the IASF, which will then
C>> administer all the contracts and payments according to an
C>> approved yearly budget. The details of that process will be
C>> documented in a Memorandum of Understanding (MoU) between ISOC,
C>> IETF and IASF.
C>>
C>> This updated AdminRest Scenario C aims to provide the following:
C>>
C>> o A continued close relationship between IETF and ISOC.
C>>
C>> o A well defined legal entity within which the IETF can define
C>> the administrative activity in terms of IETF community needs.
C>>
C>> o A Board of Trustees with operational oversight that is
C>> accountable to the IETF community.
C>>
C>> o Continued separation between the IETF standards activity and
C>> any fund-raising for standards work.
C>>
C>> o A close and well defined relationship between IASF and ISOC,
C>> documented in a BCP (or MoU).
C>>
C>> o Appropriate ISOC oversight of its standards activities funds
C>> via a yearly budget approval and open reporting of funds
C>> spent.
C>>
C>> In scenario C, it is intended that the IETF Administrative
C>> Support Foundation will be a tax-exempt not-for-profit
C>> corporation as defined by Articles of Incorporation and a set of
C>> Bylaws. These will describe the scope and purpose of the IASF
C>> and they also define the structure and responsibility of the
C>> Board of Trustees (BoT), a body that is mainly selected by the
C>> IETF and which is responsible for overseeing the IASF. A draft
C>> of the Articles of Incorporation and Bylaws is included in the
C>> next sections of this document.
C>>
C>> Scenario C allows us (IETF) to establish IETF control over our
C>> administrative support functions in terms of determining that
C>> they meet the community’s needs, and adjusting them from time to
C>> time using IETF processes. This is to address the pressing
C>> administrative issues outlined in [RFC3716].
C>>
C>> Scenario C also encourages us (the IETF) to regularly evaluate
C>> that we do want to continue the relationships with ISOC and the
C>> contracts with our services providers (contractors). It is based
C>> on the premise that we prefer to actively maintain relationships
C>> with other organizations and service providers instead of being
C>> bound to such relationships based on poorly defined and poorly
C>> documented historical facts. A draft BCP for the relationship
C>> between ISOC, IETF and IASF is included as a separate section in
C>> this document.
C>>
C>> Scenario C does however bring the burden of creating a new legal
C>> entity (IASF) and such an undertaking is also not without risks.
C>> It will need careful planning and execution. Migration from the
C>> current structure to this new structure is probably also somewhat
C>> more costly and time and labour consuming. The sections below
C>> try to show how that would be achieved and outlines what further
C>> steps are needed to provide more detail if this scenario is
C>> chosen.
C>>
C>> 2. Work Plan for the IETF Administrative Support Foundation
C>>
C>> This section gives the work plan for the IETF Administrative
C>> Support Foundation (IASF) for the remainder of 2004 and the year
C>> 2005.
C>>
C>> 2.1 Workplan goals
C>>
C>> The work plan below is intended to satisfy three goals:
C>>
C>> o Satisfy the IETF’s need for support functions in 2005
C>>
C>> o Operate with a positive account balance throughout 2005
C>>
C>> o Start building up a fund inside the IASF to serve as a buffer
C>> against budgetary emergencies in later years (such as meetings
C>> with a severe cost overrun, or force-majeure cancellations).
C>>
C>> The fund target is 6 months of operating revenue, and the target
C>> for building up the fund is 3 years. The budgeted set-aside for
C>> the fund should thus be approximately 17% of operating revenue.
C>>
C>> 2.2 Incorporation process
C>>
C>> There are 3 things that need to be in place before that
C>> corporation can be considered viable at all:
C>>
C>> o IETF consensus on the plan
C>>
C>> o ISOC agreement on a reasonable support contract
C>>
C>> o Assurance that the corporation will have tax-exempt status
C>>
C>> Once this document has been discussed in the IETF, and the IESG
C>> and IAB gauges that rough consensus seems reached, the IETF
C>> leadership will take the following actions:
C>>
C>> o Publish a Last Call on this document (to determine plan
C>> consensus).
C>>
C>> o Choose a negotiating team to negotiate the ISOC contract.
C>>
C>> o Choose an executive search team to find the IASF
C>> Administrative Director (IAD).
C>>
C>> o Consult with legal counsel to determine how best to achieve
C>> tax-exempt status; this will affect the bylaws and articles of
C>> incorporation.
C>>
C>> When the Last Call is over, the IESG will consider whether there
C>> is still consensus, and if there is, approve this document for
C>> publication. Once that happens, it will take the following