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 © The IETF Trust (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

2.  Introduction

3.  Document Shepherds

4.  Document Tracker

5.  Process Description
    5.1.  Research Group Preparation
    5.2.  IRSG Review
        5.2.1.  Initial steps
        5.2.2.  Reviews
        5.2.3.  IRSG Poll
        5.2.4.  Followup
    5.3.  IESG Review
    5.4.  RFC Editor Handling

6.  IANA Considerations

7.  Security Considerations

8.  Acknowledgements

9.  Informative References

Appendix A.  IESG Notes

Appendix B.  State Diagram

Appendix C.  Internet Research Steering Group membership

§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Changes from Last Version

Updates from draft-irtf-rfcs-00.txt:

• Added objective of including relevant citations to research literature
• Shortened IRSG review to four weeks.
• Round-robin IRSG review assignment.
• Added discussion on why an RG would prefer this process over the independent submission path
• Moved IESG review to occur before RFC Editor submission
• New suggested text for IESG notes
• Expansion of shepherd duties
• Added section on tracker
• Text on thorough reviews
• Removed section on A-D sponsored documents as a model for the IRTF docs
• Changed focus of IRSG review to that of 'editorial board' rather than 'technical review'
• Added text describing handling IESG Do-Not-Publish recommendations
• Linkage added to draft-iab-rfc-editor
• Added state diagram
• Reformatting

2.  Introduction

This document specifies a review and publication process for the Internet Research Task Force (IRTF) [RFC2014] (Weinrib, A. and J. Postel, “IRTF Research Group Guidelines and Procedures,” October 1996.). 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:

• The document author submits an Internet Draft to the RFC Editor as an independent submission.
• The RFC Editor performs independent submission review (ISR) for editorial acceptability and may request the authors revise the document before publishing.
• The IESG performs a review (to avoid collisions with standards process work) and inserts a note (see [RFC3932] (Alvestrand, H., “The IESG and RFC Editor Documents: Procedures,” October 2004.)).
• 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] (Daigle, L., “The RFC Editor,” May 2006.).) 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 (IESG Notes)) 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:

• The Research Group performs a thorough technical and editorial review of the document and agrees it should be published.
• The Internet Research Steering Group (IRSG) conducts an editorial review
• The Internet Engineering Steering Group (IESG) reviews the document to assure that there are no conflicts with current or expected standardization activities
• 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.

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] (Levkowetz, H. and D. Meyer, “Protocol Pilot: Workgroup Chair Followup of AD Evaluation Comments,” July 2004.) 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:

• 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.
• 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.
• Shepherds should summarize substantive review comments and their resolution.
• 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.

4.  Document Tracker

As of this writing the IRSG is using its own public document tracker [TRAC] (, “IRTF Document Tracker,” 2006.). 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] (, “IETF I-D Tracker,” 2006.) 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:

• URL to the draft (updated if the draft is revised)
• Document shepherd name and contact information
• Type of RFC: Informational or Experimental
• Desired IESG Note (select from Appendix A (IESG Notes))
• IRSG members performing editorial review (see Section 5.2 (IRSG Review))
• Scheduled date for IRSG poll
• IRSG poll results
• Pointers to RG reviews
• IRSG Review comments and resolutions (or pointers)

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:

• There must be a statement in the abstract identifying it as the product of the RG
• 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".
• 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?
• It must 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 usage caveats must be present.
• If the protocol has been considered in an IETF working group in the past, this must be noted in the introduction as well.
• There should be citations and references to relevant research publications.

The shepherd should be selected at this time as discussed in Section 3 (Document Shepherds). Now the document may be submitted to the IRSG for review.

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 (Document Tracker) 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 (Research Group Preparation) 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 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:

• 'Ready to publish' -- requires a thorough read and reasonably detailed review
• 'Not ready to publish' -- requires a thorough read, reasonably detailed review, and actionable comments.
• '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.
• '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 (IESG Notes)).

IRSG Review is concluded at this time. The tracker should be updated to reflect moving to new state, IESG Review.

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] (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.), 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.

6.  IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

7.  Security Considerations

There are no security considerations in this document.

8.  Acknowledgements

This document was developed in close collaboration with the Internet Research Steering Group (IRSG), see Appendix C (Internet Research Steering Group membership) 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.

9. Informative References

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."

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          |
                                            |
                                            V
                                    +---------------+
                                    |               |
                                    | RFC published |
                                    |               |
                                    +---------------+

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

Author's Address

Full Copyright Statement

Copyright © 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).