Network Working Group J. Klensin, Ed. Internet-Draft October 20, 2006 Intended status: Informational Expires: April 23, 2007 Independent Submissions to the RFC Editor draft-klensin-rfc-independent-03.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 April 23, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract There is a long-term tradition in the Internet community, predating the IETF by many years, of use of the RFC series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "independent submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the independent submission model, some reasons why it is important, and describes editorial and Klensin Expires April 23, 2007 [Page 1] Internet-Draft Independent Submissions October 2006 processing norms that can be used for independent submissions as we go forward into new relationships between the IETF community and its primary technical publisher. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology Note . . . . . . . . . . . . . . . . . . . . . 3 1.2. Context and Philosophical Assumptions . . . . . . . . . . 4 2. The Role of Independent Submissions . . . . . . . . . . . . . 4 3. Submission . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Posting of Draft . . . . . . . . . . . . . . . . . . . . . 6 4.2. Request for Publication . . . . . . . . . . . . . . . . . 6 4.3. Initial RFC Editor Review . . . . . . . . . . . . . . . . 6 4.4. Document Rejection . . . . . . . . . . . . . . . . . . . . 6 4.5. Review and Evaluation . . . . . . . . . . . . . . . . . . 7 4.6. Unsolicited Reviews . . . . . . . . . . . . . . . . . . . 7 4.7. Additional Reviews . . . . . . . . . . . . . . . . . . . . 7 4.8. Formal IESG Review . . . . . . . . . . . . . . . . . . . . 7 4.9. Final Decision and Notification . . . . . . . . . . . . . 8 4.10. Intellectual Property Rights . . . . . . . . . . . . . . . 9 4.11. Final Editing and Publication . . . . . . . . . . . . . . 9 5. The Editorial Review Board . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Changes since version -02 . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Klensin Expires April 23, 2007 [Page 2] Internet-Draft Independent Submissions October 2006 1. Introduction There is a long-term tradition in the Internet community, predating the IETF by many years, of use of the RFC series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "independent submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the independent submission model, some reasons why it is important, and describes editorial and processing norms that can be used for independent submissions as we go forward into new relationships between the IETF community and its primary technical publisher. To understand the perspective of this document, it is important to remember that the RFC-Editor function predates the creation of the IETF. As of the time of this writing, the RFC series goes back 36 years while the IETF is celebrating its 20th anniversary. All of the documents that were published before the IETF was created, and for some years thereafter, would be considered independent submissions today. As the IETF evolved, the IAB and then the IETF itself chose to publish IETF documents as RFCs while fully understanding that the RFC-Editor function was an independent publication mechanism. Other decisions were possible: e.g., the IETF could have decided to create it own publication series. It was felt that there was considerable value in continuing to publish the IETF work in the same series as the one used to publish the basic protocols for the Internet. 1.1. Terminology Note This document describes what have historically been referred to a "independent submissions". That term is distinguished from those IETF and IAB community documents that originate from formal groups -- IAB, IRTF, IETF WGs -- and from submissions submitted to the IESG for standards-track, informational, or experimental processing. Documents produced by individuals, rather than IETF WGs or others IETF-affiliated groups, but submitted for publication under Area Director sponsorship, have been known historically as "individual submissions". For convenience and obvious historical reasons, the editor and publisher of documents that are not processed through the IETF is known below as the "RFC Editor". The RFC Editor will typically by an organization or one or more senior people and associated staff, and the term is used collectively below. That term is not intended to predict the future, either in terms of who does the job or what they, or the document series, are called. Klensin Expires April 23, 2007 [Page 3] Internet-Draft Independent Submissions October 2006 1.2. Context and Philosophical Assumptions This document contains text that, if agreed to by the community, may suggest a reexamination of and a corresponding update to RFC 3932 [RFC3932]. Those issues, and proposals for changes, are discussed in a different document [RFC3932upd], but they are semi-independent of the content of this document, which focuses on the review and approval process for independent submissions. This document complements the discussion and guidelines in [RFC4714], which focuses on standards track documents. It takes a somewhat stronger view than the discussions that lead up to that document, starting from the belief that independent submissions are most valuable if they are, in fact, independent of the IETF process. From the perspective of the IETF, independent submissions are especially important as checks on the IETF processes even though such checks are not the only, or even a common, reason for them. That role is compromised if IETF-related entities are able to block or deprecate such documents to a degree beyond that needed to avoid difficulties with the standards process. 2. The Role of Independent Submissions When the RFC series was fairly new, RFCs could be used to publish general papers on networking as well as the types of documents we would describes as standards today. Those roles also developed as part of the early design and development of the ARPANET, long before anyone dreamt of the IETF and when the distinction between, e.g., standards and informational documents was less precisely drawn. In more recent years, independent submissions have become important for multiple reasons, some of them relatively new. They include: o Discussion of Internet-related technologies that are not part of the IETF agenda. o Introduction of important new ideas as a bridge publication venue between academia and IETF engineering. o Informational discussions of technologies, options, or experience with protocols. o Informational publication of vendor-specific protocols. o Critiques and discussions of alternatives to IETF standards-track protocols. The potential for such critiques provides an important check on the IETF's standards processes and should be seen in that light. o Documents considered by IETF Working Groups but not standardized. While many documents of this type are published via the IESG approval path (see RFC 3932, Section 1 [RFC3932]), the independent submission path has traditionally been open to them. Because of Klensin Expires April 23, 2007 [Page 4] Internet-Draft Independent Submissions October 2006 their intimate connection to the IETF Standards Process and WG activites and the consequent sensitivity to exact statements of relationships and to timing, there is reason to believe that all such documents should be published only at IESG request. In any event, these documents are published for the historical record. o Satirical materials. o Meeting notes and reports (RFC 164 [RFC0164] is the earliest, 1109 [RFC1109] probably the most important). o Editorials (the best example is IEN-137, not an RFC). o Eulogies (RFC 2441 [RFC2441]) o Technical contributions (e.g., RFC 1810 [RFC1810]) and, historically, o RFC Editor and, at least prior to the handoff between ISI and ICANN and the June 2000 MOU [RFC2860], IANA Policy Statements (e.g., [RFC2223] and RFC 1591 [RFC1591]). It should be clear from the list above that, to be effective, the review and approval process for independent submissions should be largely independent of the IETF. As a important principle that has been applied historically, the RFC Editor should seek advice from the IESG about possible relationships and conflicts with IETF work. The IESG may ask that, as a courtesy, publication of particular documents be deferred because their untimely publication could cause confusion or other harm with proposals under consideration for standardization. Absent compelling arguments to the contrary, the RFC Editor will honor such requests. Similarly, any submission that constitutes an alternative to, or is in conflict with, an IETF Standard or proposal for standards-track adoption must clearly indicate that relationship. The IESG may identify such conflicts as part of its review. If the IESG identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published. The specific procedures to be followed in review are described in Section 4. 3. Submission Independent submissions are submitted directly to the RFC Editor. They must first be posted as Internet Drafts, so the submission is typically simply a note requesting that the RFC Editor consider a particular Internet Draft for publication. The process is described in more detail in [RFC2223] and a working draft of an update to it [RFC2223bis]. Klensin Expires April 23, 2007 [Page 5] Internet-Draft Independent Submissions October 2006 4. Review While this document is consistent with the broad outline of independent submission and review as practiced over the years, it specifies some new arrangements in RFC Editor processing that will improve the balance between openness and independent decisions. In general, the steps in the review process are identified in the subsections below. Any of them may be iterated and, at the discretion of the RFC Editor, steps after the first may be taken out of order. 4.1. Posting of Draft The author(s) or editor(s) of a document post it as an Internet Draft. 4.2. Request for Publication After the normal opportunity for community review and feedback provided by the submission of the I-D and the I-D repository announcement thereof, the author or editor sends a request for consideration for publication to the RFC Editor at rfc-editor@rfc-editor.org. That request should note any community discussion or reviews of the document that have occurred before submission.4 4.3. Initial RFC Editor Review RFC Editor Staff perform an initial check on the document. If they believe there is a high likelihood of conflicts or other interactions with IETF efforts (including believing that the document is one that the IESG should probably process), they may forward it to the IESG, or relevant ADs, for preliminary evaluation and comment. 4.4. Document Rejection If the document does not appear publishable, the RFC Editor may reject a submitted document at any point in the process specified here. Such rejection would normally be based on the conclusion that the submission does not meet the technical or editorial standards of the RFC Series or is not relevant to the areas that the series covers. Alternatively, the RFC Editor Staff may, at their discretion, iterate with the author on the document to improve its quality. If a document is rejected by the RFC Editor, the author may request an additional review from the IAB, as described below, but the IAB is not obligated to do that review, nor is the RFC Editor obligated to publish even with a favorable IAB review. Klensin Expires April 23, 2007 [Page 6] Internet-Draft Independent Submissions October 2006 4.5. Review and Evaluation The RFC Editor arranges for one or more reviews of the document. This may include Editorial Board (see Section 5) reviews or evaluation of reviews by others. Unless there is some substantive reason to not do so, these reviews will be made public and posted on the RFC Editor web site. The author may request that the reviews be kept private and the request to publish their document be withdrawn. This section does not preclude private communications between reviewers, the Editorial Board, and the RFC Editor; such communications will remain confidential. At minimum, the author shall receive a written summary of the review(s). While the reviews will generally be public, as discussed above, reviewers are allowed to be anonymous at their request. The author or reviewer may also request that reviews on a document that is eventually published be kept private as well, with the understanding that the best way to comment on, or dissent from, an RFC is generally another RFC. 4.6. Unsolicited Reviews Unsolicited reviews from parties independent of the author are welcome at any time and will be handled as above. Unsolicited reviews will be shared with the author including the identity of the reviewer. 4.7. Additional Reviews If the author is unsatisfied with the review(s), the author may request that the RFC Editor solicit additional reviews. In exceptional circumstances, the author may request that the IAB review the documents. Such requests to the IAB, and any reviews the IAB chooses to perform, will occur according to procedures of the IAB's choosing. However, the IAB is not required to initiate a review or comply with a request for one: a request to the IAB for a review is not an appeal process. The RFC Editor is expected to consider all competent reviews carefully, and in the absence of some unusual circumstance, a preponderance of favorable reviews should lead to publication. 4.8. Formal IESG Review Once the RFC Editor has made a tentative decision to publish, the document is forwarded to the IESG for evaluation with a relatively short timeout. Klensin Expires April 23, 2007 [Page 7] Internet-Draft Independent Submissions October 2006 The IESG evaluation is not a technical one. Instead, it covers the issues outlined above in Section 1.2 and listed in RFC 3932 or its successors. That is, the evaluation should focus exclusively on conflicts or confusion with IETF process and end runs around working group activities. At the time the document is forwarded to the IESG, the RFC Editor will post an indication on its web pages that the document is under IESG review and that comments on conflicts or harm can be sent to the IESG with copies to the RFC Editor. Additional mechanisms may be developed from time to time to inform a community that a document is entering formal prepublication review. Comments not directly related to IETF procedures or conflicts may be sent directly to the author(s) and RFC Editor. In addition to the IESG review for conflict with IETF work, individuals in the IESG, or in the broader IETF community, are free to review a draft and, if they have comments of any kind --including the extreme case of believing that the proposal is damaging to the Internet as a whole-- these comments should be directed to the authors and the RFC Editor. If the IESG, after completing its review, concludes that publication of the document should be delayed for a reasonable period of time, the RFC Editor will grant that request. The current agreement between the RFC Editor and the IESG on requested delays is expected to continue. That agreement permits the IESG to ask for a delay of up to six months and, if necessary, to renew that request twice, for a total possible delay of 18 months. If the IESG concludes that the document should not be published as an RFC, it will request that the RFC Editor not publish, providing appropriate justification. The RFC Editor will consider the request to not publish the document. The RFC Editor or the author may request that the IAB review the IESG's request to delay or not publish the document and for an additional opinion. Such a request will be made public via the RFC Editor web site. As with the IESG review itself, the IAB's opinion, if any, will be advisory. And, as with author requests for an IAB technical review (see Section 4.7), the IAB is not obligated to perform this type of review. 4.9. Final Decision and Notification In all cases, the ultimate decision to publish or not publish, and with what language, rests with the RFC Editor. Klensin Expires April 23, 2007 [Page 8] Internet-Draft Independent Submissions October 2006 Information about the IESG requested publication delay or request to not publish a document will be posted to the RFC Editor web site to supplement document status information. 4.10. Intellectual Property Rights IPR provisions for independent submissions are as specified in the material on RFC Editor submissions in BCP 78 [RFC3978] although that material should eventually be migrated into a successor of this document. 4.11. Final Editing and Publication Once a document is approved for publication, it is handled in a fashion similar to other RFCs, with principles about priorities worked out with the IAB as appropriate. 5. The Editorial Review Board The RFC Editor appoints and maintains an Editorial Review Board which, much like the Editorial Boards of professional journals and publishers, provides the RFC Editor with both advice and reviews of particular proposed publications and general and strategic policy advice. The membership list of the Editorial Review Board is public and can be found at http://www.rfc-editor.org/edboard.html. From time to time, the RFC Editor will solicit suggestions for new appointees from the IAB and other sources and will seek IAB comments on those to be appointed and on the effectiveness of the review process and the quality of documents being published and criteria applied. However, to ensure the independence of the independent submission process, the final decision to appoint (or not appoint) Editorial Board members rests with the RFC Editor. 6. Security Considerations This document specifies an RFC Editor (and IETF) administrative and publication procedure. It has no specific security implications. 7. IANA Considerations This document requires no actions by the IANA. Klensin Expires April 23, 2007 [Page 9] Internet-Draft Independent Submissions October 2006 8. Acknowledgments Special thanks are due to Bob Hinden and Craig Partridge, who made several suggestions for improved text in earlier versions of this document and to Stewart Bryant, Scott Bradner, Brian Carpenter, Vint Cerf, Leslie Daigle, and Olaf Kolkman who made a number of useful suggestions about the organization and content of subsequent versions. 9. Changes since version -02 This section summarizes changes between version -02 and version -03. [[anchor17: RFC Editor: please remove this section before publication]] o Removed material suggesting specific revisions to RFC 3932. There is still a forward pointer to a proposal for those revisions, but it is not normative. o Added new text questioning whether documents considered by, but rejected in, WGs should be processed as independent submissions or via the IESG (and, implicitly, subject to normal appeal procedures if rejected there). o Clarified that the order of actions in Section 4 is not a binding requirement. o Indicated that authors should submit notes on existing discussion and reviews along with the request for publication itself. o Brian Carpenter's suggested text about technical reviews was incorporated (approximately) into Section 4.8. o Clarified the status of review privacy on documents accepted for publication. o Added text to Section 5 to indicate that the RFC Editor will solicit inputs about effectiveness and quality in addition to names of individuals. o Several small editorial and textual changes for clarity and correctness. 10. References 10.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. Klensin Expires April 23, 2007 [Page 10] Internet-Draft Independent Submissions October 2006 [RFC2223bis] Reynolds, J., Ed. and R. Braden, Ed., "Instructions to Request for Comments (RFC) Authors", . [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004. [RFC3932upd] Klensin, J., Ed., "IESG Notes on Independent Submissions to the RFC Editor". [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005. 10.2. Informative References [RFC0164] Heafner, J., "Minutes of Network Working Group meeting, 5/16 through 5/19/71", RFC 164, May 1971. [RFC1109] Cerf, V., "Report of the second Ad Hoc Network Management Review Group", RFC 1109, August 1989. [RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994. [RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995. [RFC2441] Cohen, D., "Working with Jon Tribute delivered at UCLA, October 30, 1998", RFC 2441, November 1998. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical Publication Service", RFC 4714, October 2006. Klensin Expires April 23, 2007 [Page 11] Internet-Draft Independent Submissions October 2006 Author's Address John C Klensin (editor) 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 Email: john-ietf@jck.com Klensin Expires April 23, 2007 [Page 12] Internet-Draft Independent Submissions October 2006 Full 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. 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 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Klensin Expires April 23, 2007 [Page 13]