summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5742.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5742.txt')
-rw-r--r--doc/rfc/rfc5742.txt507
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]
+