Internet DRAFT - draft-iab-advcomm


Network Working Group                                            AdvComm
Internet-Draft                                                      IETF
Expires: June 22, 2004                                 December 23, 2003

          The IETF in the Large:  Administration and Execution

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on June 22, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.


   In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB
   Advisory Committee (AdvComm), with a mandate to review the existing
   IETF administratuve structure and relationships (RFC-Editor, IETF
   Secretariat, IANA) and to propose changes to the IETF management
   process or structure to improve the overall functioning of the IETF.
   The AdvComm mandate did not include the standards process itself.

   This memo documents the AdvComm's findings and proposals.

AdvComm                   Expires June 22, 2004                 [Page 1]
Internet-Draft            draft-iab-advcomm-01             December 2003

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1   Overview of the AdvComm work process and output  . . . . . .  4
   1.2   Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.3   Next Steps . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.    Observations . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.1   Current IETF support structure . . . . . . . . . . . . . . .  5
   2.1.1 What the term IETF includes in this document . . . . . . . .  5
   2.1.2 Functions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.1.3 Support  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   2.2   Observed stress points . . . . . . . . . . . . . . . . . . .  9
   2.2.1 Stress points observed by IETF leadership  . . . . . . . . .  9
   2.2.2 Stress points observed by organizations supporting the IETF  10
   2.3   A final observation  . . . . . . . . . . . . . . . . . . . . 11
   3.    Stand Facing the Future:  Requirements for a successful
         IETF administration  . . . . . . . . . . . . . . . . . . . . 11
   3.1   Resource Management  . . . . . . . . . . . . . . . . . . . . 11
   3.1.1 Uniform Budgetary Responsibility . . . . . . . . . . . . . . 11
   3.1.2 Revenue source equivalence . . . . . . . . . . . . . . . . . 11
   3.1.3 Clarity in relationship with supporting organizations  . . . 12
   3.1.4 Flexibility in service provisioning  . . . . . . . . . . . . 12
   3.1.5 Administrative efficiency  . . . . . . . . . . . . . . . . . 12
   3.2   Stewardship  . . . . . . . . . . . . . . . . . . . . . . . . 12
   3.2.1 Accountability for change  . . . . . . . . . . . . . . . . . 12
   3.2.2 Persistence and accessibility of records . . . . . . . . . . 13
   3.3   Working environment  . . . . . . . . . . . . . . . . . . . . 13
   3.3.1 Service automation . . . . . . . . . . . . . . . . . . . . . 13
   3.3.2 Tools  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.    Advisory Committee Advice  . . . . . . . . . . . . . . . . . 14
   4.1   Proposed:  (single) formalized IETF organizational entity  . 14
   4.1.1 Comments on the necessity of this formalization  . . . . . . 15
   4.2   Possible structures  . . . . . . . . . . . . . . . . . . . . 15
   4.2.1 ISOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.2.2 ISOC Subsidiary  . . . . . . . . . . . . . . . . . . . . . . 16
   4.2.3 Completely autonomous organizational entity  . . . . . . . . 17
   4.3   Who can decide . . . . . . . . . . . . . . . . . . . . . . . 17
   5.    Security Considerations  . . . . . . . . . . . . . . . . . . 18
   6.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
   A.    IAB Advisory Committee Charter . . . . . . . . . . . . . . . 18
   B.    Input from the current IETF and IAB Chairs . . . . . . . . . 19
   C.    Consultation with ISI:  RFC-Editor . . . . . . . . . . . . . 21
   D.    Consultation with Foretec/CNRI:  Secretariat and Meeting
         Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 31
         References . . . . . . . . . . . . . . . . . . . . . . . . . 18
   E.    Consultation with ICANN:  IANA protocol parameter assignment 34
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 40

AdvComm                   Expires June 22, 2004                 [Page 2]
Internet-Draft            draft-iab-advcomm-01             December 2003

1. Introduction

   In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB
   Advisory Committee (AdvComm), with a mandate to review the existing
   IETF administratuve structure and relationships (RFC-Editor, IETF
   Secretariat, IANA) and to propose changes to the IETF management
   process or structure to improve the overall functioning of the IETF.
   This purpose was defined in the IAB Advisory Committee (AdvComm)
   charter, copied in Appendix A.  The AdvComm mandate did not include
   the standards process itself.

   The tangible output of this committee is a set of observations and
   recommendations for the IETF's executive structure - how the IETF
   might be organizationally (re)structured so that it can effectively
   and efficiently carry out its administrative activities.  As a
   necessary preamble to that, a description of the current issues and
   future requirements is presented.   The output does not represent any
   decision-making or implementation -- see Section 1.3 for a discussion
   of follow-on steps.

1.1 Overview of the AdvComm work process and output

   The AdvComm was formed in September 2003, and carried out its work
   over the course of the following 2 months, prior to the IETF58 in
   November of 2003.

   The AdvComm's membership included many of the individuals who are, or
   have been, volunteered to manage the IETF's inter-organization
   administrative relationships in recent years.  The first phase of the
   committee's work, therefore, included sharing and discussing the body
   of tacit knowledge about those relationships.  This included the
   input from the current IETF and IAB Chairs in Appendix B, and yielded
   the IETF organizational structure information in Section 2.1.

   The committee also sought input from the other end of the key
   existing administrative relationships (RFC-Editor, Secretariat, and
   IANA).  The output of those efforts is included in Appendix C,
   Appendix D, and Appendix E, and these were also used as the basis for
   the observations in Section 2.

   From these inputs, the committee drew together a list of requirements
   for successful future IETF administration, documented in Section 3.

   Finally, the committee put together some advice for how the IETF
   might consider reorganizing its administrative structure to meet
   those requirements moving forward -- Section 4.

AdvComm                   Expires June 22, 2004                 [Page 3]
Internet-Draft            draft-iab-advcomm-01             December 2003

1.2 Scope

   The AdvComm endeavored to stay focused on the IETF executive
   structure -- the collection of organizations that work together to
   bring the IETF's work to reality.  However, by virtue of the very
   fact that those relationships exist to get the work done, it was
   important to bear in mind the work being done in the IETF PROBLEM
   working group and IESG proposals for change, even as the committee
   endeavored not to infringe on the scope of those efforts.  The
   objective is that these observations and proposals should be relevant
   for today's IETF and any near-term evolutions that are deemed

1.3 Next Steps

   This documents the state of the AdvComm's thinking at the end of a
   two month process, and brings the currently-chartered work of the
   AdvComm to a close.

   Next steps include review of this material by the community, and
   specific proposals for action that will be put forward by the IAB and
   IETF Chairs.

2. Observations

2.1 Current IETF support structure

2.1.1 What the term IETF includes in this document

   RFC 3233 ([1]) provides a definition of the IETF, in terms of its
   work and its participation.

   This document discusses the collection of organizations that work
   together to support the effort described in RFC3233.  In this
   document, the term "IETF" explicitly includes the IESG, WGs, IAB,
   IRTF, and RGs.  This inclusive sense accords with considerable common
   usage of the term "IETF".  Formally, the IAB and IRTF are chartered
   independently of the IETF.  However, rather than coming up with a new
   term to encompass "the IETF and all its friends", the common usage is
   followed here.

2.1.2 Functions

   The work of the IETF is supported by a specific set of functions.  It
   is useful to distinguish between the functions and the organizations
   which provide those services, as outlined in the table below.  In
   some cases a single organization provides multiple services, but the
   functions are logically distinct.

AdvComm                   Expires June 22, 2004                 [Page 4]
Internet-Draft            draft-iab-advcomm-01             December 2003

      Function                Known as               Organization
                              (within the IETF)
      ---------               ----------------       ------------
      IESG Support            Secretariat            Foretec/CNRI
      IAB Support             ISOC/Secretariat       ISOC, Foretec/CNRI
      WG Support              Secretariat            Foretec/CNRI
      Community Support       Secretariat            Foretec/CNRI
      IETF Meetings           Secretariat            Foretec/CNRI
      RFC Publication         RFC-Editor             USC/ISI
      Standards Status Record RFC-Editor             USC/ISI
      Parameter Reg.          IANA                   ICANN
      Legal, insurance, etc   (largely invisible)    Provided by ISOC

   Table 1.  IETF functions, labels  and organizations

   In more detail, the functions can be broken down as follows:

      IESG Support

         IETF document tracking
         Working document management (mailing list, website, repository)

      IAB support

         Working document management (mailing list, website, repository)

      WG support

         Milestone tracking
         Workspace (website, mailing list)
         Working document archive (mailing list archives, document

      Community Support

         IETF mailing list
         I-D repository

      RFC Publication

AdvComm                   Expires June 22, 2004                 [Page 5]
Internet-Draft            draft-iab-advcomm-01             December 2003

         RFC editorial
         Document publication
         RFC repository management
         Official standards status record

      IETF Meetings

         Meeting Proceedings

      Protocol parameter registration

         Creation of registries
         Assignment of protocol parameters
         Management of accessible registry repository

      Legal, insurance, etc

         Legal support
         Liability insurance for IAB, IESG, WG chairs, etc

2.1.3 Support

   A presentation of the scope and depth of support that created the
   IETF and has allowed it to continue to contribute would require a
   discussion of history that is rich, vibrant, and completely beyond
   the scope of this document.  However, a very brief introduction to
   some of the current pillars is needed to understand where the IETF is

    ISOC:  Since 1992, ISOC has been the organizational home of the
      IETF.  This activity is part of its more general mission of
      serving as the international organization for global coordination
      and cooperation on the Internet, promoting and maintaining a broad
      spectrum of activities focused on the Internet's development,
      availability, and associated technologies.

    Foretec/CNRI:  The Corporation for National Research Initiatives
      (CNRI) was founded in 1986, and since 1987, CNRI has served the
      community by providing IETF Secretariat services.  Until the early
      1990s, CNRI provided legal assistance to the IETF and the IETF
      Secretariat.  After ISOC was founded, ISOC assumed overall legal
      responsibility for the substantive workings of the IETF including
      the efforts of the IETF chair, the IESG, the IAB, the area
      directors and the working group chairs.  CNRI assumed operational

AdvComm                   Expires June 22, 2004                 [Page 6]
Internet-Draft            draft-iab-advcomm-01             December 2003

      responsibility for the substantive workings of the IETF
      Secretariat.  In 1998, in order to decrease overhead costs on the
      activities, the Secretariat was reorganized placing Secretariat
      employees including the IETF Executive Director in a CNRI for-
      profit subsidiary (Foretec Seminars, Inc.).  Foretec was founded
      in 1997, in anticipation of the Secretariat becoming self-
      supporting.  CNRI and its subsidiary have continued to improve the
      operation of the Secretariat, as appropriate, and maintain a
      trained staff.

    USC/ISI:  The role of the RFC-Editor, and USC/ISI, is detailed in
      RFC2555.  The RFC document series is a set of technical and
      organizational notes about the Internet (originally the ARPANET),
      beginning in 1969.  For 30 years, the RFC-Editor was Jon Postel, a
      research scientist and manager in the Networking Division of the
      USC Information Sciences Institute (ISI), with the function
      gradually evolving into a team headed by him.  The RFC-Editor
      activity is currently organized as a project within ISI, using the
      ISI infrastructure, and supported by a contract with ISOC.  The
      RFC-Editor is the publisher of RFCs and is responsible for the
      final editorial review of the documents, as well as the
      maintenance of the online repository and index of those documents.

    ICANN:  The Internet Corporation for Assigned Names and Numbers
      (ICANN) is the non-profit corporation that was formed in 1998 to
      assume responsibility for the IP address space allocation,
      protocol parameter assignment, domain name system management, and
      root server system management functions previously performed under
      U.S.  Government contract by IANA (at ISI) and other entities.

   The support picture (who does what) can be described as follows:

      Secretariat at Foretec/CNRI

         IESG Support
         IAB Support (working document management)
         WG Support
         Community Support
         IETF meetings

      RFC Editor at USC/ISI

         [Supported by ISOC, based on a contract between USC/ISI and

         RFC publication Maintenance of standards status record


AdvComm                   Expires June 22, 2004                 [Page 7]
Internet-Draft            draft-iab-advcomm-01             December 2003

         [Relationship defined by Memorandum of Understanding: RFC2860]

         Protocol parameter registry


         IAB Support (Telechats)
         Funds RFC-Editor
         Misc IAB/IESG expenses
         Provides insurance for IAB, IESG, WG chairs, etc

   The available resources to support these activities are:

      Meeting fees -- through Foretec
      ISOC members' contributions for standards
      ICANN for IANA
      Volunteers/their employers (where applicable):

         IETF participants
         WG chairs
         Document editors
         IETF NomCom
         IAB ExecDir

2.2 Observed stress points

   The AdvComm noted several properties of the current IETF
   organizational environment that cause stress in the system.  These
   have been noted both from the point of view of the IETF leadership as
   well as that of organizations supporting the IETF.

2.2.1 Stress points observed by IETF leadership

   The current IETF funding and operational structure is dependent on
   IETF meeting attendance.  Therefore, the most obvious stressor that
   has emerged within the last two years is the decline in that
   attendance.    This trend, which has continued unabated, has resulted
   in a decline in IETF revenue (detailed in the IETF chair presentation
   at IETF 56 [2]), even as the requirements of the IETF operation are
   remaining constant or increasing.

   The result has been a budget deficit for operations which began in
   2002, and is forecasted to continue until at least 2004, even after a
   substantial increase in meeting fees.  The continuing deficits have
   depleted working capital, making the IETF less robust against

AdvComm                   Expires June 22, 2004                 [Page 8]
Internet-Draft            draft-iab-advcomm-01             December 2003

   potential future budgetary disappointments.

   The financial stress is real, but the IETF leadership has noted
   several other stressors that are impediments to finding and
   implementing solutions to the fiscal issues.  Some obvious solutions
   are not implementable in the current IETF structure.

   The rest of the stressors listed in this section should be understood
   as issues for which relief is necessary, particularly in the light of
   needing to properly address and implement solutions to the financial

   The current documentation of IETF processes and structure is, in
   places, vague about the distribution of responsibility for management
   and oversight of the IETF administrative relationships.  This makes
   it opaque to the IETF community, and sometimes leaves the leadership
   in a poor position to manage effectively.

   Additionally, the informality of the  relationships with some of the
   organizations that are carrying out key IETF functions compounds the
   problem of determining who has responsibility, and how IETF community
   consensus and desires are reflected in the activity.

   As a separate issue, important IETF institutional memory is recorded
   nowhere other than peoples' minds in many cases -- which requires
   significant transmission of oral history for IETF leadership
   transition to be effective.

   Apart from the institutional memory, other important IETF
   institutional records are spread across various organizations, and
   searching for the set of relevant documentation (especially when this
   is necessary long after the recording) can be challenging.

   Another stressor relates to the need to scale support processes in
   terms of reducing latency for mechanical processes.  That is, a
   decrease in the amount of manual labor required for the simpler tasks
   between the organizations, would make more resources available to
   focus on the special cases.  Lack of automation in the basic request
   services has been known to cause undue delay or failure in processing
   simple, routine tasks.  However, automation also requires resources
   and significant management in order to make sure it fulfills the
   community's requirements.

2.2.2 Stress points observed by organizations supporting the IETF

   Supporting organizations report difficulties in determining
   authoritative channels for directions -- either too many inputs, or
   no clear authority for resolution of change requests.

AdvComm                   Expires June 22, 2004                 [Page 9]
Internet-Draft            draft-iab-advcomm-01             December 2003

   In the absence of written agreements, supporting organizations may
   not be clear from whom to take direction.  Even where agreements
   exist, the authority to provide direction may not be clear.  The
   genesis of both problems is that the IETF relies on external bodies
   for support, but does not have sufficiently clear external
   relationships to allow it to provide input as to its requirements or
   direction on what services it desires.

2.3 A final observation

   This section attempts to capture a snapshot of the current state of
   the IETF organization, without undue fixation on the causes for
   arriving at the current state.  However, the it seems clear from the
   observations that the current state does not provide an adequate
   structure from which to reach into the future:  some changes are
   needed within the IETF administrative and executive structure.

3. Stand Facing the Future:  Requirements for a successful IETF

   This section follows the set of observations with a set of
   requirements for a properly-functioning IETF administrative
   structure.  These requirements are offered as the AdvComm's
   description of what the IETF needs, without addressing immediately
   the degree to which they are available with the current environment.
   That is, these are "requirements", not "requirements for change".

3.1 Resource Management

3.1.1 Uniform Budgetary Responsibility

   The IETF has operated in times of financial wealth and times of
   economic cutbacks in the industry.  It is reasonable to expect that
   the future holds similarly variable trends.  Therefore, it is
   important that the IETF organization has the ability to make the
   decisions to match its needs at a given point in time, i.e.,
   budgetary autonomy.  At this particular moment, there are hard
   choices to make, and the AdvComm believes that it is the IETF
   leadership, with the advice and consent of the IETF community, that
   needs to make them.

3.1.2 Revenue source equivalence

   The IETF is currently supported by money from multiple sources,
   including meeting fees, donations from interested corporate and non-
   corporate entities, and donations in kind of equipment or manpower.
   The IETF needs to be able to consider all sources of income, and all
   expenses involved in running the IETF, as pieces of one budget, to be

AdvComm                   Expires June 22, 2004                [Page 10]
Internet-Draft            draft-iab-advcomm-01             December 2003

   free to adjust all items on the occasions when the income from the
   different sources varies, and to allocate funds as reasonably

   The usual caveats apply:  that donations not threaten the
   independence of the IETF, and that donations are easier when they are
   tax deductible.

3.1.3 Clarity in relationship with supporting organizations

   While the IETF needs to be able to manage its revenue streams against
   its expense expectations, it also needs to respect the needs of
   supporting organizations to manage their own affairs.  That is, the
   text above does not suggest that the IETF should micromanage the
   financial affairs of supporting organizations.

   However, the very clear requirement is for clarity in the
   distribution of rights, responsibilities, and accountability in those
   relationships.  The usual mechanism for documenting such clarity is
   in contract form.  Thus, the IETF needs to have clear contractual
   relationships with the organizations supporting basic services,
   including meeting organization, secretarial services, IT services,

3.1.4 Flexibility in service provisioning

   The IETF needs to be able to raise money for, and fund the
   development of, additional services as appropriate.  This includes
   the development of tools for participants, repository management,

3.1.5 Administrative efficiency

   The IETF's needs should be met with the minimum of overhead.  This
   implies that there needs to be the possibility of combining work
   efforts where appropriate, and generally avoiding duplication of

3.2 Stewardship

   The requirements described below focus primarily on the needs of the
   IETF administration on a day-to-day basis.  However, responsible
   management includes stewardship for future IETF work.

3.2.1 Accountability for change

   The IETF needs to be responsible for changing its administrative
   structure to meet the community's evolving needs.  As such, the

AdvComm                   Expires June 22, 2004                [Page 11]
Internet-Draft            draft-iab-advcomm-01             December 2003

   administration needs to remain uniquely accountable to the IETF

   This also means that the distribution of responsibilities must be
   clear to the IETF community, in order to permit it to comment on
   current actions or future plans, and also to allow it to take action
   when its needs are not being adequately addressed.

   An implication of this is that responsibility for financial
   management within the IETF needs to sit with individuals who are
   accountable within the IETF organizational structure.

3.2.2 Persistence and accessibility of records

   Much of the work of the IETF is focused on reaching decisions and
   declaring closure.  However, responsibility does not stop with the
   declaration of completion.  There are any number of reasons that
   history must be adequately documented so that future work can review
   substantive records, and not rely on oral history.

   Therefore, the IETF needs to maintain and support the archiving of
   all of its working documents in a way that continues to be
   accessible, for all current and future IETF workers.

3.3 Working environment

   Part of the job of administering the IETF is identifying and ensuring
   the continued support of the tools and working environment necessary
   to support the ongoing activity.

3.3.1 Service automation

   Wherever human judgment is not required in order to complete an
   action, services should be automated to provide the most friction-
   free path and minimal delay in completing the action.

   More processes could be accomplished without requiring human judgment
   -- wherever possible, these should be identified, clarified, and

   Note that this is not intended to imply ALL processes should be
   automated!  Rather, by reducing the friction incurred in steps that
   are truly mechanical, more time and energy will be available to
   properly treat those that require individual judgment.

3.3.2 Tools

   Whether housed in an IETF-supported location or offered by individual

AdvComm                   Expires June 22, 2004                [Page 12]
Internet-Draft            draft-iab-advcomm-01             December 2003

   contribution, the PROBLEM WG has identified the need for more tool
   support for working groups and specification development.  The IETF
   needs to be able to identify, develop and support an adequately rich,
   consistent set of tools for getting the standards work done.

4. Advisory Committee Advice

   The Advisory Committee discussed the material and observations,
   described in this document, at great length.  To the AdvComm, it
   appeared clear that some level of IETF administration organizational
   change is needed to address the stressors and meet all of the
   requirements outlined in Section 3.

4.1 Proposed:  (single) formalized IETF organizational entity

   In order to ensure an IETF structure that is capable of meeting the
   requirements outlined above, the AdvComm recommends that the IETF be
   more formally organized.   This would allow the IETF to take full
   responsibility for, and management of, the resources required to
   accomplish its work (as described in Section 3.1), provide and
   maintain the necessary work environment for current work (as
   described in Section 3.3), and provide appropriate stewardship of the
   institutional information required for all aspects of current and
   future work of the organization (as described in Section 3.2).

   Some proposed models for establishing such a formalized effort are
   described in the following sections.  Some of the key expectations,
   irrespective of the final implementation of formalism, are:

   o  the administration of the IETF would remain accountable to the
      IETF leadership and community; the goal would be to ensure that
      lines of responsibility and accountability were clearer;

   o  this formalized IETF would be responsible for managing financial
      resources  (revenue and expenses) directly;

   o  this formalized IETF would be directly signatory to agreements
      with other organizations, and would therefore be able to negotiate
      and administer any appropriate contracts;

   o  however implemented, this would require a small staff complement
      (e.g., one full-time person) responsible to no other organization
      than the one chartered with the IETF's mission;

   o  nevertheless, it remains a non-goal to create an organizational
      entity that exists simply for the purpose of continuing to exist.
      This should be executed with the minimum formality needed in order
      to address the identified requirements.

AdvComm                   Expires June 22, 2004                [Page 13]
Internet-Draft            draft-iab-advcomm-01             December 2003

4.1.1 Comments on the necessity of this formalization

   An important question is:  what does this proposed formalization
   provide that cannot be provided by the status quo?  The AdvComm
   believes that an appropriately implemented formalization of the IETF
   would permit the unification of the resource management, decision
   making and stewardship that is imperative to providing clarity and
   ensuring a viable future for the IETF.  The AdvComm further believes
   that this is simply not possible to implement within the existing
   distributed and informal arrangement of responsibilities.

   Naturally, the act of forming such an organization does not
   immediately satisfy the requirements outlined in Section 3.  It is
   not a silver bullet.  Changing the formal structure will not, for
   example, change the financial status of the IETF.  However, the
   AdvComm believes it would provide the necessary basis from which the
   required decisions could be made and acted upon.

   In short, the AdvComm believes that we first have to place the
   responsibility for defining the IETF's administrative environment
   with specific people who are accountable to the IETF community.  Then
   these people can take the detailed decisions that will change the
   IETF's administrative environment to fulfill its requirements.

4.2 Possible structures

   Section 4.1 was deliberately vague on the nature of the formal
   organizational entity that might provide the proper environment,
   focusing instead on the key components of any implementation of such
   a formalization, and how the formalization activity would address the
   requirements laid out in Section 3.

   Having thus determined that formalization of the IETF is seen as a
   necessary step, the basic framework for 3 potential implementations
   of it are described below.  Note that these are not complete
   proposals, nor is enough detail available to recommend a particular
   path.  The IETF leadership might select one to explore in greater
   detail, to formulate an action proposal with sufficient detail to
   make a decision to act.

4.2.1 ISOC

   The IETF is organized as an activity of the Internet Society.  One
   potential path for increased formalism of the IETF's administration
   would be to further define that relationship.  This model anticipates
   dedication of ISOC personnel to form the "small staff complement",
   and would make ISOC responsible for all of the IETF's financial
   resources and expenses.

AdvComm                   Expires June 22, 2004                [Page 14]
Internet-Draft            draft-iab-advcomm-01             December 2003

   This approach should be relatively straightforward to implement,
   given ISOC's existing legal relationship with the IETF activity, and
   its status as signatory for IETF-related contracts (e.g., RFC-

   This proposal is consistent with the goal of minimizing the amount of
   formalization needed to meet the requirements of the IETF.

   However, the general mission of ISOC is broader than the
   standardization activity of the IETF, and the ISOC Board of Trustees
   must stay focused on apportioning resources to meet that broader
   mission.  Would this approach allow the clear lines of responsibility
   that are called for in Section 3?

4.2.2 ISOC Subsidiary

   A modification of the proposal of housing the IETF central body
   within ISOC is to create a legal not-for-profit subsidiary of ISOC,
   with a mandate that is specifically focused on the IETF's mission.
   This subsidiary would become the legal entity responsible for
   managing the IETF's resources and expenses, and would become
   signatory to any other legal instruments on the IETF's behalf.

   As a distinct legal entity in its own right, the subsidiary would be
   independently responsible for achieving its mission.  That level of
   independence addresses the concern raised against the notion of
   further formalizing the IETF within ISOC directly -- that the IETF
   mission might be disrupted by the organization's need to tend to
   other aspects of ISOC's broader mission.  The role of the IETF
   community, and the ISOC parent, in defining and supporting that
   mission would be spelled out in the creation of the legal body.

   The IETF might additionally consider what the most appropriate
   governance model would be for this approach.  If it is desirable to
   remove some of the administrative burden from the IESG and IAB, such
   a subsidiary might have its own Board of Trustees, composed of
   members appointed by IETF and ISOC.  Such a Board would be
   responsible for reviewing activities and ensuring that the
   organization's efforts were adequately in line with its mission, its
   finances were in order, and so on.  The subsidiary would report to
   its Board of Trustees.  Other governance models are certainly
   possible, and a Board of Trustees is not a requirement for this

   At the same time, as a subsidiary organization, the expectation is
   that the relationship with ISOC would remain a close one: the
   subsidiary would benefit from ISOC's existing infrastructure and
   support (a conservative approach to adding formalism and structural

AdvComm                   Expires June 22, 2004                [Page 15]
Internet-Draft            draft-iab-advcomm-01             December 2003

   overhead to the IETF activity), while the relationship would continue
   to provide a channel for the IETF to support ISOC in achieving that
   broader mission, with continued contribution of technical expertise
   and support of activities.

   This approach would require more work to create than simply housing
   the work at ISOC.   The subsidiary would have to be created and
   rights/responsibilities adjusted between it and ISOC in order to
   ensure that both have the necessary resources and frameworks to carry
   out their missions.

4.2.3 Completely autonomous organizational entity

   To complete the picture, a third option has to be considered.
   Instead of creating a subsidiary of ISOC as a separate legal entity,
   an entirely new legal entity, "IETF, Inc.", or "IETF, LLC", could be
   created for the sole purpose of managing IETF administrative

   This would offer the IETF complete autonomy with all the attendant
   rights and responsibilities.  In particular, an independent IETF
   would at a minimum, need to operate much like a startup for the first
   few years of its existence, with all the related financing and growth
   issues, and survival risks.  Given all the organizational change
   taking place within the IETF during the same period, the AdvComm
   believes that the financial and political risks of such an approach
   should not be under-estimated.

   For example, it would be necessary for the IETF to obtain initial
   working capital sufficient to handle the commitments for the first
   few meetings.  While it would be conceivable to raise working capital
   from advance meeting fees, such a financing plan would not leave much
   margin for error;  were one or more of the initial meetings to run in
   the red, the survival of a fledgling IETF could be in jeopardy.
   Given the economic environment, it probably should not be assumed
   that working capital could be raised purely from corporate donations,
   especially during an initial period in which staff required to
   solicit and manage donations would not be available.

   Additionally, the impact that such a move would have on ISOC's
   ability to carry out its mission  and the IETF's standing with
   governmental organizations needs to be considered.

4.3 Who can decide

   The AdvComm believes that the IETF leadership, acting with the advice
   and consent of the IETF community and ISOC, have the ability and the
   responsibility to act on the recommendation to formalize the IETF.

AdvComm                   Expires June 22, 2004                [Page 16]
Internet-Draft            draft-iab-advcomm-01             December 2003

5. Security Considerations

   This document does not describe any technical protocols and has no
   implications for network security.

6. Acknowledgements

   The AdvComm sincerely appreciates the time,  effort and care of the
   RFC-Editor, IANA, Secretariat and Secretariat organizations, in
   providing input, responding to the AdvComm's questions,  and
   reviewing/correcting the consultation text shown here in the


   [1]  Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, RFC
        3233, February 2002.

   [2]  Alvestrand, H., "IETF Chair plenary presentation, 03mar/slides/plenary-
        3/index.html", March 2003.

Author's Address

   Advisory Committee


Appendix A. IAB Advisory Committee Charter

   Date: Tue, 02 Sep 2003 16:34:58 -0400
   From: Leslie Daigle
   Subject: Formation of IAB Advisory Committee
   To: IETF-Announce: ;

   I would like to announce the formation of an IAB advisory
   committee, as described below.

   for the IAB.


   IAB Advisory Committee on IETF Administration Relationships

AdvComm                   Expires June 22, 2004                [Page 17]
Internet-Draft            draft-iab-advcomm-01             December 2003

   The purpose of the committee is to review the existing
   IETF administration relationships (RFC-Editor, IETF Secretariat,
   etc) and propose IETF management process or structural changes
   that would improve the overall functioning of the
   IETF. Any such proposal will be subject to review and
   acceptance by the IAB and IETF plenary. Note that the scope of the
   advisory committee does NOT include proposed changes to the standards
   development processes (e.g., WG organization, IESG management of
   documents or working groups, etc).

   The committee is chaired by the IAB Chair, Leslie Daigle, and
   consists of:

         o Bernard Aboba
         o Harald Alvestrand (IETF Chair)
         o Lynn St.Amour (ISOC President)
         o Fred Baker (Chair, ISOC Board of Trustees)
         o Brian Carpenter
         o Steve Crocker
         o Leslie Daigle (IAB Chair, chair of the committee)
         o Russ Housley
         o John Klensin

   Additional input is welcome. The committee will also make a particular
   effort to seek out further input as needed.

Appendix B. Input from the current IETF and IAB Chairs

   Input contributed by Harald Alvestrand (IETF Chair) and Leslie Daigle
   (IAB Chair).

   Looking at the administrative overview of the IETF activity,  there
   are a number of things that work well:

   o  support organizations are committed to the work of the IETF;

   o  the volunteers of the IETF WGs can (mostly) concentrate on their
      engineering work, not economics;

   o  money has (so far) been sufficient to cover the costs.

   However, there are also a number of challenges:

   o  lack of persistent records of the whole organization's efforts --
      of working documents, meeting materials, communications.  Also,

AdvComm                   Expires June 22, 2004                [Page 18]
Internet-Draft            draft-iab-advcomm-01             December 2003

      *  lack of organization of records -- even when data is stored, it
         can be hard or impossible to access when no longer current
         (e.g., it may reside on some former WG chair's hard drive)

      *  history records are kept spottily (lists of wg chairs and old
         versions of charters, to mention some);

   o  few safeguards against the "hit by a bus" problem -- much
      information about relationships is not documented, and must be
      transferred as oral tradition.  This means that significant
      overlap is needed when personnel changes;

   o  IETF leadership responsibilities are not clearly identified --
      typically handled by IETF and IAB Chairs, with some advice and
      consent from IESG and IAB, but that makes it possible to challenge
      every change decision;

   o  contracts do not clearly identify responsibility for executive
      direction.  Some contractual relationships are not documented, or
      are not visible to the IETF leadership;

   o  variable, and often unclear, documentation of responsibilities
      between IETF leadership and other organizations.  This makes it
      hard to determine how and where to discuss and effect improvements
      for the IETF that affect one or more support organization's

   o  unclear budgeting responsibilities -- the IETF leadership has to
      make decisions that will impact the revenues and costs of the
      supporting organizations, but the supporting organizations wear
      the direct effects of revenue and cost control.  Information about
      the financial impact of decisions are not available to IETF

   o  partitioned finances --  it's not possible for the IETF to make
      changes that would affect the balance of revenue and costs across
      the revenue sources/expense commitments.  E.g., raising meeting
      fees wouldn't pay for more RFC-Editor resources; more support from
      ISOC doesn't address any needs for IETF working group support

   o  the lack of clarity and the partitioning make it very hard for the
      IETF leadership, and the community as a whole, to determine points
      of accountability and implement changes for a healthy future.

AdvComm                   Expires June 22, 2004                [Page 19]
Internet-Draft            draft-iab-advcomm-01             December 2003

Appendix C. Consultation with ISI:  RFC-Editor

            Responses to Questions from IAB Advisory Committee
                          for the RFC Editor
                           October 6, 2003

    * (1) Your description of the function you are performing.   Is
    * that function, and its relationship to the IETF, adequately
    * described in RFC 2223bis, or is additional description
    * required?  If the latter, what would you suggest?


   A comprehensive summary of current RFC Editor functions is attached
   below. Note that this list has no direct relation to RFC2223bis, which
   contains instructions to RFC authors.

    * (2) What staff is being used to perform these functions and
    * what are their particular skills for doing so (either
    * individually or in the aggregate)?


   For 30 years, the RFC Editor was Jon Postel, a research scientist and
   manager in the Networking Division of the USC Information Sciences
   Institute (ISI).  It is currently organized as a project within ISI,
   using the ISI infrastructure.  The following ISI staff members comprise
   the RFC Editor project:

       Joyce Reynolds         100%
       Bob Braden              10%
       Aaron Falk              10%
       Sandy Ginoza           100%
       Project Assistant      100%
       Graduate Research Asst. 50%

   Braden and Reynolds jointly manage the RFC Editor project, with
   oversight of personnel and budgets.

   Joyce Reynolds has been contributing her editorial and management
   skills to the Internet since 1979.  She performed the IANA functions
   under Jon Postel's direction from 1983 until Postel's death in October

AdvComm                   Expires June 22, 2004                [Page 20]
Internet-Draft            draft-iab-advcomm-01             December 2003

   1998.  She continued to perform the IANA protocol parameter tasks on
   loan from ISI to ICANN, from 1998 to 2001.  She was IANA liaison to the
   IESG from 1998 to 2001, transitioning the role to Michelle Cotton in
   the 2001.

   Reynolds performed the RFC Editor functions under Jon Postel's
   direction from 1987 until 1998.  Reynolds has been a member of the IETF
   since 1988, and she served as User Services Area Director on the IESG
   for 10 years.  Reynolds now serves a liaison to the IAB and IESG.  She
   handles the final proofing and quality control on RFCs prior to

   Bob Braden has made many contributions to the Internet protocol
   technology and community.  He helped design TCP/IP during the original
   research period beginning in 1978, and he has devoted his professional
   career since 1978 to the Internet.  He served for 13 years on the
   original IAB and as its Executive Director for about 5 years.  Since
   1998 Braden has been co-leader of the RFC Editor project.  He is the
   principal reviewer of individual submissions.  He also works on
   technical issues related to the RFC Editor project.

   Aaron Falk is a significant player in the IETF as a Working Group
   chair, in the areas of transport protocols and satellite technology.
   On the RFC Editor team, he assists with policy questions and handles
   technical development, overseeing the work of the grad student

   Sandy Ginoza is the principal technical editor.  She is generally
   responsible for managing the RFC Editor queue and much of the
   day-to-day interface with the IESG and authors.  Ginoza sends and
   receives a LOT of email, and she plays a central role in the

   Two part-time Project Assistants, Mieke Van de Kamp and Alison de la
   Cruz, do editing, mark-up, and initial proofing of individual RFCs.
   Our goal is to have three pairs of eyes read every RFC word-for-word,
   and in most instances we are able to do so.

   A half-time USC Graduate Research Assistant provides programming
   support by developing, extending, and maintaining RFC Editor scripts
   and tools.

    * (3) What criteria do you use to determine whether you are being
    * successful, and how successful?  Using those criteria, how
    * successful are you and what could be done, especially from the
    * IETF side, to improve that evaluation?

AdvComm                   Expires June 22, 2004                [Page 21]
Internet-Draft            draft-iab-advcomm-01             December 2003


   We can begin with a historical perspective on this question.  When Jon
   Postel unexpectedly passed away 5 years ago, Reynolds and Braden took
   on the challenge of carrying on Postel's RFC Editor function.  The
   publication stream continued, with a modest increase in quantity and,
   we believe, no loss of quality.  Furthermore, the transition was
   largely invisible to the IETF.  In addition, the new RFC Editor project
   has significantly defined and clarified the publication process,
   improved the web site, added tools to improve productivity and quality,
   and adapted the procedures to changing realities.  We are proud of
   these achievements.

   The three primary axes for measuring RFC Editor success are (1)
   quantity, (2) quality, and (3) accessibility.

       1. Quantity

       Roughly, quantitative success means the ability to keep up with
       the submission rate.  Since the submission rate tends to be
       bursty, to avoid long delays we need an average capacity
       somewhat in excess of the average.

       RFC publication is necessarily a heavily labor-intensive process.

       Our goal is generally to complete the publication process in
       less than 4 weeks, exclusive of external factors beyond our
       control -- normative dependence upon other documents, delays by
       authors or the IESG, IANA delays, etc.

       2. Quality

       Publication quality is harder to measure, but "we know it when
       we see it."  Considering quality as the absence of faults, by
       noting faults we can observe lack of quality.

       One measure of faults is the number of errata that appear after
       publication.  In addition, there may be faults apparent to a
       reader, such as a meaningless title, confusing organization,
       useless Abstract, inadequate introduction, confusing
       formatting, bad sentences, or bad grammar.  There are of course
       limits to our ability to repair bad writing; ultimately,
       quality depends upon the authors as well as the editing

       The only way to maintain quality is to continually monitor our
       work internally, to track external complaints, and to adjust
       our practice to correct frequent faults.  Specific faults have

AdvComm                   Expires June 22, 2004                [Page 22]
Internet-Draft            draft-iab-advcomm-01             December 2003

       sometimes led us to create new tools for checking
       consistency, to avoid clerical errors.  Sometimes they have led
       to new user guidelines (e.g., on abbreviations or on Abstract

       3. Accessibility

       An important part of the RFC Editor function is to provide a
       database for locating relevant RFCs.  This is actually a very
       hard problem, because there is often a complex semantic web
       among RFCs on a particular topic.  We have made great
       improvements in our search engine and web site, but there is
       undoubtedly a need for more progress in this area.  The
       challenge is to provide better guideposts to users without
       creating a significant additional manpower requirement.

       We make heavy use of our own search and access tools, and this
       gives us feedback on their success and sometimes suggests

   Finally, we offer some specific suggestions to answer the question,
   "What can the IETF do to improve the RFC Editor's evaluation" (i.e., our
   service to the community)?

   1. Give us better documents to publish.  Many are well written and
     organized, but some are bad and a few are very bad and need a great
     deal of work to create acceptable publications.  Better input
     documents will improve both our quantity and our quality.

     The IESG has been making a large effort to improve the quality of
     Internet Drafts before they become RFCs, and we are very grateful
     for this.

     One issue of particular concern is the increasing number of RFCs
     authored by non-English speakers.  These can consume much extra
     editorial effort.  We don't know any solution to this problem, but
     we know that the IESG is aware of it and working with provide
     editorial assistance when necessary within working groups.

   2. Prepare a series of RFCs containing "road maps" that describe the
     semantic web of RFCs in a particular area.  Although these would
     rapidly become out-dated in detail, they would still provide very
     important guides to RFC readers.

   The RFC Editor is as self-critical as any organization could be, but we
   believe there is no objective basis for claiming that we are not doing
   a good job for the Internet.  We continually strive to do a better job.

AdvComm                   Expires June 22, 2004                [Page 23]
Internet-Draft            draft-iab-advcomm-01             December 2003

    * (4) How would you characterize the quality of your relationship
    * with the IETF and its leadership?  Is there mutual trust and a
    * sense of working together on issues, or do you and your
    * colleagues sometimes see the relationship as adversarial?


   The RFC Editor shares with much of the rest of the Internet community a
   deep desire to advance the technology and practice of the Internet.  We
   consider ourselves partners with the IETF, the IESG, and the IAB in
   this endeavor.

   Although the major goals coincide, the IESG and the RFC Editor quite
   properly have somewhat different priorities. The RFC Editor's role,
   historically and currently, is to create and maintain the RFC document
   series as a high-quality and vital channel for technical communication,
   while the IESG is concerned with managing the Internet engineering and
   standards process.  This difference sometimes leads to honest
   disagreements, but we have generally worked out mutually-satisfactory
   solutions to these conflicts.

   The word "adversarial" seems completely inappropriate, and we are
   struggling to understand what could have led to its appearance here.

    * (5) Are there specific known problems you would like us to look
    * at and understand?  If so, please describe them.


   (A) The length of time for IESG review and recommendations on individual
      submissions has sometimes become excessive.  We understand the load
      of IESG members, but we would like to ask their help in keeping
      response to a few months.

      The RFC Editor has been attempting to raise the bar on accepting
      individual submissions, to avoid wasting valuable IESG time as well
      as to maintain (or improve) the quality of the RFC series.

   (B) We would like understanding and support of the RFC Editor's statutory
      and historic responsibility to publish significant technical documents
      about networking that originate outside the IETF standards process.
      This publication has several important purposes.

       One is to bring out new technical ideas for consideration and
       discussion.  We believe that the future success of the Internet

AdvComm                   Expires June 22, 2004                [Page 24]
Internet-Draft            draft-iab-advcomm-01             December 2003

       demands an infusion of new ideas (or old ideas revitalized),
       and that the publication of such ideas as RFCs is important.

       Another purpose is to build a shared literature of mature
       technical discussion, to help avoid the periodic
       re-discussions that take place on our mailing lists.

       Finally, the RFC series provides a historic repository for
       important ideas.  We have come across a number of examples of
       important suggestions and partial technology developments that
       have been lost, or hard to locate, because they were not
       published as RFCs.  The community spends too much of our time
       re-inventing many, many wheels.

      Our ultimate goal is to publish more high-quality submissions, so
      we can raise the bar for publication.

      Independent submission publications represent only a minor
      fraction of the RFC production.  For example, so far in calendar
      2003 we have published 178 RFCs, including 14 independent submissions.
      If all the drafts that we think deserve to be preserved as RFCs were
      to be published, this fraction would grow, but we would not expect
      it to grow beyond 25% of the total number of published RFCs.

   (C) We would like to work with the IAB/IESG in re-examining the issue
      of normative references.  We believe that the current definition of
      normative is ambiguous and unclear, and that as a result some
      publications may be unnecessarily held up for normative references
      where these are unnecessary.

   (D) We would like to cooperate in an investigation of the issues in
      extending the character set beyond US-ASCII,.e.g., to UTF-8.  A
      major issue is whether there is a set of preparation, display, and
      searching tools for both the RFC Editor and the RFC consumers.
      These tools need to be ubiquitously available and mature enough.

   The RFC Editor is looking for input on how we can best continue to
   serve the community.  We are grateful for the suggestions we have
   received, and we have adopted as many of them as feasible; the
   result has been quite a long list of incremental improvements in
   our service over the past 5 years.

    * (6) How do you see the costs of your function evolving?  If
    * things become more costly over time, what are the main
    * determiners of cost (e.g., general inflation, general IETF
    * growth, increase in the number of particular functions you are

AdvComm                   Expires June 22, 2004                [Page 25]
Internet-Draft            draft-iab-advcomm-01             December 2003

    * carried out to perform,...).  Are you doing some things that
    * IETF (IESG or otherwise) request that you do not consider
    * cost-effective and, if so, what are they?


   The major cost factor is the number of documents submitted and
   published.  This has grown relatively slowly over time.  It appears to
   us that the IETF process has (perhaps fortunately) been the bottleneck
   that has kept the rate of RFC production from growing exponentially.
   We do not expect that to change dramatically.

   In more detail, the cost factors are:

       (a) Inflation (on salaries)

           This shows a small and predictable annual increase.

       (b) The number of RFCs published.

           This is the primary cost factor.  The bulk of the
           editorial and coordinating functions are directly
           attributable to specific documents.  At present,
           we estimate that this cost category represents
           70% of our personnel time, and 63% of our cost.

       (c) Tasks not directly related to specific RFCs.

           This includes many functions: management (budget and
           personnel as well as policy and procedure development),
           IETF liaison, reviews of independent submissions,
           development and maintenance of web pages, scripts, and
           tools, the RFC Online project, maintaining the Errata
           web page, etc.  These are currently estimated to
           require 30% of our personnel time, and 37% of our

   Minor extensions of function can be absorbed with little extra cost
   (but at a leisurely pace).  We are not proposing any major functional
   extensions at this time; such extensions would have to be costed
   separately (were money available for them.)

   Disk storage and web services are provided by ISI's support organization
   and are treated as overhead.  Most of the desktop machines used by the
   project were originally bought under research contracts, although the
   RFC Editor budget includes a very small item for equipment upgrades.

AdvComm                   Expires June 22, 2004                [Page 26]
Internet-Draft            draft-iab-advcomm-01             December 2003



   The RFC Editor edits and publishes the archival series of RFC
   (originally "Request for Comment") documents. The RFCs form an archival
   series of memos about computer communication and packet switching
   networks that records the technical history of the ARPAnet and the
   Internet, beginning in 1969. The RFC Editor is funded by the Internet
   Society and operates under the general direction of the IAB (Internet
   Architecture Board).

   The RFC Editor publishes RFCs and a master index of the RFC series
   electronically on the Internet, via all common access protocols
   (currently, the Web, email, rsync, and FTP). It announces the existence
   of each new RFC via electronic mail to one or more mailing lists. The
   RFC Editor maintains a comprehensive web site with a variety of tools
   and lists to locate and access RFCs.  This website also contains
   general information about RFC editorial policies, publication queue
   status, errata, and any other information that will make the RFC series
   more accessible and more useful.

   During the RFC editing process, the RFC Editor strives for quality,
   clarity, and consistency of style and format. Editorial guidelines and
   procedures to achieve these ends are established by the RFC Editor in
   consultation with the IAB and IESG (Internet Engineering Steering
   Group). The RFC Editor periodically publishes a revision of these its
   guidelines to authors.

   The RFC Editor coordinates closely with the IESG to carry out the
   Internet standards process as documented in the latest revision of "The
   Internet Standards Process" and later amendments.  The RFC Editor also
   coordinates closely with the Internet Assigned Numbers Authority
   (IANA), to ensure that the parameters used in new and revised protocol
   descriptions are properly registered.


   I. Editing and publishing RFCs

     (1) Publication process.

         The RFC Editor edits and publishes RFCs in accordance with RFC
         2026 (or replacement documents) and RFC 2223bis.  This includes
         the following tasks:

               (a) Performing the final editing of the documents to maintain
                   consistency of style, editorial standards, and clarity.

AdvComm                   Expires June 22, 2004                [Page 27]
Internet-Draft            draft-iab-advcomm-01             December 2003

            At minimum, the RFC Editor:

           (i) Copy-edits the documents, including the correction of
               spelling and grammar, and some checking for
               inconsistent notation.  Ambiguous sentences are
               resolved with the authors.

           (ii) Enforces the formatting rules of Section 3 of RFC

           (iii) Ensures that sections follow guidelines and rules
               of Section 4 of RFC 2223bis

           (iv) Verifies the consistency of references and
               citations, and verifies contents of references to RFCs
               and I-Ds.

           (v)  Verifies that all normative dependencies have been

           (vi) Verifies that guidelines from Section 2 of RFC 2223bis
               are followed, with respect to: URLs, titles,
               abbreviations, IANA Considerations, author
               lists, and Requirement-Level words.

                   (vii) Typesets the documents in the standard RFC style.

                  (viii) Verifies the correctness of published MIBs and
               ABNF fragments, using compilers.

         (b) Providing authors with a review period of no less than 48
             hours to approve the document.

         (c) Publishing new RFCs online by installing them in the official
          RFC archive, which is accessible via HTTP, FTP, and SMTP.
          The RFC Editor also provides compressed aggregate files of
          subsets of the complete RFC series, accessible via HTTP and
          FTP. PDF facsimiles are also maintained for all .txt RFCs.

         (d) Publicly announcing the availability of new RFCs via a
             mailing list.

         (e) Coordinating with the IANA for assignment of protocol
          parameter values for RFCs in the submission queue.

         (f) Coordinating closely with the IESG to ensure that the rules
          of RFC 2026 (or replacement) are followed.  RFC Editor
          personnel attend IETF meetings.  A designated RFC Editor

AdvComm                   Expires June 22, 2004                [Page 28]
Internet-Draft            draft-iab-advcomm-01             December 2003

          person serves as liaison to the IAB and IESG.

    (2) Individual Submission Publication

       The RFC Editor publishes technically competent and useful
       documents that arise outside the IETF process, in accordance
       with RFC 2026.  The RFC Editor makes the final determination on
       the publishability of such documents, with review by the IESG
       and input from knowledgeable persons.

       The RFC Editor reviews all such documents for acceptable
       editorial quality and for content, and works with the authors
       when necessary to raise the quality to an acceptable level.

    (3) Online RFC meta-information

         The RFC editor publishes the following status information via
         the Web and FTP.

         (a) A list of all RFCs currently published, including complete
             bibliographic information and document status. This list
             is published both in human and machine-readable (XML)

         (b) A document consisting of summaries of RFCs in each range of 100.

         (c) A list of errors found in published RFCs.

         (d) An "RFC Editor Queue" specifying the stage of every document
             in the process of editing, review, and publication.

         (e) An RFC Editor web site containing
               (i)   A search engine for RFCs.
              (ii)   Information on the RFC publication process.
             (iii)   Links to the above published items.

     (4) Public Queries

       Responding to, and when appropriate, redirecting, a wide range of
       email queries received in the RFC Editor mailbox.

   II. Improved Process and Infrastructure

     When resources allow, the RFC Editor makes improvements to its
     processes and to the RFC repository infrastructure.  This includes
     improvements and extensions to the set of scripts used by the RFC
     Editor: (i) to maintain its databases and web pages, and (ii) to

AdvComm                   Expires June 22, 2004                [Page 29]
Internet-Draft            draft-iab-advcomm-01             December 2003

     increase the efficiency and quality of the editing process.

     Changes in procedure are often suggested by IETF members as well as
     by the IESG.  Here are some examples of changes that are either in
     process or have been suggested for possible action in the future.

     (1) Publication process

       (a) Accepting documents in XML encoding when there
           is an accompanying tool that will produce nroff markup.

       (b) Studying the feasibility of editing the XML form of
           submitted documents, prior to producing the final nroff
           and .txt versions.

       (c) Adopting additional tools for verifying formal
           specification languages used in RFCs in addition to
           MIBs, PIBs, and ABNF.

      (2) Database Accessibility and Quality

       (d) Improving the usefulness of the Errata information
           (i) Distinguish mere typographic errors from
                    errors of substance
           (ii) Link errata to RFC index on web page.

       (e) Providing Web-based "enhanced" views of RFCs, including:

           (i)   Links to other related RFCs and references.
           (ii)  Links to and from online errata pages.

      (3) Maintaining an online repository of the corrected values
       of MIBs that have been published in

      (4) Completing the RFC Online project, to bring online those
       early RFCs that are available only in paper form.

Appendix D. Consultation with Foretec/CNRI:  Secretariat and Meeting

               Secretariat Responses to Questions from
                     IAB Advisory Committee

AdvComm                   Expires June 22, 2004                [Page 30]
Internet-Draft            draft-iab-advcomm-01             December 2003

                        November 7, 2003

   * (1) Your description of the function you are performing.
   * Is that function, and its relationship to the IETF, adequately
   * understood for working purposes, or is additional description
   * required?  If the latter, what would you suggest?

   The Secretariat work is divided into four parts: Meeting Planning,
   WG support, IESG support, and IETF Community support.

   IETF meeting planning includes: identifying venues; negotiating
   contracts; working closely with the WG chairs and the IESG to
   schedule events and avoid conflicts; preparing the agendas
   for the WG sessions; arranging for F&B and AV; handling
   registration; seeking and signing up hosts; providing Internet
   access, a terminal room, and a wireless network when a host is not
   available; providing on-site support; and preparing the proceedings.
   Meeting planning also may include organizing the IESG retreat.

   WG support includes: maintaining and updating charters, milestones,
   and other information for the 140+ WGs; tracking changes in chairs;
   hosting and archiving the discussion mailing lists; and processing
   requests to publish IDs as RFCs.

   IESG support includes: providing all support required for IESG
   teleconferences, which take place every two weeks and cover as many
   as 20+ documents each (i.e., processing "Last Calls", preparing the
   agenda and package, moderating the teleconference, preparing the
   minutes, sending out approval announcements, and updating the
   information in the ID Tracker); tracking the movement of I-Ds to RFCs;
   interfacing with the RFC Editor; performing administrative functions
   associated with WG creation, rechartering, and closing; maintaining
   the internal IESG Web pages; sending miscellaneous message to the
   IETF announcement list on behalf of the IESG, and posting them to the
   Web site, where applicable (e.g., appeals to the IESG and IESG
   responses to appeals); providing support to the NomCom, as needed
   (i.e., sending announcements, hosting/updating the Web site,
   arranging for conference calls); and developing Web-based tools to
   support IESG decision-making.

   IETF Community support includes: running the IETF meetings; hosting
   the IETF Web site, and keeping the web site it up to date; hosting the
   IETF announcement and discussion lists; responding to enquiries sent
   to the IETF Secretariat, the Executive Director, the meeting Registrar,
   the Webmaster, and the trouble-ticket systems; processing Intellectual
   Property Rights Notices; processing Liaison Statements; and posting

AdvComm                   Expires June 22, 2004                [Page 31]
Internet-Draft            draft-iab-advcomm-01             December 2003


   * (2) What staff is being used to perform these functions and
   * what are their particular skills for doing so (either
   * individually or in the aggregate)?

     -- Three people perform administrative functions.
     -- Four-and-a-half people perform technical support.
     -- One-and-a-half people do development.
     -- Three people do maintenance.

   * (3) What criteria do you use to determine whether you are being
   * successful, and how successful?  Using those criteria, how
   * successful are you and what could be done, especially from the
   * IETF side, to improve that evaluation?

   The continued efficient operation and evolution of the Internet is one
   important goal and challenge facing the IETF, and also the IETF
   Secretariat. Working together to assist the IETF in performing this
   important function has been a motivating factor in CNRI's support for
   almost 15 years. The criteria followed by CNRI, and (more recently)
   its subsidiary Foretec, in their efforts on behalf of the entire
   Internet community is to provide a consistent and dependable mechanism
   that enables those persons interested in the many and varied issues
   that are raised within the IETF to perform their important work in the
   Internet standards process unburdened by the routine administrative
   tasks associated with such endeavors. While I think this has been a
   successful activity over many years, there is always room for
   improvement; and a continuing dialogue between CNRI, ISOC, and the IETF
   leadership is useful for this purpose. High on my list of suggestions
   would be finding a way to increase the funds available to meet the
   increasing demands placed on the Secretariat. We can no longer depend
   only on attendance fees at meetings for this purpose.

   * (4) How would you characterize the quality of your relationship
   * with the IETF and its leadership?  Is there mutual trust and a
   * sense of working together on issues, or do you and your
   * colleagues sometimes see the relationship as adversarial?

   While the Foretec management may have issues arising from day to day
   workflow demands on limited resources, CNRI values the trusted
   relationship we have had with the IETF community.    The issue is
   cooperating in the development of new funding sources, and learning to
   live within the available resources. There is also an issue about

AdvComm                   Expires June 22, 2004                [Page 32]
Internet-Draft            draft-iab-advcomm-01             December 2003

   effective lines of authority for the purpose of carrying out certain
   aspects of the overall standards process. There are many demands and
   pressures on the IESG and hence on the Secretariat. These workflow
   demands need to be addressed in a more systematic way for the benefit
   of all.

   * (5) Are there specific known problems you would like us to look
   * at and understand?  If so, please describe them.

   Workload is high. Given the budgetary constraints that the Secretariat
   is under, there are no resources to take on additional work.  The
   staff supporting all areas are working overtime just to keep up with
   the current workload.

   The Secretariat does not believe that the IETF Community appreciates
   the scope of the tasks. The Secretariat is automating more tasks,
   hopefully reducing the overall workload. There is a long queue of
   requests for new features in the tools that the Secretariat has built.
   There is not money to hire more developers. The IETF Executive Director
   is documenting processes. This has naturally caused discussion about
   whether the processes are what everyone wants the processes to be.
   While expected, it also increases workload.

   * (6) How do you see the costs of your function evolving?  If
   * things become more costly over time, what are the main
   * determiners of cost (e.g., general inflation, general IETF
   * growth, increase in the number of particular functions you are
   * carried out to perform,...).  Are you doing some things that
   * IETF (IESG or otherwise) request that you do not consider
   * cost-effective and, if so, what are they?

   The total budget for IETF-related activities at Foretec last year was
   about $2.5M. The vast bulk was covered by IETF meeting fees, but the
   shortfall was covered by contributions from CNRI and Foretec.

   CNRI has been asked by its Board to find a solution to the problem.

Appendix E. Consultation with ICANN:  IANA protocol parameter assignment

AdvComm                   Expires June 22, 2004                [Page 33]
Internet-Draft            draft-iab-advcomm-01             December 2003

            Responses to Questions from IAB Advisory Committee
           for the IANA Protocol Parameter Assignment Function

                       November 7, 2003

   * (1) Your description of the function you are performing.   Is that
   * function, and its relationship to the IETF, adequately described in
   * RFC 2860 (the MOU) and RFC 2434 (Guidelines for IANA considerations),
   * or is additional description required?  If the latter, what would
   * you suggest?

   Per Michelle [Cotton, IANA], RFC 2860 probably remains sufficient as
   an MOU describing the functions that the IANA provides to the IETF.
   That office consists of, effective soon, a manager, three technical
   clerical staff (four full-time equivalents) plus half a dozen people
   on a consulting basis, performing functions for the IETF and the RIRs.
   The portion of that effort supporting IETF parameter assignment is
   roughly a full-time-equivalent plus software support and normal
   management/employment overheads. Fundamentally, the IETF parameter
   assignment function consists of accepting requests for protocol
   numbers for extensible protocols (such as IP Protocol, PPP PID, TCP/UDP
   Port, and the like), validating them according to business rules,
   identifying the appropriate registry, and in some cases portion of a
   registry, assigning the number, and documenting the result.

   RFC 2434 has served the IANA staff well as a guide, but is now in need
   of updating. Specific concerns with the document relate to the meaning
   of terms and the specificity of the information provided to the IANA in
   internet drafts.

   One issue relates to the meaning of the term "IETF consensus". When a
   document has passed through a defined consensus process, such as a
   working group, this is straightforward. When requests come to IANA that
   have not done so, IANA needs specific guidance on IETF expectations.
   This generally comes in the form of AD direction or consulting advice.
   An improved process would help, though; business rules that inform the
   IANA when a new registry is appropriate, and what rules should be
   applied in assignment of values in any given registry, for example,
   would help.

   Parameter assignment being an essentially clerical function, specific
   guidance to the clerical staff is absolutely mandatory, and often
   lacking or unclear. In IANA's dreams, every internet draft would
   contain an IANA Considerations section, even if all it said was
   "IANA need not concern itself with this draft". In the absence of such
   a statement, the IESG's IANA Liaison is forced to read the entire
   document at least twice: once when the IESG is first handed the

AdvComm                   Expires June 22, 2004                [Page 34]
Internet-Draft            draft-iab-advcomm-01             December 2003

   document, to ensure that any instructions to IANA are clear, and again
   when the IESG hands the document on, to ensure that it can perform the
   requests the draft makes. This is clearly time-consuming and prone to

   IANA is now receiving a certain level of instruction in internet drafts,
   which is good. However, even the present level of advice is frequently
   lacking in clarity. For example, a PPP NCP definition might well
   require the assignment of two PIDs, one for the data exchange and one
   for the NCP itself. These two numbers come from four very separate
   ranges: 0001..00FF, 0101..7FFF, 8001..BFFF, and C001..FFFF. The choice
   of range is important, especially on low speed lines using
   byte-oriented asynchronous transmission, as the data assignment has a
   trade-off implied for the relative frequency of messages using the
   specified protocol, and the control function PIDs are partitioned as
   well. In such a case, IANA needs to know not that "two PIDs are
   required", but that "two PPP PIDs are required, the data PID named
   <d-name$gt; defined in section <> from the range 0001..00FF, and the
   control PID named <c-name$gt; defined in section <> from
   the range 8001..BFFF".

   Descriptions of registries to be designed need to be equally clear. If
   the specification says in its IANA Considerations section that "a
   registry named 'Fubar Code Points' should be built; the initial values
   in a table <name> and IANA may assign additional values in any
   remaining value between the last initial code point and 65535", that
   is exactly what will happen. If there are additional expectations,
   such as "the working group's assigned number advisor will be asked"
   or "all assignments must be made in an RFC of informational or
   standard status", they won't necessarily be met - unless the IANA
   Considerations section specifies as much. What you put in the IANA
   Considerations section is what will be followed.  It should be made
   clear so that the implementors get what they requested.  Also, clear
   IANA Considerations sections also help the community, not only IANA.
   It makes (1) the authors think about all aspects of the creation of a
   registry and instructions on how to maintain but also (2) the public
   knows and understands the new registry instructions and how they can
   get assignments/registrations in that registry.

   Something that would materially help the IANA in its evaluation of
   internet drafts is a comment tracking system on the IETF side. The
   IANA's use of such a system is apparent: any comments it makes on the
   draft would appear in the system, where the IESG may readily retrieve
   them, and the IANA can find its comments when the draft later comes
   there. To be truly helpful, it should also include at least any last
   call IETF commentary and AD commentary, including agreed changes to
   the document. This would permit IANA to review those notes as well,
   which may in turn elicit further IANA commentary ("if you make that

AdvComm                   Expires June 22, 2004                [Page 35]
Internet-Draft            draft-iab-advcomm-01             December 2003

   change, you should also specify <> in the IANA Considerations section")
   or may guide IANA's implementation.

   Normative references apply to IANA considerations as well as to other
   parts of the specification. Recently, the IESG started passing
   documents along prior to other documents normative for them, allowing
   them to sit in later queues to synchronize with their normative
   documents. In the special case where the normative document defines a
   registry and the draft under discussion assigns a value from that
   registry, this case needs to be handled in queue and in process like
   any other normative reference.

   * (2) What staff is being used to perform these functions and what
   * are their particular skills for doing so (either individually or
   * in the aggregate)?

   The staff assigned to this function, on 4 November 2003, includes
   Michelle Cotton and an assistant. They are essentially intelligent
   clerical staff familiar with computer back office applications, but
   otherwise with no special technical training. For technical questions,
   they depend heavily on advisors within IANA or assigned by the IETF.

   It should be kept in mind that it is not the IANA's job to understand
   how every protocol works that is being defined in a new registry.  The
   IANA needs to know how to create and maintain the registry

   * (3) What criteria do you use to determine whether you are being
   * successful, and how successful?  Using those criteria, how
   * successful are you and what could be done, especially from the IETF
   * side, to improve that evaluation?

   The basic measure of success is the number of assignments made.

   Michelle's sense is that IANA is now moderately successful, however
   further improvement can be made internally and externally.

   Paul is defining web-based automation which should help various
   aspects of IANA's work, including in part the IETF IANA function.
   Michelle believes that this automation will materially help her
   timeliness. But for that to be carried out properly, clear business
   guidelines must be given IANA for each of the existing registries,

AdvComm                   Expires June 22, 2004                [Page 36]
Internet-Draft            draft-iab-advcomm-01             December 2003

   guidelines whose application can be readily automated. This is likely
   an IETF effort, or at least requires serious IETF input.

   * (4) How would you characterize the quality of your relationship with
   * the IETF and its leadership?  Is there mutual trust and a sense of
   * working together on issues, or do you and your colleagues sometimes
   * see the relationship as adversarial?

   At this point, Michelle feels that IETF/IAB leadership is friendly and
   generally constructive. She is very cognizant of AD workload, and as
   such tries to focus questions and find other people to ask them of. As
   such, she perceives the communication level and volume to be on the
   light side of "about right".

   Again, amplified clarity of IESG/WG policy would reduce her question
   load, and there may be utility for an IAB liaison from the IANA such as
   IANA has with the IESG. That is really a question for the IAB; if it
   has questions for IANA, the chair should feel free to invite her
   comment or invite a liaison.

   * (5) Are there specific known problems you would like us to look at
   * and understand?  If so, please describe them.

   This note has made a point concerning clarity of instructions, clarity
   of policy, and clarity of registries. There is ongoing work at IANA to
   clean up registry files inherited when IANA was split out from the RFC
   Editor's office; in dealing with the business considerations questions
   already raised, it may be helpful for a tiger team from the IETF to
   review their registries with them and make suggestions.

   There is an ongoing problem with receiving announcements concerning at
   least some internet drafts. Michelle plans to follow up with the
   Secretariat on this, but in short it appears that the IANA liaison is
   not copied on at least some list that internet draft actions are
   announced on. This seems to pertain to individual submissions that the
   IESG advises the RFC Editor that it "has no problem" publishing.

   * (6) How do you see the costs of your function evolving?  If things
   * become more costly over time, what are the main determiners of cost
   * (e.g., general inflation, general IETF growth, increase in the number
   * of >particular functions you are carried out to perform,...).  Are you
   * doing some things that IETF (IESG or otherwise) request that you do
   * not consider cost-effective and, if so, what are they?

AdvComm                   Expires June 22, 2004                [Page 37]
Internet-Draft            draft-iab-advcomm-01             December 2003

   As detailed, the function described in RFC 2860 represents approximately
   a person-equivalent, plus facilities, software support, and standard
   business loading. This has been the approximate load level for at
   least the past five years, and is projected to remain about the same
   for the near future. The cost-effectiveness issues revolve around
   human-in-the-loop effort involved in reading drafts, investigating
   inquiries, and such that have been detailed here. The sense is that an
   effective comment management system plus the work flow systems ICANN
   is planning to implement should result in a net near term improvement
   in efficiency and timeliness; projected IETF growth should then
   consume that improvement over time.

AdvComm                   Expires June 22, 2004                [Page 38]
Internet-Draft            draft-iab-advcomm-01             December 2003

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

AdvComm                   Expires June 22, 2004                [Page 39]