[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 3932) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5742

INTERNET DRAFT                                               H. Alvestrand
Obsoletes: 3932 (if approved)                                       Google
Updates: 3710, 2026 (if approved)                               R. Housley
Category: Best Current Practice (if approved)               Vigil Security
Expires: 16 May 2009                                      16 November 2009


IESG Procedures for Handling of Independent and IRTF Stream Submissions
                 <draft-housley-iesg-rfc3932bis-12.txt>


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/1id-abstracts.html

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

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.










Alvestrand & Housley                                            [Page 1]

RFC3932bis                 Update of RFC 3932              November 2009


Abstract

   This document describes the procedures used by the IESG for handling
   documents submitted for RFC publication on the Independent Submission
   and IRTF streams.

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

1.  Introduction and History

   RFC 4844 [N1] defines four RFC streams.  When a document is submitted
   for publication, the review that it receives depends on the stream in
   which it will be published.  The four streams defined in RFC 4844
   are:
      - The IETF stream
      - The IAB stream
      - The IRTF stream
      - The Independent Submission stream

   The IETF is responsible for maintaining the Internet Standards
   Process, which includes the requirements for developing, reviewing
   and approving Standards Track and BCP RFCs.  These RFCs, and any
   other IETF-generated Informational or Experimental documents, are
   reviewed by appropriate IETF bodies [N2] and published as part of the
   IETF Stream.

   Documents published in streams other than the IETF Stream might not
   receive any review by the IETF for such things as security,
   congestion control, or inappropriate interaction with deployed
   protocols.  Generally, there is no attempt for IETF consensus or IESG
   approval.  Therefore, the IETF disclaims, for any of the non-IETF
   Stream documents, any knowledge of the fitness of those RFCs for any
   purpose.

   IESG processing described in this document is concerned only with the
   last two categories, which comprise the Independent Submission Stream
   and the IRTF Stream, respectively [N1].

   Following the approval of RFC 2026 [N2] and prior to the publication
   of RFC 3932 [I1], the IESG reviewed all Independent Submission Stream
   documents before publication.  This review was often a full-scale
   review of technical content, with the Area Director (ADs) attempting
   to clear points with the authors, stimulate revisions of the
   documents, encourage the authors to contact appropriate working
   groups (WGs) and so on.  This was a considerable drain on the
   resources of the IESG, and since this was not the highest priority
   task of the IESG members, it often resulted in significant delays.




Alvestrand & Housley                                            [Page 2]

RFC3932bis                 Update of RFC 3932              November 2009


   In March 2004, the IESG decided to make a major change in this review
   model, with the IESG taking 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 AD chooses to review the technical
   content of the document and finds issues, that AD will communicate
   these issues to the RFC Editor, and they will be treated the same way
   as comments on the documents from other sources.

   Prior to 2006, documents from the IRTF were treated as either IAB
   submissions or individual submissions via the RFC Editor.  However,
   the Internet Research Steering Group (IRSG) has established a review
   process for the publication of RFCs on the IRTF Stream [I2].  Once
   these procedures are fully adopted, the IESG will be responsible only
   for checking for conflicts between the work of the IETF and the
   documents submitted, but results of the check will be reported to the
   IRTF.  These results may be copied to the RFC Editor as a courtesy.

   This document describes only the review process done by the IESG when
   the RFC Editor or the IRTF requests that review.  The RFC Editor will
   request the review of Independent Submission Stream documents, and
   the IRTF will request review of IRTF Stream documents.  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 as part of the
   Independent Submission Stream, or the IESG may suggest that a
   document submitted to the IETF is better suited for submission to the
   RFC Editor as part of Independent Submission Stream but these
   interactions are not described in this memo.

   For the convenience of the reader, this document includes description
   of some actions taken by the RFC Editor, the IAB, and the IRSG.  The
   inclusion of these actions is not normative.  Rather, these actions
   are included to describe the overall process surrounding the
   normative IESG procedures described in this document.  No RFC Editor,
   IAB, or IRSG procedures are set by this document.

1.1.  Changes since RFC 3932

   RFC 3932 provided procedures for the review of Independent Submission
   Stream submissions.  With the definition of procedures by the IRSG
   for the IRTF Stream, it has become clear that similar procedures
   apply to the review by the IESG of IRTF Stream documents.

   The IAB and the RFC Editor have made updates to the formatting of the
   title page for all RFCs [N3].  With these changes, the upper left
   hand corner of the title page indicates the stream that produced the
   RFC.  This label replaces some of the information that was previously



Alvestrand & Housley                                            [Page 3]

RFC3932bis                 Update of RFC 3932              November 2009


   provided in mandatory IESG notes on non-IETF-stream documents.

   The IESG may request the inclusion of an IESG note in an Independent
   Submission or IRTF Stream document to explain the specific
   relationship, if any, to IETF work.  In case there is a dispute about
   the content of the IESG note, this document provides a dispute
   resolution process.

2.  Background Material

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

   The procedures developed by the IRTF for documents created by the
   Research Groups also include review by the IESG [I2].

   The IESG Charter, RFC 3710 [I5], section 5.2.2 describes the review
   process that was employed in Spring 2003 (even though the RFC was not
   published until 2004); with the publication of RFC 3932 [I1], the
   procedure described in RFC 3710 was no longer relevant to documents
   submitted via the RFC Editor.  The publication of this document
   further updates section 5.2.2 of RFC 3710, now covering both the IRTF
   Stream and the Independent Submission Stream.

3.  Detailed Description of IESG Review

   The RFC Editor reviews Independent Submission Stream submissions for
   suitability for publication as RFCs.  As described in RFC 4846 [I3],
   the RFC Editor asks the IESG to review the documents for conflicts
   with the IETF standards process or work done in the IETF community.

   Similarly, documents intended for publication as part of the IRTF
   Stream are sent to the IESG for review for conflicts with the IETF
   standards process or work done in the IETF community [I2].

   The IESG review of these Independent Submission Stream and IRTF
   Stream documents reach one of the following five types of conclusion,
   any of which may be accompanied by a request to include an IESG note
   if the document is published.

   1. The IESG has concluded that there is no conflict between this
      document and IETF work.

   2. The IESG has concluded that this work is related to IETF work done
      in WG <X>, but this relationship does not prevent publishing.

   3. The IESG has concluded that publication could potentially disrupt



Alvestrand & Housley                                            [Page 4]

RFC3932bis                 Update of RFC 3932              November 2009


      the IETF work done in WG <X> and recommends not publishing the
      document at this time.

   4. The IESG has concluded that this document violates IETF procedures
      for <Y> and should therefore not be published without IETF review
      and IESG approval.

   5. The IESG has concluded 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 RFC headers and boilerplate is intended to describe the
   relationship of the document to the IETF standards process [N3].  In
   exceptional cases, when the relationship of the document to the IETF
   standards process might be unclear, the IESG may request the
   inclusion of an IESG note to clarify the relationship of the document
   to the IETF standards process.  Such a note is likely to include
   pointers to related IETF RFCs.  The dispute resolution process in
   Section 4 is provided to handle situation where the IRSG or RFC
   Editor is concerned with the content of the requested IESG note.

   The last two responses are included respectively, for the case where
   a document attempts to take actions (such as registering a new URI
   scheme) that require IETF Review, Standards Action, or IESG Approval
   (as these terms are defined in RFC 5226 [3]), and for the case where
   an IETF protocol is proposed to be changed or extended in a way not
   anticipated by the original authors that may be detrimental to the
   normal usage of the protocol, but where the protocol documents do not
   explicitly say that this type of extension requires IETF review.

   If a document requires 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 IETF 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 complete review within four weeks after
   notification by the RFC Editor or IRTF.  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
   that WG and, in the case of a possible conflict with an IANA
   registration procedure, the IANA expert for that registry.

   If the IESG does not find any conflict between an independent
   submission and IETF work, then the RFC Editor is responsible for
   judging the technical merits for that submission, including



Alvestrand & Housley                                            [Page 5]

RFC3932bis                 Update of RFC 3932              November 2009


   considerations of possible harm to the Internet.  If the IESG does
   not find any conflict between an IRTF submission and IETF work, then
   the IRSG is responsible for judging the technical merits for that
   submission, including considerations of possible harm to the
   Internet.

   The RFC Editor, in agreement with the IAB, shall manage mechanisms
   for appropriate technical review of independent submissions.
   Likewise, the IRSG, in agreement with the IAB, shall manage
   mechanisms for appropriate technical review of IRTF submissions.

4.  Dispute Resolution

   Experience has shown that the IESG and the RFC Editor have worked
   well together regarding publication recommendations and IESG notes.
   Where questions have arisen, they have been quickly resolved when all
   parties become aware of the concerns.  However, should a dispute ever
   arise, a third party can assist with resolution.  Therefore, this
   dispute procedure has an informal dialogue phase followed by an
   arbitration phase if the matter remains unresolved.

   If IESG requests the inclusion of an IESG note and the IRSG or the
   RFC Editor intends to publish the document without the requested IESG
   note, then they must provide a clear and concise description of the
   concerns to the IESG before proceeding.  A proposal for alternate
   IESG note text from the IRSG or the RFC Editor is highly encouraged.

   If the IESG does not want the document to be published without the
   requested IESG note, then the IESG must initiate an informal
   dialogue.  The dialogue should not take more than six weeks.  This
   period of time allows the IESG to conduct an IETF Last Call
   concerning the content of the requested IESG note (and not on the
   document as a whole) to determine community consensus if desired.  At
   the end of the dialogue, the IESG can reaffirm the original IESG
   note, provide an alternate IESG note, or withdraw the note
   altogether.  If an IESG note is requested, the IRSG or the RFC Editor
   must state whether they intend to include it.

   If dialogue fails to resolve IRSG or RFC Editor concerns with the
   content of a requested IESG note and they intend to publish the
   document as an RFC without the requested IESG note, then the IESG can
   formally ask the IAB to provide arbitration.  The IAB is not
   obligated to perform arbitration and may decline the request.  If the
   IAB declines, the RFC Editor decides whether the IESG note is
   included.  If the IAB accepts, the IAB review will occur according to
   procedures of the IAB's own choosing.  The IAB can direct the
   inclusion of the IESG note, direct the withdrawal of the IESG note,
   or leave the final decision to the RFC Editor.  Unlike the IAB



Alvestrand & Housley                                            [Page 6]

RFC3932bis                 Update of RFC 3932              November 2009


   reviews specified in RFC 4846 [I3], if the IAB directs the inclusion
   or withdrawal the IESG note, the IAB decision is binding, not
   advisory.

5.  Examples of Cases Where Publication Is Harmful

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

   Rejected Alternative Bypass:

      As a WG is working on a solution to a problem, a participant
      decides to ask for Independent Submission Stream publication of a
      solution that the WG has rejected.  Publication of the document
      will give the publishing party an RFC number 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).

      Note: in general, the IESG has no problem with rejected
      alternatives being made available to the community; such
      publications can be a valuable contribution to the technical
      literature.  However, it is necessary to avoid confusion with the
      alternatives adopted by the WG.

   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.  No IANA consideration says 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.

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





Alvestrand & Housley                                            [Page 7]

RFC3932bis                 Update of RFC 3932              November 2009


6.  IAB Statement

   In its capacity as the body that approves the general policy followed
   by the RFC Editor (see RFC 2850 [I4]), the IAB has reviewed this
   proposal and supports it as an operational change that is in line
   with the respective roles of the IESG, IRTF, and RFC Editor.  The IAB
   continues to monitor discussions within the IETF about potential
   adjustments to the IETF document publication processes and recognizes
   that the process described in this document, as well as other general
   IETF publication processes, may need to be adjusted to align with any
   changes that result from such discussions.

7.  Security Considerations

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

8.  Acknowledgements

   RFC 3932 was a product of the IESG in October 2004, and it was
   reviewed in the IETF, by the RFC Editor, and by the IAB.  Special
   thanks for the development of RFC 3932 go to John Klensin, Keith
   Moore, Pete Resnick, Scott Bradner, Kurt Zeilenga, Eliot Lear, Paul
   Hoffman, Brian Carpenter, and all other IETF community participants
   who provided valuable feedback.

   This update to RFC 3932 was the product of the IESG in July and
   August of 2008, and it was reviewed in the IETF, by the RFC Editor,
   by the IRSG, and by the IAB.  Special thanks for the development of
   this update go to (in alphabetical order) Jari Arkko, Ran Atkinson,
   Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin,
   Olaf Kolkman, and Andy Malis.

9.  References

9.1.  Normative Reference

   [N1]  Internet Architecture Board and L. Daigle, Ed., "The RFC Series
         and RFC Editor", RFC 4844, July 2007.

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

   [N3]  Internet-Draft: draft-iab-streams-headers-boilerplates, work in
         progress.






Alvestrand & Housley                                            [Page 8]

RFC3932bis                 Update of RFC 3932              November 2009


9.2.  Informative References

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

   [I2]  Internet-Draft: draft-irtf-rfcs, work in progress.

   [I3]  Klensin, J., and D. Thaler, "Independent Submissions to the RFC
         Editor", RFC 4846, July 2007.

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

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

Authors' Address

   Harald Alvestrand
   EMail: harald@alvestrand.no

   Russell Housley
   Email: housley@vigilsec.com




























Alvestrand & Housley                                            [Page 9]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/