Network Working Group                                          L. Daigle
Internet-Draft                                                       Ed.
Expires: January 26, 2007                    Internet Architecture Board
                                                                   (IAB)
                                                           July 25, 2006


                     The RFC Series and RFC Editor
                          draft-iab-rfc-editor

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes the framework for an RFC Series and an RFC
   Editor function that incorporate the principles of organized
   community involvement and accountability that has become necessary as
   the Internet technical community has grown, thereby enabling the RFC
   Series to continue to fulfill its mandate.





Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 1]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  RFC Series Mission . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Roles and Responsibilities . . . . . . . . . . . . . . . . . .  6
     3.1.  RFC Editor . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  IAB  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Operational Oversight  . . . . . . . . . . . . . . . . . .  6
   4.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Document approval  . . . . . . . . . . . . . . . . . . . .  8
       4.1.1.  Definition . . . . . . . . . . . . . . . . . . . . . .  8
       4.1.2.  Operational Implementation . . . . . . . . . . . . . .  9
       4.1.3.  Process Change . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Editing, processing and publication of documents . . . . .  9
       4.2.1.  Definition . . . . . . . . . . . . . . . . . . . . . .  9
       4.2.2.  Operational Implementation . . . . . . . . . . . . . .  9
       4.2.3.  Process Change . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Archiving and indexing . . . . . . . . . . . . . . . . . . 10
       4.3.1.  Definition . . . . . . . . . . . . . . . . . . . . . . 10
       4.3.2.  Operational Implementation . . . . . . . . . . . . . . 10
       4.3.3.  Process Change . . . . . . . . . . . . . . . . . . . . 10
   5.  RFC Streams  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  RFC Approval Processes . . . . . . . . . . . . . . . . . . 11
       5.1.1.  IETF Document Stream . . . . . . . . . . . . . . . . . 11
       5.1.2.  IAB Document Stream  . . . . . . . . . . . . . . . . . 12
       5.1.3.  IRTF Document Stream . . . . . . . . . . . . . . . . . 12
       5.1.4.  Independent Submission Stream  . . . . . . . . . . . . 12
     5.2.  RFC Technical Publication Requirements . . . . . . . . . . 12
       5.2.1.  IETF Documents . . . . . . . . . . . . . . . . . . . . 13
       5.2.2.  IAB Documents  . . . . . . . . . . . . . . . . . . . . 13
       5.2.3.  IRTF Documents . . . . . . . . . . . . . . . . . . . . 13
       5.2.4.  Independent Submissions  . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IAB members at the time of approval  . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Appendix A.  A Retrospective of IAB Charters and RFC Editor  . . . 16
     A.1.  1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     A.2.  1994 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     A.3.  2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19










Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 2]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


1.  Introduction

   The first Request for Comment (RFC) document was published in April
   of 1969 as part of the effort to design and build what we now know of
   as the Internet.  Since then, the RFC series has been the archival
   series dedicated to documenting Internet technical specifications,
   including standards and related contributions by the Internet
   research and engineering community.

   As described in the history of the first 30 years of the RFC Editor (
   [7]), the RFC series was created for the purpose of capturing the
   research and engineering thought that underlies the design of (what
   we now know of as) the Internet.  As the Internet Engineering Task
   Force was formalized to carry out the discussion and documentation of
   Internet standards, IETF documents have become a large part (but not
   the entirety) of the RFC series.

   As the IETF has grown up and celebrated its own 20 years of history,
   its requirements for archival publication of its output have changed
   and become more rigorous.  Perhaps most signifcantly, the IETF must
   be able to define (based on its own open consensus discussion
   processes and leadership directions) and implement adjustments to its
   publication processes.

   At the same time, the Internet engineering and research community as
   a whole has grown and come to require more openness and
   accountability in all organizations supporting it.  More than ever,
   this community needs an RFC Series that is supported (operationally
   and in principles) such that there is a balance of:

   o  expert implementation

   o  clear management and direction -- for operations & evolution
      across all the series (IETF & not)

   o  appropriate community input into and review of activities

   Today, there is confusion and therefore sometimes tension over where
   and how to address RFC issues that are particular to contributing
   groups (e.g., IETF, or IAB, or independent individuals).  It isn't
   clear where there should be community involvement versus RFC Editor
   control; depending on the issue, there might be more or less
   involvement from the IAB or IESG or community at large.  There are
   similar issues wiht handling RFC Series-wide issues -- where to
   discuss and resolve them in a way that is balanced across the whole
   series?

   For example, there are current discussions about Intellectual



Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 3]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


   Property Rights (IPR) for IETF-generated documents, but it's not
   clear when or how to abstract the portions of those discussions that
   are relevant to the rest of the RFC Series.  Discussions of labelling
   (of RFCs in general, IETF documents in particular, or some
   combination thereof) generally must be applied on an RFC Series-wide
   basis or not at all.  Without a new framework for managing the RFC
   Series, it is difficult to have those discussions in a way that isn't
   "us and them" -- either the IETF dictating the reality of the rest of
   the RFC Series, or the RFC Series imposing undue restrictions on the
   IETF document series.  In such an environment, it's easier for the
   RFC Editor to be caught in the crossfire than empowered to find
   constructive and lasting solutions.

   As part of its charter (see Appendix A), the IAB has a responsibility
   for the RFC Editor.  Acknowledging the IETF's and the general
   Internet engineering and research community's evolving needs, the IAB
   would like to see a future for the RFC series that continues to meet
   its original mandate of providing the archival series for the
   research and engineering technical documentation that describes the
   Internet.

   With this document, the IAB provides the framework for the RFC series
   and an RFC Editor function with the specific purpose of ensuring the
   RFC series and RFC Editor role are maintained and supported in ways
   that are consistent with the stated purpose of the RFC series and the
   realities of today's Internet research and engineering community.
   The framework describes the existing "streams" of RFCs and provides
   clear direction of how to evolve this framework and its supporting
   pieces through discussion and future document revision.

   Specifically, this document provides a brief charter for the RFC
   Series, describes the role of the RFC Editor, IAB and IASA in a new
   framework for managing the RFC Series, and discusses the streams of
   input to the RFC series from the various constituencies it serves.

















Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 4]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


2.  RFC Series Mission

   The RFC Series is the archival series dedicated to documenting
   Internet technical specifications, including standards and related
   contributions by the Internet research and engineering community.

   RFCs are available free of charge to anyone via the Internet.












































Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 5]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


3.  Roles and Responsibilities

   As this document proposes changes to the framework for supporting the
   RFC Series mission, this section reviews the planned roles and
   responsibilities of the entities that have had, and will have,
   involvement in continued support of the mission.

3.1.  RFC Editor

   The RFC Editor is an expert technical editor and series editor,
   acting to support the mission of the RFC Series.  As such, the RFC
   Editor is the implementer handling the editorial management of the
   RFC Series, in accordance with the defined processes.  In addition,
   they are expected to be the expert and prime mover in discussions
   about policies for editing, publishing and archiving RFCs.

3.2.  IAB

   The general role of the IAB, in this model, is to ensure that the RFC
   Series mission is being appropriately supported, for the whole
   community for which it was created.  The IAB does not,
   organizationally, have comprehensive publishing or editorial
   expertise.  Therefore, the role of the IAB as put forward in this
   document is focused on ensuring that principles are met, the
   appropriate bodies and communities are duly informed and consulted,
   and the RFC Editor organization has what it needs in order to execute
   on the material that is in their mandate.

   It is the responsibility of the IAB to approve the appointment of an
   organization to act as RFC Editor and to approve the general policy
   followed by the RFC Editor.

3.3.  Operational Oversight

   The IETF Administrative Support Activity (BCP101, [2]), was created
   to provide administrative support for the IETF, the IAB, and the
   IRTF.  In its role of supporting the IAB, the IASA is tasked with
   providing the funding for and operational oversight of the RFC
   Editor.

   The IAOC (IETF Administrative Oversight Committee) is the oversight
   board of the IASA, and the IAD (IETF Administrative Director) is the
   chief actor for the IASA.

   The IAOC works with the IAB to identify suitable persons or entities
   to carry out the work defined by the technical publication
   requirements defined for the various RFC input streams (see
   Section 5.2).



Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 6]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


   The IAOC establishes appropriate (contractual) agreements with the
   selected persons or entities for the RFC Editor.  The IAOC may define
   additional operational requirements and policies for management
   purposes, in order to meet the requirements defined by the various
   communities.

   In accordance with BCP101, the IAOC provides oversight of the
   operation of the RFC Editor activity based on the established
   agreement(s).

   The IAB monitors the effectiveness of the policies in force and their
   implementation to ensure that the RFC Editor activity meets the
   editorial management and document publication needs as referenced in
   this document.  In the event of serious non-conformance, the IAB,
   either on its own initiative or at the request of the IAOC, may
   require the IAOC to vary or terminate and renegotiate the
   arrangements for the RFC Editor activity.


































Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 7]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


4.  Framework

   With the RFC Series mission outlined above, this document describes a
   framework for supporting

   o  the operational implementation of the RFC Series, based on

   o  public process and definition documents, for which there are

   o  clear responsibilities and mechanisms for update and change.

   Generally speaking, the RFC Editor is responsible for the operational
   implementation of the RFC Series.  As outlined in Section 3.3, the
   IAD provides the oversight of this operational role.

   Responsibility for the individual process documents (maintenance and
   update) is defined in more detail below.  Generally speaking, the RFC
   Editor works with the appropriate community to ensure that the
   process documents reflect current requirements.  The IAB is charged
   with the role of verifying that appropriate community input has been
   sought and that any changes appropriately account for community
   requirements.

   There are 3 categories of activity described for implementing the RFC
   Series to support its mission:

   o  Approval of documents.

   o  Editing, processing, and publication of documents.

   o  Archiving and indexing the documents.

4.1.  Document approval

   The RFC Series mission implicitly requires that documents are
   reviewed and approved for acceptance into the series.  Section 5.1
   describes the different streams of documents that are put to the RFC
   Editor for publication as RFCs today.

4.1.1.  Definition

   While there may be general policies for approval of documents as RFCs
   (to ensure the coherence of the RFC Series), there are policies
   defined for the approval of documents in each stream.  Generally
   speaking, there is a different approving body for each stream.  The
   current defintitions are catalogued in Section 5.1.





Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 8]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


4.1.2.  Operational Implementation

   Each stream has its own documented approval process.  The RFC Editor
   is responsible for the approval of documents in the Independent
   Submission stream, and works with the other approving bodies to
   ensure smooth passage of approved documents into the next phases,
   ultimately to publication and archiving as an RFC.

4.1.3.  Process Change

   From time to time, it may be necessary to change the approval
   processes for any given stream, or even add or remove streams.  This
   may occur when the RFC Editor, the IAB, the body responsible for a
   given stream of documents, or the community determines that there are
   issues to be resolved in general for RFC approval, or for per-stream
   approval processes.

   In this framework, the general approach is that the IAB will work
   with RFC Editor and other parties to get community input and it will
   verfy that any changes appropriately account for community
   requirements.

4.2.  Editing, processing and publication of documents

   Producing and maintaining a coherent, well-edited document series
   requires specialized skills and subject matter expertise.  This is
   the domain of the RFC Editor.  Nevertheless, the community served by
   the RFC Series, and the communities served by the individual streams
   of RFCs, have requirements that help define the nature of the series.

4.2.1.  Definition

   General and stream-specific requirements for the RFC Series are
   documented in community approved documents (catalogued in Section 5.2
   below).

   Any specific numbers or concrete values required to make the
   requirements operational are the subject of agreements between the
   IASA and the RFC Editor (e.g., contracts, statement of work, service
   level agreement, etc).

4.2.2.  Operational Implementation

   The RFC Editor is responsible for ensuring editing, processing and
   publication of RFCs that are consistent with the requirements laid
   out in the appropriate documents.  The RFC Editor works with the IASA
   (in the form of the IAD) for regular reporting and feedback.




Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 9]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


4.2.3.  Process Change

   From time to time, it may be necessary to change the requirements for
   any given stream, or the RFC series in general.  This may occur when
   the RFC Editor, the IAB, the body responsible for a given stream of
   documents, or the community determines that there are issues to be
   resolved in general for RFCs, or for per-stream requirements.

   In this model, the general approach is that the IAB will work with
   RFC Editor to get community input and it will approve changes by
   validating appropriate consideration of community requirements.

4.3.  Archiving and indexing

   The activity of archiving and indexing the RFC Series can be informed
   by series editing subject matter expertise.  It also is informed by
   requirements by the using community.  As long as the RFC Series is to
   remain coherent, there should be uniform archiving and indexing of
   RFCs across all streams.

4.3.1.  Definition

   In principle, there should be a community consensus document
   describing the archiving and indexing requirements for the RFC
   Series.  In practice, we continue with the archive as built by the
   capable RFC Editors since the series' inception.

   Any specific concrete requirements for the archive and index
   operation are the subject of agreements between the IASA and the RFC
   Editor (e.g., contracts, statement of work, service level agreement,
   etc).

4.3.2.  Operational Implementation

   The RFC Editor is responsible for ensuring the RFC archive and index
   are maintained appropriately.  The RFC Editor works with the IASA (in
   the form of the IAD) for regular reporting and feedback.

4.3.3.  Process Change

   Should there be a community move to propose changes to the
   requirements for the RFC archive and index, the IAB will work with
   RFC Editor to get community input and it will approve changes by
   validating appropriate consideration of community requirements.







Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 10]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


5.  RFC Streams

   Various contributors provide input to the RFC series.  These
   contributors come from several different communities, each with its
   own defined process for approving documents that will be published by
   the RFC Editor.  This is nothing new; however, over time, the various
   communities and document requirements have grown and separated.  In
   order to promote harmony in discussing the collective set of
   requirements, it is useful to recognize each in their own space --
   and they are referred to here as "streams".

   Note that by identifying separate streams, there is no intention of
   dividing them or undermining their management as one series.  Rather,
   the opposite is true -- by clarifying the constituent parts, it is
   easier to make them work together without the friction that sometimes
   arises when discussing various requirements today.

   The subsections below identify the streams that exist today.  There
   is no immediate expectation of new streams being created and it is
   preferrable that new streams *not* be created.  Creation of streams,
   and all policies surrounding general changes to the RFC Series, are
   discussed above in Section 4.

5.1.  RFC Approval Processes

   Processes for approval of documents (or requirements) for each stream
   are defined by the community that defines the stream.  The IAB is
   charged with the role of verifying that appropriate community input
   has been sought and that the changes are consistent with the RFC
   Series mission and this overall framework.

   The RFC Editor is expected to publish all documents passed to it
   after appropriate review and approval in one of the identified
   streams.

5.1.1.  IETF Document Stream

   The IETF document stream includes IETF WG documents as well as
   "individual submissions" sponsored by an IESG area director.  Any
   document being published as part of the IETF standards process must
   follow this stream.

   Approval of documents in this stream is defined by the IETF standards
   process (RFC2026, [3], and its successors).

   Changes to the approval process for this stream are made by updating
   the IETF standards process documents.




Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 11]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


5.1.2.  IAB Document Stream

   The IAB defines the processes by which it approves its documents.
   (This is currently defined on a web page.  Going forward, it will be
   published as an RFC.)

   Consistent with the above, any documents that the IAB wishes to
   publish as BCPs (part of the IETF standards track) are subject to the
   approval processes referred to in Section 5.1.1.

5.1.3.  IRTF Document Stream

   The IRTF is chartered as an activity of the IAB.  With the approval
   of the IAB, the IRTF may publish and update a process for publication
   of its own, non-IETF standards track, documents.

   Current document draft: draft-irtf-rfcs-00.txt

5.1.4.  Independent Submission Stream

   The RFC series has always served a broader Internet technical
   community than the IETF.  The "independent submission" stream is
   defined to provide review and (possible) approval of documents that
   are outside the scope of the streams identified above.

   Generally speaking, approval of documents in this stream falls under
   the purview of the RFC Editor.  Currently, the RFC Editor coordinates
   its publication review with the IESG as described in [4].

   Consistent with the rest of the streams, there needs to be a
   community consensus document to define that process.  The IAB will
   establish forum on which it will gauge community consensus for a
   document that defines the approval process for this stream.

   The current document under discussion is:
   draft-klensin-rfc-independent-02

5.2.  RFC Technical Publication Requirements

   The Internet engineering and research community has not only grown it
   has become more diverse, and sometimes more demanding.  The IETF, as
   a standards developing organization, has publication requirements
   that extend beyond those of an academic journal.  The IAB does not
   have the same interdependence with IANA assignments as the IETF
   stream does.  Therefore, there is the need to both codify the
   publishing requirements of each stream, and endeavour to harmonize
   them to the extent that is reasonable.




Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 12]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


   Therefore, it is expected that the community of effort behind each
   document stream will outline their technical publication
   requirements.

   As part of the RFC Editor oversight, the IAB must agree that the
   requirements are consistent with and implementable as part of the RFC
   Editor activity.

5.2.1.  IETF Documents

   These are defined in an IETF stream document.  The current proposed
   version is documented in draft-mankin-pub-req.

5.2.2.  IAB Documents

   Although they were developed for the IETF standards process, the IAB
   will identify the applicable requirements in in Section 5.2.1 for its
   stream.

   If the IAB elects to define other requirements, they should deviate
   minimally from those (in an effort to keep the collective technical
   publication requirements reasonably managed by one technical
   publisher).

5.2.3.  IRTF Documents

   Although they were developed for the IETF standards process, the IRTF
   will identify the applicable requirements in in Section 5.2.1 for its
   stream.

   If the IRTF elects to define other requirements, they should deviate
   minimally from those (in an effort to keep the collective technical
   publication requirements reasonably managed by one technical
   publisher).

5.2.4.  Independent Submissions

   Although they were developed for the IETF standards process, the RFC
   Editor will identify the applicable requirements in in Section 5.2.1
   for its stream.

   If the RFC Editor elects to define other requirements, they should
   deviate minimally from those (in an effort to keep the collective
   technical publication requirements reasonably managed by one
   technical publisher).






Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 13]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


6.  Security Considerations

   The processes for the publication of documents must prevent the
   introduction of unapproved changes.  Since the RFC Editor maintains
   the index of publications, sufficient security must be in place to
   prevent these published documents from being changed by external
   parties.












































Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 14]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


7.  IAB members at the time of approval

   To be filled in.

8.  References

   [1]  Carpenter, B., "Charter of the Internet Architecture Board
        (IAB)", RFC 2850, May 2000.

   [2]  Austein, R. and B. Wijnen, "Structure of the IETF Administrative
        Support Activity (IASA)", BCP 101, April 2005.

   [3]  Bradner, S., "The Internet Standards Process -- Revision 3",
        RFC 2026, October 1996.

   [4]  Alvestrand, H., "The IESG and RFC Editor Documents: Procedures",
        RFC 3932, October 2004.

   [5]  Chapin, L., "Charter of the Internet Architecture Board (IAB)",
        RFC 1358, August 1992.

   [6]  Huitema, C., "Charter of the Internet Architecture Board (IAB)",
        RFC 1601, March 1994.

   [7]  Editor, RFC., "30 Years of RFCs", RFC 2555, April 1999.


























Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 15]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


Appendix A.  A Retrospective of IAB Charters and RFC Editor

   With this document, the IAB's role with respect to the RFC Series and
   RFC Editor is being adjusted to work more directly with the RFC
   Editor and provide oversight to ensure the RFC Series mission
   principles and communities' input are addressed appropriately.

   This section provides an overview of the role of the IAB with respect
   to the RFC Editor as it has been presented in IAB Charter RFCs dating
   back to 1992.  The point of this section is that the IAB's role has
   historically been substantive -- whether it is supposed to be
   directly responsible for the RFC series' editorial management (c.
   1992), or appointment of the RFC Editor organization and approval of
   general policy (c. 2000).

A.1.  1992

   [5] says:

   [The IAB's] responsibilities shall include:
   [...]
         (2)  The editorial management and publication of the Request for
              Comments (RFC) document series, which constitutes the
              archival publication series for Internet Standards and
              related contributions by the Internet research and
              engineering community.

A.2.  1994

   [6] says:

   [The IAB's] responsibilities under this charter include:

      (d) RFC Series and IANA

         The IAB is responsible for editorial management and publication of
         the Request for Comments (RFC) document series, and for
         administration of the various Internet assigned numbers.

   which it elaborates as

      2.4 RFC Series and Assigned Numbers

         The RFC series constitutes the archival publication channel for
         Internet Standards and for other contributions by the Internet
         research and engineering community.  The IAB shall select an RFC
         Editor, who shall be responsible for the editorial management and
         publication of the RFC series.



Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 16]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


A.3.  2000

   [1], which is the most recent IAB Charter document, says:

      (d) RFC Series and IANA

      The RFC Editor executes editorial management and publication of the
      IETF "Request for Comment" (RFC) document series, which is the
      permanent document repository of the IETF.  The RFC series
      constitutes the archival publication channel for Internet Standards
      and for other contributions by the Internet research and engineering
      community. RFCs are available free of charge to anyone via the
      Internet. The IAB must approve the appointment of an organization to
      act as RFC Editor and the general policy followed by the RFC Editor.





































Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 17]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


Authors' Addresses

   Leslie L. Daigle
   Ed.

   Email: ledaigle@cisco.com, leslie@thinkingcat.com


   (IAB)

   Email: iab@iab.org
   URI:   http://www.iab.org/







































Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 18]


Internet-Draft           draft-iab-rfc-editor-01               July 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

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




Daigle & Internet Architecture Board  Expires January 26, 2007    [Page 19]