doc: Add RFC documents

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]
+