Internet Draft Crocker and Malamud
Expires May 1, 1993
Possible Changes
in the Standards Development Process
(Draft 5.1)
1. Introduction
1.1 Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or made obsolete by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current
status of any Internet Draft.
1.2 Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Status of this Memo . . . . . . . . . . . . . . . . . . 1
1.2 Contents . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Abstract . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Background of POISED Group . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 The Current World . . . . . . . . . . . . . . . . . . . 4
2.2 The Obvious Problems . . . . . . . . . . . . . . . . . . 5
2.3 The Real Problems . . . . . . . . . . . . . . . . . . . 7
3. The Proposed Structure . . . . . . . . . . . . . . . . . . . 9
3.1 The Technical Task Force . . . . . . . . . . . . . . . . 10
PAGE 1
Internet Draft Crocker and Malamud
3.2 Architectural and Process Guidelines . . . . . . . . . . 14
3.3 The Process Board . . . . . . . . . . . . . . . . . . . 16
3.4 The Editor . . . . . . . . . . . . . . . . . . . . . . . 18
4. The Process . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Selection of the Leadership . . . . . . . . . . . . . . 19
4.2 Selection of Technical Task Force Leaders . . . . . . . 21
4.3 Openness as a General Principle . . . . . . . . . . . . 24
5. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
1.3 Abstract
This document is a response to the call for a working group to
examine the Process for Organization of Internet Standards (POISED).
The document contains one possible set of solutions to the issues
examined by the POISED working group. It does not reflect a position
of the working group and is not necessarily a consensus view.
The document suggests the replacement of the current technology
development bodies of the Internet (the IAB, IETF, IESG, and IRTF)
with a new, streamlined structure. We refer to this community as the
Technical Task Force of the Internet.
In this system, working groups would define problems and review
solutions and design teams would come up with solutions to those
problems. Working groups would be part of areas. Area Chairs would,
together with an Architect and an overall Chair, form a Technical
Board, which would manage the workings of the Technical Task Force. A
Process Board would provide oversight to the process, requiring that
the Technical Task Force develop objective technical and process
criteria and adhere to those criteria.
The document also deals at length the with questions of
accountability of boards to the general membership. The document
recommends a set of procedures, such as open meetings, and discusses
ways of handling the selection and approval process for personnel
changes. The document considers many of these issues within the
broader context of the Internet Society as well as the Technical Task
Force.
PAGE 2
Internet Draft Crocker and Malamud
1.4 Background of POISED Group
The Process for Organization of Internet Standards (POISED)
working group was formed with the explicit charter to "to examine the
Internet standards process and the responsibilities of the IAB, with
attention to the relationship between the IAB and IETF/IESG." This
Internet Draft examines those issues.
In addition to the explicit charter provisions, there was
extensive discussion by the POISED group of a variety of other issues
such as the structure of the IAB and the by-laws of the Internet
Society. We find that the Internet standards process is closely tied
to these broader issues and our recommendations thus take a broader
scope than might have been initially anticipated.
This report is simply a preliminary set of recommendations and
should not be taken as the policy of the IETF, the IESG, the IAB, or
the Internet Society. It is also important to stress that this report
represents our personal views and does not necessarily reflect a
consensus view among the POISED working group. In particular, while
we make preliminary recommendations it should be stressed that there
may be several solutions to these problems and that we make specific
recommendations as a method of focusing the discussion, not to
forestall any other approaches.
The report is a distillation of the views of many people.
Members of the Internet Society trustees, the IAB, the IESG, the IRTF,
and the IETF have all contributed their input and their insight. We
do not cite these many reviewers by name as we feel that this will
provide more freedom to reach a compromise in the ensuing discussions.
This report begins with an examination of the current process and
the problems that process has encountered. Next, we recommend a
restructuring of that process, replacing the current organizational
framework with a streamlined set of bodies and procedures. I n
addition, we examine the role of the Internet Society and provide a
set of recommendations on the structure of that society and on the
process by which it operates. We conclude with a brief transition
plan.
Our goal throughout this effort has been to examine structural
and procedural changes that will streamline the process of technology
development for the Internet, making it smoother, more predictable,
PAGE 3
Internet Draft Crocker and Malamud
and speedier. We propose a model that we believe will put our best
technical leadership at the beginning of the process, and will
accelerate technology development while still preserving due process,
fairness, and accountability.
2. Background
2.1 The Current World
Standards development for the Internet uses a model that is
substantially unchanged from the early DARPA roots. The Internet
Architecture Board, originally appointed by DARPA, has been a self-
selecting body. The IAB appoints two task forces to assist it:
o The Internet Engineering Task Force (IETF)
o The Internet Research Task Force (IRTF)
The IAB appoints a chair of the IETF, who selects a series of
Area Directors who serve at his discretion. The collection of Area
Directors form the Internet Engineering Steering Group (IESG) which
collectively provides technical and process management of the IETF.
The Area Directors (AD) in turn may appoint people to an Area
Directorate who assist them in the management of the area.
Each area has a set of working groups that are formed by the
IESG. Each working group is given a charter and a chair, appointed by
the IESG. The working group meets at one or more IETFs (and
occasionally at other times) and produces one or more specifications.
In theory at least, the working group has then fulfilled its charge
and disbands. Most working groups set themselves the goal of
producing one or more standards-track specifications.
The IRTF has a similar structure. The chair of the IAB appoints
a chair of the IRTF, who in turn manages an Internet Research Steering
Group (IRSG), comprised of the chairs of the various research groups
in the IRTF. The work of the IRTF ranges from classical research to
advanced development activities, including such notable successes as
multicasting and Privacy Enhanced Mail.
Recently, the Internet Society was formed as an umbrella group
for this process. The Internet Society has a much wider charter than
the standards-development functions of the IAB and IETF, but one of
the prime motivations for formation of the society was an
institutional "home" for the IAB and the IETF, with all the
implications of legal protection of the standards-making process. The
PAGE 4
Internet Draft Crocker and Malamud
Internet Society started with three organizational members, who
appointed the first three trustees. These trustees in turn selected
the rest of the trustees.
The Society has individual and corporate members. Voting rights
in the Society are available to individual, not corporate members of
the society. Although the by-laws do not specifically require
election of trustees, Internet Society officials indicate that their
intention is to have the majority of the trustees elected by the
membership.
The Internet Society trustees are empowered to select members of
the IAB. The system has thus evolved that trustees are selected by
some method, who in turn appoint IAB members. IAB members select
their chair, and also name the chair of the IETF. The IETF chair
selects an IESG.
2.2 The Obvious Problems
The formation of the POISED group was in reaction to a recent IAB
decision, the selection of the International Organization for
Standardization (ISO) definition of a Connectionless Network Service
(CLNS) as a basis for focusing a long-standing discussion on future
evolution of the Internet Protocol.
The publication by the IAB of an Internet Draft on IP version 7
was the culmination of several steps. Routing and addressing in the
Internet have become increasingly critical issues, with routing tables
exploding in size and the IP address space rapidly depleting. Work in
the traditional IETF working groups, such as the one working on the
Border Gateway Protocol (BGP), did not appear to be making sufficient
progress towards a solution.
To address these problems, the IAB formed a special Routing and
Addressing (ROAD) task force. Selection of a task force by the IAB on
an invitation-only basis was a significant departure from the usual
IETF tradition of open working groups. The IAB felt that a focused
effort by a selected group was needed given the seriousness of the
situation.
The ROAD group considered the issues at several meetings and in
intense electronic mail exchanges, but was unable to make any specific
recommendations on a solution to the problems at hand. The ROAD group
work was reviewed by the IESG and the IESG made a recommendation for a
PAGE 5
Internet Draft Crocker and Malamud
period of further study by a series of traditional IETF working
groups. That recommendation was forwarded to the IAB.
The IAB reviewed the IESG recommendation and felt that the
problems at hand were so severe that a more focused effort was needed.
It overruled the IESG recommendation and instead proposed that the ISO
CLNS be considered as a straw man, and that this straw man be studied
intensively by one or more IETF working groups.
An Internet Draft was prepared by the IAB. With an IETF meeting
coming, the Internet Draft was published and a one-page summary was
prepared by the Chair announcing the draft. The depth of community
reaction to the IPv7 draft was immediate, loud, and clear. The IESG
felt that the decision to focus on one protocol was premature and that
the IAB had exceeded its role in the process. Many members of the
IETF felt that the IAB had prematurely decided on one technical
solution without proper deliberations by an open IETF working group.
It was felt by some that the straw man nature of the draft was
obscured by the stronger language contained in the one-page summary.
However, others feel that the problem was not merely a public
relations situation in which the press release was too strong. To
many people, the problem was in the decision contained in the
underlying draft, not a problem with wording in the summary.
The community reaction led to two results. First, the IPv7
decision was set aside and the original IESG recommendation for a
period of intensive study of alternative solutions was adopted.
Second, the POISED working group was formed to determine if there were
steps that could be taken to prevent such a painful level of
controversy in the future.
Part of the depth of the reaction to the IPv7 decision was rooted
in a feeling among many members of the IETF that there had a been a
pattern of decisions by the IAB which were out of out of synch with
the expectations and desires of the IETF. As is usual in such
situations, there were merits in the arguments on both sides.
The IAB has always brought important insight and wisdom to bear
on the issues at hand. In some of the more spectacular cases,
however, it appeared that the decisions of the IAB were in
disagreement with the expectations of the membership of the IETF. At
the very least there is a pattern of communications problems related
to the distance between the IAB and the IETF.
PAGE 6
Internet Draft Crocker and Malamud
There has been a great deal of discussion on whether a problem
exists or not. There is clearly a perceived problem and, in our view,
a perceived problem is a real one. In particular, to the extent that
perceptions exist that the IAB is isolated, the IETF is irresponsible,
or the Internet Society is unresponsive, we must begin to deal with
those perceptions. It is important, however, to look beyond the
perceptions and attempt to address the real underlying causes.
2.3 The Real Problems
One of the biggest problems uncovered during the discussion of
the POISED working group has been delay. It is clear that we need to
maintain high standards of quality, but is also clear that we have
built up a bureaucracy that must be retuned. Specifications are
formed by the working group, forwarded to the area directorate,
considered by the IESG, then forwarded to the IAB.
Multiple levels of review are important, but in many cases the
relative functions of the IESG and the IAB are unclear, leading to
delay. Additional delay is also built in from reviews by the RFC
Editor and by the IETF Secretariat. We do not criticize individual
actions here, but do point out that the end result is that documents
that have gone through a tremendous amount of effort from the working
group are often returned.
Delay shows that things are broken on both sides of the process.
The IAB has justifiably sent many drafts back after uncovering real
and substantial problems in the specifications. The IESG has likewise
caused delay, sometimes through the sheer volume of work the
volunteers have to manage, sometimes through more systematic problems
such as an inefficient use of the IETF secretariat. The problem of
delay is a symptom of broader problems throughout the system.
One of the biggest reasons for the depth of reaction on the IPv7
controversy, and in many situations, has been the element of surprise.
In the case of the IPv7 controversy, for example, few in the community
realized that a decision was forthcoming. This surprise appears to
be, in great part, responsible for the furor that resulted from the
decision.
The surprise is a result of the complexity of the system and the
fact that all members of the leadership are volunteers with high
workloads. The complexity of our process, the distance between
PAGE 7
Internet Draft Crocker and Malamud
players, and the volume of paperwork, as well as the complexity of the
entire technical arena have all combined to make our process
uncertain.
Surprise carries two kinds of cost. First, it raises the amount
of time that it takes to get a standard through the system. Technical
specifications are sent back to the working group for refinement,
initial approaches are abandoned, and potentially controversial
projects are delayed.
The real cost of surprise, however, is human. Surprise causes
contention in the community and makes it harder for us to work
together. People drop out of the system, institutional barriers form
between groups such as the IAB and IESG, and we loose the ability to
focus on producing technology.
A variety of problems have also arisen based on the historical
genesis of the structure of the IAB and the IETF. The membership of
the IETF views itself as an independent body, yet the reality of the
structure is that the IETF is at the bottom of a hierarchy of
committees. There is great confusion as to who is in charge.
Related to the question of the hierarchy is the question of
accountability. Our leaders do not serve fixed terms or have any form
of accountability to the membership. A lack of accountability of the
leadership to the membership has resulted in a great deal of ill will
and situations such as the IPv7 controversy.
Accountability is a key issue, and there is a great desire by all
involved in the process to avoid a process of accountability that
destroys the focus on technical matters that have made the Internet so
successful. A process of formal voting and rigid committees, such as
is found in ANSI or other standards-making bodies, does not seem to
fit the technical focus of our community.
Rough consensus has been the process by which all portions of the
Internet have made decisions. The IAB functions by consensus, working
groups and the IESG also function in this manner. The challenge is to
find a way to instill accountability by consensus, yet still maintain
due process and, at the same time, rapidly develop and deploy new
solutions to pressing technical problems.
There is one other set of issues that we found to be crucial.
The Internet Society has been formed with clearly laudable intention
PAGE 8
Internet Draft Crocker and Malamud
of broadening support for the Internet beyond a technical few. The
Internet Society has the potential for being an institutional home for
technology development in the Internet, yet go far beyond technology
development, providing education, a professional society,
publications, conferences, and many other desirable functions.
The IETF and IAB have been placed under the auspices of the
Internet Society. Yet, the number of IETF members who have joined the
Internet Society is remarkably low and there is still significant
resistance to placement of the IETF within the Internet Society
framework.
We believe that the Internet Society has a scope beyond that of
the IETF, but that the IETF is crucial to the initial development of
the Internet Society. There are steps that the Society can take to
underscore its commitment to an open, democratic process that will
greatly help in gaining the support of the technical development
community.
In trying to fix these problems, we have avoided focusing on the
actions of specific individuals. We feel strongly that the problems
facing the Internet community are rooted in the current structure and
processes, and will not be fixed through simple changes in personnel.
It should be noted, however, that there is considerable feeling at all
levels that some personnel changes are needed, but that the current
structure makes it very difficult to initiate and complete those
personnel changes.
A system has built up over time consisting of the IRTF, the IETF,
Area Directorates, the IESG, the IAB, and, recently, the Internet
Society. All of this superstructure is built on top of the
fundamental activities: people developing code and standards and
coming to a rough consensus on the best approach. Just as the
superstructure has not always functioned perfectly, we are
increasingly having problems with working groups not producing
solutions of high quality.
3. The Proposed Structure
In this section, we propose a revision to the existing structure.
Our main goals are to shift away from a focus on the IAB and the IETF
as separate organizations and find a way of streamlining the process
of technology development. We also try to craft a system that
includes due process guarantees to ensure fairness, but at the same
PAGE 9
Internet Draft Crocker and Malamud
time help preserve our focus on working technology instead of paper
standards.
3.1 The Technical Task Force
We start by considering all of the organizations as a single
community, the Technical Task Force. Our first proposal is thus that
the Internet Society charter this group, the Technical Task Force.
The Technical Task Force is responsible for standards-development, for
the development of technology, and for all of the functions we have
grown used to in the IAB, the IRTF, the IESG, and the IETF.
We explain in this section how the functions of these different
bodies can be streamlined into a simple structure consisting of
working groups and design teams, governed by a Process Board and a
Technical Board. We attempt to integrate the functions of
architectural review and advanced development into the mainstream of
the process through an enhanced view of the working group.
The core of the process is the working group. We start by
concentrating on this core. We can then build up an organizational
structure that adds technical review, process guarantees, logistical
management, and other functions.
The working group is, by definition, an open group looking at a
problem. Anybody can attend as an individual. This openness is both
essential and inherently inefficient. Working groups often suffer,
however, from "design by committee." It is not uncommon, therefore,
for small, self-selected groups to form and work out proposals. The
proposal for a Simple Management Protocol (SMP) Framework is a notable
recent example.
The desire for small, self-selecting teams can also be seen in
the Research Task Force. IRTF members felt strongly that they had
conflicting pressures to make their committees open but to limit
participation to focus on problems.
The notion of small, self-selected design teams seems both useful
and inevitable. We take note of this effect and acknowledge its place
in the technical development process. The design team is defined as
being closed and self-selecting. The SMP Framework group is an
example of a design team. The MIME effort was largely the effort of a
few developers working closely together (and also collaborating well
with the working group who contributed a great deal to the process).
PAGE 10
Internet Draft Crocker and Malamud
Some of the IRTF groups function as design teams and have produced
valuable contributions ranging from IP multicasting to PEM.
Our proposal thus begins with a system of design teams and
working groups. In the traditional top-down approach in which leaders
set the agenda, a working group is formed with a problem to solve.
One or more design teams can go off and try to solve the problem. The
resulting solutions are brought before the working group, which
decides on the technical merits of the approaches and revises and
edits them until a rough consensus is reached.
Although design teams are self-selecting groups it is essential
that a working group must allow the proposals of all design teams to
be heard. If a substantial proposal is on the table, the working
group has an obligation to consider it. Any one design team may be
closed, but the working group must consider all competing proposals.
A design team does not have to be in response to a pre-existing
working group. If a group comes in with a substantial proposal to a
real problem, there is an obligation to form an open working group to
consider that proposal. The working group must give enough time to
other design teams to come up with alternative solutions to the
problem.
Working groups are collected under the umbrella of an area, which
has one or more (co-)chairs. We propose that long-term development
(the research or advanced development function) and a coherent
approach to development (the architecture function) are integral parts
of the development of standards. The current partition of
architecture to the IAB and research to the IRTF has made it hard to
move the results of advanced development into the engineering phases
of technology development. It has led to a situation in which some of
the best minds are no longer part of the day-to-day development of
solutions for the Internet.
We thus propose folding many of the architectural, research, and
engineering functions into an integrated Technical Task Force. All of
these functions are handled through working groups. The traditional
working group is the engineering working group, an open forum
chartered for a problem of limited scope which operates for a limited
duration.
A research working group is also an open forum, but operates for
a longer duration trying to solve a problem of limited scope. Note
PAGE 11
Internet Draft Crocker and Malamud
that to the extent that researchers wish to take a few people to try
and solve a problem, they may easily do so as a design team. The
working group is the open forum where the research results are
discussed and reviewed.
There are instances where this model may not match the current
IRTF structure. In particular, we distinguish between advanced
development efforts and true research programs. We use the term
research working group as a shorthand for advanced development
activities and recognize that true research may not fit in our
framework.
In particular, there are situations where researchers wish to
compare proposals in a closed setting out of a concern that their
ideas may be prematurely misinterpreted. We feel that such gatherings
have an important place in the development of technology, but might be
more appropriately provided by other portions of the Internet Society.
The Internet Society provides an important forum for this type of work
to take place, existing in proximity to the Technical Task Force
without necessarily having to exist within it. We feel that this is a
matter that the Internet Society should actively investigate in order
to provide a forum that preserves the many positive features of the
current IRTF.
The third type of group is the architectural working group which
operates for a longer duration, trying to solve a problem of broader
scope. Normally, an area will have one architectural working group,
but on occasion it may make sense for more than one to exist. It may
also be useful for two or more areas to share a single architectural
working group or for two architectural working groups in different
areas to work together on a specific topic.
The definition of three forms of working groups is not meant to
set definitions in stone. The key point is that a forum is provided
for people to try and determine the best solution for predefined
problems. The key is the problem to be solved and we describe three
forms of working groups only to emphasize that they can perform
functions in addition to the production of a standards-track
specification.
Working groups are collected into areas. The area is managed by
one or more area (co-)chairs. The area chair(s) may wish to form an
Area Advisory Group (AAG) which serves at the chairs' discretion. The
purpose of the AAG will differ by area. In some cases, the AAG will
PAGE 12
Internet Draft Crocker and Malamud
be a series of "deputy chairs." In other cases, the AAG will be a
place where senior members of the community can provide advice. We
feel it is inappropriate to decide the structure of these bodies as
the matter should be left to the discretion of the Area Chair and the
Technical Board.
The collection of area chairs acts as the governing body for
standards development and other technical aspects of the process. We
call this body the Technical Board. The Technical Board has a chair,
who is the leader of the Technical Task Force of the Internet. We
envision the chair of the Technical Board as being a different person
from the Area Chairs.
Members of the Technical Board would serve for two-year terms,
ensuring that the line management of the working groups is highly
responsive to the technical community. We also recognize the
tremendous time commitment by dedicated volunteers for these positions
and feel that two-year terms make it much easier to find talented
people to serve. We do not see a need for term limitations to prevent
a person from serving multiple terms.
We envision the definition of areas to be fluid, changing
according to the technical needs of the community. It is a crucial
part of our proposal that we continue to avoid the turf wars that
other standards bodies have found in standing, permanent committees.
We do not have those turf wars and we wish to retain this very
important feature of the IETF.
It is an important feature of our system that it is the working
groups that form the Technical Task Force and that area definitions
are simply a management tool. We do not split areas by some rigid
definition: some are layers in the protocol stack, some are functional
areas. We feel this fluid approach where all the working groups are
the Technical Task Force is crucial.
In addition to Area Chairs, the Technical Board would include
other positions. We recommend, for instance, that the formal position
of Architect be reinstituted. Such a position would provide a
valuable function of monitoring the cohesion of the architecture
across areas and providing the integrated architectural vision that is
so sorely needed for the Internet.
The Technical Board has overall responsibility for management of
the standards process. It is responsible for taking working group
PAGE 13
Internet Draft Crocker and Malamud
documents that have made it through an area and collectively deciding
on the standards status of that document. It is responsible for
developing objective criteria by which documents can be judged, then
applying those criteria to prospective standards.
We would hope that under such a system, the working group becomes
the focus of the Technical Task Force. We hope that members of the
leadership, ranging from trustees of the Internet Society to the
members of the Process and Technical Boards would take an active part
in working groups.
In summary, we propose a system of working groups and design
teams, collected together into an area. The collection of areas forms
the Technical Task Force of the Internet. It is the responsibility of
this Technical Task Force to develop technology, some of that
technology resulting in standards for the Internet.
3.2 Architectural and Process Guidelines
The best guarantee of due process is the establishment of a set
of objective criteria by which proposals may be judged. It would be
the obligation of the Technical Task Force to develop and make widely
known those criteria.
The IETF and IAB currently have a set of criteria for review, but
while great effort has been placed in the development of the 3-stage
Proposed, Draft, and Standard status for documents, we feel that not
enough attention has been placed on detailed, objective criteria for
review. While there are in fact some global criteria (e.g., running
code), we feel that it is necessary to have a much richer, detailed
body of literature that details our design decisions and our operating
procedures. This does not, however, mean that we must have a
complicated rule book or a bureaucratic straightjacket. Properly
formulated criteria can help move the system along and keep the focus
on technical quality.
Criteria for review are both technical and procedural. The
requirement that a working group presents a fair playing field that
allows multiple design teams to compete is an example of a due process
requirement. Another example is that if a design team forms
independently and comes up with a substantial proposal a working group
must be formed to review it.
PAGE 14
Internet Draft Crocker and Malamud
Many of the procedural requirements come to the very heart of
what makes us different from other standards-making bodies. Many of
these differences have not been brought out of the realm of collective
wisdom and unwritten understandings and made explicit. For example,
there is wide consensus that the Internet community makes standards
based on things that work. Running code, as David Clark has observed,
is the fundamental characteristic that makes the Internet different
from other standards-development organizations.
Running code as a principle is short-hand for a set of criteria
that have developed over time. For routing, for example, a protocol
must have three independent, interoperable implementations before
being considered as a standard. A more stringent version of the
requirement for interoperability would be to require a bakeoff with an
independent observer.
Another important criterion for review is that a new protocol
must not hurt the installed base. The Internet is a working, complex
system and it is widely acknowledged that the technical community has
an obligation to keep that system going. A criterion for review could
thus be published stating that any proposal that adds to an existing
protocol will receive increased scrutiny, and anything that changes an
existing protocol will receive even greater scrutiny.
Similarly, proposals that work at the infrastructural level of
the Internet are likely to require more careful review than those that
operate at the top level. Specifically, a message of the day protocol
that operates on a previously unused port should require a lower level
of review than a proposal to change the IP header definition.
Making these principles explicit means that there is a basis for
judging proposals. If one group advocates a politically correct
solution but has no code, the community can point to the requirements
and objectively decide against the political solution and for a more
technically-based decision. If a group complains that they have a
great idea that a working group ignored, we can point to the objective
requirements.
Procedural requirements go hand-in-hand with architectural
requirements. For the Internet, there is no grand architecture
against which all proposals can be measured. The architecture of the
Internet, as Vinton Cerf has pointed out, can frequently be found in
the protocols. Architectural cohesion consists of an examination of
PAGE 15
Internet Draft Crocker and Malamud
the nitty-gritty details of the individual specifications to see if
they match up.
We feel that there should be more architectural cohesion in the
Internet, hence the proposal to revise the position of Architect of
the Internet. However, there are also architectural principles
implicit in many IAB decisions. By pulling out those principles, we
can begin building a body of written decisions that make explicit our
assumptions.
In the examination of one specification for example, the IAB
discovered a text field in a header that did not specify the character
set to be used. Stating that text fields in headers must specify a
character set is an example of an architectural principle. By making
these principles explicit (and in writing), the community starts to
build up a set of objective criteria over time. We want to stress
that objective criteria do not mean a reversion to the bureaucratic
morass of other organizations: we can preserve and even enhance the
qualities that have made the Internet so successful.
The use of objective criteria, built on a case by case basis,
does not alleviate the need for coherent architectural vision. The
two go hand in hand, one providing a bottom up approach, the other a
top down design. We need both approaches for the Internet.
3.3 The Process Board
While we envision the Technical Task Force establishing
standards, there is a need for an independent body to guarantee that
the process works properly. We propose the formation of a Process
Board consisting of 5 members. Members of the Process Board are
selected by the membership of the Technical Task Force subject to
ratification or selection by the Internet Society trustees as
described below.
The Process Board has as its primary obligation preservation of
the integrity of the standards-making system. If an individual feels
that an action in the Technical Task Force has violated the
established procedures, the Process Board will hold a hearing on the
matter and render a decision in writing.
This review function of the Process Board is, we hope, something
that need not be exercised on a frequent basis. The Process Board
will not be making technical judgments. It will be judging if the
PAGE 16
Internet Draft Crocker and Malamud
objective technical and process requirements published by the
Technical Task Force have been observed in a specific instance.
There will be instances where there are insufficient objective
criteria to make a decision. In this case, the Process Board would
send the decision back to the Technical Board, directing it to make
explicit its criteria for decision. The Technical Board would, if the
criteria to be established are substantial enough, hold hearings to
determine what its policy should be.
For example, in examining a technical decision, if the Technical
Board had formed a closed group, the Process Board might have insisted
that a working group be formed to define a problem. If one technology
had been picked over another, the Process Board might have held
hearings on the number of interoperable implementations, whether the
working group had a chance to consider alternative solutions, or
whether there were concrete criteria established for picking one
solution over another. The Process Board could, in our view, even
look at a set of criteria and judge that they were not a technically-
adequate base for making a decision.
We envision this Process Board as having other functions related
to the integrity of mechanisms in the Technical Task Force. As
discussed below in the section on selection, there needs to be some
relationship between the Internet Society and the Task Force. We view
the Internet Society trustees as assisting in the selection of
membership of the Process Board, thus providing that link.
The Process Board, in turn, would, together with the membership
of the Technical Task Force, assist in the appointment of the Area
Chairs and other members of the Technical Board. The Process Board
would also be asked to ratify any reorganization of the Technical Task
Force into different areas.
In addition, the Process Board would have the responsibility for
establishing the high-level technical direction of negotiations with
other standards bodies. Much of the liaison with other bodies would
be at the working group level, but high-level issues would be handled
by the Process Board, based on the overall technical direction
established within the Technical Task Force.
For example, the Internet Society might wish to establish itself
as an international standards-making body under the provisions of the
International Telecommunication Union. The organizational
PAGE 17
Internet Draft Crocker and Malamud
relationship is a matter for decision by the trustees of the Internet
Society. Questions of detail at a single protocol are handled by the
working group. However, to the extent that we send a delegation to a
plenary of a group like the CCITT, we view the Process Board, as the
senior members of the technical community, representing us.
The Process Board should be constituted with fixed terms. We
recommend three-year terms, with the initial five appointments made
for staggered terms so that there is an opportunity to select one or
two members each year. We feel that this provides a balance between
the need for periodic change and the need for terms long enough to
give people the independence to make tough decisions.
3.4 The Editor
Dissemination of information is a crucial function of the
Internet, the Internet Society, and the Technical Task Force. The
Request for Comment (RFC) series is the bedrock of the process. The
RFCs have built over time and there is great public confusion over the
difference between the types of RFCs.
We feel that there is a need for a series of informational
documents for the community. If a group wishes to document some
technical function, for example, it should be able to do so and
publish that documentation into the public record without necessarily
submitting that information to a working group for approval. It is
important, however, to make sure that there is no confusion between
these informational documents and standards of the Technical Task
Force.
We recommend that the Internet Society trustees establish the
position of an independent Editor, That Editor is responsible for
preserving the integrity and independence of the publication process
and the maintenance of an on-line archive that contains standards
documents, informational documents, and the agenda, minutes, and
decisions of various bodies of the Internet Society. We do not
envision the position of Editor being responsible for production of
agendas, minutes, and decisions, but will be simply managing the forum
where these documents would be placed.
This on-line forum would be freely available to the general
public using, at a minimum, an e-mail based information server and
anonymous FTP. The Editor would be able to use any other methods of
dissemination that encouraged broad availability of the public record.
PAGE 18
Internet Draft Crocker and Malamud
The current funding for the position of Editor of the RFCs, for
the computers needed to disseminate information, and for the Internet
Assigned Numbers Authority is currently provided for by the U.S.
government. These activities take money and the Internet Society will
need to work with current funding sources or develop new ones to
provide continuity in these essential tasks.
Note that this Editor function would not be also responsible for
the publication of newsletters, journals, and other material of the
Internet Society. We are concerned here only that an independent,
technical person be appointed to supervise the publication of the
technical documentation of the Internet.
We also recommend that the function of the Internet Assigned
Numbers Authority (IANA) be undertaken by the Editor. The IANA
function is one of the more important examples of technical
information that must be maintained, and we believe it makes sense to
have this function also be part of the independent position of Editor.
In this report, we recommend the appointment of an independent,
technical Editor and that this appointment be for a three-year term.
We do not, however, address the area of organization of the
publications of the Technical Task Force. Specifically, we do not
address the question of the organization of the Request for Comment
series.
4. The Process
4.1 Selection of the Leadership
It is clear that the IETF membership wishes rough consensus to be
the grounds for decision-making and there is a clear consensus against
a voting process. Rough consensus is an inherently ambiguous process
and we believe that the question of how we select our leaders is one
of the most crucial elements of this proposal.
It is clear that a system of fixed terms is necessary and that
the selection of leaders should be with some form of consent by the
general membership. We note, however, that defining the membership of
the technical task force is difficult. We view the technology
development community as being anybody who is on the Internet and who
helps deploy solutions. Attendance at the IETF general meetings is
not a requirement, nor should it be.
PAGE 19
Internet Draft Crocker and Malamud
The IETF is a fluid body. As we change physical locations for
meetings, the makeup of attendees changes. As we begin to incorporate
video and audio broadcasts over the network into our meetings, the
definition of presence at a meeting becomes more ambiguous.
Finally,one of the big differences between our process and the more
traditional standards-making organizations is our emphasis on the use
of the network: a large travel budget is not a requirement for
participation.
The question thus becomes how do we balance the need for
accountability to the membership with the inherent difficulty in
deciding what that membership is? We find it useful to begin to break
the issue down into pieces.
In our system, there are three governing bodies that must be
selected:
o the Internet Society trustees
o the Process Board
o the Technical Board
We begin with the question of the trustees. There has been a
desire within the Internet Society to ensure the long-term viability
of the body through measures such as appointment of trustees during
the initial period of operation. While these concerns are
understandable, we feel that if Internet Society is to be viewed as a
legitimate body to house the Technical Task Force it is essential that
the democratic election of the leadership be clearly established in
the by-laws.
We propose that the by-laws require election of 1/3 of the
trustees every year by the membership. We feel that in an ideal world
that all trustees should be elected, but realize that the Internet
Society by-laws make such a change dependent on the unanimous consent
of all three of the Charter Members. Gaining such unanimous consent
may be politically unrealistic, but we do feel it crucial that the by-
laws require all other trustees to be elected.
In addition, there should be a method by which individual members
can nominate potential trustees, either through an open nomination
process or one that specifies 1% of the membership can sign a petition
to require placement of the individual on the ballot. Again, these
provisions are fundamental to the character and nature of an open
Internet Society and should be in the by-laws.
PAGE 20
Internet Draft Crocker and Malamud
One suggestion we have heard repeated several times has been that
the Internet Society should place all trustees up for election this
year with staggered terms. This approach is similar to the one that
was adopted by the Usenix board for its trustees. The effect would be
an immediate end to any perceived legitimacy problems and would allow
the Internet Society and the standards-making bodies to get on with
the technical challenges facing the Internet. We feel such a step is
not essential, and that there is merit in the stability of an
initially appointed board, but do strongly recommend immediate
election of one-third of the trustees and changes in the by-laws to
require elections and an open nominating procedure are absolutely
essential.
4.2 Selection of Technical Task Force Leadership
We now turn our attention to the selection of the governing
boards of the Technical Task Force. A wide variety of variants on the
rough consensus model have been suggested. We can break the problem
of selecting leadership into three parts:
o selection of a slate of nominees
o selection of one person for the position
o ratification of that selection
There needs to be some form of link between the technical task
force and the Internet Society. We propose that link be at the level
of the Process Board. There are two possible models (and infinite
variations) for how this might work.
In the first model, there is an open nomination process. The
trustees select the one of the nominees and the Technical Task Force
then ratifies that choice. Ratification of that choice would be
through the process of rough consensus. Rough consensus can mean
approval by rough consensus, or veto by rough consensus. Veto by
rough consensus might be taken to mean that (almost) everybody agrees
that the choice is bad, or it might use the standard that a
"substantial" number of objections constitutes a veto. We are well
aware of the ambiguity in the terms "consensus" and "substantial" and
return to that question below.
In the second model, the Technical Task Force prepares a slate of
a limited number of nominees. This slate is presented to the Internet
Society trustees, who make a selection. Note that it is possible that
PAGE 21
Internet Draft Crocker and Malamud
the number of nominees equals the number of positions, in which case
the Internet Society trustees would have been asked to ratify and not
select.
We are thus faced with a situation that must balance several
considerations. First, it is absolutely essential that the selection
process be objectively fair. Objectively fair means that we must be
able to walk into a litigation situation and demonstrate that the
Technical Task Force is not just a cartel formed to freeze out
outsiders or limit competition.
A second consideration is the desire for accountability to the
membership of the Technical Task Force in a way that avoids defining
membership. We wish to avoid gaming situations that allow one
organization to send many people to a particular meeting, or wait for
a particular meeting location to bring up a situation.
Rough consensus works well for approval or veto of a specific name,
but it is our opinion that this is not an adequate method of deciding
who to select.
The process of rough consensus for standards making consists of
looking a competing proposals and deciding how to proceed. While this
process of review and compromise works well for paper proposals, it is
very hard to modify people to reflect a consensus.
If the Technical Task Force wishes to select its leadership
directly, we recommend that objective criteria be established that
list qualifications for membership on the Process Board. A working
group would be then formed to select potential nominees and those
nominees would be presented to the membership at a plenary.
If there is no overwhelming consensus on one choice for a
position, we feel it essential that the Technical Task Force then
forward multiple names to the Internet Society trustees who would make
the final selection. If there is a clear consensus within the
Technical Task Force, then the trustees are merely asked to ratify the
selection.
We believe that the standard for selection must be that if a
substantial number of people object, there is no consensus and
multiple names must be forwarded. Any other procedure leaves us open
to charges of an ambiguous, unfair process.
PAGE 22
Internet Draft Crocker and Malamud
While selection of the Process Board involves the Internet
Society trustees, we view the selection of the Technical Board as
being a matter for decision solely within the technical community.
Again, we recommend a procedure whereby the membership of the
Technical Task Force attempt to forge a consensus for members of the
Technical Board and that the name is sent to the Process Board for
ratification. In the case of a lack of consensus, the Process Board
would select the members of the Technical Board from a slate
determined by the membership.
It is not clear that the use of rough consensus will scale
indefinitely. Rough consensus requires that an intervening group make
the selection and eventually it may be desirable to move towards
direct selection of the Process Board and the Technical Board by the
membership of the Technical Task Force.
Such a direct selection would require some form of voting.
Several proposals have been advanced, such as the requirement that a
person have attended n of the last m IETF meetings to be empowered to
vote. Another proposal has been that a person must be certified by a
board of their peers as to technical competence before being allowed
to vote or pass some other form of literacy test.
We defer the question of direct voting in this report, but point
out that the issue will probably need to be revisited. In addition,
we defer the question of "electronic attendees" as a matter that needs
to be worked out by the Technical Task Force. In both cases, however,
the Technical Task Force would be required to establish objective
criteria to preserve due process.
One other principle is worth mentioning. Rough consensus is an
inherently uncertain procedure. Somebody must decide if that
consensus exists. We envision the Chair of the Technical Task Force
making that decision, but there is the potential for abuse in such a
system. We propose that if 50 people sign (by electronic mail or on
paper) a petition protesting any decision of the Technical Task Force,
that the Process Board would hold a hearing on the decision to try and
determine if there were was truly a basis for deciding on rough
consensus.
To avoid ambiguity, the Technical Task Force will need to
establish as many concrete criteria for decision-making as possible.
This makes a determination of a consensus more easily verified. These
criteria hold for technical decisions as well as personnel decisions.
PAGE 23
Internet Draft Crocker and Malamud
Deciding that people in leadership roles should have certain
qualifications (e.g., Area Chairs should first have served as working
group chairs) will make decision making significantly simpler.
4.3 Openness as a General Principle
The Technical Task Force and the Internet Society are more than
just a professional society. We are a group that makes standards, and
must observe the due process requirements of open decision making
appropriate to such a governmental body.
We propose that a general set of principles be applied to all
meetings of the Technical Board, the Process Board, and the Internet
Society trustees. All meetings of these bodies should, as a general
rule, be open to observers, should have an agenda published 30 days in
advance, and should specify the location of the meeting.
In addition, we recommend that individuals be allowed to submit
written comments in advance on agenda items and that the chair of the
meeting be required to hear oral statements of a representative sample
of interested parties. We also recommend that meetings of all three
groups use, to the greatest extent possible, the Internet. For
example, we believe that it is now technically feasible to have
meetings of Internet bodies broadcast audio over the Multicast
Backbone (MBONE), enabling those the entire Internet to listen to the
process. Finally, we recommend that minutes of the meetings be posted
on the network within 30 days and that any decisions on substantive
matters be rendered in writing and posted.
While meetings of the governing boards must be open and conduct
their affairs in an open manner, we feel that it is equally important
that the rest of the Society also conduct its affairs in the light of
day. When committees are formed, there should be a call to the
membership for participation and an open process of selection. When
decisions are made or when budgets are decided, it is ultimately in
the interests of the Society and its parts to disclose such
information.
We do note that these general principles cannot be uniformly
applied to all situations. For example, the IESG currently conducts a
great deal of its work by electronic mail and teleconference and the
principle of openness needs to be balanced with the need for keeping
the process moving. In addition, there are situations, particularly
PAGE 24
Internet Draft Crocker and Malamud
relating to personnel matters, that may need to be dealt with in an
executive session.
We do not wish to determine which situations require modification
of the general principles of openness, but do feel that such
situations should be the exception, not the rule. When it is
necessary to hold a closed meeting, or one held without sufficient
notice, this should be a conscious exception to the principles of
openness.
5. Transition
This report proposes a sweeping set of changes that reorganize
the current bodies into a Technical Task Force, a Process Board, and
an Editor. All of these would be under the umbrella of the Internet
Society, but the Internet Society would underscore the importance of
principles such as open meetings and the election of officials by the
membership.
We believe that the first step is to see if there is a rough
consensus among the IETF that these steps would begin to solve the
problems that led to the formation of the POISED group. Consensus by
the POISED group and more generally in the IETF would be essential
preliminary steps.
To the extent that there appears to be a clear consensus at the
next IETF, a nomination working group could meet and make its initial
recommendations. These names would help give an air reality to these
proposals, making concrete the types of people that would fill the
positions.
The working group would be charged with establishing the initial
area definitions and the names of the people to fill the two-year
positions on the Technical Board. The working group would also
establish a set of staggered terms for the Process Board of one, two,
and three years and recommend names to fill those positions. The
names for both groups would be one person per slot if a consensus is
available, or multiple names if a consensus cannot be reached.
If accepted by the IETF, we propose that the recommendations and
the slate of names be submitted to the Internet Society trustees. We
believe that there are many ramifications of the changes here and hope
that the trustees would consider these steps at an open meeting where
PAGE 25
Internet Draft Crocker and Malamud
members of the IETF, the IESG, and the IAB are able to voice their
opinions.
If in fact there is agreement that the changes are appropriate
and the names selected are acceptable, we believe that these changes
could be in place as early as the Columbus IETF. This is a rapid
change, but we note that the major function of the IETF, the operation
of working groups, would not be disrupted. Transition from old bodies
to the new ones will certainly require careful coordination, but we
anticipate a substantial overlap in personnel making will make this
transition challenging yet workable.
Simultaneous with the appointment of the Process Board, the
Internet Society would have to consider changes in its by-laws.
Putting these changes up for an advisory vote by the membership would
be one way for the trustees to determine if there is substantial
support for the types of process changes we have recommended. Since
elections can proceed at the discretion of the trustees under the
current by-laws, one procedure would be to put trustees up for
election and add on that same ballot a referendum on the proposals
presented here.
A two-step transition is envisioned. At the November IETF, the
proposals are debated. During the next few months, the Internet
Society would ratify selections, modify by-laws, and hold elections.
At the next IETF, the changes would go into place.
We recognize that the transition schedule is aggressive. The
problems facing the community are serious and should be addressed.
However, our transition plan does depend on a strong consensus
emerging around the major details of the structural changes proposed.
To the extent that a consensus does not emerge the transition plan
should be extended.
We do not currently have a structural system in place in the
Internet standards-development bodies that allow change to occur
gracefully. Appointments have no fixed terms and there are no easy
procedures to make changes in process explicit. While quick adoption
of a new system may be a bit abrupt, we feel it is essential that we
rapidly move towards a system that institutionalizes change. Failure
to do so can only lead to another episode like IP version 7.
PAGE 26
Internet Draft Crocker and Malamud
6. Conclusion
We find that the Internet technical development process has
worked well for many years because of its focus on technical content.
Rigid separation between an Internet Architecture Board and the
technical committees of the IRTF and the IETF have diffused that focus
on technical content.
The creation of a Technical Task Force that streamlines the
operation of technology development would renew the technical focus
that we need. Concentration on working groups and design teams will
allow the talented engineers and researchers in the community to focus
on their work.
Process guarantees are absolutely essential in any standards-
development body. We find that open meetings with published agendas
and written decisions are a crucial element to the preservation of due
process. In addition, it is crucial that an explicit set of process
and architectural guidelines be developed and published to guide
future development, to help train new members of the community, and to
preserve a fair and neutral forum for the incorporation of new
technology.
These objective guidelines enhance the technical process. We
have the opportunity to explicitly state requirements such as working
code, thus making a clear, objective statement of how we differ from
other technology development organizations. Failure to focus on
principles such as working code mean that we continue a long slide
towards design by committee, complex bureaucracy, and all the other
negative aspects of other standards bodies. An explicit focus on
principles such as working code and rough consensus allow us to
clearly concentrate on what matters: the construction of a billion
node network and new ways to use that network.
Objective criteria are not enough. We need to have clearly
defined leadership positions with fixed terms. Those leadership
positions must be accountable to the general membership. Consent of
the governed has been the most persistent theme we have heard during
the tenure of this working group.
In the case of members of the Process Board and the Technical
Board, the membership of the Technical Task Force selects criteria for
its leadership and comes to a rough consensus on who the leaders might
be. If there is not rough consensus, then a set of potential nominees
PAGE 27
Internet Draft Crocker and Malamud
are selected. For members of the Process Board, the Internet Society
trustees either select or ratify members. In the case of the
Technical Board, the Process Board either selects or ratifies members.
In the case of the Internet Society trustees, we find it crucial
that the membership of that Society must select its leaders. The
Internet Society is ultimately only as good as its membership and we
must trust that membership to make wise decisions. We feel that
strong adherence to principles of accountability and openness will
allow the technical community to become an integral, active part of
the Internet Society.
There is one overriding goal in this proposal: allowing the
community to get back to the real problems facing us. We need a
system that can adapt easily to changing needs without the level of
gridlock we have found inherent in the current system. The current
system does not adapt well to needs for personnel changes, to needs
for structural changes, or to needs for changes in process.
We think it is important, indeed crucial, that these changes are
put into effect in a manner that preserves the parts of our system
that work. In particular, the Internet has many senior leaders who
have contributed immensely, both in the past and in the present. If
the changes we propose are to work, they will only work if we are able
to enlist those leaders. We cannot create a system where our best
talent does not want to participate.
Finally , we want to see a more flexible, streamlined structure
and more objective criteria for making decisions. We feel that these
changes will allow us to get back to the consideration of network
management that works, routing protocols that scale, a security
infrastructure that can be trusted, resource discovery techniques that
find information, and the thousands of other technical challenges that
face us.
7. Authors' Addresses
Steve Crocker Carl Malamud
Trusted Information Systems 302 W. Glendale Avenue
3060 Washington Road Alexandria, VA 22301
Glenwood, MD 21738 carl@malamud.com
crocker@tis.com
This Internet Draft expires May 1, 1993.
PAGE 28