Request for Comments: 3716 IETF
Category: Informational March 2004
The IETF in the Large: Administration and Execution
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 (2004). All Rights Reserved.
Abstract
In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB
Advisory Committee (AdvComm), with a mandate to review the existing
IETF administrative structure and relationships (RFC Editor, IETF
Secretariat, IANA) and to propose changes to the IETF management
process or structure to improve the overall functioning of the IETF.
The AdvComm mandate did not include the standards process itself.
This memo documents the AdvComm’s findings and proposals.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview of the AdvComm Work Process and Output. . . . 3
1.2. Scope. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Next Steps . . . . . . . . . . . . . . . . . . . . . . 4
2. Observations . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Current IETF Support Structure . . . . . . . . . . . . 4
2.1.1. What the Term IETF Includes in this Document . 4
2.1.2. Functions. . . . . . . . . . . . . . . . . . . 4
2.1.3. Support. . . . . . . . . . . . . . . . . . . . 6
2.2. Observed Stress Points . . . . . . . . . . . . . . . . 8
2.2.1. Stress Points Observed by IETF Leadership. . . 8
2.2.2. Stress Points Observed by Organizations
Supporting the IETF. . . . . . . . . . . . . . 10
2.3. A final Observation. . . . . . . . . . . . . . . . . . 10
3. Stand Facing the Future: Requirements for a Successful
IETF Administration. . . . . . . . . . . . . . . . . . . . . 10
3.1. Resource Management. . . . . . . . . . . . . . . . . . 10
3.1.1. Uniform Budgetary Responsibility . . . . . . . 10
3.1.2. Revenue Source Equivalence . . . . . . . . . . 11
3.1.3. Clarity in Relationship with Supporting
Organizations. . . . . . . . . . . . . . . . . 11
3.1.4. Flexibility in Service Provisioning. . . . . . 11
3.1.5. Administrative Efficiency. . . . . . . . . . . 11
3.2. Stewardship. . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Accountability for Change. . . . . . . . . . . 12
3.2.2. Persistence and Accessibility of Records . . . 12
3.3. Working Environment. . . . . . . . . . . . . . . . . . 12
3.3.1. Service Automation . . . . . . . . . . . . . . 12
3.3.2. Tools. . . . . . . . . . . . . . . . . . . . . 13
4. Advisory Committee Advice . . . . . . . . . . . . . . . . . 13
4.1. Proposed: (Single) Formalized IETF Organizational
Entity . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Comments on the Necessity of this
Formalization. . . . . . . . . . . . . . . . . 14
4.2. Possible Structures. . . . . . . . . . . . . . . . . . 14
4.2.1. ISOC . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. ISOC Subsidiary. . . . . . . . . . . . . . . . 15
4.2.3. Completely Autonomous Organizational Entity. . 16
4.3. Who Can Decide . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations. . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
7. Informative References . . . . . . . . . . . . . . . . . . . 18
A. IAB Advisory Committee Charter . . . . . . . . . . . . . . . 19
B. Input from the current IETF and IAB Chairs . . . . . . . . . 20
C. Consultation with ISI: RFC Editor . . . . . . . . . . . . . 21
D. Consultation with Foretec/CNRI: Secretariat and Meeting
Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 32
E. Consultation with ICANN: IANA Protocol Parameter
Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 35
Author’s Address . . . . . . . . . . . . . . . . . . . . . . 39
Full Copyright Statement . . . . . . . . . . . . . . . . . . 40
1. Introduction
In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB
Advisory Committee (AdvComm), with a mandate to review the existing
IETF administrative structure and relationships (RFC Editor, IETF
Secretariat, IANA) and to propose changes to the IETF management
process or structure to improve the overall functioning of the IETF.
This purpose was defined in the IAB Advisory Committee (AdvComm)
charter, copied in Appendix A. The AdvComm mandate did not include
the standards process itself.
The tangible output of this committee is a set of observations and
recommendations for the IETF’s executive structure - how the IETF
might be organizationally (re)structured so that it can effectively
and efficiently carry out its administrative activities. As a
necessary preamble to that, a description of the current issues and
future requirements is presented. The output does not represent any
decision-making or implementation -- see Section 1.3 for a discussion
of follow-on steps.
1.1. Overview of the AdvComm Work Process and Output
The AdvComm was formed in September 2003, and carried out its work
over the course of the following 2 months, prior to the IETF58 in
November of 2003.
The AdvComm’s membership included many of the individuals who are, or
have been, volunteered to manage the IETF’s inter-organization
administrative relationships in recent years. The first phase of the
committee’s work, therefore, included sharing and discussing the body
of tacit knowledge about those relationships. This included the
input from the current IETF and IAB Chairs in Appendix B, and yielded
the IETF organizational structure information in Section 2.1.
The committee also sought input from the other end of the key
existing administrative relationships (RFC Editor, Secretariat, and
IANA). The output of those efforts is included in Appendix C,
Appendix D, and Appendix E, and these were also used as the basis for
the observations in Section 2.
From these inputs, the committee drew together a list of requirements
for successful future IETF administration, documented in Section 3.
Finally, the committee put together some advice for how the IETF
might consider reorganizing its administrative structure to meet
those requirements moving forward -- Section 4.
1.2. Scope
The AdvComm endeavored to stay focused on the IETF executive
structure -- the collection of organizations that work together to
bring the IETF’s work to reality. However, by virtue of the very
fact that those relationships exist to get the work done, it was
important to bear in mind the work being done in the IETF PROBLEM
working group and IESG proposals for change, even as the committee
endeavored not to infringe on the scope of those efforts. The
objective is that these observations and proposals should be relevant
for today’s IETF and any near-term evolutions that are deemed
appropriate.
1.3. Next Steps
This documents the state of the AdvComm’s thinking at the end of a
two month process, and brings the currently-chartered work of the
AdvComm to a close.
Next steps include review of this material by the community, and
specific proposals for action that will be put forward by the IAB and
IETF Chairs.
2. Observations
2.1. Current IETF Support Structure
2.1.1. What the Term IETF Includes in this Document
RFC 3233 ([1]) provides a definition of the IETF, in terms of its
work and its participation.
This document discusses the collection of organizations that work
together to support the effort described in RFC 3233. In this
document, the term "IETF" explicitly includes the IESG, WGs, IAB,
IRTF, and RGs. This inclusive sense accords with considerable common
usage of the term "IETF". Formally, the IAB and IRTF are chartered
independently of the IETF. However, rather than coming up with a new
term to encompass "the IETF and all its friends", the common usage is
followed here.
2.1.2. Functions
The work of the IETF is supported by a specific set of functions. It
is useful to distinguish between the functions and the organizations
which provide those services, as outlined in the table below. In
some cases a single organization provides multiple services, but the
functions are logically distinct.
Function Known as Organization
(within the IETF)
--------- ---------------- ------------
IESG Support Secretariat Foretec/CNRI
IAB Support ISOC/Secretariat ISOC, Foretec/CNRI
WG Support Secretariat Foretec/CNRI
Community Support Secretariat Foretec/CNRI
IETF Meetings Secretariat Foretec/CNRI
RFC Publication RFC Editor USC/ISI
Standards Status Record RFC Editor USC/ISI
Parameter Reg. IANA ICANN
Legal, insurance, etc. (largely invisible) Provided by ISOC
Table 1. IETF functions, labels and organizations
In more detail, the functions can be broken down as follows:
IESG Support
Telechats
Communications
IETF document tracking
Working document management (mailing list, website, repository)
IAB support
Telechats
Communications
Working document management (mailing list, website, repository)
WG support
Charters
Milestone tracking
Workspace (website, mailing list)
Working document archive (mailing list archives, document
repository)
Community Support
Website
IETF mailing list
Announcements
I-D repository
RFC Publication
Website
RFC editorial
Document publication
RFC repository management
Official standards status record
IETF Meetings
Planning
Meeting Proceedings
Protocol parameter registration
Creation of registries
Assignment of protocol parameters
Management of accessible registry repository
Legal, insurance, etc.
Legal support
Liability insurance for IAB, IESG, WG chairs, etc.
Miscellaneous
2.1.3. Support
A presentation of the scope and depth of support that created the
IETF and has allowed it to continue to contribute would require a
discussion of history that is rich, vibrant, and completely beyond
the scope of this document. However, a very brief introduction to
some of the current pillars is needed to understand where the IETF is
today.
ISOC: Since 1992, ISOC has been the organizational home of the
IETF. This activity is part of its more general mission of
serving as the international organization for global coordination
and cooperation on the Internet, promoting and maintaining a broad
spectrum of activities focused on the Internet’s development,
availability, and associated technologies.
Foretec/CNRI: The Corporation for National Research Initiatives
(CNRI) was founded in 1986, and since 1987, CNRI has served the
community by providing IETF Secretariat services. Until the early
1990s, CNRI provided legal assistance to the IETF and the IETF
Secretariat. After ISOC was founded, ISOC assumed overall legal
responsibility for the substantive workings of the IETF including
the efforts of the IETF chair, the IESG, the IAB, the area
directors and the working group chairs. CNRI assumed operational
responsibility for the substantive workings of the IETF
Secretariat. In 1998, in order to decrease overhead costs on the
activities, the Secretariat was reorganized placing Secretariat
employees including the IETF Executive Director in a CNRI for-
profit subsidiary (Foretec Seminars, Inc.). Foretec was founded
in 1997, in anticipation of the Secretariat becoming self-
supporting. CNRI and its subsidiary have continued to improve the
operation of the Secretariat, as appropriate, and maintain a
trained staff.
USC/ISI: The role of the RFC Editor, and USC/ISI, is detailed in
RFC 2555. The RFC document series is a set of technical and
organizational notes about the Internet (originally the ARPANET),
beginning in 1969. For 30 years, the RFC Editor was Jon Postel, a
research scientist and manager in the Networking Division of the
USC Information Sciences Institute (ISI), with the function
gradually evolving into a team headed by him. The RFC Editor
activity is currently organized as a project within ISI, using the
ISI infrastructure, and supported by a contract with ISOC. The
RFC Editor is the publisher of RFCs and is responsible for the
final editorial review of the documents, as well as the
maintenance of the online repository and index of those documents.
ICANN: The Internet Corporation for Assigned Names and Numbers
(ICANN) is the non-profit corporation that was formed in 1998 to
assume responsibility for the IP address space allocation,
protocol parameter assignment, domain name system management, and
root server system management functions previously performed under
U.S. Government contract by IANA (at ISI) and other entities.
The support picture (who does what) can be described as follows:
Secretariat at Foretec/CNRI
IESG Support
IAB Support (working document management)
WG Support
Community Support
IETF meetings
RFC Editor at USC/ISI
[Supported by ISOC, based on a contract between USC/ISI and ISOC]
RFC publication Maintenance of standards status record
IANA/ICANN
[Relationship defined by Memorandum of Understanding: RFC 2860]
Protocol parameter registry
ISOC
IAB Support (Telechats)
Funds RFC Editor
Misc IAB/IESG expenses
Provides insurance for IAB, IESG, WG chairs, etc.
The available resources to support these activities are:
Meeting fees -- through Foretec
ISOC members’ contributions for standards
ICANN for IANA
Volunteers/their employers (where applicable):
IETF participants
WG chairs
Document editors
IETF NomCom
IESG
IAB
IAB ExecDir
2.2. Observed Stress Points
The AdvComm noted several properties of the current IETF
organizational environment that cause stress in the system. These
have been noted both from the point of view of the IETF leadership as
well as that of organizations supporting the IETF.
2.2.1. Stress Points Observed by IETF Leadership
The current IETF funding and operational structure is dependent on
IETF meeting attendance. Therefore, the most obvious stressor that
has emerged within the last two years is the decline in that
attendance. This trend, which has continued unabated, has resulted
in a decline in IETF revenue (detailed in the IETF chair presentation
at IETF 56 [2]), even as the requirements of the IETF operation are
remaining constant or increasing.
The result has been a budget deficit for operations which began in
2002, and is forecasted to continue until at least 2004, even after a
substantial increase in meeting fees. The continuing deficits have
depleted working capital, making the IETF less robust against
potential future budgetary disappointments.
The financial stress is real, but the IETF leadership has noted
several other stressors that are impediments to finding and
implementing solutions to the fiscal issues. Some obvious solutions
are not implementable in the current IETF structure.
The rest of the stressors listed in this section should be understood
as issues for which relief is necessary, particularly in the light of
needing to properly address and implement solutions to the financial
stress.
The current documentation of IETF processes and structure is, in
places, vague about the distribution of responsibility for management
and oversight of the IETF administrative relationships. This makes
it opaque to the IETF community, and sometimes leaves the leadership
in a poor position to manage effectively.
Additionally, the informality of the relationships with some of the
organizations that are carrying out key IETF functions compounds the
problem of determining who has responsibility, and how IETF community
consensus and desires are reflected in the activity.
As a separate issue, important IETF institutional memory is recorded
nowhere other than peoples’ minds in many cases -- which requires
significant transmission of oral history for IETF leadership
transition to be effective.
Apart from the institutional memory, other important IETF
institutional records are spread across various organizations, and
searching for the set of relevant documentation (especially when this
is necessary long after the recording) can be challenging.
Another stressor relates to the need to scale support processes in
terms of reducing latency for mechanical processes. That is, a
decrease in the amount of manual labor required for the simpler tasks
between the organizations, would make more resources available to
focus on the special cases. Lack of automation in the basic request
services has been known to cause undue delay or failure in processing
simple, routine tasks. However, automation also requires resources
and significant management in order to make sure it fulfills the
community’s requirements.
2.2.2. Stress Points Observed by Organizations Supporting the IETF
Supporting organizations report difficulties in determining
authoritative channels for directions -- either too many inputs, or
no clear authority for resolution of change requests.
In the absence of written agreements, supporting organizations may
not be clear from whom to take direction. Even where agreements
exist, the authority to provide direction may not be clear. The
genesis of both problems is that the IETF relies on external bodies
for support, but does not have sufficiently clear external
relationships to allow it to provide input as to its requirements or
direction on what services it desires.
2.3. A Final Observation
This section attempts to capture a snapshot of the current state of
the IETF organization, without undue fixation on the causes for
arriving at the current state. However, it seems clear from the
observations that the current state does not provide an adequate
structure from which to reach into the future: some changes are
needed within the IETF administrative and executive structure.
3. Stand Facing the Future: Requirements for a Successful IETF
Administration
This section follows the set of observations with a set of
requirements for a properly-functioning IETF administrative
structure. These requirements are offered as the AdvComm’s
description of what the IETF needs, without addressing immediately
the degree to which they are available with the current environment.
That is, these are "requirements", not "requirements for change".
3.1. Resource Management
3.1.1. Uniform Budgetary Responsibility
The IETF has operated in times of financial wealth and times of
economic cutbacks in the industry. It is reasonable to expect that
the future holds similarly variable trends. Therefore, it is
important that the IETF organization has the ability to make the
decisions to match its needs at a given point in time, i.e.,
budgetary autonomy. At this particular moment, there are hard
choices to make, and the AdvComm believes that it is the IETF
leadership, with the advice and consent of the IETF community, that
needs to make them.
3.1.2. Revenue Source Equivalence
The IETF is currently supported by money from multiple sources,
including meeting fees, donations from interested corporate and non-
corporate entities, and donations in kind of equipment or manpower.
The IETF needs to be able to consider all sources of income, and all
expenses involved in running the IETF, as pieces of one budget, to be
free to adjust all items on the occasions when the income from the
different sources varies, and to allocate funds as reasonably
required.
The usual caveats apply: that donations not threaten the
independence of the IETF, and that donations are easier when they are
tax deductible.
3.1.3. Clarity in Relationship with Supporting Organizations
While the IETF needs to be able to manage its revenue streams against
its expense expectations, it also needs to respect the needs of
supporting organizations to manage their own affairs. That is, the
text above does not suggest that the IETF should micro-manage the
financial affairs of supporting organizations.
However, the very clear requirement is for clarity in the
distribution of rights, responsibilities, and accountability in those
relationships. The usual mechanism for documenting such clarity is
in contract form. Thus, the IETF needs to have clear contractual
relationships with the organizations supporting basic services,
including meeting organization, secretarial services, IT services,
etc.
3.1.4. Flexibility in Service Provisioning
The IETF needs to be able to raise money for, and fund the
development of, additional services as appropriate. This includes
the development of tools for participants, repository management,
etc.
3.1.5. Administrative Efficiency