The IETF’s needs should be met with the minimum of overhead. This
implies that there needs to be the possibility of combining work
efforts where appropriate, and generally avoiding duplication of
effort.
3.2. Stewardship
The requirements described below focus primarily on the needs of the
IETF administration on a day-to-day basis. However, responsible
management includes stewardship for future IETF work.
3.2.1. Accountability for Change
The IETF needs to be responsible for changing its administrative
structure to meet the community’s evolving needs. As such, the
administration needs to remain uniquely accountable to the IETF
community.
This also means that the distribution of responsibilities must be
clear to the IETF community, in order to permit it to comment on
current actions or future plans, and also to allow it to take action
when its needs are not being adequately addressed.
An implication of this is that responsibility for financial
management within the IETF needs to sit with individuals who are
accountable within the IETF organizational structure.
3.2.2. Persistence and Accessibility of Records
Much of the work of the IETF is focused on reaching decisions and
declaring closure. However, responsibility does not stop with the
declaration of completion. There are any number of reasons that
history must be adequately documented so that future work can review
substantive records, and not rely on oral history.
Therefore, the IETF needs to maintain and support the archiving of
all of its working documents in a way that continues to be
accessible, for all current and future IETF workers.
3.3. Working Environment
Part of the job of administering the IETF is identifying and ensuring
the continued support of the tools and working environment necessary
to support the ongoing activity.
3.3.1. Service Automation
Wherever human judgment is not required in order to complete an
action, services should be automated to provide the most friction-
free path and minimal delay in completing the action.
More processes could be accomplished without requiring human
judgment. Wherever possible, these processes should be identified,
clarified, and automated.
Note that this is not intended to imply ALL processes should be
automated! Rather, by reducing the friction incurred in steps that
are truly mechanical, more time and energy will be available to
properly treat those that require individual judgment.
3.3.2. Tools
Whether housed in an IETF-supported location or offered by individual
contribution, the PROBLEM WG has identified the need for more tool
support for working groups and specification development. The IETF
needs to be able to identify, develop and support an adequately rich,
consistent set of tools for getting the standards work done.
4. Advisory Committee Advice
The Advisory Committee discussed the material and observations,
described in this document, at great length. To the AdvComm, it
appeared clear that some level of IETF administration organizational
change is needed to address the stressors and meet all of the
requirements outlined in Section 3.
4.1. Proposed: (Single) Formalized IETF Organizational Entity
In order to ensure an IETF structure that is capable of meeting the
requirements outlined above, the AdvComm recommends that the IETF be
more formally organized. This would allow the IETF to take full
responsibility for, and management of, the resources required to
accomplish its work (as described in Section 3.1), provide and
maintain the necessary work environment for current work (as
described in Section 3.3), and provide appropriate stewardship of the
institutional information required for all aspects of current and
future work of the organization (as described in Section 3.2).
Some proposed models for establishing such a formalized effort are
described in the following sections. Some of the key expectations,
irrespective of the final implementation of formalism, are:
o the administration of the IETF would remain accountable to the
IETF leadership and community; the goal would be to ensure that
lines of responsibility and accountability were clearer;
o this formalized IETF would be responsible for managing financial
resources (revenue and expenses) directly;
o this formalized IETF would be directly signatory to agreements
with other organizations, and would therefore be able to negotiate
and administer any appropriate contracts;
o however implemented, this would require a small staff complement
(e.g., one full-time person) responsible to no other organization
than the one chartered with the IETF’s mission;
o nevertheless, it remains a non-goal to create an organizational
entity that exists simply for the purpose of continuing to exist.
This should be executed with the minimum formality needed in order
to address the identified requirements.
4.1.1. Comments on the Necessity of this Formalization
An important question is: what does this proposed formalization
provide that cannot be provided by the status quo? The AdvComm
believes that an appropriately implemented formalization of the IETF
would permit the unification of the resource management, decision
making and stewardship that is imperative to providing clarity and
ensuring a viable future for the IETF. The AdvComm further believes
that this is simply not possible to implement within the existing
distributed and informal arrangement of responsibilities.
Naturally, the act of forming such an organization does not
immediately satisfy the requirements outlined in Section 3. It is
not a silver bullet. Changing the formal structure will not, for
example, change the financial status of the IETF. However, the
AdvComm believes it would provide the necessary basis from which the
required decisions could be made and acted upon.
In short, the AdvComm believes that we first have to place the
responsibility for defining the IETF’s administrative environment
with specific people who are accountable to the IETF community. Then
these people can take the detailed decisions that will change the
IETF’s administrative environment to fulfill its requirements.
4.2. Possible Structures
Section 4.1 was deliberately vague on the nature of the formal
organizational entity that might provide the proper environment,
focusing instead on the key components of any implementation of such
a formalization, and how the formalization activity would address the
requirements laid out in Section 3.
Having thus determined that formalization of the IETF is seen as a
necessary step, the basic framework for 3 potential implementations
of it are described below. Note that these are not complete
proposals, nor is enough detail available to recommend a particular
path. The IETF leadership might select one to explore in greater
detail, to formulate an action proposal with sufficient detail to
make a decision to act.
4.2.1. ISOC
The IETF is organized as an activity of the Internet Society. One
potential path for increased formalism of the IETF’s administration
would be to further define that relationship. This model anticipates
dedication of ISOC personnel to form the "small staff complement",
and would make ISOC responsible for all of the IETF’s financial
resources and expenses.
This approach should be relatively straightforward to implement,
given ISOC’s existing legal relationship with the IETF activity, and
its status as signatory for IETF-related contracts (e.g., RFC
Editor).
This proposal is consistent with the goal of minimizing the amount of
formalization needed to meet the requirements of the IETF.
However, the general mission of ISOC is broader than the
standardization activity of the IETF, and the ISOC Board of Trustees
must stay focused on apportioning resources to meet that broader
mission. Would this approach allow the clear lines of responsibility
that are called for in Section 3?
4.2.2. ISOC Subsidiary
A modification of the proposal of housing the IETF central body
within ISOC is to create a legal not-for-profit subsidiary of ISOC,
with a mandate that is specifically focused on the IETF’s mission.
This subsidiary would become the legal entity responsible for
managing the IETF’s resources and expenses, and would become
signatory to any other legal instruments on the IETF’s behalf.
As a distinct legal entity in its own right, the subsidiary would be
independently responsible for achieving its mission. That level of
independence addresses the concern raised against the notion of
further formalizing the IETF within ISOC directly -- that the IETF
mission might be disrupted by the organization’s need to tend to
other aspects of ISOC’s broader mission. The role of the IETF
community, and the ISOC parent, in defining and supporting that
mission would be spelled out in the creation of the legal body.
The IETF might additionally consider what the most appropriate
governance model would be for this approach. If it is desirable to
remove some of the administrative burden from the IESG and IAB, such
a subsidiary might have its own Board of Trustees, composed of
members appointed by IETF and ISOC. Such a Board would be
responsible for reviewing activities and ensuring that the
organization’s efforts were adequately in line with its mission, its
finances were in order, and so on. The subsidiary would report to
its Board of Trustees. Other governance models are certainly
possible, and a Board of Trustees is not a requirement for this
approach.
At the same time, as a subsidiary organization, the expectation is
that the relationship with ISOC would remain a close one: the
subsidiary would benefit from ISOC’s existing infrastructure and
support (a conservative approach to adding formalism and structural
overhead to the IETF activity), while the relationship would continue
to provide a channel for the IETF to support ISOC in achieving that
broader mission, with continued contribution of technical expertise
and support of activities.
This approach would require more work to create than simply housing
the work at ISOC. The subsidiary would have to be created and
rights/responsibilities adjusted between it and ISOC in order to
ensure that both have the necessary resources and frameworks to carry
out their missions.
4.2.3. Completely Autonomous Organizational Entity
To complete the picture, a third option has to be considered. Instead
of creating a subsidiary of ISOC as a separate legal entity, an
entirely new legal entity, "IETF, Inc.", or "IETF, LLC", could be
created for the sole purpose of managing IETF administrative
activities.
This would offer the IETF complete autonomy with all the attendant
rights and responsibilities. In particular, an independent IETF
would at a minimum, need to operate much like a startup for the first
few years of its existence, with all the related financing and growth
issues, and survival risks. Given all the organizational change
taking place within the IETF during the same period, the AdvComm
believes that the financial and political risks of such an approach
should not be under-estimated.
For example, it would be necessary for the IETF to obtain initial
working capital sufficient to handle the commitments for the first
few meetings. While it would be conceivable to raise working capital
from advance meeting fees, such a financing plan would not leave much
margin for error; were one or more of the initial meetings to run in
the red, the survival of a fledgling IETF could be in jeopardy. Given
the economic environment, it probably should not be assumed that
working capital could be raised purely from corporate donations,
especially during an initial period in which staff required to
solicit and manage donations would not be available.
Additionally, the impact that such a move would have on ISOC’s
ability to carry out its mission and the IETF’s standing with
governmental organizations needs to be considered.
4.3. Who Can Decide
The AdvComm believes that the IETF leadership, acting with the advice
and consent of the IETF community and ISOC, have the ability and the
responsibility to act on the recommendation to formalize the IETF.
5. Security Considerations
This document does not describe any technical protocols and has no
implications for network security.
6. Acknowledgements
The AdvComm sincerely appreciates the time, effort and care of the
RFC Editor, IANA, Secretariat and Secretariat organizations in
providing input, responding to the AdvComm’s questions, and
reviewing/correcting the consultation text shown here in the
appendixes.
The members of the IAB Advisory Committee that prepared this report
were:
o Bernard Aboba
o Harald Alvestrand (IETF Chair)
o Lynn St.Amour (ISOC President)
o Fred Baker (Chair, ISOC Board of Trustees)
o Brian Carpenter
o Steve Crocker
o Leslie Daigle (IAB Chair, chair of the committee)
o Russ Housley
o John Klensin
7. Informative References
[1] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, RFC
3233, February 2002.
[2] Alvestrand, H., "IETF Chair plenary presentation, http://
www.ietf.org/proceedings/03mar/slides/plenary-3/index.html",
March 2003.
[3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[4] Reynolds, J. and B. Braden, Eds., "Instructions to Request for
Comments (RFC) Authors", Work in Progress.
Appendix A. IAB Advisory Committee Charter
Date: Tue, 02 Sep 2003 16:34:58 -0400
From: Leslie Daigle
Subject: Formation of IAB Advisory Committee
To: IETF-Announce: ;
I would like to announce the formation of an IAB advisory
committee, as described below.
Thanks,
Leslie,
for the IAB.
=================
IAB Advisory Committee on IETF Administration Relationships
The purpose of the committee is to review the existing
IETF administration relationships (RFC Editor, IETF Secretariat,
etc.) and propose IETF management process or structural changes
that would improve the overall functioning of the
IETF. Any such proposal will be subject to review and
acceptance by the IAB and IETF plenary. Note that the scope of the
advisory committee does NOT include proposed changes to the standards
development processes (e.g., WG organization, IESG management of
documents or working groups, etc.).
The committee is chaired by the IAB Chair, Leslie Daigle, and
consists of:
o Bernard Aboba
o Harald Alvestrand (IETF Chair)
o Lynn St.Amour (ISOC President)
o Fred Baker (Chair, ISOC Board of Trustees)
o Brian Carpenter
o Steve Crocker
o Leslie Daigle (IAB Chair, chair of the committee)
o Russ Housley
o John Klensin
Additional input is welcome. The committee will also make a
particular effort to seek out further input as needed. --
Appendix B. Input from the Current IETF and IAB Chairs
Input contributed by Harald Alvestrand (IETF Chair) and Leslie Daigle
(IAB Chair).
Looking at the administrative overview of the IETF activity, there
are a number of things that work well:
o support organizations are committed to the work of the IETF;
o the volunteers of the IETF WGs can (mostly) concentrate on their
engineering work, not economics;
o money has (so far) been sufficient to cover the costs.
However, there are also a number of challenges:
o lack of persistent records of the whole organization’s efforts --
of working documents, meeting materials, communications. Also,
* lack of organization of records -- even when data is stored, it
can be hard or impossible to access when no longer current
(e.g., it may reside on some former WG chair’s hard drive)
* history records are kept spottily (lists of wg chairs and old
versions of charters, to mention some);
o few safeguards against the "hit by a bus" problem -- much
information about relationships is not documented, and must be
transferred as oral tradition. This means that significant
overlap is needed when personnel changes;
o IETF leadership responsibilities are not clearly identified --
typically handled by IETF and IAB Chairs, with some advice and
consent from IESG and IAB, but that makes it possible to challenge
every change decision;
o contracts do not clearly identify responsibility for executive
direction. Some contractual relationships are not documented, or
are not visible to the IETF leadership;
o variable, and often unclear, documentation of responsibilities
between IETF leadership and other organizations. This makes it
hard to determine how and where to discuss and effect improvements
for the IETF that affect one or more support organization’s
activity;
o unclear budgeting responsibilities -- the IETF leadership has to
make decisions that will impact the revenues and costs of the
supporting organizations, but the supporting organizations wear
the direct effects of revenue and cost control. Information about
the financial impact of decisions are not available to IETF
leadership;
o partitioned finances -- it’s not possible for the IETF to make
changes that would affect the balance of revenue and costs across
the revenue sources/expense commitments. For example, raising
meeting fees wouldn’t pay for more RFC Editor resources; more
support from ISOC doesn’t address any needs for IETF working group
support functions;
o the lack of clarity and the partitioning make it very hard for the
IETF leadership, and the community as a whole, to determine points
of accountability and implement changes for a healthy future.
Appendix C. Consultation with ISI: RFC Editor
Note: "RFC2223bis" in the text below refers to RFC 2223bis [4], a
work in progress to update RFC 2223 [3].
Responses to Questions from IAB Advisory Committee
for the RFC Editor
October 6, 2003
*
* (1) Your description of the function you are performing. Is
* that function, and its relationship to the IETF, adequately
* described in RFC 2223bis, or is additional description
* required? If the latter, what would you suggest?
ANSWER:
A comprehensive summary of current RFC Editor functions is attached
below. Note that this list has no direct relation to RFC 2223bis,
which contains instructions to RFC authors.
*
* (2) What staff is being used to perform these functions and
* what are their particular skills for doing so (either
* individually or in the aggregate)?
*
ANSWER:
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). It is currently organized as a project within ISI,
using the ISI infrastructure. The following ISI staff members
comprise the RFC Editor project:
Joyce Reynolds 100%
Bob Braden 10%
Aaron Falk 10%
Sandy Ginoza 100%
Project Assistant 100%
Graduate Research Asst. 50%
Braden and Reynolds jointly manage the RFC Editor project, with
oversight of personnel and budgets.
Joyce Reynolds has been contributing her editorial and management
skills to the Internet since 1979. She performed the IANA functions
under Jon Postel’s direction from 1983 until Postel’s death in
October 1998. She continued to perform the IANA protocol parameter
tasks on loan from ISI to ICANN, from 1998 to 2001. She was IANA
liaison to the IESG from 1998 to 2001, transitioning the role to
Michelle Cotton in the 2001.
Reynolds performed the RFC Editor functions under Jon Postel’s
direction from 1987 until 1998. Reynolds has been a member of the
IETF since 1988, and she served as User Services Area Director on the
IESG for 10 years. Reynolds now serves a liaison to the IAB and
IESG. She handles the final proofing and quality control on RFCs
prior to publication.
Bob Braden has made many contributions to the Internet protocol
technology and community. He helped design TCP/IP during the
original research period beginning in 1978, and he has devoted his
professional career since 1978 to the Internet. He served for 13
years on the original IAB and as its Executive Director for about 5
years. Since 1998 Braden has been co-leader of the RFC Editor
project. He is the principal reviewer of individual submissions. He
also works on technical issues related to the RFC Editor project.
Aaron Falk is a significant player in the IETF as a Working Group
chair, in the areas of transport protocols and satellite technology.
On the RFC Editor team, he assists with policy questions and handles
technical development, overseeing the work of the grad student
programmer.
Sandy Ginoza is the principal technical editor. She is generally
responsible for managing the RFC Editor queue and much of the day-
to-day interface with the IESG and authors. Ginoza sends and
receives a LOT of email, and she plays a central role in the
operation.
Two part-time Project Assistants, Mieke Van de Kamp and Alison De La
Cruz, do editing, mark-up, and initial proofing of individual RFCs.
Our goal is to have three pairs of eyes read every RFC word-for-word,
and in most instances we are able to do so.
A half-time USC Graduate Research Assistant provides programming
support by developing, extending, and maintaining RFC Editor scripts
and tools.
* (3) What criteria do you use to determine whether you are being
* successful, and how successful? Using those criteria, how
* successful are you and what could be done, especially from the
* IETF side, to improve that evaluation?
ANSWER:
We can begin with a historical perspective on this question. When
Jon Postel unexpectedly passed away 5 years ago, Reynolds and Braden
took on the challenge of carrying on Postel’s RFC Editor function.
The publication stream continued, with a modest increase in quantity
and, we believe, no loss of quality. Furthermore, the transition was
largely invisible to the IETF. In addition, the new RFC Editor
project has significantly defined and clarified the publication
process, improved the web site, added tools to improve productivity
and quality, and adapted the procedures to changing realities. We
are proud of these achievements.
The three primary axes for measuring RFC Editor success are (1)
quantity, (2) quality, and (3) accessibility.
1. Quantity
Roughly, quantitative success means the ability to keep up with
the submission rate. Since the submission rate tends to be
bursty, to avoid long delays we need an average capacity somewhat
in excess of the average.
RFC publication is necessarily a heavily labor-intensive process.
Our goal is generally to complete the publication process in less
than 4 weeks, exclusive of external factors beyond our control --
normative dependence upon other documents, delays by authors or
the IESG, IANA delays, etc.
2. Quality
Publication quality is harder to measure, but "we know it when we
see it." Considering quality as the absence of faults, by noting
faults we can observe lack of quality.
One measure of faults is the number of errata that appear after
publication. In addition, there may be faults apparent to a
reader, such as a meaningless title, confusing organization,
useless Abstract, inadequate introduction, confusing formatting,