Network Working Group H. Alvestrand Internet-Draft March 6, 2004 Expires: September 4, 2004 The IESG and RFC Editor documents: Procedures draft-iesg-rfced-documents-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3667. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 4, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document gives 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. NOTE IN DRAFT: These guidelines are proposed, not adopted. Comments are welcome - please send them to iesg@ietf.org. 1. Introduction and history For several years years, the IESG has reviewed all documents submitted by individuals for RFC publication ("RFC Editor documents") Alvestrand Expires September 4, 2004 [Page 1] Internet-Draft IESG & RFCEd Docs March 2004 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 the IESG members do, 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 for checking for conflicts between the work of the IETF and the documents submitted ONLY; soliciting technical review is deemed to be the responsibility of the RFC Editor. If an IESG member has issues with the technical content of the document, that member will communicate these issues to the RFC Editor, where they will be treated the same way as comments on the documents from other sources. 2. Background material The review of independent submissions by the IESG was prescribed by RFC 2026 [1] section 4.2.3 and RFC 2418 [2] section 8. RFC 3710 [3] section 5.2.2 describes the spring 2003 review process; with the publication of this document, that section is no longer relevant to documents submitted via the RFC Editor. 3. Detailed description of IESG review The IESG will review all documents submitted through the RFC Editor 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 draft 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, all of which may be accompanied by an IESG note to be put on the document if the RFC Editor wishes to publish. o The IESG has not found any conflict between this document and IETF work. o The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing. o The IESG thinks that publication is harmful to the IETF work done in WG , and recommends not publishing the document at this time. o The IESG thinks that this document violates IETF procedures for , and should therefore not be published without IETF review. Alvestrand Expires September 4, 2004 [Page 2] Internet-Draft IESG & RFCEd Docs March 2004 o 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. The last two cases are included for the case where a document attempts to do things (such as URI scheme definition) that require IETF consensus or IESG approval, and 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. (NOTE IN DRAFT - the examples section should have an example of this case.) In the case of a document requiring 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. (NOTE IN DRAFT: it's unfair to say "you can't publish it there, and we refuse to take it there" - so if we reject publication without IETF review, we have to offer the opportunity for IETF review....) The IESG will attempt to 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 IESG may contact the IANA expert for that registry; in these cases up to 8 weeks may be required, and the RFC Editor will be sent a note saying that the IESG is consulting with about the document. Note that judging the technical merits of submissions, including considerations of possible harm to the Internet, will become solely the responsbility of the RFC Editor. The IESG assumes that the RFC Editor will create its own 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, unless the IESG decides otherwise: o For documents that have been considered in the IETF at one time: This document 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 document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document for any purpose, and in particular notes that it is not known to have had IETF review for security, congestion control or inappropriate interaction with deployed Alvestrand Expires September 4, 2004 [Page 3] Internet-Draft IESG & RFCEd Docs March 2004 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. o For documents that are independent of the IETF process: This document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document for any purpose, and in particular notes that it is not known to have had IETF review for 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. 5. Examples of cases where publication is harmful This section gives a couple of examples where it might be appropriate to delay or prevent publishing of a document due to conflict with IETF work. It forms part of the background material, not a part of the procedure. Publish While Waiting: In 2003, the V6OPS WG was working on establishing evaluation criteria for the family of mechanisms known as "IPv6 transition mechanisms". The author of one of these mechanisms asked for publication as Experimental. The judgment of the WG chairs at the time was that publication of this document would remove sufficient energy from the group that the evaluation criteria work would not be finished, and the IETF would be unable to make a well thought out choice between mechanisms to pursue. Thus, the WG asked for this document not to be published at that time. 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. There is no IANA consideration saying how these bits can be repurposed - but the standard defines a 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 Alvestrand Expires September 4, 2004 [Page 4] Internet-Draft IESG & RFCEd Docs March 2004 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 - this is a matter for discussion in the IETF community. 6. Security Considerations The process change described in this memo has no bearing on the security of the Internet. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. [3] Alvestrand, H., "An IESG Charter", February 2004. Author's Address Harald Alvestrand EMail: harald@alvestrand.no Alvestrand Expires September 4, 2004 [Page 5] Internet-Draft IESG & RFCEd Docs March 2004 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Alvestrand Expires September 4, 2004 [Page 6]