diff options
Diffstat (limited to 'doc/rfc/rfc5743.txt')
| -rw-r--r-- | doc/rfc/rfc5743.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc5743.txt b/doc/rfc/rfc5743.txt new file mode 100644 index 0000000..f944c3e --- /dev/null +++ b/doc/rfc/rfc5743.txt @@ -0,0 +1,507 @@ + + + + + + +Internet Research Task Force (IRTF) A. Falk +Request for Comments: 5743 IRTF +Category: Informational December 2009 +ISSN: 2070-1721 + + + Definition of an Internet Research Task Force (IRTF) Document Stream + +Abstract + + This memo defines the publication stream for RFCs from the Internet + Research Task Force. Most documents undergoing this process will + come from IRTF Research Groups, and it is expected that they will be + published as Informational or Experimental RFCs by the RFC Editor. + +Status of this Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + deployment. Documents approved for publication by the IRSG are not a + candidate for any level of Internet Standard; see Section 2 of RFC + 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5743. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + + + + + +Falk Informational [Page 1] + +RFC 5743 IRTF RFCs December 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Approval Process . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Research Group Preparation . . . . . . . . . . . . . . . . 3 + 2.2. IRSG Review and Approval . . . . . . . . . . . . . . . . . 4 + 2.3. IESG Review . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.4. RFC Editor Handling . . . . . . . . . . . . . . . . . . . . 5 + 3. Rules for Submission and Use of Material . . . . . . . . . . . 5 + 3.1. Procedures Requested of the IETF Trust . . . . . . . . . . 6 + 3.2. Patent and Trademark Rules for the IRTF Stream . . . . . . 6 + 4. IAB Statement . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 + 7. Informative References . . . . . . . . . . . . . . . . . . . . 7 + Appendix A. Internet Research Steering Group membership . . . . . 9 + +1. Introduction + + From time to time the Internet Research Task Force (IRTF) [RFC2014] + will wish to publish a document in the Internet RFC series. This + memo defines the steps required to publish a document in the IRTF RFC + stream. Document streams are described in Section 5 of [RFC4844]. + Most documents undergoing this process will come from IRTF Research + Groups and it is expected that they will be published as + Informational or Experimental RFCs by the RFC Editor. + + The IRTF RFC stream provides an avenue for research groups to publish + their findings with an IRTF label. Pre-publication editorial review + by the Internet Research Steering Group (IRSG) increases the + readability of documents and ensures proper caveats (described in + Section 2.1) are applied. + + The IRTF RFC approval process may be summarized as: + + o The Research Group (RG) performs a thorough technical and + editorial review of the document and agrees it should be + published. + + o The Internet Research Steering Group (IRSG) reviews the document + and approves it for publication. + + o The Internet Engineering Steering Group (IESG) reviews the + document to assure that there are no conflicts with current or + expected standardization activities. + + o The document is submitted to the RFC Editor for publication. + + + + +Falk Informational [Page 2] + +RFC 5743 IRTF RFCs December 2009 + + + This document has been updated based on over a year of experience and + processing of roughly a dozen documents. The IRTF concludes that + there has been sufficient experience to justify that the benefits and + process are sound. + +2. Approval Process + + The following sections describe the steps for IRTF-stream document + review and publication process. There are fundamentally two steps: + IRSG review and IESG review. The document shepherd is responsible + for making sure reviews are responded to and documented and that the + process moves along. + +2.1. Research Group Preparation + + If an IRTF Research Group desires to publish a document as an IRTF + RFC, the process in this document must be followed. First, the RG + must review the document for editorial and technical quality. + + The following guidelines should be adhered to: + + o There must be a statement in the abstract identifying it as the + product of the RG. + + o There must be a paragraph near the beginning (for example, in the + introduction) describing the level of support for publication. + Example text might read: "this document represents the consensus + of the FOOBAR RG" or "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". + + o The breadth of review the document has received must also be + noted. For example, was this document read by all the active + research group members, only three people, or folks who are not + "in" the RG but are expert in the area? + + o It must also be very clear throughout the document that it is not + an IETF product and is not a standard. + + o If an experimental protocol is described, appropriate usage + caveats must be present. + + o If the protocol has been considered in an IETF working group in + the past, this must be noted in the introduction as well. + + o There should be citations and references to relevant research + publications. + + + + +Falk Informational [Page 3] + +RFC 5743 IRTF RFCs December 2009 + + + The Research Group identifies a document shepherd whose + responsibility is to track and facilitate document progression + through RFC publication. The shepherd should be copied on all + correspondence relating to the document. + +2.2. IRSG Review and Approval + + The IRSG functions similar to an editorial review board. It is the + IRSG's responsibility to ensure high technical and editorial quality. + The IRSG will review and approve all documents intended for RFC + publication from the IRTF stream. + + The purpose of the IRSG review is to ensure consistent technical + clarity and editorial quality for IRTF publications. The IRSG review + is not a deep technical review (this should take place within the + RG). At least one IRSG member who is not a chair of that research + group must review the document and the RG's editorial process. + + IRSG reviewers should look for clear, cogent, and consistent writing. + An important aspect of the review is to gain a critical reading from + reviewers who are not subject matter experts and, in the process, + assure the document will be accessible to those beyond the authoring + research group. Also, reviewers should assess whether sufficient + editorial and technical review has been conducted within the RG and + the requirements of this process document have been met, for example, + reviewers should evaluate whether the breadth of review the document + has received is adequate for the material at hand. Finally, + reviewers should check that appropriate citations to related research + literature have been made. + + Reviews should be written to be public. Review comments should be + sent to the IRSG and RG mailing lists and entered into the IRTF's + document tracker. All IRSG review comments must be addressed. + However, the RG need not accept every comment. It is the + responsibility of the shepherd to understand the comments and ensure + that the RG considers them, including adequate dialog between the + reviewer and the author and/or RG. + + Following resolution of the editorial review, the IRSG will make a + decision as to whether to approve the document for publication. If + the IRSG does not approve the document, it returns to the research + group with feedback on what would need to be fixed for publication. + In rare cases, the IRSG may determine that a document is not suitable + for publication as an IRTF RFC. (For example, members of the RG may + assert to the IRSG that there was no RG consensus to publish the + document.) Other publication streams would still be available to + those authors. + + + + +Falk Informational [Page 4] + +RFC 5743 IRTF RFCs December 2009 + + +2.3. IESG Review + + The IRTF Chair will then extend the Internet Engineering Steering + Group (IESG) an opportunity to review the document according to the + process and scope described in [RFC5742]. The scope of this review + is confined to that described in Section 4.2.3 of [RFC2026] for non- + IETF documents, specifically it is "to ensure that the non-standards + track Experimental and Informational designations are not misused to + circumvent the Internet Standards Process." + + The IESG (via the IETF Secretariat) is expected to provide the IRTF + chair and document shepherd with a response, normally within four + weeks, as to whether publication of the draft is perceived to be at + odds with the Internet Standards Process. + +2.4. RFC Editor Handling + + The IRTF Chair will then ask the RFC Editor to publish the document, + after which it will be enqueued for publication. + + The document enters the RFC Editor queue at the same priority as non- + standard IETF-stream and IAB-stream 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. + The AUTH48 review stage of RFC publication is an area where the + shepherd may be of particular assistance, ensuring a) authors respond + promptly in reviewing about-to-be-published RFCs and b) authors don't + inject changes into the document at the last minute which would not + be supported by the research group or other reviewers. + + If not already present, the RFC Editor will insert labels and text + for the "Status of this Memo" section that identify the document as + the product of the IRTF. The current text is defined in [RFC5741]. + +3. Rules for Submission and Use of Material + + The goals of the IRTF Stream are based on a desire that research + within the IRTF have broad impact and the publication rights should, + in general, not restrict republication (with appropriate citations). + However, in uncommon cases, it may be desirable to publish a document + that does not permit derivative works. This section, adapted from + [RFC5744], describes rules and procedures supporting these goals. + See [RFC5744] for a discussion of the background and rationale for + the specific language. (From a historical perspective, the goal has + been to preserve the rights that IRTF authors have previously had + when publishing documents as RFC Editor Independent Submissions. + [RFC5744] defines those rights.) + + + + +Falk Informational [Page 5] + +RFC 5743 IRTF RFCs December 2009 + + + IRTF Stream authors will submit their material as Internet-Drafts. + These drafts will be submitted to, and stored in, the IETF Internet- + Drafts repository in the same fashion as IETF Internet-Drafts. + During Internet-Draft submission, authors who intend to submit their + document for publication in the IRTF Stream will grant rights as + described in [RFC5378]. To request that the contribution be + published as an RFC that permits no derivative works, an author may + use the form specified for use with RFC 5378. The IETF Trust will + indicate that, in cooperation with the IRTF, the Trust grants to + readers and users of material from IRTF Stream RFCs the right to make + unlimited derivative works, unless the RFC specifies that no + derivative works are permitted. This will permit anyone to copy, + extract, modify, or otherwise use material from IRTF Stream RFCs as + long as suitable attribution is given. Contributors of Internet- + Drafts intended for the IRTF Stream will include suitable boilerplate + defined by the IETF Trust. This boilerplate shall indicate + compliance with RFC 5378 and shall explicitly indicate either that no + derivative works can be based on the contribution, or, as is + preferred, that unlimited derivative works may be crafted from the + contribution. It should be understood that the final publication + decision for the IRTF Stream rests with the IRTF Chair. Compliance + with these terms is not a guarantee of publication. In particular, + the IRTF Chair may question the appropriateness of a "no derivative + works" restriction requested by an author. The appropriateness of + such usage must be negotiated among the authors and the IRTF Chair. + +3.1. Procedures Requested of the IETF Trust + + The IRTF requests that the IETF Trust and its Trustees assist in + meeting the goals and procedures set forth in this document. The + Trustees are requested to publicly confirm their willingness and + ability to accept responsibility for the Intellectual Property Rights + for the IRTF Stream. They are also requested to indicate their + willingness and intent to work according to the procedures and goals + defined by the IRTF. Specifically, the Trustees are asked to develop + the necessary boilerplate to enable the suitable marking of documents + so that the IETF Trust receives the rights as specified in RFC 5378. + These procedures need to also allow documents to grant either no + rights to make derivative works, or preferentially, the right to make + unlimited derivative works from the documents. It is left to the + Trust to specify exactly how this shall be clearly indicated in each + document. + +3.2. Patent and Trademark Rules for the IRTF Stream + + As specified above, contributors of documents for the IRTF stream are + expected to use the IETF Internet-Draft process, complying therein + with the rules specified in the latest version of BCP 9, whose + + + +Falk Informational [Page 6] + +RFC 5743 IRTF RFCs December 2009 + + + version at the time of writing was [RFC2026]. This includes the + disclosure of Patent and Trademark issues that are known, or can be + reasonably expected to be known, to the contributor. Disclosure of + license terms for patents is also requested, as specified in the most + recent version of BCP 79. The version of BCP 79 at the time of this + writing was RFC 3979 [RFC3979], which is updated by [RFC4879]. The + IRTF Stream has chosen to use the IETF's IPR disclosure mechanism, + www.ietf.org/ipr/, for this purpose. The IRTF would prefer that the + most liberal terms possible be made available for specifications + published as IRTF Stream documents. Terms that do not require fees + or licensing are preferable. Non-discriminatory terms are strongly + preferred over those which discriminate among users. However, + although disclosure is required, there are no specific requirements + on the licensing terms for intellectual property related to IRTF + Stream publication. + +4. IAB Statement + + In its capacity as the body that approves the creation of document + streams (see [RFC4844]), the IAB has reviewed this proposal and + supports it as an operational change that is in line with the + respective roles of the IRTF, IESG, and RFC Editor. + +5. Security Considerations + + There are no security considerations in this document. + +6. Acknowledgements + + This document was developed in close collaboration with the Internet + Research Steering Group (IRSG), see Appendix A for membership. + Useful contributions were made by Mark Allman, Bob Braden, Brian + Carpenter, Leslie Daigle, Stephen Farrell, Tom Henderson, Rajeev + Koodli, Danny McPherson, Allison Mankin, Craig Partridge, Juergen + Schoenwaelder, Karen Sollins, and Mark Townsley who contributed to + development of the process defined in this document. + +7. Informative References + + [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines + and Procedures", BCP 8, RFC 2014, October 1996. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC3979] Bradner, S., "Intellectual Property Rights in IETF + Technology", BCP 79, RFC 3979, March 2005. + + + + +Falk Informational [Page 7] + +RFC 5743 IRTF RFCs December 2009 + + + [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC + Series and RFC Editor", RFC 4844, July 2007. + + [RFC4879] Narten, T., "Clarification of the Third Party Disclosure + Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. + + [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide + to the IETF Trust", BCP 78, RFC 5378, November 2008. + + [RFC5741] Daigle, L., Ed., and O. Kolkman, Ed., "On RFC Streams, + Headers, and Boilerplates", RFC 5741, December 2009. + + [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for + Handling of Independent and IRTF Stream Submissions", + BCP 92, RFC 5742, December 2009. + + [RFC5744] Braden, R. and J. Halpern, "Procedures for Rights Handling + in the RFC Independent Submission Stream", RFC 5744, + December 2009. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Falk Informational [Page 8] + +RFC 5743 IRTF RFCs December 2009 + + +Appendix A. Internet Research Steering Group Membership + + IRSG members at the time of this writing: + + Bill Arbaugh, MOBOPTS RG; Bob Braden; John Buford, SAM RG; Ran + Canetti, CFRG; Leslie Daigle; Wes Eddy, ICCRG; Aaron Falk, IRTF + Chair; Kevin Fall, DTN RG; Stephen Farrell, DTN RG; Sally Floyd, + TMRG; Andrei Gurtov, HIPRG; Tom Henderson, HIPRG; Rajeev Koodli, + MOBOPTS RG; Olaf Kolkman, IAB Chair; John Levine, ASRG; Tony Li, + RRG; Dave McGrew, CFRG; Jeremy Mineweaser, SAM RG; Craig + Partridge, E2E RG; Juergen Schoenwaelder, NMRG; Karen Sollins, E2E + RG; Michael Welzl, ICCRG; John Wroclawski; Lixia Zhang, RRG + +Author's Address + + Aaron Falk + BBN Technologies + 10 Moulton Street + Cambridge, MA 02138 + USA + + Phone: +1-617-873-2575 + EMail: falk@bbn.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Falk Informational [Page 9] + |