Network Working Group                                      H. Alvestrand
Internet-Draft                                             July 15, 2004
Expires: January 13, 2005


             The IESG and RFC Editor documents: Procedures
                   draft-iesg-rfced-documents-03.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3667.

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

Copyright Notice

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

Abstract

   This document describes the IESG's procedures for handling documents
   submitted for RFC publication via the RFC Editor, subsequent to the
   changes proposed by the IESG at the Seoul IETF, March 2004.

   This document updates procedures described in RFC 2026 and RFC 3710.

1. Introduction and history

   There are a number of different methods by which an RFC is published,
   some of which include review in the Internet Engineering Task Force
   (IETF), and some of which include approval by the Internet



Alvestrand              Expires January 13, 2005                [Page 1]


Internet-Draft             IESG & RFCEd Docs                   July 2004


   Engineering Steering Group (IESG):
   o  IETF Working Group (WG) to Standards Track: Includes WG consensus,
      review in the IETF, IETF Last Call and IESG approval
   o  IETF Working Group to Experimental/Informational: Includes WG
      consensus, review in the IETF and IESG approval
   o  AD Sponsored to Standards Track: Includes review in the IETF, IETF
      Last Call and IESG approval
   o  AD Sponsored Individual to Experimental/Informational: Includes
      some form of review in the IETF and IESG approval
   o  Documents for which special rules exist
   o  RFC Editor documents to Experimental/Informational
   This memo is concerned with the IESG processing of the last category
   only.

   Special rules apply to some documents, including documents from the
   Internet Architecture Board (IAB), April 1st RFCs, and republication
   of documents from other standards development organizations. The IESG
   and the RFC Editor keep a running dialogue, in consultation with the
   IAB, on these other documents and classification of them, but they
   are outside the scope of this memo.

   For the last few years, the IESG has reviewed all RFC Editor
   documents (documents submitted by individuals to the RFC Editor for
   RFC publication) before publication. In 2003, this review was often a
   full scale review of technical content, with the ADs attempting to
   clear points with the authors, stimulate revisions of the documents,
   encourage the authors to contact appropriate working groups and so
   on. This was a considerable drain on the resources of the IESG, and
   since this is not the highest priority task the IESG members do, it
   often resulted in significant delays.

   In March 2004, the IESG decided to make a major change in this review
   model. The new review model will have the IESG take responsibility
   ONLY for checking for conflicts between the work of the IETF and the
   documents submitted; soliciting technical review is deemed to be the
   responsibility of the RFC Editor. If an individual IESG member
   chooses to review the technical content of the document, and finds
   issues, that member will communicate these issues to the RFC Editor,
   where they will be treated the same way as comments on the documents
   from other sources.

   Note: This document describes only the review process done by the
   IESG when the RFC Editor requests that review. There are many other
   interactions between document editors and the IESG - for instance, an
   AD may suggest that an author submit a document as input for work
   within the IETF rather than to the RFC Editor, or the IESG may
   suggest that a document submitted to the IETF is better suited for
   submission to the RFC Editor - but these interactions are not



Alvestrand              Expires January 13, 2005                [Page 2]


Internet-Draft             IESG & RFCEd Docs                   July 2004


   described in this memo.

2. Background material

   The review of independent submissions by the IESG was prescribed by
   RFC 2026 [1] section 4.2.3. The procedure described in this document
   is compatible with that description.

   RFC 3710 [4] section 5.2.2 describes the spring 2003 review process
   (even though the RFC was published in 2004); with the publication of
   this document, the procedure described in RFC 3710 is no longer
   relevant to documents submitted via the RFC Editor.

3. Detailed description of IESG review

   The RFC Editor reviews submissions for suitability for publications
   as RFC. Once the RFC Editor thinks a document may be suited for RFC
   publication, the RFC Editor asks the IESG to review the documents for
   conflicts with the IETF standards process or work done in the IETF
   community.

   The review is initiated by a note from the RFC Editor specifying the
   draft name, the RFC Editor's belief about the document's present
   suitability for publication, and (if possible) the list of people who
   have reviewed the document for the RFC Editor.

   The IESG may return five different responses, any of which may be
   accompanied by an IESG note to be put on the document if the RFC
   Editor wishes to publish.

   1.  The IESG has not found any conflict between this document and
       IETF work.
   2.  The IESG thinks that this work is related to IETF work done in WG
       <X>, but this does not prevent publishing.
   3.  The IESG thinks that publication is harmful to the IETF work done
       in WG <X>, and recommends not publishing the document at this
       time.
   4.  The IESG thinks that this document violates IETF procedures for
       <X>, and should therefore not be published without IETF review
       and IESG approval.
   5.  The IESG thinks that this document extends an IETF protocol in a
       way that requires IETF review, and should therefore not be
       published without IETF review and IESG approval.

   The last two cases are included for the case where a document
   attempts to do things (such as registering a new URI scheme) that
   require IETF consensus or IESG approval (as these terms are defined
   in RFC 2434 [2]), and the case where an IETF protocol is proposed to



Alvestrand              Expires January 13, 2005                [Page 3]


Internet-Draft             IESG & RFCEd Docs                   July 2004


   be changed or extended in an unanticipated way that may be harmful to
   the normal usage of the protocol, but where the protocol documents do
   not explicitly say that this type of extension requires IETF review.

   In the case of a document requiring IETF review, the IESG will offer
   the author the opportunity to ask for publication as an AD-sponsored
   individual document, which is subject to full IESG review including
   possible assignment to a WG or rejection. Redirection to the full
   IESG review path is not a guarantee that the IESG will accept the
   work item, or even that the IESG will give it any particular
   priority; it is a guarantee that the IESG will consider the document.

   The IESG will normally have review done within 4 weeks from the RFC
   Editor's notification. In the case of a possible conflict, the IESG
   may contact a WG or a WG chair for an outside opinion of whether
   publishing the document is harmful to the work of the WG, and in the
   case of a possible conflict with an IANA registration procedure, the
   IESG may contact the IANA expert for that registry.

   Note that if the IESG has not found any conflict between a submission
   and IETF work, then judging its technical merits, including
   considerations of possible harm to the Internet, will become the
   responsbility of the RFC Editor. The IESG assumes that the RFC
   Editor, in agreement with the IAB, will manage mechanisms for
   additional technical review.

4. Standard IESG note

   One of the following IESG notes will be sent to the RFC Editor for
   all documents with a request for placement either in or immediately
   following the "Status of this Memo" section of the finished RFC,
   unless the IESG decides otherwise:
   1.  For documents that specify a protocol or other technology, and
       that have been considered in the IETF at one time:

       The content of this RFC was at one time considered by the IETF,
       and therefore it may resemble a current IETF work in progress or
       a published IETF work. This RFC is not a candidate for any level
       of Internet Standard. The IETF disclaims any knowledge of the
       fitness of this RFC for any purpose, and in particular notes that
       the decision to publish is not based on IETF review for such
       things as security, congestion control or inappropriate
       interaction with deployed protocols.  The RFC Editor has chosen
       to publish this document at its discretion. Readers of this RFC
       should exercise caution in evaluating its value for
       implementation and deployment. See RFC XXXX for more information.
   2.  For documents that specify a protocol or similar technology, and
       are independent of the IETF process:



Alvestrand              Expires January 13, 2005                [Page 4]


       This RFC is not a candidate for any level of Internet Standard.
       The IETF disclaims any knowledge of the fitness of this RFC for
       any purpose, and in particular notes that the decision to publish
       is not based on IETF review for such things as security,
       congestion control or inappropriate interaction with deployed
       protocols.  The RFC Editor has chosen to publish this document at
       its discretion. Readers of this document should exercise caution
       in evaluating its value for implementation and deployment. See
       RFC XXXX for more information.
   3.  For documents that do not specify a protocol or similar
       technology:

       This RFC is not a candidate for any level of Internet Standard.
       The IETF disclaims any knowledge of the fitness of this RFC for
       any purpose, and notes that the decision to publish is not based
       on IETF review apart from IESG review for conflict with IETF
       work. The RFC Editor has chosen to publish this document at its
       discretion. See RFC XXXX for more information.
   NOTE TO RFC EDITOR: Please replace "RFC XXXX" with the actual RFC
   number of this document when published, and delete this sentence.

5. Examples of cases where publication is harmful

   This section gives a couple of examples where it might be appropriate
   to delay or prevent publishing of a document due to conflict with
   IETF work. It forms part of the background material, not a part of
   the procedure.

   Rejected Alternative Bypass: A WG is working on a solution to a
   problem, and a participant decides to ask for publication of a
   solution that the WG has rejected. Publication of the document will
   give the publishing party an RFC number to refer to before the WG is
   finished. It seems better to have the WG product published first, and
   have the non-adopted document published later, with a clear
   disclaimer note saying that "the IETF technology for this function is
   X". Example: Photuris (RFC 2522), which was published after IKE (RFC
   2409).

   Inappropriate Reuse of "free" Bits: In 2003, a proposal for an
   experimental RFC was published that wanted to reuse the high bits of
   the "fragment offset" part of the IP header for another purpose.
   There is no IANA consideration saying how these bits can be
   repurposed - but the standard defines a specific meaning for them.
   The IESG concluded that implementations of this experiment risked
   causing hard-to-debug interoperability problems, and recommended not
   publishing the document in the RFC series. The RFC Editor accepted
   the recommendation.

   Note: in general, the IESG has no problem with rejected alternatives
   being made available to the community; such publications can be a



Alvestrand              Expires January 13, 2005                [Page 5]


Internet-Draft             IESG & RFCEd Docs                   July 2004


   valuable contribution to the technical literature.  However, it is
   necessary to avoid confusion with the alternatives the working group
   did adopt.

   The RFC series is one of many available publication channels; this
   document takes no position on the question of which documents the RFC
   series is appropriate for - this is a matter for discussion in the
   IETF community.

6. IAB statement

   In its capacity as the body that approves the general policy followed
   by the RFC Editor (see RFC2850 [3]), the IAB has reviewed this
   proposal and supports it as an operational change that is in line
   with the respective roles of the IESG and RFC Editor.  The IAB
   continues to monitor the range of organized discussions within the
   IETF about potential adjustments to the IETF document publication
   processes (e.g., NEWTRK working group), and recognizes that the
   process described in this document, as well as other general IETF
   publication processes, and others may need to be adjusted in the
   light of the outcome of those discussions.

7. Security Considerations

   The process change described in this memo has no direct bearing on
   the security of the Internet.

8. Acknowledgements

   This document is a product of the IESG, and all its members deserve
   thanks for their contributions to it.

   This document has been reviewed in the IETF, by the RFC Editor and
   the IAB; the IAB produced the text of section 6. Special thanks go to
   John Klensin, Keith Moore, Pete Resnick, Scott Bradner, Kurt
   Zeilenga, Eliot Lear, Paul Hoffman, Brian Carpenter and all other
   IETF community members who provided valuable feedback on the
   document.

Normative references

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

Informative references

   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.



Alvestrand              Expires January 13, 2005                [Page 6]


Internet-Draft             IESG & RFCEd Docs                   July 2004


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

   [4]  Alvestrand, H., "An IESG charter", RFC 3710, February 2004.


Author's Address

   Harald Alvestrand

   EMail: harald@alvestrand.no

Appendix A. Changes from version -01 to -02

   This section should be removed by the RFC Editor.

   These changes were made to address comments raised during Last Call:
   o  Added more description of "special rules" to intro, and made it
      clearer that this memo doesn't describe those
   o  Added para at beginning of section 2 indicating that this document
      does not describe all IESG-author interactions
   o  Modified description of RFC Editor's work process at start of
      section 3
   o  Changed "IETF review" to "IETF review and IESG approval" in bullet
      4 and 5 of section 3
   o  Clarified relative roles of RFC Editor and IESG at end of section
      3
   o  Used formulation of "decision to publish is not based on IETF
      review" rather than "has not had IETF review" in standard IESG
      notes
   o  Added section 6 with an IAB statement
   o  Added this section

Appendix B. Changes from version -02 to -03

   This section should be removed by the RFC Editor.

   Added mention of 3710 and 2026 to the abstract

   Spelled out "IAB". Removed use of "SDO".

   Removed one example (Publish While Waiting)









Alvestrand              Expires January 13, 2005                [Page 7]


Internet-Draft             IESG & RFCEd Docs                   July 2004


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 IETF's procedures with respect to rights in IETF 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 (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.


Acknowledgment

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




Alvestrand              Expires January 13, 2005                [Page 8]