One document matched: draft-irtf-rfcs-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-irtf-rfcs-04.txt" ipr="trust200902">
<front>
<title abbrev="IRTF RFCs">Definition of an Internet Research Task Force
(IRTF) Document Stream</title>
<author fullname="Aaron Falk" initials="A." surname="Falk">
<organization abbrev="IRTF Chair">BBN Technologies</organization>
<address>
<postal>
<street>10 Moulton Street</street>
<city>Cambridge</city>
<code>02138</code>
<region>MA</region>
<country>USA</country>
</postal>
<phone>+1-617-873-2575</phone>
<email>falk@bbn.com</email>
</address>
</author>
<date day="21" month="September" year="2009" />
<area>Internet Research Task Force</area>
<keyword>IRTF</keyword>
<keyword>RFC</keyword>
<keyword>Process</keyword>
<keyword>Research</keyword>
<keyword>Publication</keyword>
<keyword>Stream</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Changes from Last Version (to be removed before RFC publication)">
<t>Updates from draft-irtf-rfcs-03.txt</t>
<t><list style="symbols">
<t>Removed Section 3.5 "Intellectual Property"</t>
<t>Inserted Section 4 "Rules for Submission and Use of Material",
specifying copyrights, IETF Trust request, and IPR procedures
adapted from draft-braden-independent-submission-01.txt.</t>
<t>Inserted ToC</t>
</list>Updates from draft-irtf-rfcs-02.txt</t>
<t><list style="symbols">
<t>Changed category to Informational</t>
<t>Added citation to RFC3978 (BCP78) in derivative rights
discussion</t>
<t>Fixed typos</t>
</list></t>
<t>Updates from draft-irtf-rfcs-01.txt:</t>
<t><list style="symbols">
<t>Removed internal process description not needed for stream
definition (added to wiki)</t>
<t>IESG review text now points to draft-housely-rfc3932bis</t>
<t>Replaced proposed IESG notes with pointer to
draft-iab-streams-headers-boilerplate</t>
<t>Added recommendation to permit unlimited derivative rights</t>
</list></t>
</section>
<section title="Introduction">
<t>From time to time the Internet Research Task Force (IRTF) <xref
target="RFC2014"></xref> 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
<xref target="RFC4844"></xref>. 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.</t>
<t>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 <xref
target="rg-prep"></xref>) are applied.</t>
<t>The IRTF RFC approval process may be summarized as:<list
style="symbols">
<t>The Research Group (RG) performs a thorough technical and
editorial review of the document and agrees it should be
published.</t>
<t>The Internet Research Steering Group (IRSG) reviews the document
and approves it for publication.</t>
<t>The Internet Engineering Steering Group (IESG) reviews the
document to assure that there are no conflicts with current or
expected standardization activities.</t>
<t>The document is submitted to the RFC Editor for publication.</t>
</list></t>
<t>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.</t>
</section>
<section title="Approval Process">
<t>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.</t>
<section anchor="rg-prep" title="Research Group Preparation">
<t>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.</t>
<t>The following guidelines should be adhered to:</t>
<t><list style="symbols">
<t>There must be a statement in the abstract identifying it as the
product of the RG</t>
<t>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".</t>
<t>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?</t>
<t>It must also be very clear throughout the document that it is
not an IETF product and is not a standard.</t>
<t>If an experimental protocol is described, appropriate usage
caveats must be present.</t>
<t>If the protocol has been considered in an IETF working group in
the past, this must be noted in the introduction as well.</t>
<t>There should be citations and references to relevant research
publications.</t>
</list>The Research Group identifies a document shepherd whose
responsibilty is to track and facilitate document progression through
RFC publication. The shepherd should be copied on all correspondence
relating to the document.</t>
</section>
<section anchor="irsg-review" title="IRSG Review and Approval">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="IESG Review">
<t>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 <xref
target="I-D.housley-iesg-rfc3932bis"></xref>. The scope of this review
is confined to that described in <xref target="RFC2026"></xref>,
section 4.2.3, 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."</t>
<t>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.</t>
<t>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).</t>
</section>
<section title="RFC Editor Handling">
<t>The IRTF Chair will then ask the RFC Editor to publish the
document, after which it will be enqueued for publication.</t>
<t>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.</t>
<t>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 <xref
target="I-D.iab-streams-headers-boilerplates"></xref>.</t>
</section>
</section>
<section title="Rules for Submission and Use of Material">
<t>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 <xref
target="I-D.braden-independent-submission"></xref>, describes rules and
procedures supporting these goals. See <xref
target="I-D.braden-independent-submission"></xref> 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. <xref
target="I-D.braden-independent-submission"></xref> defines those
rights.)</t>
<t>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 <xref target="RFC5378"></xref>. 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.</t>
<section title="Procedures requested of the IETF Trust">
<t>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.</t>
</section>
<section title="Patent and Trademark Rules for the IRTF Stream">
<t>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 version
at the time of writing was <xref target="RFC2026"></xref>. 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 <xref
target="RFC3979"></xref> updated by <xref target="RFC4879"></xref>.
The IRTF Stream has chosen to use the IETF's IPR disclosure mechanism,
www.ietf.org/ipr/, for this purpose. The IRTF would prefer the most
liberal terms possible be made available for specifications published
as IRTF Stream documents. Terms which 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.</t>
</section>
</section>
<section title="IAB Statement">
<t>In its capacity as the body that approves the creation of document
streams (see <xref target="RFC4844"></xref>), 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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>There are no security considerations in this document.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document was developed in close collaboration with the Internet
Research Steering Group (IRSG), see <xref target="irsg"></xref> 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.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.3979'?>
<?rfc include='reference.RFC.4879'?>
<?rfc include='reference.RFC.5378'?>
<?rfc include='reference.RFC.4844'?>
<?rfc include='reference.I-D.braden-independent-submission'?>
<?rfc include='reference.RFC.2014'?>
<?rfc include='reference.RFC.2026'?>
<?rfc include='reference.I-D.housley-iesg-rfc3932bis'?>
<?rfc include='reference.I-D.iab-streams-headers-boilerplates'?>
</references>
<section anchor="irsg" title="Internet Research Steering Group membership">
<t>IRSG members at the time of this writing:</t>
<t><list style="empty">
<t>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</t>
</list></t>
<t></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 13:18:18 |