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).
AbstractThis 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.
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. RFC 2026  section 4.2.3. The procedure described in this document is compatible with that description.
RFC 3710  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. RFC 2434 ), 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.
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.
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. 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
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. RFC 2850 ), 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.
 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.  Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.  Alvestrand, H., "An IESG charter", RFC 3710, February 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- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.