Network Working Group H. Alvestrand
Internet-Draft April 7, 2004
Expires: October 6, 2004
The IESG and RFC Editor documents: Procedures
draft-iesg-rfced-documents-01.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3667.
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 October 6, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document gives the IESG's procedures for handling documents
submitted for RFC publication via the RFC Editor, subsequent to the
changes proposed by the IESG at the Seoul IETF, March 2004.
NOTE IN DRAFT: These guidelines are proposed, not adopted. Comments
are welcome - please send them to iesg@ietf.org.
1. Introduction and history
There are a number of different methods by which an RFC is published,
some of which include review in the Internet Engineering Task Force
Alvestrand Expires October 6, 2004 [Page 1]
Internet-Draft IESG & RFCEd Docs April 2004
(IETF), and some of which include approval by the Internet
Engineering Steering Group (IESG):
o IETF Working Group to Standards Track: Includes WG consensus,
review in the IETF, IETF Last Call and IESG approval
o IETF Working Group to Experimental/Informational: Includes WG
consensus, review in the IETF and IESG approval
o AD Sponsored to Standards Track: Includes review in the IETF, IETF
Last Call and IESG approval
o AD Sponsored Individual to Experimental/Informational: Includes
some form of review in the IETF and IESG approval
o Documents for which special rules exist, including IAB documents
and April 1st RFCs, and republication of documents from other SDOs
- the IESG and the RFC Editor keep a running dialogue on which
documents these are
o RFC Editor documents to Experimental/Informational
This memo is concerned with the IESG processing of the last category
only.
For the last few years, the IESG has reviewed all documents submitted
by individuals to the RFC Editor for RFC publication ("RFC Editor
documents") before publication. In 2003, this review was often a full
scale review of technical content, with the ADs attempting to clear
points with the authors, stimulate revisions of the documents,
encourage the authors to contact appropriate working groups and so
on. This was a considerable drain on the resources of the IESG, and
since this is not the highest priority task the IESG members do, it
often resulted in significant delays.
In March 2004, the IESG decided to make a major change in this review
model. The new review model will have the IESG take responsibility
ONLY for checking for conflicts between the work of the IETF and the
documents submitted; soliciting technical review is deemed to be the
responsibility of the RFC Editor. If an individual IESG member
chooses to review the technical content of the document, and finds
issues, that member will communicate these issues to the RFC Editor,
where they will be treated the same way as comments on the documents
from other sources.
2. Background material
The review of independent submissions by the IESG was prescribed by
RFC 2026 [1] section 4.2.3. The procedure described in this document
is compatible with that description.
RFC 3710 [3] section 5.2.2 describes the spring 2003 review process;
with the publication of this document, the procedure described in RFC
3710 is no longer relevant to documents submitted via the RFC Editor.
Alvestrand Expires October 6, 2004 [Page 2]
Internet-Draft IESG & RFCEd Docs April 2004
3. Detailed description of IESG review
The IESG will review all documents submitted through the RFC Editor
for conflicts with the IETF standards process or work done in the
IETF community. The review is initiated by a note from the RFC Editor
specifying the draft name, the RFC Editor's belief about the
document's present suitability for publication, and (if possible) the
list of people who have reviewed the document for the RFC Editor.
The IESG may return five different responses, all of which may be
accompanied by an IESG note to be put on the document if the RFC
Editor wishes to publish.
1. The IESG has not found any conflict between this document and
IETF work.
2. The IESG thinks that this work is related to IETF work done in WG
<X>, but this does not prevent publishing.
3. The IESG thinks that publication is harmful to the IETF work done
in WG <X>, and recommends not publishing the document at this
time.
4. The IESG thinks that this document violates IETF procedures for
<X>, and should therefore not be published without IETF review.
5. The IESG thinks that this document extends an IETF protocol in a
way that requires IETF review, and should therefore not be
published without IETF review.
The last two cases are included for the case where a document
attempts to do things (such as URI scheme definition) that require
IETF consensus or IESG approval (as these terms are defined in RFC
2434 [2]), and the case where an IETF protocol is proposed to be
changed or extended in an unanticipated way that may be harmful to
the normal usage of the protocol, but where the protocol documents do
not explicitly say that this type of extension requires IETF review.
In the case of a document requiring IETF review, the IESG will offer
the author the opportunity to ask for publication as an AD-sponsored
individual document, which is subject to full IESG review including
possible assignment to a WG or rejection. Redirection to the full
IESG review path is not a guarantee that the IESG will accept the
work item, or even that the IESG will give it any particular
priority; it is a guarantee that the IESG will consider the document.
The IESG will normally have review done within 4 weeks from the RFC
Editor's notification. In the case of a possible conflict, the IESG
may contact a WG or a WG chair for an outside opinion of whether
publishing the document is harmful to the work of the WG, and in the
case of a possible conflict with an IANA registration procedure, the
IESG may contact the IANA expert for that registry.
Alvestrand Expires October 6, 2004 [Page 3]
Internet-Draft IESG & RFCEd Docs April 2004
Note that judging the technical merits of submissions, including
considerations of possible harm to the Internet, will become solely
the responsbility of the RFC Editor. The IESG assumes that the RFC
Editor will manage its own mechanisms for additional technical
review.
4. Standard IESG note
One of the following IESG notes will be sent to the RFC Editor for
all documents for placement either in or immediately following the
"Status of this Memo" section of the finished RFC, unless the IESG
decides otherwise:
1. For documents that specify a protocol or other technology, and
that have been considered in the IETF at one time:
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. This RFC is not a candidate for any level
of Internet Standard. The IETF disclaims any knowledge of the
fitness of this RFC for any purpose, and in particular notes that
it has not had IETF review for such things as security,
congestion control or inappropriate interaction with deployed
protocols. The RFC Editor has chosen to publish this document at
its discretion. Readers of this RFC should exercise caution in
evaluating its value for implementation and deployment. See RFC
XXXX for more information.
2. For documents that specify a protocol or similar technology, and
are independent of the IETF process:
This RFC is not a candidate for any level of Internet Standard.
The IETF disclaims any knowledge of the fitness of this RFC for
any purpose, and in particular notes that it has not had IETF
review for such things as security, congestion control or
inappropriate interaction with deployed protocols. The RFC
Editor has chosen to publish this document at its discretion.
Readers of this document should exercise caution in evaluating
its value for implementation and deployment. See RFC XXXX for
more information.
3. For documents that do not specify a protocol or similar
technology:
This RFC is not a candidate for any level of Internet Standard.
The IETF disclaims any knowledge of the fitness of this RFC for
any purpose, and notes that it has not had IETF review. The RFC
Editor has chosen to publish this document at its discretion. See
RFC XXXX for more information.
NOTE TO RFC EDITOR: Please replace "RFC XXXX" with the actual RFC
number of this document when published, and delete this sentence.
Alvestrand Expires October 6, 2004 [Page 4]
Internet-Draft IESG & RFCEd Docs April 2004
5. Examples of cases where publication is harmful
This section gives a couple of examples where it might be appropriate
to delay or prevent publishing of a document due to conflict with
IETF work. It forms part of the background material, not a part of
the procedure.
Publish While Waiting: In 2003, the V6OPS WG was working on
establishing evaluation criteria for the family of mechanisms known
as "IPv6 transition mechanisms". The author of one of these
mechanisms asked for publication as Experimental. The judgment of the
WG chairs at the time was that publication of this document would
remove sufficient energy from the group that the evaluation criteria
work would not be finished, and the IETF would be unable to make a
well thought out choice between mechanisms to pursue. Thus, the WG
asked for this document not to be published at that time.
Rejected Alternative Bypass: A WG is working on a solution to a
problem, and a participant decides to ask for publication of a
solution that the WG has rejected. Publication of the document will
give the publishing party an RFC number to refer to before the WG is
finished. It seems better to have the WG product published first, and
have the non-adopted document published later, with a clear
disclaimer note saying that "the IETF technology for this function is
X". Example: Photuris (RFC 2522), which was published after IKE (RFC
2409).
Inappropriate Reuse of "free" Bits: In 2003, a proposal for an
experimental RFC was published that wanted to reuse the high bits of
the "fragment offset" part of the IP header for another purpose.
There is no IANA consideration saying how these bits can be
repurposed - but the standard defines a specific meaning for them.
The IESG concluded that implementations of this experiment risked
causing hard-to-debug interoperability problems, and recommended not
publishing the document in the RFC series. The RFC Editor accepted
the recommendation.
Note: in general, the IESG has no problem with rejected alternatives
being made available to the community; such publications can be a
valuable contribution to the technical literature. However, it is
necessary to avoid confusion with the alternatives the working group
did adopt.
The RFC series is one of many available publication channels; this
document takes no position on the question of which documents the RFC
series is appropriate for - this is a matter for discussion in the
IETF community.
Alvestrand Expires October 6, 2004 [Page 5]
Internet-Draft IESG & RFCEd Docs April 2004
6. Security Considerations
The process change described in this memo has no bearing on the
security of the Internet.
7. Acknowledgements
This document has been reviewed in the IETF, by the RFC Editor and
the IAB. Special thanks go to John Klensin, Keith Moore, Pete
Resnick, Scott Bradner, Kurt Zeilenga, Eliot Lear, Paul Hoffman and
all other IETF community members who provided valuable feedback on
the document.
References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Alvestrand, H., "An IESG Charter", February 2004.
Author's Address
Harald Alvestrand
EMail: harald@alvestrand.no
Alvestrand Expires October 6, 2004 [Page 6]
Internet-Draft IESG & RFCEd Docs April 2004
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 IETF's procedures with respect to rights in IETF 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 (2004). 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.
Alvestrand Expires October 6, 2004 [Page 7]