One document matched: draft-housley-iesg-rfc3932bis-00.txt
INTERNET DRAFT H. Alvestrand
Obsoletes: 3932 (if approved) Google
Updates: 3710, 2026 (if approved) R. Housley
Category: Best Current Practice (if approved) Vigil Security
Exipres: January 2009 July 30, 2008
The IESG Procedures for Independent Stream Submissions from
the RFC Editor and IRTF Stream Submissions from the IRSG
<draft-housley-iesg-rfc3932bis-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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes the procedures used by the IESG for handling
documents submitted for RFC publication via the RFC Editor and IRTF.
This document updates procedures described in RFC 2026 and RFC 3710.
{{{ RFC Editor: Please change "RFC XXXX" to the number assigned to
this document prior to publication. }}}
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 & Housley [Page 1]
RFC3932bis IESG and RFC Editor Documents: Procedures April 2008
(IETF), and some of which include approval by the Internet
Engineering Steering Group (IESG):
o IETF Working Group (WG) to Standards Track: Includes WG consensus,
review in the IETF, IETF Last Call, and IESG approval
o IETF WG to Experimental/Informational: Includes WG consensus,
review in the IETF, and IESG approval
o Area Director (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
o RFC Editor documents to Experimental/Informational
o Internet Research Task Force (IRTF) documents to
Experimental/Informational
This memo is only concerned with the IESG processing of the last two
categories, which comprise Independent Submission Stream and the IRTF
Document Stream, respectively [5].
Special rules apply to some documents, including documents from the
Internet Architecture Board (IAB), April 1st RFCs, and republication
of documents from other standards development organizations. The
IESG and the RFC Editor keep a running dialogue, in consultation with
the IAB, on such documents and their classification, but they are
outside the scope of the procedures described in this memo.
Prior to the publication of RFC 3932 [6], the IESG has reviewed all
Independent Submission Stream documents before publication. 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 of the IESG members, it often resulted in significant delays.
In March 2004, the IESG decided to make a major change in this review
model, with the IESG taking 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 IESG member
Alvestrand & Housley [Page 2]
RFC3932bis IESG and RFC Editor Documents: Procedures April 2008
will communicate these issues to the RFC Editor, and they will be
treated the same way as comments on the documents from other sources.
Prior to July 2008 (???), documents from the IRTF were treated as
individual submissions via the RFC Editor. However, the Internet
Research Steering Group (IRSG) has established a review process for
the publication of RFCs on the IRTF Document Stream. Once these
procedures are fully adopted, the IESG will continue to be
responsible only for checking for conflicts between the work of the
IETF and the documents submitted, but results of the check will be
reported to the IRTF. These results may be copied to the RFC Editor
as a courtesy.
This document describes only the review process done by the IESG when
the RFC Editor or the IRTF requests that review. There are many
other interactions between document editors and the IESG for
instance, an Area Director (AD) may suggest that an author submit a
document as input for work within the IETF rather than to the RFC
Editor as part of the Independent Submission Stream, or the IESG may
suggest that a document submitted to the IETF is better suited for
submission to the RFC Editor as part of Independent Submission Stream
but these interactions are not described in this memo.
1.1. Changes since RFC 3932
RFC 3932 provided procedures for the review of Independent Submission
Stream submissions. With the definition of procedures by the IRSG
for the IRTF Document Stream, it has become clear that similar
procedures apply to the review by the IESG of IRTF Document Stream
documents.
The IAB and the RFC Editor have made updates to the formatting of the
title page for all RFCs [7]. With theses changes, the upper left
hand corner of the title page indicates the stream that produced the
RFC. This label eliminates the need for a mandatory IESG note on all
Independent Stream documents.
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.
The procedures developed by the IRTF for documents created by the
Research Groups also include review by the IESG.
The IESG Charter, RFC 3710 [2], section 5.2.2 describes the review
process that was employed in Spring 2003 (even though the RFC was not
Alvestrand & Housley [Page 3]
RFC3932bis IESG and RFC Editor Documents: Procedures April 2008
published until 2004); with the publication of this document, the
procedure described in RFC 3710 is no longer relevant to documents
submitted via the RFC Editor.
3. Detailed Description of IESG Review
The RFC Editor reviews Independent Stream submissions for suitability
for publications as RFC. Once the RFC Editor thinks a document may
be suited for RFC publication, the RFC Editor asks the IESG to review
the documents 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
document 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.
Similarly, documents intended for publication as part of the IRTF
Stream are sent to the IESG for review for conflicts with the IETF
standards process or work done in the IETF community.
The IESG review of these Independent Stream and IRTF Stream documents
may return one of the following five responses.
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 and
IESG approval.
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 and IESG approval.
Generally, the RFC headers and boilerplate clearly describe the
relationship of the document to the IETF standards process [7]. In
exceptional cases, when the relationship of the document to the IETF
standards process might be unclear, the IESG response may be
accompanied by a clarifying IESG note to be put on the document if
the RFC Editor wishes to publish the document.
Alvestrand & Housley [Page 4]
RFC3932bis IESG and RFC Editor Documents: Procedures April 2008
The last two responses are included respectively, for the case where
a document attempts to take actions (such as registering a new URI
scheme) that require IETF Consensus, Standards Action, or IESG
Approval (as these terms are defined in RFC 5226 [3]), and for 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.
If a document requires 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 after
notification by the RFC Editor or IRTF. 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 IANA expert for that registry.
If the IESG does not found any conflict between a submission and IETF
work, then judging its technical merits, including considerations of
possible harm to the Internet, will become the responsibility of the
RFC Editor or the IRTF. The IESG assumes that the RFC Editor and
IRTF, in agreement with the IAB, will manage mechanisms for
additional technical review.
4. Examples of Cases Where Publication Is Harmful
This section gives a couple of examples where delaying or preventing
publication of a document might be appropriate due to conflict with
IETF work. It forms part of the background material, not a part of
the procedure.
Rejected Alternative Bypass: As a WG is working on a solution to a
problem, a participant decides to ask for RFC publication of a
solution that the WG has rejected as part of the Independent Stream.
Publication of the document will give the publishing party an RFC
number 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
Alvestrand & Housley [Page 5]
RFC3932bis IESG and RFC Editor Documents: Procedures April 2008
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. No
IANA consideration says 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 adopted by the WG.
The RFC series is one of many available publication channels; this
document takes no position on the question of which documents are
appropriate for publication in the RFC Series. That is a matter for
discussion in the Internet community.
5. IAB Statement
In its capacity as the body that approves the general policy followed
by the RFC Editor (see RFC 2850 [4]), the IAB has reviewed this
proposal and supports it as an operational change that is in line
with the respective roles of the IESG, IRTF, and RFC Editor. The IAB
continues to monitor discussions within the IETF about potential
adjustments to the IETF document publication processes and recognizes
that the process described in this document, as well as other general
IETF publication processes, may need to be adjusted to align with any
changes that result from such discussions.
6. Security Considerations
The process change described in this memo has no direct bearing on
the security of the Internet.
7. Acknowledgements
RFC 3932 was a product of the IESG in October 2004, and it was
reviewed in the IETF, by the RFC Editor, and by the IAB. Special
thanks for the development of RFC 3932 go to John Klensin, Keith
Moore, Pete Resnick, Scott Bradner, Kurt Zeilenga, Eliot Lear, Paul
Hoffman, Brian Carpenter, and all other IETF community members who
provided valuable feedback.
This update to RFC 3932 was the product of the IESG in July 2008, and
Alvestrand & Housley [Page 6]
RFC3932bis IESG and RFC Editor Documents: Procedures April 2008
it was reviewed in the IETF, by the RFC Editor, by the IRSG, and by
the IAB. Special thanks for this development of this update go to
Aaron Falk, Olaf Kolkman, and Lars Eggert.
8. References
8.1. Normative Reference
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.
8.2. Informative References
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2226, May 2008.
[4] Internet Architecture Board and B. Carpenter, Ed., "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May
2000.
[5] Internet Architecture Board and L. Daigle, Ed., "The RFC Series
and RFC Editor", RFC 4844, July 2007.
[6] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures",
RFC 3932, October 2004.
[7] Header and boilerplate document from the IAB.
Authors' Address
Harald Alvestrand
EMail: harald@alvestrand.no
Russell Housley
Email: housley@vigilsec.com
Copyright and IPR Statements
Copyright (C) The IETF Trust (2008).
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 translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
Alvestrand & Housley [Page 7]
RFC3932bis IESG and RFC Editor Documents: Procedures April 2008
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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.
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.
Alvestrand & Housley [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-21 20:05:40 |