Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


Network Working Group IAB Advisory Committee Request for Comments: 3716 IETF Category: Informational March 2004

        The IETF in the Large:  Administration and Execution

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

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


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

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Overview of the AdvComm Work Process and Output. . . .  3
     1.2.  Scope. . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  Next Steps . . . . . . . . . . . . . . . . . . . . . .  4
 2.  Observations . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Current IETF Support Structure . . . . . . . . . . . .  4
           2.1.1.  What the Term IETF Includes in this Document .  4
           2.1.2.  Functions. . . . . . . . . . . . . . . . . . .  4
           2.1.3.  Support. . . . . . . . . . . . . . . . . . . .  6
     2.2.  Observed Stress Points . . . . . . . . . . . . . . . .  8
           2.2.1.  Stress Points Observed by IETF Leadership. . .  8
           2.2.2.  Stress Points Observed by Organizations
                   Supporting the IETF. . . . . . . . . . . . . . 10
     2.3.  A final Observation. . . . . . . . . . . . . . . . . . 10
 3.  Stand Facing the Future:  Requirements for a Successful
     IETF Administration. . . . . . . . . . . . . . . . . . . . . 10
     3.1.  Resource Management. . . . . . . . . . . . . . . . . . 10
           3.1.1.  Uniform Budgetary Responsibility . . . . . . . 10

IAB Advisory Committee Informational [Page 1] RFC 3716 The IETF: Administration and Execution March 2004

           3.1.2.  Revenue Source Equivalence . . . . . . . . . . 11
           3.1.3.  Clarity in Relationship with Supporting
                   Organizations. . . . . . . . . . . . . . . . . 11
           3.1.4.  Flexibility in Service Provisioning. . . . . . 11
           3.1.5.  Administrative Efficiency. . . . . . . . . . . 11
     3.2.  Stewardship. . . . . . . . . . . . . . . . . . . . . . 12
           3.2.1.  Accountability for Change. . . . . . . . . . . 12
           3.2.2.  Persistence and Accessibility of Records . . . 12
     3.3.  Working Environment. . . . . . . . . . . . . . . . . . 12
           3.3.1.  Service Automation . . . . . . . . . . . . . . 12
           3.3.2.  Tools. . . . . . . . . . . . . . . . . . . . . 13
 4.  Advisory Committee Advice  . . . . . . . . . . . . . . . . . 13
     4.1.  Proposed:  (Single) Formalized IETF Organizational
           Entity . . . . . . . . . . . . . . . . . . . . . . . . 13
           4.1.1.  Comments on the Necessity of this
                   Formalization. . . . . . . . . . . . . . . . . 14
     4.2.  Possible Structures. . . . . . . . . . . . . . . . . . 14
           4.2.1.  ISOC . . . . . . . . . . . . . . . . . . . . . 15
           4.2.2.  ISOC Subsidiary. . . . . . . . . . . . . . . . 15
           4.2.3.  Completely Autonomous Organizational Entity. . 16
     4.3.  Who Can Decide . . . . . . . . . . . . . . . . . . . . 17
 5.  Security Considerations. . . . . . . . . . . . . . . . . . . 17
 6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
 7.  Informative References . . . . . . . . . . . . . . . . . . . 18
 A.  IAB Advisory Committee Charter . . . . . . . . . . . . . . . 19
 B.  Input from the current IETF and IAB Chairs . . . . . . . . . 20
 C.  Consultation with ISI:  RFC Editor . . . . . . . . . . . . . 21
 D.  Consultation with Foretec/CNRI:  Secretariat and Meeting
     Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 32
 E.  Consultation with ICANN:  IANA Protocol Parameter
     Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 35
     Author's Address . . . . . . . . . . . . . . . . . . . . . . 39
     Full Copyright Statement . . . . . . . . . . . . . . . . . . 40

1. Introduction

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

IAB Advisory Committee Informational [Page 2] RFC 3716 The IETF: Administration and Execution March 2004

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

1.1. Overview of the AdvComm Work Process and Output

 The AdvComm was formed in September 2003, and carried out its work
 over the course of the following 2 months, prior to the IETF58 in
 November of 2003.
 The AdvComm's membership included many of the individuals who are, or
 have been, volunteered to manage the IETF's inter-organization
 administrative relationships in recent years.  The first phase of the
 committee's work, therefore, included sharing and discussing the body
 of tacit knowledge about those relationships.  This included the
 input from the current IETF and IAB Chairs in Appendix B, and yielded
 the IETF organizational structure information in Section 2.1.
 The committee also sought input from the other end of the key
 existing administrative relationships (RFC Editor, Secretariat, and
 IANA).  The output of those efforts is included in Appendix C,
 Appendix D, and Appendix E, and these were also used as the basis for
 the observations in Section 2.
 From these inputs, the committee drew together a list of requirements
 for successful future IETF administration, documented in Section 3.
 Finally, the committee put together some advice for how the IETF
 might consider reorganizing its administrative structure to meet
 those requirements moving forward -- Section 4.

1.2. Scope

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

IAB Advisory Committee Informational [Page 3] RFC 3716 The IETF: Administration and Execution March 2004

1.3. Next Steps

 This documents the state of the AdvComm's thinking at the end of a
 two month process, and brings the currently-chartered work of the
 AdvComm to a close.
 Next steps include review of this material by the community, and
 specific proposals for action that will be put forward by the IAB and
 IETF Chairs.

2. Observations

2.1. Current IETF Support Structure

2.1.1. What the Term IETF Includes in this Document

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

2.1.2. Functions

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

IAB Advisory Committee Informational [Page 4] RFC 3716 The IETF: Administration and Execution March 2004

    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

IAB Advisory Committee Informational [Page 5] RFC 3716 The IETF: Administration and Execution March 2004

 RFC Publication
    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

IAB Advisory Committee Informational [Page 6] RFC 3716 The IETF: Administration and Execution March 2004

    directors and the working group chairs.  CNRI assumed operational
    responsibility for the substantive workings of the IETF
    Secretariat.  In 1998, in order to decrease overhead costs on the
    activities, the Secretariat was reorganized placing Secretariat
    employees including the IETF Executive Director in a CNRI for-
    profit subsidiary (Foretec Seminars, Inc.).  Foretec was founded
    in 1997, in anticipation of the Secretariat becoming self-
    supporting.  CNRI and its subsidiary have continued to improve the
    operation of the Secretariat, as appropriate, and maintain a
    trained staff.
    USC/ISI:  The role of the RFC Editor, and USC/ISI, is detailed in
    RFC 2555.  The RFC document series is a set of technical and
    organizational notes about the Internet (originally the ARPANET),
    beginning in 1969.  For 30 years, the RFC Editor was Jon Postel, a
    research scientist and manager in the Networking Division of the
    USC Information Sciences Institute (ISI), with the function
    gradually evolving into a team headed by him.  The RFC Editor
    activity is currently organized as a project within ISI, using the
    ISI infrastructure, and supported by a contract with ISOC.  The
    RFC Editor is the publisher of RFCs and is responsible for the
    final editorial review of the documents, as well as the
    maintenance of the online repository and index of those documents.
    ICANN:  The Internet Corporation for Assigned Names and Numbers
    (ICANN) is the non-profit corporation that was formed in 1998 to
    assume responsibility for the IP address space allocation,
    protocol parameter assignment, domain name system management, and
    root server system management functions previously performed under
    U.S. Government contract by IANA (at ISI) and other entities.
 The support picture (who does what) can be described as follows:
 Secretariat at Foretec/CNRI
    IESG Support
    IAB Support (working document management)
    WG Support
    Community Support
    IETF meetings
 RFC Editor at USC/ISI
    [Supported by ISOC, based on a contract between USC/ISI and ISOC]
    RFC publication Maintenance of standards status record

IAB Advisory Committee Informational [Page 7] RFC 3716 The IETF: Administration and Execution March 2004

    [Relationship defined by Memorandum of Understanding: RFC 2860]
    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
 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.

IAB Advisory Committee Informational [Page 8] RFC 3716 The IETF: Administration and Execution March 2004

 The result has been a budget deficit for operations which began in
 2002, and is forecasted to continue until at least 2004, even after a
 substantial increase in meeting fees.  The continuing deficits have
 depleted working capital, making the IETF less robust against
 potential future budgetary disappointments.
 The financial stress is real, but the IETF leadership has noted
 several other stressors that are impediments to finding and
 implementing solutions to the fiscal issues.  Some obvious solutions
 are not implementable in the current IETF structure.
 The rest of the stressors listed in this section should be understood
 as issues for which relief is necessary, particularly in the light of
 needing to properly address and implement solutions to the financial
 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.

IAB Advisory Committee Informational [Page 9] RFC 3716 The IETF: Administration and Execution March 2004

2.2.2. Stress Points Observed by Organizations Supporting the IETF

 Supporting organizations report difficulties in determining
 authoritative channels for directions -- either too many inputs, or
 no clear authority for resolution of change requests.
 In the absence of written agreements, supporting organizations may
 not be clear from whom to take direction.  Even where agreements
 exist, the authority to provide direction may not be clear.  The
 genesis of both problems is that the IETF relies on external bodies
 for support, but does not have sufficiently clear external
 relationships to allow it to provide input as to its requirements or
 direction on what services it desires.

2.3. A Final Observation

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

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

 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.

IAB Advisory Committee Informational [Page 10] RFC 3716 The IETF: Administration and Execution March 2004

3.1.2. Revenue Source Equivalence

 The IETF is currently supported by money from multiple sources,
 including meeting fees, donations from interested corporate and non-
 corporate entities, and donations in kind of equipment or manpower.
 The IETF needs to be able to consider all sources of income, and all
 expenses involved in running the IETF, as pieces of one budget, to be
 free to adjust all items on the occasions when the income from the
 different sources varies, and to allocate funds as reasonably
 The usual caveats apply:  that donations not threaten the
 independence of the IETF, and that donations are easier when they are
 tax deductible.

3.1.3. Clarity in Relationship with Supporting Organizations

 While the IETF needs to be able to manage its revenue streams against
 its expense expectations, it also needs to respect the needs of
 supporting organizations to manage their own affairs.  That is, the
 text above does not suggest that the IETF should micro-manage the
 financial affairs of supporting organizations.
 However, the very clear requirement is for clarity in the
 distribution of rights, responsibilities, and accountability in those
 relationships.  The usual mechanism for documenting such clarity is
 in contract form.  Thus, the IETF needs to have clear contractual
 relationships with the organizations supporting basic services,
 including meeting organization, secretarial services, IT services,

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

IAB Advisory Committee Informational [Page 11] RFC 3716 The IETF: Administration and Execution March 2004

3.2. Stewardship

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

3.2.1. Accountability for Change

 The IETF needs to be responsible for changing its administrative
 structure to meet the community's evolving needs.  As such, the
 administration needs to remain uniquely accountable to the IETF
 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.

IAB Advisory Committee Informational [Page 12] RFC 3716 The IETF: Administration and Execution March 2004

 More processes could be accomplished without requiring human
 judgment.  Wherever possible, these processes should be identified,
 clarified, and automated.
 Note that this is not intended to imply ALL processes should be
 automated!  Rather, by reducing the friction incurred in steps that
 are truly mechanical, more time and energy will be available to
 properly treat those that require individual judgment.

3.3.2. Tools

 Whether housed in an IETF-supported location or offered by individual
 contribution, the PROBLEM WG has identified the need for more tool
 support for working groups and specification development.  The IETF
 needs to be able to identify, develop and support an adequately rich,
 consistent set of tools for getting the standards work done.

4. Advisory Committee Advice

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

4.1. Proposed: (Single) Formalized IETF Organizational Entity

 In order to ensure an IETF structure that is capable of meeting the
 requirements outlined above, the AdvComm recommends that the IETF be
 more formally organized.  This would allow the IETF to take full
 responsibility for, and management of, the resources required to
 accomplish its work (as described in Section 3.1), provide and
 maintain the necessary work environment for current work (as
 described in Section 3.3), and provide appropriate stewardship of the
 institutional information required for all aspects of current and
 future work of the organization (as described in Section 3.2).
 Some proposed models for establishing such a formalized effort are
 described in the following sections.  Some of the key expectations,
 irrespective of the final implementation of formalism, are:
 o  the administration of the IETF would remain accountable to the
    IETF leadership and community; the goal would be to ensure that
    lines of responsibility and accountability were clearer;
 o  this formalized IETF would be responsible for managing financial
    resources (revenue and expenses) directly;

IAB Advisory Committee Informational [Page 13] RFC 3716 The IETF: Administration and Execution March 2004

 o  this formalized IETF would be directly signatory to agreements
    with other organizations, and would therefore be able to negotiate
    and administer any appropriate contracts;
 o  however implemented, this would require a small staff complement
    (e.g., one full-time person) responsible to no other organization
    than the one chartered with the IETF's mission;
 o  nevertheless, it remains a non-goal to create an organizational
    entity that exists simply for the purpose of continuing to exist.
    This should be executed with the minimum formality needed in order
    to address the identified requirements.

4.1.1. Comments on the Necessity of this Formalization

 An important question is:  what does this proposed formalization
 provide that cannot be provided by the status quo?  The AdvComm
 believes that an appropriately implemented formalization of the IETF
 would permit the unification of the resource management, decision
 making and stewardship that is imperative to providing clarity and
 ensuring a viable future for the IETF.  The AdvComm further believes
 that this is simply not possible to implement within the existing
 distributed and informal arrangement of responsibilities.
 Naturally, the act of forming such an organization does not
 immediately satisfy the requirements outlined in Section 3.  It is
 not a silver bullet.  Changing the formal structure will not, for
 example, change the financial status of the IETF.  However, the
 AdvComm believes it would provide the necessary basis from which the
 required decisions could be made and acted upon.
 In short, the AdvComm believes that we first have to place the
 responsibility for defining the IETF's administrative environment
 with specific people who are accountable to the IETF community.  Then
 these people can take the detailed decisions that will change the
 IETF's administrative environment to fulfill its requirements.

4.2. Possible Structures

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

IAB Advisory Committee Informational [Page 14] RFC 3716 The IETF: Administration and Execution March 2004

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

4.2.1. ISOC

 The IETF is organized as an activity of the Internet Society.  One
 potential path for increased formalism of the IETF's administration
 would be to further define that relationship.  This model anticipates
 dedication of ISOC personnel to form the "small staff complement",
 and would make ISOC responsible for all of the IETF's financial
 resources and expenses.
 This approach should be relatively straightforward to implement,
 given ISOC's existing legal relationship with the IETF activity, and
 its status as signatory for IETF-related contracts (e.g., RFC
 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.

IAB Advisory Committee Informational [Page 15] RFC 3716 The IETF: Administration and Execution March 2004

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

IAB Advisory Committee Informational [Page 16] RFC 3716 The IETF: Administration and Execution March 2004

 margin for error;  were one or more of the initial meetings to run in
 the red, the survival of a fledgling IETF could be in jeopardy. Given
 the economic environment, it probably should not be assumed that
 working capital could be raised purely from corporate donations,
 especially during an initial period in which staff required to
 solicit and manage donations would not be available.
 Additionally, the impact that such a move would have on ISOC's
 ability to carry out its mission and the IETF's standing with
 governmental organizations needs to be considered.

4.3. Who Can Decide

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

5. Security Considerations

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

6. Acknowledgements

 The AdvComm sincerely appreciates the time, effort and care of the
 RFC Editor, IANA, Secretariat and Secretariat organizations in
 providing input, responding to the AdvComm's questions, and
 reviewing/correcting the consultation text shown here in the
 The members of the IAB Advisory Committee that prepared this report
    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

IAB Advisory Committee Informational [Page 17] RFC 3716 The IETF: Administration and Execution March 2004

7. Informative References

 [1]  Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, RFC
      3233, February 2002.
 [2]  Alvestrand, H., "IETF Chair plenary presentation, http://",
      March 2003.
 [3]  Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
      2223, October 1997.
 [4]  Reynolds, J. and B. Braden, Eds., "Instructions to Request for
      Comments (RFC) Authors", Work in Progress.

IAB Advisory Committee Informational [Page 18] RFC 3716 The IETF: Administration and Execution March 2004

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
 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.  --

IAB Advisory Committee Informational [Page 19] RFC 3716 The IETF: Administration and Execution March 2004

Appendix B. Input from the Current IETF and IAB Chairs

 Input contributed by Harald Alvestrand (IETF Chair) and Leslie Daigle
 (IAB Chair).
 Looking at the administrative overview of the IETF activity,  there
 are a number of things that work well:
 o  support organizations are committed to the work of the IETF;
 o  the volunteers of the IETF WGs can (mostly) concentrate on their
    engineering work, not economics;
 o  money has (so far) been sufficient to cover the costs.
 However, there are also a number of challenges:
 o  lack of persistent records of the whole organization's efforts --
    of working documents, meeting materials, communications.  Also,
  • lack of organization of records – even when data is stored, it

can be hard or impossible to access when no longer current

       (e.g., it may reside on some former WG chair's hard drive)
  • history records are kept spottily (lists of wg chairs and old

versions of charters, to mention some);

 o  few safeguards against the "hit by a bus" problem -- much
    information about relationships is not documented, and must be
    transferred as oral tradition.  This means that significant
    overlap is needed when personnel changes;
 o  IETF leadership responsibilities are not clearly identified --
    typically handled by IETF and IAB Chairs, with some advice and
    consent from IESG and IAB, but that makes it possible to challenge
    every change decision;
 o  contracts do not clearly identify responsibility for executive
    direction.  Some contractual relationships are not documented, or
    are not visible to the IETF leadership;
 o  variable, and often unclear, documentation of responsibilities
    between IETF leadership and other organizations.  This makes it
    hard to determine how and where to discuss and effect improvements
    for the IETF that affect one or more support organization's

IAB Advisory Committee Informational [Page 20] RFC 3716 The IETF: Administration and Execution March 2004

 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.  For example, raising
    meeting fees wouldn't pay for more RFC Editor resources; more
    support from ISOC doesn't address any needs for IETF working group
    support functions;
 o  the lack of clarity and the partitioning make it very hard for the
    IETF leadership, and the community as a whole, to determine points
    of accountability and implement changes for a healthy future.

Appendix C. Consultation with ISI: RFC Editor

 Note: "RFC2223bis" in the text below refers to RFC 2223bis [4], a
 work in progress to update RFC 2223 [3].
          Responses to Questions from IAB Advisory Committee
                          for the RFC Editor
                            October 6, 2003
  • (1) Your description of the function you are performing. Is
  • that function, and its relationship to the IETF, adequately
  • described in RFC 2223bis, or is additional description
  • required? If the latter, what would you suggest?
 A comprehensive summary of current RFC Editor functions is attached
 below.  Note that this list has no direct relation to RFC 2223bis,
 which contains instructions to RFC authors.
  • (2) What staff is being used to perform these functions and
  • what are their particular skills for doing so (either
  • individually or in the aggregate)?

IAB Advisory Committee Informational [Page 21] RFC 3716 The IETF: Administration and Execution March 2004

 For 30 years, the RFC Editor was Jon Postel, a research scientist and
 manager in the Networking Division of the USC Information Sciences
 Institute (ISI).  It is currently organized as a project within ISI,
 using the ISI infrastructure.  The following ISI staff members
 comprise the RFC Editor project:
    Joyce Reynolds         100%
    Bob Braden              10%
    Aaron Falk              10%
    Sandy Ginoza           100%
    Project Assistant      100%
    Graduate Research Asst. 50%
 Braden and Reynolds jointly manage the RFC Editor project, with
 oversight of personnel and budgets.
 Joyce Reynolds has been contributing her editorial and management
 skills to the Internet since 1979.  She performed the IANA functions
 under Jon Postel's direction from 1983 until Postel's death in
 October 1998.  She continued to perform the IANA protocol parameter
 tasks on loan from ISI to ICANN, from 1998 to 2001.  She was IANA
 liaison to the IESG from 1998 to 2001, transitioning the role to
 Michelle Cotton in the 2001.
 Reynolds performed the RFC Editor functions under Jon Postel's
 direction from 1987 until 1998.  Reynolds has been a member of the
 IETF since 1988, and she served as User Services Area Director on the
 IESG for 10 years.  Reynolds now serves a liaison to the IAB and
 IESG.  She handles the final proofing and quality control on RFCs
 prior to publication.
 Bob Braden has made many contributions to the Internet protocol
 technology and community.  He helped design TCP/IP during the
 original research period beginning in 1978, and he has devoted his
 professional career since 1978 to the Internet.  He served for 13
 years on the original IAB and as its Executive Director for about 5
 years.  Since 1998 Braden has been co-leader of the RFC Editor
 project.  He is the principal reviewer of individual submissions.  He
 also works on technical issues related to the RFC Editor project.
 Aaron Falk is a significant player in the IETF as a Working Group
 chair, in the areas of transport protocols and satellite technology.
 On the RFC Editor team, he assists with policy questions and handles
 technical development, overseeing the work of the grad student

IAB Advisory Committee Informational [Page 22] RFC 3716 The IETF: Administration and Execution March 2004

 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?
 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.

IAB Advisory Committee Informational [Page 23] RFC 3716 The IETF: Administration and Execution March 2004

    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 process.
    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
    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 sections.)
 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)?

IAB Advisory Committee Informational [Page 24] RFC 3716 The IETF: Administration and Execution March 2004

 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 them to
    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.
  • (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.

IAB Advisory Committee Informational [Page 25] RFC 3716 The IETF: Administration and Execution March 2004

 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
     One is to bring out new technical ideas for consideration and
     discussion.  We believe that the future success of the Internet
     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

IAB Advisory Committee Informational [Page 26] RFC 3716 The IETF: Administration and Execution March 2004

     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
  • 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.

IAB Advisory Committee Informational [Page 27] RFC 3716 The IETF: Administration and Execution March 2004

    (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
    (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 cost.
 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.


 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

IAB Advisory Committee Informational [Page 28] RFC 3716 The IETF: Administration and Execution March 2004

 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.
        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

IAB Advisory Committee Informational [Page 29] RFC 3716 The IETF: Administration and Execution March 2004

        (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
    (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 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.

IAB Advisory Committee Informational [Page 30] RFC 3716 The IETF: Administration and Execution March 2004

    (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) forms.
    (b) A document consisting of summaries of RFCs in each range of
    (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
 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.

IAB Advisory Committee Informational [Page 31] RFC 3716 The IETF: Administration and Execution March 2004

    (2) Database Accessibility and Quality
        (d) Improving the usefulness of the Errata information
            (i)  Distinguish mere typographic errors from errors of
            (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 RFCs.
    (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
                           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.

IAB Advisory Committee Informational [Page 32] RFC 3716 The IETF: Administration and Execution March 2004

 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 I-Ds.
  • (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)?
  1. - Three people perform administrative functions.
  2. - Four-and-a-half people perform technical support.
  3. - One-and-a-half people do development.
  4. - 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

IAB Advisory Committee Informational [Page 33] RFC 3716 The IETF: Administration and Execution March 2004

 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
  • (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
 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

IAB Advisory Committee Informational [Page 34] RFC 3716 The IETF: Administration and Execution March 2004

  • 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
          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

IAB Advisory Committee Informational [Page 35] RFC 3716 The IETF: Administration and Execution March 2004

 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
 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 error.
 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.

IAB Advisory Committee Informational [Page 36] RFC 3716 The IETF: Administration and Execution March 2004

 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
 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.

IAB Advisory Committee Informational [Page 37] RFC 3716 The IETF: Administration and Execution March 2004

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

IAB Advisory Committee Informational [Page 38] RFC 3716 The IETF: Administration and Execution March 2004

  • (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?
 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.

Author's Address

 IAB Advisory Committee

IAB Advisory Committee Informational [Page 39] RFC 3716 The IETF: Administration and Execution March 2004

Full Copyright Statement

 Copyright (C) The Internet Society (2004).  This document is subject
 to the rights, licenses and restrictions contained in BCP 78 and
 except as set forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed
 to pertain to the implementation or use of the technology
 described in this document or the extent to which any license
 under such rights might or might not be available; nor does it
 represent that it has made any independent effort to identify any
 such rights.  Information on the procedures with respect to
 rights in RFC documents can be found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use
 of such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository
 The IETF invites any interested party to bring to its attention
 any copyrights, patents or patent applications, or other
 proprietary rights that may cover technology that may be required
 to implement this standard.  Please address the information to the
 IETF at


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

IAB Advisory Committee Informational [Page 40]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3716.txt · Last modified: 2004/03/24 20:32 (external edit)