Definition of an Internet Research Task Force (IRTF) Document Stream
RFC 5743

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]