summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3932.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3932.txt')
-rw-r--r--doc/rfc/rfc3932.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3932.txt b/doc/rfc/rfc3932.txt
new file mode 100644
index 0000000..4cfac8b
--- /dev/null
+++ b/doc/rfc/rfc3932.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group H. Alvestrand
+Request for Comments: 3932 October 2004
+BCP: 92
+Updates: 3710, 2026
+Category: Best Current Practice
+
+
+ The IESG and RFC Editor Documents: Procedures
+
+Status of this Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+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
+ 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 WG to Experimental/Informational: Includes WG consensus,
+ review in the IETF, and IESG approval
+
+ o Area Director (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
+
+
+
+
+Alvestrand Best Current Practice [Page 1]
+
+RFC 3932 IESG and RFC Editor Documents: Procedures October 2004
+
+
+ o RFC Editor documents to Experimental/Informational
+
+ This memo is only concerned with the IESG processing of the last
+ category.
+
+ 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 their classification, 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 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. 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,
+ and 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 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.
+
+
+
+
+
+Alvestrand Best Current Practice [Page 2]
+
+RFC 3932 IESG and RFC Editor Documents: Procedures October 2004
+
+
+ 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
+ document 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 responses are included respectively, for the case where
+ a document attempts to take actions (such as registering a new URI
+ scheme) that require IETF consensus or IESG approval (as these terms
+ are defined in RFC 2434 [2]), and for the case where an IETF protocol
+ is proposed to 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.
+
+
+
+
+Alvestrand Best Current Practice [Page 3]
+
+RFC 3932 IESG and RFC Editor Documents: Procedures October 2004
+
+
+ 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 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
+ 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
+ responsibility 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 3932 for more information.
+
+
+
+
+
+
+
+
+Alvestrand Best Current Practice [Page 4]
+
+RFC 3932 IESG and RFC Editor Documents: Procedures October 2004
+
+
+ 2. For documents that specify a protocol or similar technology and
+ are independent of the IETF process:
+
+ 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 3932 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 3932 for more information.
+
+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: 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. No
+ IANA consideration says how these bits can be repurposed, but the
+ standard defines a specific meaning for them. The IESG concluded
+
+
+
+
+Alvestrand Best Current Practice [Page 5]
+
+RFC 3932 IESG and RFC Editor Documents: Procedures October 2004
+
+
+ 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
+ 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. That 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 RFC 2850 [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, 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.
+
+ This document has been reviewed in the IETF and 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.
+
+
+
+
+
+
+
+Alvestrand Best Current Practice [Page 6]
+
+RFC 3932 IESG and RFC Editor Documents: Procedures October 2004
+
+
+9. References
+
+9.1. Normative Reference
+
+ [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+9.2. Informative References
+
+ [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+ [3] Internet Architecture Board and B. Carpenter, Ed., "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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alvestrand Best Current Practice [Page 7]
+
+RFC 3932 IESG and RFC Editor Documents: Procedures October 2004
+
+
+Full 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.
+
+ 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.
+
+Intellectual Property
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Alvestrand Best Current Practice [Page 8]
+