doc: Add RFC documents

1 files changed, 2243 insertions, 0 deletions

diff --git a/doc/rfc/rfc3716.txt b/doc/rfc/rfc3716.txt
new file mode 100644
index 0000000..0c64916
--- /dev/null
+++ b/doc/rfc/rfc3716.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+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.
+
+Abstract
+
+   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
+   appropriate.
+
+
+
+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
+
+      Telechats
+      Communications
+      IETF document tracking
+      Working document management (mailing list, website, repository)
+
+   IAB support
+
+      Telechats
+      Communications
+      Working document management (mailing list, website, repository)
+
+   WG support
+
+      Charters
+      Milestone tracking
+      Workspace (website, mailing list)
+      Working document archive (mailing list archives, document
+         repository)
+
+   Community Support
+
+      Website
+      IETF mailing list
+      Announcements
+      I-D repository
+
+
+
+
+
+
+
+IAB Advisory Committee       Informational                      [Page 5]
+
+RFC 3716        The IETF:  Administration and Execution       March 2004
+
+
+   RFC Publication
+
+      Website
+      RFC editorial
+      Document publication
+      RFC repository management
+      Official standards status record
+
+   IETF Meetings
+
+      Planning
+      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.
+      Miscellaneous
+
+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
+   today.
+
+      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
+
+
+   IANA/ICANN
+
+      [Relationship defined by Memorandum of Understanding: RFC 2860]
+
+      Protocol parameter registry
+
+   ISOC
+
+      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
+      IESG
+      IAB
+      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
+   stress.
+
+   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
+    Administration
+
+   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
+   required.
+
+   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,
+   etc.
+
+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,
+   etc.
+
+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
+   effort.
+
+
+
+
+
+
+
+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
+   community.
+
+   This also means that the distribution of responsibilities must be
+   clear to the IETF community, in order to permit it to comment on
+   current actions or future plans, and also to allow it to take action
+   when its needs are not being adequately addressed.
+
+   An implication of this is that responsibility for financial
+   management within the IETF needs to sit with individuals who are
+   accountable within the IETF organizational structure.
+
+3.2.2.  Persistence and Accessibility of Records
+
+   Much of the work of the IETF is focused on reaching decisions and
+   declaring closure.  However, responsibility does not stop with the
+   declaration of completion.  There are any number of reasons that
+   history must be adequately documented so that future work can review
+   substantive records, and not rely on oral history.
+
+   Therefore, the IETF needs to maintain and support the archiving of
+   all of its working documents in a way that continues to be
+   accessible, for all current and future IETF workers.
+
+3.3.  Working Environment
+
+   Part of the job of administering the IETF is identifying and ensuring
+   the continued support of the tools and working environment necessary
+   to support the ongoing activity.
+
+3.3.1.  Service Automation
+
+   Wherever human judgment is not required in order to complete an
+   action, services should be automated to provide the most friction-
+   free path and minimal delay in completing the action.
+
+
+
+
+
+
+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
+   Editor).
+
+   This proposal is consistent with the goal of minimizing the amount of
+   formalization needed to meet the requirements of the IETF.
+
+   However, the general mission of ISOC is broader than the
+   standardization activity of the IETF, and the ISOC Board of Trustees
+   must stay focused on apportioning resources to meet that broader
+   mission.  Would this approach allow the clear lines of responsibility
+   that are called for in Section 3?
+
+4.2.2.  ISOC Subsidiary
+
+   A modification of the proposal of housing the IETF central body
+   within ISOC is to create a legal not-for-profit subsidiary of ISOC,
+   with a mandate that is specifically focused on the IETF's mission.
+   This subsidiary would become the legal entity responsible for
+   managing the IETF's resources and expenses, and would become
+   signatory to any other legal instruments on the IETF's behalf.
+
+   As a distinct legal entity in its own right, the subsidiary would be
+   independently responsible for achieving its mission.  That level of
+   independence addresses the concern raised against the notion of
+   further formalizing the IETF within ISOC directly -- that the IETF
+   mission might be disrupted by the organization's need to tend to
+   other aspects of ISOC's broader mission.  The role of the IETF
+   community, and the ISOC parent, in defining and supporting that
+   mission would be spelled out in the creation of the legal body.
+
+
+
+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
+   approach.
+
+   At the same time, as a subsidiary organization, the expectation is
+   that the relationship with ISOC would remain a close one: the
+   subsidiary would benefit from ISOC's existing infrastructure and
+   support (a conservative approach to adding formalism and structural
+   overhead to the IETF activity), while the relationship would continue
+   to provide a channel for the IETF to support ISOC in achieving that
+   broader mission, with continued contribution of technical expertise
+   and support of activities.
+
+   This approach would require more work to create than simply housing
+   the work at ISOC.   The subsidiary would have to be created and
+   rights/responsibilities adjusted between it and ISOC in order to
+   ensure that both have the necessary resources and frameworks to carry
+   out their missions.
+
+4.2.3.  Completely Autonomous Organizational Entity
+
+   To complete the picture, a third option has to be considered. Instead
+   of creating a subsidiary of ISOC as a separate legal entity, an
+   entirely new legal entity, "IETF, Inc.", or "IETF, LLC", could be
+   created for the sole purpose of managing IETF administrative
+   activities.
+
+   This would offer the IETF complete autonomy with all the attendant
+   rights and responsibilities.  In particular, an independent IETF
+   would at a minimum, need to operate much like a startup for the first
+   few years of its existence, with all the related financing and growth
+   issues, and survival risks.  Given all the organizational change
+   taking place within the IETF during the same period, the AdvComm
+   believes that the financial and political risks of such an approach
+   should not be under-estimated.
+
+   For example, it would be necessary for the IETF to obtain initial
+   working capital sufficient to handle the commitments for the first
+   few meetings.  While it would be conceivable to raise working capital
+   from advance meeting fees, such a financing plan would not leave much
+
+
+
+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
+   appendixes.
+
+   The members of the IAB Advisory Committee that prepared this report
+   were:
+
+      o Bernard Aboba
+      o Harald Alvestrand (IETF Chair)
+      o Lynn St.Amour (ISOC President)
+      o Fred Baker (Chair, ISOC Board of Trustees)
+      o Brian Carpenter
+      o Steve Crocker
+      o Leslie Daigle (IAB Chair, chair of the committee)
+      o Russ Housley
+      o John Klensin
+
+
+
+
+
+
+
+
+
+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://
+        www.ietf.org/proceedings/03mar/slides/plenary-3/index.html",
+        March 2003.
+
+   [3]  Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
+        2223, October 1997.
+
+   [4]  Reynolds, J. and B. Braden, Eds., "Instructions to Request for
+        Comments (RFC) Authors", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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.
+
+   Thanks,
+   Leslie,
+   for the IAB.
+
+   =================
+
+   IAB Advisory Committee on IETF Administration Relationships
+
+   The purpose of the committee is to review the existing
+   IETF administration relationships (RFC Editor, IETF Secretariat,
+   etc.) and propose IETF management process or structural changes
+   that would improve the overall functioning of the
+   IETF. Any such proposal will be subject to review and
+   acceptance by the IAB and IETF plenary. Note that the scope of the
+   advisory committee does NOT include proposed changes to the standards
+   development processes (e.g., WG organization, IESG management of
+   documents or working groups, etc.).
+
+   The committee is chaired by the IAB Chair, Leslie Daigle, and
+   consists of:
+
+         o Bernard Aboba
+         o Harald Alvestrand (IETF Chair)
+         o Lynn St.Amour (ISOC President)
+         o Fred Baker (Chair, ISOC Board of Trustees)
+         o Brian Carpenter
+         o Steve Crocker
+         o Leslie Daigle (IAB Chair, chair of the committee)
+         o Russ Housley
+         o John Klensin
+
+   Additional input is welcome.  The committee will also make a
+   particular effort to seek out further input as needed.  --
+
+
+
+
+
+
+
+
+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
+      activity;
+
+
+
+
+
+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
+      leadership;
+
+   o  partitioned finances --  it's not possible for the IETF to make
+      changes that would affect the balance of revenue and costs across
+      the revenue sources/expense commitments.  For example, raising
+      meeting fees wouldn't pay for more RFC Editor resources; more
+      support from ISOC doesn't address any needs for IETF working group
+      support functions;
+
+   o  the lack of clarity and the partitioning make it very hard for the
+      IETF leadership, and the community as a whole, to determine points
+      of accountability and implement changes for a healthy future.
+
+Appendix C.  Consultation with ISI:  RFC Editor
+
+   Note: "RFC2223bis" in the text below refers to RFC 2223bis [4], a
+   work in progress to update RFC 2223 [3].
+
+            Responses to Questions from IAB Advisory Committee
+                            for the RFC Editor
+
+                              October 6, 2003
+
+   *
+   * (1) Your description of the function you are performing.   Is
+   * that function, and its relationship to the IETF, adequately
+   * described in RFC 2223bis, or is additional description
+   * required?  If the latter, what would you suggest?
+
+   ANSWER:
+
+   A comprehensive summary of current RFC Editor functions is attached
+   below.  Note that this list has no direct relation to RFC 2223bis,
+   which contains instructions to RFC authors.
+
+   *
+   * (2) What staff is being used to perform these functions and
+   * what are their particular skills for doing so (either
+   * individually or in the aggregate)?
+   *
+
+
+
+
+
+
+IAB Advisory Committee       Informational                     [Page 21]
+
+RFC 3716        The IETF:  Administration and Execution       March 2004
+
+
+   ANSWER:
+
+   For 30 years, the RFC Editor was Jon Postel, a research scientist and
+   manager in the Networking Division of the USC Information Sciences
+   Institute (ISI).  It is currently organized as a project within ISI,
+   using the ISI infrastructure.  The following ISI staff members
+   comprise the RFC Editor project:
+
+      Joyce Reynolds         100%
+      Bob Braden              10%
+      Aaron Falk              10%
+      Sandy Ginoza           100%
+      Project Assistant      100%
+      Graduate Research Asst. 50%
+
+   Braden and Reynolds jointly manage the RFC Editor project, with
+   oversight of personnel and budgets.
+
+   Joyce Reynolds has been contributing her editorial and management
+   skills to the Internet since 1979.  She performed the IANA functions
+   under Jon Postel's direction from 1983 until Postel's death in
+   October 1998.  She continued to perform the IANA protocol parameter
+   tasks on loan from ISI to ICANN, from 1998 to 2001.  She was IANA
+   liaison to the IESG from 1998 to 2001, transitioning the role to
+   Michelle Cotton in the 2001.
+
+   Reynolds performed the RFC Editor functions under Jon Postel's
+   direction from 1987 until 1998.  Reynolds has been a member of the
+   IETF since 1988, and she served as User Services Area Director on the
+   IESG for 10 years.  Reynolds now serves a liaison to the IAB and
+   IESG.  She handles the final proofing and quality control on RFCs
+   prior to publication.
+
+   Bob Braden has made many contributions to the Internet protocol
+   technology and community.  He helped design TCP/IP during the
+   original research period beginning in 1978, and he has devoted his
+   professional career since 1978 to the Internet.  He served for 13
+   years on the original IAB and as its Executive Director for about 5
+   years.  Since 1998 Braden has been co-leader of the RFC Editor
+   project.  He is the principal reviewer of individual submissions.  He
+   also works on technical issues related to the RFC Editor project.
+
+   Aaron Falk is a significant player in the IETF as a Working Group
+   chair, in the areas of transport protocols and satellite technology.
+   On the RFC Editor team, he assists with policy questions and handles
+   technical development, overseeing the work of the grad student
+   programmer.
+
+
+
+
+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
+   operation.
+
+   Two part-time Project Assistants, Mieke Van de Kamp and Alison De La
+   Cruz, do editing, mark-up, and initial proofing of individual RFCs.
+   Our goal is to have three pairs of eyes read every RFC word-for-word,
+   and in most instances we are able to do so.
+
+   A half-time USC Graduate Research Assistant provides programming
+   support by developing, extending, and maintaining RFC Editor scripts
+   and tools.
+
+   * (3) What criteria do you use to determine whether you are being
+   * successful, and how successful?  Using those criteria, how
+   * successful are you and what could be done, especially from the
+   * IETF side, to improve that evaluation?
+
+   ANSWER:
+
+   We can begin with a historical perspective on this question.  When
+   Jon Postel unexpectedly passed away 5 years ago, Reynolds and Braden
+   took on the challenge of carrying on Postel's RFC Editor function.
+   The publication stream continued, with a modest increase in quantity
+   and, we believe, no loss of quality.  Furthermore, the transition was
+   largely invisible to the IETF.  In addition, the new RFC Editor
+   project has significantly defined and clarified the publication
+   process, improved the web site, added tools to improve productivity
+   and quality, and adapted the procedures to changing realities.  We
+   are proud of these achievements.
+
+   The three primary axes for measuring RFC Editor success are (1)
+   quantity, (2) quality, and (3) accessibility.
+
+   1. Quantity
+
+      Roughly, quantitative success means the ability to keep up with
+      the submission rate.  Since the submission rate tends to be
+      bursty, to avoid long delays we need an average capacity somewhat
+      in excess of the average.
+
+      RFC publication is necessarily a heavily labor-intensive process.
+
+
+
+
+
+
+
+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
+      improvements.
+
+   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?
+   *
+
+   ANSWER:
+
+   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.
+
+   ANSWER:
+
+   (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
+       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?
+   *
+   *
+
+   ANSWER:
+
+   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
+          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 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.
+
+APPENDIX -- FUNCTIONS OF RFC EDITOR
+
+   OVERVIEW
+
+   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.
+
+   SPECIFIC TASKS
+
+   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
+                 2223bis
+
+          (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
+                 satisfied.
+
+
+
+
+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
+          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 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
+          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
+   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
+                   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 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
+             Planning
+
+                  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)?
+
+     -- 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
+
+
+
+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
+   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
+   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
+   administratively.
+
+   * (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
+   IETF
+
+   EMail: iab@iab.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+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
+   at http://www.ietf.org/ipr.
+
+   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 ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+IAB Advisory Committee       Informational                     [Page 40]
+