INTERNET DRAFT H. Alvestrand Obsoletes: 3932 (if approved) Google Updates: 3710, 2026 (if approved) R. Housley Category: Best Current Practice (if approved) Vigil Security Exipres: 18 May 2009 18 November 2008 IESG Procedures for Handling of Independent and IRTF Stream Submissions Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 Abstract This document describes the procedures used by the IESG for handling documents submitted for RFC publication on the Independent and IRTF streams. This document updates procedures described in RFC 2026 and RFC 3710. {{{ RFC Editor: Please change "RFC XXXX" to the number assigned to this document prior to publication. }}} 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 Alvestrand & Housley [Page 1] RFC3932bis Update of RFC 3932 November 2008 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 and published as part of the IETF Stream. Documents published in streams other than the IETF Stream may 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. This memo is only concerned with the IESG processing of the last two categories, which comprise the Independent Submission Stream and the IRTF Document 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. 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 Alvestrand & Housley [Page 2] RFC3932bis Update of RFC 3932 November 2008 process for the publication of RFCs on the IRTF Document Stream [I2]. Once these procedures are fully adopted, the IESG will continue to 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. 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. 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 Document Stream, it has become clear that similar procedures apply to the review by the IESG of IRTF Document 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 eliminates the need for a mandatory IESG note on all Independent Submission and IRTF Stream documents. 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 RFC 3710, section 5.2.2 so that it covers the IRTF stream and the Individual Submission Stream. Alvestrand & Housley [Page 3] RFC3932bis Update of RFC 3932 November 2008 3. Detailed Description of IESG Review The RFC Editor reviews Independent Stream submissions for suitability for publications as RFC. 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 Stream and IRTF Stream documents reach one of the following five types of conclusions. 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 , but this relationship does not prevent publishing. 3. The IESG has concluded that publication could potentially disrupt the IETF work done in WG and recommends not publishing the document at this time. 4. The IESG has concluded that this document violates IETF procedures for 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. Generally, the RFC headers and boilerplate clearly 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 response may be accompanied by a clarifying IESG note and a request that the RFC Editor include the IESG note in the document if the document is published. 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 an unanticipated way 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. Alvestrand & Housley [Page 4] RFC3932bis Update of RFC 3932 November 2008 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 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. 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 RFC publication, as part of the Independent Stream, 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 Alvestrand & Housley [Page 5] RFC3932bis Update of RFC 3932 November 2008 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. 5. 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. 6. Security Considerations The process change described in this memo has no direct bearing on the security of the Internet. 7. 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 Alvestrand & Housley [Page 6] RFC3932bis Update of RFC 3932 November 2008 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 this development of this update go to (in alphabetical order) Jari Arkko, Ran Atkinson, Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, and Olaf Kolkman. 8. References 8.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. 8.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 7] RFC3932bis Update of RFC 3932 November 2008 Copyright and IPR Statements Copyright (C) The IETF Trust (2008). 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 translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 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, THE IETF TRUST 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. 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 procedures with respect to rights in RFC 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. Alvestrand & Housley [Page 8] RFC3932bis Update of RFC 3932 November 2008 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. Alvestrand & Housley [Page 9]