< draft-housley-iesg-rfc3932bis-11.txt   draft-housley-iesg-rfc3932bis-12.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
Expires: 12 May 2010 12 November 2009 Expires: 16 May 2009 16 November 2009
IESG Procedures for Handling of Independent and IRTF Stream Submissions IESG Procedures for Handling of Independent and IRTF Stream Submissions
<draft-housley-iesg-rfc3932bis-11.txt> <draft-housley-iesg-rfc3932bis-12.txt>
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 3, line 35 skipping to change at page 3, line 35
request the review of Independent Submission Stream documents, and request the review of Independent Submission Stream documents, and
the IRTF will request review of IRTF Stream documents. There are the IRTF will request review of IRTF Stream documents. There are
many other interactions between document editors and the IESG for many 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
Independent Submission Stream, or the IESG may suggest that a Independent Submission Stream, or the IESG may suggest that a
document submitted to the IETF is better suited for submission to the document submitted to the IETF is better suited for submission to the
RFC Editor as part of Independent Submission Stream but these RFC Editor as part of Independent Submission Stream but these
interactions are not described in this memo. interactions are not described in this memo.
For the convenience of the reader, this document includes description
of some actions taken by the RFC Editor, the IAB, and the IRSG. The
inclusion of these actions is not normative. Rather, these actions
are included to describe the overall process surrounding the
normative IESG procedures described in this document. No RFC Editor,
IAB, or IRSG procedures are set by this document.
1.1. Changes since RFC 3932 1.1. Changes since RFC 3932
RFC 3932 provided procedures for the review of Independent Submission RFC 3932 provided procedures for the review of Independent Submission
Stream submissions. With the definition of procedures by the IRSG Stream submissions. With the definition of procedures by the IRSG
for the IRTF Stream, it has become clear that similar procedures for the IRTF Stream, it has become clear that similar procedures
apply to the review by the IESG of IRTF Stream documents. apply to the review by the IESG of IRTF Stream documents.
The IAB and the RFC Editor have made updates to the formatting of the The IAB and the RFC Editor have made updates to the formatting of the
title page for all RFCs [N3]. With these changes, the upper left title page for all RFCs [N3]. With these changes, the upper left
hand corner of the title page indicates the stream that produced the hand corner of the title page indicates the stream that produced the
skipping to change at page 6, line 40 skipping to change at page 6, line 47
the end of the dialogue, the IESG can reaffirm the original IESG the end of the dialogue, the IESG can reaffirm the original IESG
note, provide an alternate IESG note, or withdraw the note note, provide an alternate IESG note, or withdraw the note
altogether. If an IESG note is requested, the IRSG or the RFC Editor altogether. If an IESG note is requested, the IRSG or the RFC Editor
must state whether they intend to include it. must state whether they intend to include it.
If dialogue fails to resolve IRSG or RFC Editor concerns with the If dialogue fails to resolve IRSG or RFC Editor concerns with the
content of a requested IESG note and they intend to publish the content of a requested IESG note and they intend to publish the
document as an RFC without the requested IESG note, then the IESG can document as an RFC without the requested IESG note, then the IESG can
formally ask the IAB to provide arbitration. The IAB is not formally ask the IAB to provide arbitration. The IAB is not
obligated to perform arbitration and may decline the request. If the obligated to perform arbitration and may decline the request. If the
IAB accepts, the IAB review will occur according to procedures of the IAB declines, the RFC Editor decides whether the IESG note is
IAB's own choosing. The IAB can direct the inclusion of the IESG included. If the IAB accepts, the IAB review will occur according to
note or withdraw the note altogether. Unlike the IAB reviews procedures of the IAB's own choosing. The IAB can direct the
specified in RFC 4846 [I3], in this situation, the IAB decision is inclusion of the IESG note, direct the withdrawal of the IESG note,
binding, not advisory. or leave the final decision to the RFC Editor. Unlike the IAB
reviews specified in RFC 4846 [I3], if the IAB directs the inclusion
or withdrawal the IESG note, the IAB decision is binding, not
advisory.
5. Examples of Cases Where Publication Is Harmful 5. 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 8, line 21 skipping to change at page 8, line 33
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 the development of
this update go to (in alphabetical order) Jari Arkko, Ran Atkinson, this update go to (in alphabetical order) Jari Arkko, Ran Atkinson,
Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin,
and Olaf Kolkman. Olaf Kolkman, and Andy Malis.
9. References 9. References
9.1. Normative Reference 9.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. 6 change blocks. 
9 lines changed or deleted 19 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/