< draft-housley-iesg-rfc3932bis-05.txt   draft-housley-iesg-rfc3932bis-06.txt >
INTERNET DRAFT H. Alvestrand INTERNET DRAFT H. Alvestrand
Obsoletes: 3932 (if approved) Google Obsoletes: 3932 (if approved) Google
Updates: 3710, 2026 (if approved) R. Housley Updates: 3710, 2026 (if approved) R. Housley
Category: Best Current Practice (if approved) Vigil Security Category: Best Current Practice (if approved) Vigil Security
Exipres: 26 April 2009 26 October 2008 Exipres: 18 May 2009 18 November 2008
IESG Procedures for Handling of Independent and IRTF Stream Submissions IESG Procedures for Handling of Independent and IRTF Stream Submissions
<draft-housley-iesg-rfc3932bis-05.txt> <draft-housley-iesg-rfc3932bis-06.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 14 skipping to change at page 2, line 14
which it will be published. The four streams defined in RFC 4844 which it will be published. The four streams defined in RFC 4844
are: are:
- The IETF stream - The IETF stream
- The IAB stream - The IAB stream
- The IRTF stream - The IRTF stream
- The Independent Submission stream - The Independent Submission stream
The IETF is responsible for maintaining the Internet Standards The IETF is responsible for maintaining the Internet Standards
Process, which includes the requirements for developing, reviewing Process, which includes the requirements for developing, reviewing
and approving Standards Track and BCP RFCs. These RFCs, and any and approving Standards Track and BCP RFCs. These RFCs, and any
other Informational or Experimental standards-related documents, are other IETF-generated Informational or Experimental documents, are
reviewed by appropriate IETF bodies and published as part of the IETF reviewed by appropriate IETF bodies and published as part of the IETF
Stream. Stream.
Documents published in streams other than the IETF Stream are not Documents published in streams other than the IETF Stream may not
reviewed by the IETF for such things as security, congestion control, receive any review by the IETF for such things as security,
or inappropriate interaction with deployed protocols. They have also congestion control, or inappropriate interaction with deployed
not been subject to IESG approval, including an IETF-wide Last Call. protocols. Generally, there is no attempt for IETF consensus or IESG
Therefore, the IETF disclaims, for any of the non-IETF Stream approval. Therefore, the IETF disclaims, for any of the non-IETF
documents, any knowledge of the fitness of those RFCs for any Stream documents, any knowledge of the fitness of those RFCs for any
purpose. purpose.
This memo is only concerned with the IESG processing of the last two This memo is only concerned with the IESG processing of the last two
categories, which comprise the Independent Submission Stream and the categories, which comprise the Independent Submission Stream and the
IRTF Document Stream, respectively [N1]. IRTF Document Stream, respectively [N1].
Following the approval of RFC 2026 [N2] and prior to the publication Following the approval of RFC 2026 [N2] and prior to the publication
of RFC 3932 [I1], the IESG reviewed all Independent Submission Stream of RFC 3932 [I1], the IESG reviewed all Independent Submission Stream
documents before publication. This review was often a full-scale documents before publication. This review was often a full-scale
review of technical content, with the Area Director (ADs) attempting review of technical content, with the Area Director (ADs) attempting
to clear points with the authors, stimulate revisions of the to clear points with the authors, stimulate revisions of the
documents, encourage the authors to contact appropriate working documents, encourage the authors to contact appropriate working
groups and so on. This was a considerable drain on the resources of groups (WGs) and so on. This was a considerable drain on the
the IESG, and since this is not the highest priority task of the IESG resources of the IESG, and since this was not the highest priority
members, it often resulted in significant delays. 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 In March 2004, the IESG decided to make a major change in this review
model, with the IESG taking responsibility only for checking for model, with the IESG taking responsibility only for checking for
conflicts between the work of the IETF and the documents submitted. conflicts between the work of the IETF and the documents submitted.
Soliciting technical review is deemed to be the responsibility of the Soliciting technical review is deemed to be the responsibility of the
RFC Editor. If an individual AD chooses to review the technical RFC Editor. If an individual AD chooses to review the technical
content of the document and finds issues, that AD will communicate content of the document and finds issues, that AD will communicate
these issues to the RFC Editor, and they will be treated the same way these issues to the RFC Editor, and they will be treated the same way
as comments on the documents from other sources. as comments on the documents from other sources.
Prior to 2006, documents from the IRTF were treated as individual Prior to 2006, documents from the IRTF were treated as either IAB
submissions via the RFC Editor. However, the Internet Research submissions or individual submissions via the RFC Editor. However,
Steering Group (IRSG) has established a review process for the the Internet Research Steering Group (IRSG) has established a review
publication of RFCs on the IRTF Document Stream [I2]. Once these process for the publication of RFCs on the IRTF Document Stream [I2].
procedures are fully adopted, the IESG will continue to be Once these procedures are fully adopted, the IESG will continue to be
responsible only for checking for conflicts between the work of the responsible only for checking for conflicts between the work of the
IETF and the documents submitted, but results of the check will be 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 reported to the IRTF. These results may be copied to the RFC Editor
as a courtesy. as a courtesy.
This document describes only the review process done by the IESG when This document describes only the review process done by the IESG when
the RFC Editor or the IRTF requests that review. There are many the RFC Editor or the IRTF requests that review. There are many
other interactions between document editors and the IESG for other interactions between document editors and the IESG for
instance, an AD may suggest that an author submit a document as input instance, an 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 for work within the IETF rather than to the RFC Editor as part of the
skipping to change at page 3, line 47 skipping to change at page 3, line 47
The review of independent submissions by the IESG was prescribed by The review of independent submissions by the IESG was prescribed by
RFC 2026 [N2] section 4.2.3. The procedure described in this RFC 2026 [N2] section 4.2.3. The procedure described in this
document is compatible with that description. document is compatible with that description.
The procedures developed by the IRTF for documents created by the The procedures developed by the IRTF for documents created by the
Research Groups also include review by the IESG [I2]. Research Groups also include review by the IESG [I2].
The IESG Charter, RFC 3710 [I5], section 5.2.2 describes the review The IESG Charter, RFC 3710 [I5], section 5.2.2 describes the review
process that was employed in Spring 2003 (even though the RFC was not process that was employed in Spring 2003 (even though the RFC was not
published until 2004); with the publication of RFC 3932 [I1], the published until 2004); with the publication of RFC 3932 [I1], the
procedure described in RFC 3710 is no longer relevant to documents procedure described in RFC 3710 was no longer relevant to documents
submitted via the RFC Editor. The publication of this document submitted via the RFC Editor. The publication of this document
further updates RFC 3710, section 5.2.2 so that it covers the IRTF further updates RFC 3710, section 5.2.2 so that it covers the IRTF
stream and the Individual Submission Stream. stream and the Individual Submission Stream.
3. Detailed Description of IESG Review 3. Detailed Description of IESG Review
The RFC Editor reviews Independent Stream submissions for suitability The RFC Editor reviews Independent Stream submissions for suitability
for publications as RFC. As described in RFC 4846 [I3], the RFC for publications as RFC. As described in RFC 4846 [I3], the RFC
Editor asks the IESG to review the documents for conflicts with the Editor asks the IESG to review the documents for conflicts with the
IETF standards process or work done in the IETF community. IETF standards process or work done in the IETF community.
Similarly, documents intended for publication as part of the IRTF Similarly, documents intended for publication as part of the IRTF
Stream are sent to the IESG for review for conflicts with the IETF Stream are sent to the IESG for review for conflicts with the IETF
standards process or work done in the IETF community [I2]. standards process or work done in the IETF community [I2].
The IESG review of these Independent Stream and IRTF Stream documents The IESG review of these Independent Stream and IRTF Stream documents
reach one of the following five types of conclusions. reach one of the following five types of conclusions.
1. The IESG has not found any conflict between this document and IETF 1. The IESG has concluded that there is no conflict between this
work. document and IETF work.
2. The IESG finds that this work is related to IETF work done in WG 2. The IESG has concluded that this work is related to IETF work done
<X>, but this relationship does not prevent publishing. in WG <X>, but this relationship does not prevent publishing.
3. The IESG finds that publication is harmful to the IETF work done 3. The IESG has concluded that publication could potentially disrupt
in WG <X> and recommends not publishing the document at this time. the IETF work done in WG <X> and recommends not publishing the
document at this time.
4. The IESG finds that this document violates IETF procedures for <X> 4. The IESG has concluded that this document violates IETF procedures
and should therefore not be published without IETF review and IESG for <X> and should therefore not be published without IETF review
approval. and IESG approval.
5. The IESG finds that this document extends an IETF protocol in a 5. The IESG has concluded that this document extends an IETF protocol
way that requires IETF review and should therefore not be in a way that requires IETF review and should therefore not be
published without IETF review and IESG approval. published without IETF review and IESG approval.
Generally, the RFC headers and boilerplate clearly describe the Generally, the RFC headers and boilerplate clearly describe the
relationship of the document to the IETF standards process [N3]. In relationship of the document to the IETF standards process [N3]. In
exceptional cases, when the relationship of the document to the IETF exceptional cases, when the relationship of the document to the IETF
standards process might be unclear, the IESG response may be standards process might be unclear, the IESG response may be
accompanied by a clarifying IESG note and a request that the RFC accompanied by a clarifying IESG note and a request that the RFC
Editor include the IESG note in the document if the document is Editor include the IESG note in the document if the document is
published. published.
The last two responses are included respectively, for the case where The last two responses are included respectively, for the case where
a document attempts to take actions (such as registering a new URI a document attempts to take actions (such as registering a new URI
scheme) that require IETF Review, Standards Action, or IESG Approval scheme) that require IETF Review, Standards Action, or IESG Approval
(as these terms are defined in RFC 5226 [3]), and for the case where (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 an IETF protocol is proposed to be changed or extended in an
unanticipated way that may be harmful to the normal usage of the unanticipated way that may be detrimental to the normal usage of the
protocol, but where the protocol documents do not explicitly say that protocol, but where the protocol documents do not explicitly say that
this type of extension requires IETF review. this type of extension requires IETF review.
If a document requires IETF review, the IESG will offer the author If a document requires IETF review, the IESG will offer the author
the opportunity to ask for publication as an AD-sponsored individual the opportunity to ask for publication as an AD-sponsored individual
document, which is subject to full IESG review, including possible document, which is subject to full IETF review, including possible
assignment to a WG or rejection. Redirection to the full IESG review 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 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 even that the IESG will give it any particular priority; it is a
guarantee that the IESG will consider the document. guarantee that the IESG will consider the document.
The IESG will normally complete review within four weeks after The IESG will normally complete review within four weeks after
notification by the RFC Editor or IRTF. In the case of a possible 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 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 opinion of whether publishing the document is harmful to the work of
that WG and, in the case of a possible conflict with an IANA that WG and, in the case of a possible conflict with an IANA
skipping to change at page 5, line 29 skipping to change at page 5, line 29
If the IESG does not find any conflict between an independent If the IESG does not find any conflict between an independent
submission and IETF work, then the RFC Editor is responsible for submission and IETF work, then the RFC Editor is responsible for
judging the technical merits for that submission, including judging the technical merits for that submission, including
considerations of possible harm to the Internet. If the IESG does considerations of possible harm to the Internet. If the IESG does
not find any conflict between an IRTF submission and IETF work, then not find any conflict between an IRTF submission and IETF work, then
the IRSG is responsible for judging the technical merits for that the IRSG is responsible for judging the technical merits for that
submission, including considerations of possible harm to the submission, including considerations of possible harm to the
Internet. Internet.
The IESG assumes that the RFC Editor, in agreement with the IAB, will The RFC Editor, in agreement with the IAB, shall manage mechanisms
manage mechanisms for appropriate technical review of independent for appropriate technical review of independent submissions.
submissions. Likewise, the IESG also assumes that the IRSG, in Likewise, the IRSG, in agreement with the IAB, shall manage
agreement with the IAB, will manage mechanisms for appropriate mechanisms for appropriate technical review of IRTF submissions.
technical review of IRTF submissions.
4. Examples of Cases Where Publication Is Harmful 4. Examples of Cases Where Publication Is Harmful
This section gives a couple of examples where delaying or preventing This section gives a couple of examples where delaying or preventing
publication of a document might be appropriate due to conflict with publication of a document might be appropriate due to conflict with
IETF work. It forms part of the background material, not a part of IETF work. It forms part of the background material, not a part of
the procedure. the procedure.
Rejected Alternative Bypass: Rejected Alternative Bypass:
skipping to change at page 7, line 10 skipping to change at page 7, line 9
RFC 3932 was a product of the IESG in October 2004, and it was 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 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 thanks for the development of RFC 3932 go to John Klensin, Keith
Moore, Pete Resnick, Scott Bradner, Kurt Zeilenga, Eliot Lear, Paul Moore, Pete Resnick, Scott Bradner, Kurt Zeilenga, Eliot Lear, Paul
Hoffman, Brian Carpenter, and all other IETF community participants Hoffman, Brian Carpenter, and all other IETF community participants
who provided valuable feedback. who provided valuable feedback.
This update to RFC 3932 was the product of the IESG in July and This update to RFC 3932 was the product of the IESG in July and
August of 2008, and it was reviewed in the IETF, by the RFC Editor, August of 2008, and it was reviewed in the IETF, by the RFC Editor,
by the IRSG, and by the IAB. Special thanks for this development of by the IRSG, and by the IAB. Special thanks for this development of
this update go to (in alphabetical order) Lars Eggert, Aaron Falk, this update go to (in alphabetical order) Jari Arkko, Ran Atkinson,
Sam Hartman, and Olaf Kolkman. Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin,
and Olaf Kolkman.
8. References 8. References
8.1. Normative Reference 8.1. Normative Reference
[N1] Internet Architecture Board and L. Daigle, Ed., "The RFC Series [N1] Internet Architecture Board and L. Daigle, Ed., "The RFC Series
and RFC Editor", RFC 4844, July 2007. and RFC Editor", RFC 4844, July 2007.
[N2] Bradner, S., "The Internet Standards Process -- Revision 3", [N2] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
 End of changes. 16 change blocks. 
38 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/