Network Working Group A. Falk
Internet-Draft IRTF Chair
Intended status: Informational June 8, 2007
Expires: December 10, 2007
Internet Research Task Force RFCs
draft-irtf-rfcs-01.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 December 10, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Falk Expires December 10, 2007 [Page 1]
Internet-Draft IRTF RFCs June 2007
Abstract
This document describes an RFC publication process for documents
produced by research groups of the Internet Research Task Force.
Table of Contents
1. Changes from Last Version . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Document Shepherds . . . . . . . . . . . . . . . . . . . . . . 6
4. Document Tracker . . . . . . . . . . . . . . . . . . . . . . . 7
5. Process Description . . . . . . . . . . . . . . . . . . . . . 8
5.1. Research Group Preparation . . . . . . . . . . . . . . . . 8
5.2. IRSG Review . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Initial steps . . . . . . . . . . . . . . . . . . . . 9
5.2.2. Reviews . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.3. IRSG Poll . . . . . . . . . . . . . . . . . . . . . . 10
5.2.4. Followup . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. IESG Review . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. RFC Editor Handling . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. Informative References . . . . . . . . . . . . . . . . . . . . 15
Appendix A. IESG Notes . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. State Diagram . . . . . . . . . . . . . . . . . . . . 17
Appendix C. Internet Research Steering Group membership . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Falk Expires December 10, 2007 [Page 2]
Internet-Draft IRTF RFCs June 2007
1. Changes from Last Version
Updates from draft-irtf-rfcs-00.txt:
o Added objective of including relevant citations to research
literature
o Shortened IRSG review to four weeks.
o Round-robin IRSG review assignment.
o Added discussion on why an RG would prefer this process over the
independent submission path
o Moved IESG review to occur before RFC Editor submission
o New suggested text for IESG notes
o Expansion of shepherd duties
o Added section on tracker
o Text on thorough reviews
o Removed section on A-D sponsored documents as a model for the IRTF
docs
o Changed focus of IRSG review to that of 'editorial board' rather
than 'technical review'
o Added text describing handling IESG Do-Not-Publish recommendations
o Linkage added to draft-iab-rfc-editor
o Added state diagram
o Reformatting
Falk Expires December 10, 2007 [Page 3]
Internet-Draft IRTF RFCs June 2007
2. Introduction
This document specifies a review and publication 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 Informational or Experimental
RFCs by the RFC Editor.
Historically, drafts from IRTF Research Group have been treated like
independent submissions by the RFC Editor. Roughly, the process
consisted 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 collisions with standards
process work) and inserts a note (see [RFC3932]).
o Independent submissions experienced lower priority processing as
they move through the RFC Editor's queue.
This document defines a new review and publication process for an
IRTF Document Stream. (Document streams are described in Section 5
of [I-D.iab-rfc-editor].) While a Research Group or RG member may
continue to choose to publish RFCs through the independent submission
process, an IRTF document stream brings certain advantages. First,
IRSG review is conducted by the Internet Research Steering Group,
which includes researchers who understand the IRTF and the goals and
operations of the member Research Groups. This may not be true for
the RFC Editorial Board, who normally review independent submissions.
Second, by avoiding RFC Editorial Board review, IRTF RFCs will spend
less time with the RFC Editor. Finally, the proposed IESG note for
IRTF RFCs (see Appendix A) was developed by the IRSG to be more
applicable to RG publications than the note normally prepended to
independent submissions (see RFC3932). The RFC3932 language was
developed to apply to a wide range of document types including, for
example, vendor-developed protocols and the warnings have been
characterized as strong and conservative. Note, however, that the
IESG makes the final choice of text and this document cannot make
guarantees. Nevertheless, the text recommended in this document is
intended to apply to most IRTF documents.
The IRTF RFC process may be summarized as:
Falk Expires December 10, 2007 [Page 4]
Internet-Draft IRTF RFCs June 2007
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) conducts an editorial
review
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 and
treated with the same processing priority as, for example, IAB-
stream documents
This draft has been updated based on about nine months of experience
and processing of four documents. The IRTF plans to continue the
trial of this process for several more documents and may again revise
this process.
Falk Expires December 10, 2007 [Page 5]
Internet-Draft IRTF RFCs June 2007
3. Document Shepherds
Documents must have a shepherd. This is a relatively new concept
initially developed in the IETF to ensure that issues raised in the
review and publication process are responded to in a timely manner.
The IETF shepherding process is described in
[I-D.ietf-proto-wgchair-doc-shepherding] and has been adapted to the
IRTF publication process.
Shepherd responsibilities are noted for each phase of the publication
process in subsequent sections. Some general things to note:
o Shepherds should normally be an RG chair since they know the IRSG
members, are familiar with the technical content, and know the
document history. However, the RG chair should generally not be a
shepherd if they are an author of the document, but may assume the
responsibility if the IRTF chair so permits (e.g., when another
shepherd is not available within a reasonable time period). If
the chair can not be the document shepherd, they should select
someone from the Research Group for this role since it is
important that they are able to interact with the RG and assess
the group's response to comments.
o Shepherds are responsible to track and facilitate document
progression through RFC publication. This includes finding IRSG
reviewers, facilitating resolution of review comments, entering
information into the tracker(s), keeping track of review
schedules, and prodding token holders to act expeditiously.
o Shepherds should summarize substantive review comments and their
resolution.
o Shepherds should be copied on all correspondence regarding a
document. For example, if the IESG has questions during their
review, the shepherd should be included in the exchange. This can
be helpful should the RG take a position different than the author
on suggested changes.
Falk Expires December 10, 2007 [Page 6]
Internet-Draft IRTF RFCs June 2007
4. Document Tracker
As of this writing the IRSG is using its own public document tracker
[TRAC]. This tracker is intended to collect the shepherd and
reviewer identities, reviewer comments, and state transitions as the
document progresses. It is the responsibility of the shepherd to
maintain the tracker.
It is expected that, in the future, the IRTF will use the IETF's I-D
Tracker [IDTRAC] to collect and manage this information.
Modifications are planned for the I-D Tracker to accommodate the IRTF
publication process. When the I-D Tracker can support the process
described below, the IRSG tracker will no longer be used.
Information to be captured in the tracker:
o URL to the draft (updated if the draft is revised)
o Document shepherd name and contact information
o Type of RFC: Informational or Experimental
o Desired IESG Note (select from Appendix A)
o IRSG members performing editorial review (see Section 5.2)
o Scheduled date for IRSG poll
o IRSG poll results
o Pointers to RG reviews
o IRSG Review comments and resolutions (or pointers)
Falk Expires December 10, 2007 [Page 7]
Internet-Draft IRTF RFCs June 2007
5. Process Description
The following sections describe the steps for IRTF-track 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.
5.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.
Here are some content guidelines to 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
contributors, 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 shepherd should be selected at this time as discussed in
Section 3. Now the document may be submitted to the IRSG for review.
Falk Expires December 10, 2007 [Page 8]
Internet-Draft IRTF RFCs June 2007
5.2. IRSG Review
The IRSG functions similar to an editorial review board. It is the
IRSG's responsibility to ensure high technical and editorial quality.
5.2.1. Initial steps
The RG chair brings the document to the IRSG for publication by
sending an email message to the IRSG requesting review and including
a pointer to the draft. The RG should be copied on the mail message
requesting IRSG review. If the RG chair is not going to be the
document shepherd, that person should be identified at this time.
The shepherd should do several things at this time:
1. Create an entry in the tracker for the document, entering all of
the items listed in Section 4 that are available and setting the
document state to "IRSG Review".
2. Send an email to the IRSG mailing list with pointers to the new
tracker entries (this may be automated)
3. Find two members of the IRSG to perform a thorough review of the
document. This is to ensure at least two thorough reviews are
performed. (Use of a tool for round-robin assignment of reviews
is under consideration.)
4. Open the poll, scheduled to close four weeks later.
5.2.2. Reviews
The purpose of the IRSG review is to ensure consistent editorial and
technical quality for IRTF publications. IRSG review is not a deep
technical review. (This should take place within the RG.) At least
one IRSG member other than the chair of the RG bringing the work
forth 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 and the
requirements of this process document, such as those described in
Section 5.1 have been met. 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
Falk Expires December 10, 2007 [Page 9]
Internet-Draft IRTF RFCs June 2007
sent to the IRSG and RG mailing lists and entered into the 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. Reviews and their resolution should be entered into the tracker
by the document shepherd.
5.2.3. IRSG Poll
A (firm) four-week IRSG review period follows after which a poll is
taken. 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 provide a
thorough review in a specified period of time.
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. The IRTF chair will
record the poll results in the tracker.
5.2.4. Followup
When an ID has been published reflecting the resolution of all
comments, the shepherd sends an email to the IRTF Chair (cc'ing the
IRSG and the RG) summarizing the IRSG review comments and their
resolution and including pointers to the tracker entries, detailed
reviews, and discussion. The note should also contain the preferred
IESG note (see Appendix A).
IRSG Review is concluded at this time. The tracker should be updated
to reflect moving to new state, IESG Review.
Falk Expires December 10, 2007 [Page 10]
Internet-Draft IRTF RFCs June 2007
5.3. IESG Review
The IRTF Chair will then send an email message to IESG
(iesg@ietf.org) and the secretariat (iesg-secretariat@ietf.org)
requesting a review and including the preferred IESG note. The 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 have other comments in the
datatracker which the RG may use to revise the document.
The IESG may conclude that draft conflicts with the IETF process and
recommend against publication (i.e,. DNP or Do-Not-Publish). 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 DNP
recommendation from the IESG, to inform the RFC Editor in its
publishing decision).
The shepherd now sends a request for publication including pointers
to the reviews in the tracker to the IRTF Chair, cc'ing the RG and
IRSG. The tracker should be updated at this time to reflect the new
state, "Doc approved, awaiting submission to RFC Editor."
5.4. RFC Editor Handling
The IRTF Chair will forward the request for publication email to the
RFC Editor, placing the document in the RFC Editor's publication
queue. The tracker should be updated to reflect the state of "RFC
Editor publication queue."
The document enters the RFC Editor queue at the same priority as
IETF- and IAB-track (non-standards) 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.
Falk Expires December 10, 2007 [Page 11]
Internet-Draft IRTF RFCs June 2007
6. 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 December 10, 2007 [Page 12]
Internet-Draft IRTF RFCs June 2007
7. Security Considerations
There are no security considerations in this document.
Falk Expires December 10, 2007 [Page 13]
Internet-Draft IRTF RFCs June 2007
8. Acknowledgements
This document was developed in close collaboration with the Internet
Research Steering Group (IRSG), see Appendix C for membership.
Useful contributions were made by Mark Allman, Bob Braden, Brian
Carpenter, Leslie Daigle, Stephen Farrell, Tom Henderson, Rajeev
Koodli, Allison Mankin, Craig Partridge, Juergen Schoenwaelder, Karen
Sollins, and Mark Townsley who contributed to development of the
process defined in this document.
Falk Expires December 10, 2007 [Page 14]
Internet-Draft IRTF RFCs June 2007
9. Informative References
[I-D.iab-rfc-editor]
Daigle, L., "The RFC Editor", draft-iab-rfc-editor-00
(work in progress), May 2006.
[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.
[IDTRAC] "IETF I-D Tracker", 2006,
<https://datatracker.ietf.org/public/pidtracker.cgi>.
[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.
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", BCP 92, RFC 3932, October 2004.
[TRAC] "IRTF Document Tracker", 2006,
<http://www1.tools.ietf.org/group/irtf/trac/report/1>.
Falk Expires December 10, 2007 [Page 15]
Internet-Draft IRTF RFCs June 2007
Appendix A. IESG Notes
After the review an IESG note is typically added. While the IESG may
request the addition of any note they choose, the following notes are
suggested for IRTF RFCs.[[anchor11: Note that the proposed notes
below generated significant discussion with the IESG. The IAB plans
to work with the IESG, IRSG, and larger community on determining an
acceptable labeling for non-IETF document streams. The outcome of
that discussion may result in changes to this text.]]
For documents that represent the consensus of an IRTF Research Group:
"This document is not an IETF Internet Standard. It represents
the consensus of the XXX Research Group of the Internet Research
Task Force. It may be considered for standardization by the
IETF in the future."
For documents that are not consensus documents but that the Research
Group wishes to see published:
"This document in not an IETF Internet Standard. It represents
the individual opinion(s) of one or more members of the XXX
Research Group of the Internet Research Task Force. It may be
considered for standardization by the IETF or adoption as a
IRTF Research Group consensus document in the future."
Falk Expires December 10, 2007 [Page 16]
Internet-Draft IRTF RFCs June 2007
Appendix B. State Diagram
The diagram below shows the states and transition events for IRTF RFC
processing.
+---------------+ +------------+ review cmnts +-----------------+
| request to | | |-------------->| IRSG Review: |
| publish from |---->|IRSG Review | | revised ID |
| RG chair, | | |<--------------| to address IRSG |
| identify | +-----+------+ revised ID | review |
| shepherd | |IRSG +-----------------+
+---------------+ |Approval
|
+-----------+
|
| RG: revised +------------------+
| draft | RG: revised ID |
| +---------------+ to avoid IETF |
| | | conflict |
| | +------------------+
| | ^
V V |RG: revise
+--------------+ +-------+-------+ +-------+
| |IESG: DNP |RG: revise, | | |
| IESG review |---------->|proceed, or +->| STOP |
| | |stop? | | |
+-------+------+ +-------+-------+ +-------+
| | ^
|IESG: |RG: proceed |
|no-conflict | |
V V |
+------------------+ +--------------+ |
| IRSG: waiting to |<----------+ IRTF Chair +------+
| submit to RFC-Ed | IAB: OK | consults IAB | IAB: DNP
+----------+-------+ +--------------+
|
|shepherd sends
|summary email
|
V
+---------------+
| Doc approved, | +---------------+
| awaiting | | RFC Editor |
| submission to +----------->| publication |
| RFC Editor | IRTF chair | queue |
| | sends msg +-------+-------+
+---------------+ to RFC Ed |
|
Falk Expires December 10, 2007 [Page 17]
Internet-Draft IRTF RFCs June 2007
V
+---------------+
| |
| RFC published |
| |
+---------------+
Falk Expires December 10, 2007 [Page 18]
Internet-Draft IRTF RFCs June 2007
Appendix C. Internet Research Steering Group membership
IRSG members at the time of this writing:
Mark Allman, IMRG Bill Arbaugh, MOBOPTS RG Bobby Bhattacharjee,
P2P RG Bob Braden John Buford, SAM RG Ran Canetti, CFRG Leslie
Daigle Wes Eddy, ICCG 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 Mark Williams, EME
Tilman Wolf, EME RG John Wroclawski Bill Yeager, P2P RG Lixia
Zhang, RRG
Falk Expires December 10, 2007 [Page 19]
Internet-Draft IRTF RFCs June 2007
Author's Address
Aaron Falk
USC Information Sciences Institute
4676 Admiralty Way, Suite 1001
Marina Del Rey, California 90292
USA
Phone: +1-310-448-9327
Email: falk@isi.edu
Falk Expires December 10, 2007 [Page 20]
Internet-Draft IRTF RFCs June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Falk Expires December 10, 2007 [Page 21]
