Network Working Group A. Falk
Internet-Draft IRTF Chair
Expires: August 30, 2006 February 26, 2006
IRTF Research Group RFCs
draft-irtf-rfcs-00.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 August 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a process for research groups in the Internet
Research Task Force to publish RFCs.
Falk Expires August 30, 2006 [Page 1]
Internet-Draft IRTF RFCs February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Process Model . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Research Group Preparation . . . . . . . . . . . . . . . . 4
2.2. Document Shepherds . . . . . . . . . . . . . . . . . . . . 4
2.3. Submission to the IRSG . . . . . . . . . . . . . . . . . . 5
2.4. IRSG Review . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. RFC Editor Handling . . . . . . . . . . . . . . . . . . . 5
2.6. IESG Handling . . . . . . . . . . . . . . . . . . . . . . 6
2.7. Exiting . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. Informative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Falk Expires August 30, 2006 [Page 2]
Internet-Draft IRTF RFCs February 2006
1. Introduction
This is proposal for a document process for the Internet Research
Task Force (IRTF) [RFC2014]. Most documents undergoing this process
will come from IRTF Research Groups and the objective is that they
are published as RFCs by the RFC Editor.
Currently, the IRTF Research Group drafts are treated like
independent submissions by the RFC Editor. Roughly, the process
consists of the following steps:
o The document author submits an Internet Draft to the RFC Editor as
an independent submission.
o The RFC Editor performs independent submission review (ISR) for
editorial acceptability and may request the authors revise the
document before publishing.
o The IESG performs a review (to avoid standards process end-
arounds) and inserts a disclaimer (see RFC3932[RFC3932]).
o Independent submissions are delayed by lower priority treatment as
they move through the RFC Editor's queue.
This proposal changes the following:
o The RFC Editor's ISR review
o IRTF document publication priority in the RFC Editor queue
o The RFC3932 disclaimer placed on non-IETF documents by the
Internet Engineering Steering Group
The IRTF plans a trial of this process for several several documents
after which this draft may be updated or published.
Falk Expires August 30, 2006 [Page 3]
Internet-Draft IRTF RFCs February 2006
2. Process Model
The IRTF shall use the process for IETF-sponsored individual
submissions (sometimes called AD-sponsored individual submissions) as
a model for IRTF document handling. From time to time, individuals
will approach a member of the IESG to publish a document that is not
the product of an IETF working group. These documents do not receive
RFC3932 disclaimers, do not receive low priority treatment by the RFC
Editor, and do not experience ISR review. However, they do receive a
thorough review by the IESG. For non-standards documents (yes, there
are rare cases of non-wg standards documents), the sponsoring AD
gives the document a thorough review, sometimes requiring expert
reviews or IETF-wide last calls, if the topic seems to warrant broad
review. The bottom line is that a set of experienced, responsible
folks give the document a thorough review before publishing it as an
"IETF product".
This proposal adapts the above process to the IRTF as described in
the following sections. The RFC Editor and the IAB have reviewed the
procedure below and fully support it.
2.1. Research Group Preparation
An RG decides to publish a document using the IRTF publication track.
The RG performs a review for editorial and technical content. The
document should have a statement in the abstract identifying the
document as the product of the RG and a paragraph in the first
section describing the level of support for the document (e.g., "this
document represents the consensus of the FOOBAR RG", "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")
and the breadth of review for the document. I.e., was this document
read by all the active contributors, 3 people, or folks who are not
"in" the RG but are expert in the area? It should also be very clear
throughout the document that it is not an IETF product and is not a
standard. If an experimental protocol is described appropriate
caveats need to be present.
2.2. Document Shepherds
Documents should have a shepherd. This is a relatively new concept
developed in the IETF to ensure that issues raised in the review and
publication process (e.g., by the IESG and RFC Editor) are responded
to in a timely manner. The IETF shepherding process is described in
[I-D.ietf-proto-wgchair-doc-shepherding] and should be adapted to the
IRTF publication process as some items in the draft will not apply.
Falk Expires August 30, 2006 [Page 4]
Internet-Draft IRTF RFCs February 2006
2.3. Submission to the IRSG
The sponsoring RG chair brings the document to the IRSG for
publication. The expectation is that the RG chair has already
reviewed the draft thoroughly and considers it of publishable quality
editorially and technically. The RG should be copied on the mail
message requesting IRSG review.
2.4. IRSG Review
A (firm) eight-week IRSG review period follows after which a poll is
taken. Reviews should be similar to that for a conference paper.
Votes can be:
o 'ready to publish' -- requires a thorough read and reasonably
detailed review
o 'not ready to publish' -- requires a thorough read, reasonably
detailed review, and actionable comments.
o 'no objection' -- I don't object if this document goes forward;
I've read the document (perhaps quickly); I have some small
comments which are not show stoppers; I don't have great expertise
in the area.
o 'request more time to review' -- a commitment to to provide a
thorough review in a specified period of time.
Reviews should be written to be public. In particular, they should
be sent to the submitted RG mailing list. (We may need a tracker of
some sort to collect reviews.)
At least two other IRSG members (besides the one sponsoring the
document) need to vote 'ready to publish' for the document to move
forward. Any vote of 'not ready to publish' will hold a document's
progress until the comments are addressed. The IRTF chair may choose
to override 'not ready to publish' holds that, in the opinion of the
chair, have received an adequate response.
2.5. RFC Editor Handling
The document is submitted to the RFC Editor who does not perform an
ISR review. The RFC Editor sends it to the IESG for an RFC3932
review. There are several reasons why the IESG may block a document,
described in RFC3932 section 4. (The document shepherd should be
responsible for checking the IETF datatracker for IESG blocking and
non-blocking comments and forward them to the RG.)
Falk Expires August 30, 2006 [Page 5]
Internet-Draft IRTF RFCs February 2006
2.6. IESG Handling
Rather than the disclaimers found in RFC3932, the IESG will instruct
the RFC Editor to add the following disclaimer:
"This RFC is a product of the Internet Research Task Force and
is not a candidate for any level of Internet Standard. The
IRTF publishes the results of Internet-related research and
development activities. These results might not be suitable
for deployment."
For documents that specify a protocol or other technology, and that
have been considered in the IETF at one time:
"This RFC is a product of the Internet Research Task Force.
The content of this RFC was at one time considered by the
IETF, and therefore it may resemble a current IETF work in
progress or a published IETF work. However, this is not an
IETF document is not a candidate for any level of Internet
Standard. The IRTF publishes the results of Internet-related
research and development activities. These results might not
be suitable for deployment."
(These disclaimers will require approval by the IESG.)
2.7. Exiting
The document enters the RFC Editor queue at the same priority as IETF
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.
Falk Expires August 30, 2006 [Page 6]
Internet-Draft IRTF RFCs February 2006
3. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Falk Expires August 30, 2006 [Page 7]
Internet-Draft IRTF RFCs February 2006
4. Security Considerations
There are no security considerations in this document.
Falk Expires August 30, 2006 [Page 8]
Internet-Draft IRTF RFCs February 2006
5. Acknowledgements
Many thanks for Mark Allman, Bob Braden, Leslie Daigle, and Allison
Mankin who contributed to preparation of this process.
6. Informative References
[I-D.ietf-proto-wgchair-doc-shepherding]
Levkowetz, H. and D. Meyer, "Protocol Pilot: Workgroup
Chair Followup of AD Evaluation Comments",
draft-ietf-proto-wgchair-doc-shepherding-00 (work in
progress), July 2004.
[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
and Procedures", BCP 8, RFC 2014, October 1996.
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", BCP 92, RFC 3932, October 2004.
Falk Expires August 30, 2006 [Page 9]
Internet-Draft IRTF RFCs February 2006
Author's Address
Aaron Falk
IRTF Chair
4676 Admiralty Way, Suite 1001
Marina Del Rey, California 90292
USA
Phone: +1-310-448-9327
Email: falk@isi.edu
Falk Expires August 30, 2006 [Page 10]
Internet-Draft IRTF RFCs February 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Falk Expires August 30, 2006 [Page 11]
