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,,,, or 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

                                                                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

     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

     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

     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

     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

     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

     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

     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

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

     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

     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

     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

     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

     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

     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

     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

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

     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

     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

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

     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

     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

     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

     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

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

     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

     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

     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

     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      

This Internet Draft expires May 1, 1993.

                                                               PAGE 28