Network Working Group A. Falk
Internet-Draft IRTF Chair
Intended status: BCP September 7, 2008
Expires: March 11, 2009
Definition of an Internet Research Task Force (IRTF) Document Stream
draft-irtf-rfcs-02.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 March 11, 2009.
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.
1. Changes from Last Version (to be removed)
Updates from draft-irtf-rfcs-01.txt:
Falk Expires March 11, 2009 [Page 1]
Internet-Draft IRTF RFCs September 2008
o Removed internal process description not needed for stream
definition (added to wiki)
o IESG review text now points to draft-housely-rfc3932bis
o Replaced proposed IESG notes with pointer to
draft-iab-streams-headers-boilerplate
o Added recommendation to permit unlimited derivative rights
2. 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
readibility of documents and ensures proper caveats (described in
Section 3.1) are applied.
The IRTF RFC approval process may be summarized as:
o The Research Group 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.
This draft 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 the benefits and
process are sound.
Falk Expires March 11, 2009 [Page 2]
Internet-Draft IRTF RFCs September 2008
3. 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.
3.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.
The Research Group identifies a document shepherd who's responsibilty
is to track and facilitate document progression through RFC
publication. The shepherd should be copied on all correspondence
relating to the document.
Falk Expires March 11, 2009 [Page 3]
Internet-Draft IRTF RFCs September 2008
3.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 the IRTF
RFC stream.
The purpose of the IRSG review is to ensure consistent technical
clarity and editorial quality for IRTF publications. 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.
3.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 [I-D.housley-iesg-rfc3932bis]. The
Falk Expires March 11, 2009 [Page 4]
Internet-Draft IRTF RFCs September 2008
scope of this review is confined to that described in [RFC2026],
section 4.2.3, for non-IETF documents, specifically it is "[t]o
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 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.
The IESG may recommend against publication. Should this occur, the
RG may choose to revise the document based on the comments
accompanying this recommendation and pass a revised version to the
IESG. If the RG and IESG cannot come to agreement publishing the
document, the RG chair may ask the IRTF Chair to raise the matter
with the IAB, which will act as final arbiter on whether the document
is submitted to the RFC Editor (along with the commentary and
recommendation from the IESG, to inform the RFC Editor in its
publishing decision).
3.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 specific text is defined in
[I-D.iab-streams-headers-boilerplates].
3.5. Intellectual Property
IRTF documents should include a derivative rights statement where the
authors grant unlimited permission for derivative works with
appropriate credits and citations. This is because research within
the IRTF is intended to have broad impact and would be encouraged by
avoiding limitations on the use of the documents. Also, it is
Falk Expires March 11, 2009 [Page 5]
Internet-Draft IRTF RFCs September 2008
currently the common case for non-IETF RFCs.
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. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
There are no security considerations in this document.
7. 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.
8. Informative References
[I-D.housley-iesg-rfc3932bis]
Alvestrand, H. and R. Housley, "IESG Procedures for
Handling of Independent and IRTF Stream Submissions",
draft-housley-iesg-rfc3932bis-01 (work in progress),
August 2008.
[]
Daigle, L. and O. Kolkman, "On RFC Streams Headers and
Boilerplates", draft-iab-streams-headers-boilerplates-00
(work in progress), June 2008.
Falk Expires March 11, 2009 [Page 6]
Internet-Draft IRTF RFCs September 2008
[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.
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
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 Expires March 11, 2009 [Page 7]
Internet-Draft IRTF RFCs September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Falk Expires March 11, 2009 [Page 8]
