doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc5742.txt b/doc/rfc/rfc5742.txt
new file mode 100644
index 0000000..c646c68
--- /dev/null
+++ b/doc/rfc/rfc5742.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     H. Alvestrand
+Request for Comments: 5742                                        Google
+BCP: 92                                                       R. Housley
+Obsoletes: 3932                                           Vigil Security
+Updates: 2026, 3710                                        December 2009
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+                           IESG Procedures for
+            Handling of Independent and IRTF Stream Submissions
+
+Abstract
+
+   This document describes the procedures used by the IESG for handling
+   documents submitted for RFC publication from the Independent
+   Submission and IRTF streams.
+
+   This document updates procedures described in RFC 2026 and RFC 3710.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at http://www.rfc-
+   editor.org/info/rfc5742.
+
+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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+
+Alvestrand & Housley     Best Current Practice                  [Page 1]
+
+RFC 5742                   Update to RFC 3932              December 2009
+
+
+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 Directors (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 because this was not the highest priority
+   task of the IESG members, it often resulted in significant delays.
+
+   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
+
+
+
+
+
+Alvestrand & Housley     Best Current Practice                  [Page 2]
+
+RFC 5742                   Update to RFC 3932              December 2009
+
+
+   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 Independent Submissions via the RFC Editor.  However,
+   the Internet Research Steering Group (IRSG) has established a review
+   process for the publication of RFCs from 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
+   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
+
+
+
+Alvestrand & Housley     Best Current Practice                  [Page 3]
+
+RFC 5742                   Update to RFC 3932              December 2009
+
+
+   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
+   and the Independent Submission streams.
+
+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 and IRTF stream
+   documents results in 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
+      the IETF work done in WG <X> and recommends not publishing the
+      document at this time.
+
+
+
+
+
+
+Alvestrand & Housley     Best Current Practice                  [Page 4]
+
+RFC 5742                   Update to RFC 3932              December 2009
+
+
+   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 [N3] is intended to describe the
+   relationship of the document to the IETF standards process.  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 situations in which 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 [I6]), and for the case where
+   there is a proposed change or extension to an IETF protocol that was
+   not anticipated by the original authors and 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 of
+   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
+   considerations of possible harm to the Internet.  If the IESG does
+   not find any conflict between an IRTF submission and IETF work, then
+
+
+
+Alvestrand & Housley     Best Current Practice                  [Page 5]
+
+RFC 5742                   Update to RFC 3932              December 2009
+
+
+   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 the 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
+   reviews specified in RFC 4846 [I3], if the IAB directs the inclusion
+
+
+
+
+Alvestrand & Housley     Best Current Practice                  [Page 6]
+
+RFC 5742                   Update to RFC 3932              December 2009
+
+
+   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     Best Current Practice                  [Page 7]
+
+RFC 5742                   Update to RFC 3932              December 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 (in alphabetical order)
+   Scott Bradner, Brian Carpenter, Paul Hoffman, John Klensin, Eliot
+   Lear, Keith Moore, Pete Resnick, Kurt Zeilenga, 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]  Daigle, L., Ed., and Internet Architecture Board, "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]  Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers,
+         and Boilerplates", RFC 5741, December 2009.
+
+
+
+
+
+
+Alvestrand & Housley     Best Current Practice                  [Page 8]
+
+RFC 5742                   Update to RFC 3932              December 2009
+
+
+9.2.  Informative References
+
+   [I1]  Alvestrand, H., "The IESG and RFC Editor Documents:
+         Procedures", BCP 92, RFC 3932, October 2004.
+
+   [I2]  Falk, A., "Definition of an Internet Research Task Force (IRTF)
+         Document Stream", RFC 5743, December 2009.
+
+   [I3]  Klensin, J., Ed., and D. Thaler, Ed., "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.
+
+   [I6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
+
+Authors' Address
+
+   Harald Alvestrand
+   EMail: harald@alvestrand.no
+
+   Russell Housley
+   EMail: housley@vigilsec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand & Housley     Best Current Practice                  [Page 9]
+