Network Working Group A. Falk Internet-Draft IRTF Chair Expires: August 30, 2006 February 26, 2006 IRTF Research Group RFCs draft-irtf-rfcs-00.txt 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/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 August 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a process for research groups in the Internet Research Task Force to publish RFCs. Falk Expires August 30, 2006 [Page 1] Internet-Draft IRTF RFCs February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Process Model . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Research Group Preparation . . . . . . . . . . . . . . . . 4 2.2. Document Shepherds . . . . . . . . . . . . . . . . . . . . 4 2.3. Submission to the IRSG . . . . . . . . . . . . . . . . . . 5 2.4. IRSG Review . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. RFC Editor Handling . . . . . . . . . . . . . . . . . . . 5 2.6. IESG Handling . . . . . . . . . . . . . . . . . . . . . . 6 2.7. Exiting . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. Informative References . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Falk Expires August 30, 2006 [Page 2] Internet-Draft IRTF RFCs February 2006 1. Introduction This is proposal for a document process for the Internet Research Task Force (IRTF) [RFC2014]. Most documents undergoing this process will come from IRTF Research Groups and the objective is that they are published as RFCs by the RFC Editor. Currently, the IRTF Research Group drafts are treated like independent submissions by the RFC Editor. Roughly, the process consists of the following steps: o The document author submits an Internet Draft to the RFC Editor as an independent submission. o The RFC Editor performs independent submission review (ISR) for editorial acceptability and may request the authors revise the document before publishing. o The IESG performs a review (to avoid standards process end- arounds) and inserts a disclaimer (see RFC3932[RFC3932]). o Independent submissions are delayed by lower priority treatment as they move through the RFC Editor's queue. This proposal changes the following: o The RFC Editor's ISR review o IRTF document publication priority in the RFC Editor queue o The RFC3932 disclaimer placed on non-IETF documents by the Internet Engineering Steering Group The IRTF plans a trial of this process for several several documents after which this draft may be updated or published. Falk Expires August 30, 2006 [Page 3] Internet-Draft IRTF RFCs February 2006 2. Process Model The IRTF shall use the process for IETF-sponsored individual submissions (sometimes called AD-sponsored individual submissions) as a model for IRTF document handling. From time to time, individuals will approach a member of the IESG to publish a document that is not the product of an IETF working group. These documents do not receive RFC3932 disclaimers, do not receive low priority treatment by the RFC Editor, and do not experience ISR review. However, they do receive a thorough review by the IESG. For non-standards documents (yes, there are rare cases of non-wg standards documents), the sponsoring AD gives the document a thorough review, sometimes requiring expert reviews or IETF-wide last calls, if the topic seems to warrant broad review. The bottom line is that a set of experienced, responsible folks give the document a thorough review before publishing it as an "IETF product". This proposal adapts the above process to the IRTF as described in the following sections. The RFC Editor and the IAB have reviewed the procedure below and fully support it. 2.1. Research Group Preparation An RG decides to publish a document using the IRTF publication track. The RG performs a review for editorial and technical content. The document should have a statement in the abstract identifying the document as the product of the RG and a paragraph in the first section describing the level of support for the document (e.g., "this document represents the consensus of the FOOBAR RG", "the views in this document were considered controversial by the FOOBAR RG but the RG reached a consensus that the document should still be published") and the breadth of review for the document. I.e., was this document read by all the active contributors, 3 people, or folks who are not "in" the RG but are expert in the area? It should also be very clear throughout the document that it is not an IETF product and is not a standard. If an experimental protocol is described appropriate caveats need to be present. 2.2. Document Shepherds Documents should have a shepherd. This is a relatively new concept developed in the IETF to ensure that issues raised in the review and publication process (e.g., by the IESG and RFC Editor) are responded to in a timely manner. The IETF shepherding process is described in [I-D.ietf-proto-wgchair-doc-shepherding] and should be adapted to the IRTF publication process as some items in the draft will not apply. Falk Expires August 30, 2006 [Page 4] Internet-Draft IRTF RFCs February 2006 2.3. Submission to the IRSG The sponsoring RG chair brings the document to the IRSG for publication. The expectation is that the RG chair has already reviewed the draft thoroughly and considers it of publishable quality editorially and technically. The RG should be copied on the mail message requesting IRSG review. 2.4. IRSG Review A (firm) eight-week IRSG review period follows after which a poll is taken. Reviews should be similar to that for a conference paper. Votes can be: o 'ready to publish' -- requires a thorough read and reasonably detailed review o 'not ready to publish' -- requires a thorough read, reasonably detailed review, and actionable comments. o 'no objection' -- I don't object if this document goes forward; I've read the document (perhaps quickly); I have some small comments which are not show stoppers; I don't have great expertise in the area. o 'request more time to review' -- a commitment to to provide a thorough review in a specified period of time. Reviews should be written to be public. In particular, they should be sent to the submitted RG mailing list. (We may need a tracker of some sort to collect reviews.) At least two other IRSG members (besides the one sponsoring the document) need to vote 'ready to publish' for the document to move forward. Any vote of 'not ready to publish' will hold a document's progress until the comments are addressed. The IRTF chair may choose to override 'not ready to publish' holds that, in the opinion of the chair, have received an adequate response. 2.5. RFC Editor Handling The document is submitted to the RFC Editor who does not perform an ISR review. The RFC Editor sends it to the IESG for an RFC3932 review. There are several reasons why the IESG may block a document, described in RFC3932 section 4. (The document shepherd should be responsible for checking the IETF datatracker for IESG blocking and non-blocking comments and forward them to the RG.) Falk Expires August 30, 2006 [Page 5] Internet-Draft IRTF RFCs February 2006 2.6. IESG Handling Rather than the disclaimers found in RFC3932, the IESG will instruct the RFC Editor to add the following disclaimer: "This RFC is a product of the Internet Research Task Force and is not a candidate for any level of Internet Standard. The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment." For documents that specify a protocol or other technology, and that have been considered in the IETF at one time: "This RFC is a product of the Internet Research Task Force. 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. However, this is not an IETF document is not a candidate for any level of Internet Standard. The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment." (These disclaimers will require approval by the IESG.) 2.7. Exiting The document enters the RFC Editor queue at the same priority as IETF documents. The document shepherd is responsible for ensuring that the document authors are responsive to the RFC Editor and that the RFC editing process goes smoothly. Falk Expires August 30, 2006 [Page 6] Internet-Draft IRTF RFCs February 2006 3. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Falk Expires August 30, 2006 [Page 7] Internet-Draft IRTF RFCs February 2006 4. Security Considerations There are no security considerations in this document. Falk Expires August 30, 2006 [Page 8] Internet-Draft IRTF RFCs February 2006 5. Acknowledgements Many thanks for Mark Allman, Bob Braden, Leslie Daigle, and Allison Mankin who contributed to preparation of this process. 6. Informative References [I-D.ietf-proto-wgchair-doc-shepherding] Levkowetz, H. and D. Meyer, "Protocol Pilot: Workgroup Chair Followup of AD Evaluation Comments", draft-ietf-proto-wgchair-doc-shepherding-00 (work in progress), July 2004. [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, October 1996. [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004. Falk Expires August 30, 2006 [Page 9] Internet-Draft IRTF RFCs February 2006 Author's Address Aaron Falk IRTF Chair 4676 Admiralty Way, Suite 1001 Marina Del Rey, California 90292 USA Phone: +1-310-448-9327 Email: falk@isi.edu Falk Expires August 30, 2006 [Page 10] Internet-Draft IRTF RFCs February 2006 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 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. 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 (2006). 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. Falk Expires August 30, 2006 [Page 11]