< draft-iesg-rfced-documents-02.txt		draft-iesg-rfced-documents-03.txt >
	Network Working Group H. Alvestrand		Network Working Group H. Alvestrand
	Internet-Draft May 4, 2004		Internet-Draft July 15, 2004
	Expires: November 2, 2004		Expires: January 13, 2005
	The IESG and RFC Editor documents: Procedures		The IESG and RFC Editor documents: Procedures
	draft-iesg-rfced-documents-02.txt		draft-iesg-rfced-documents-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		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		and any of which I become aware will be disclosed, in accordance with
	RFC 3667.		RFC 3667.
	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 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 2, 2004.		This Internet-Draft will expire on January 13, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document describes the IESG's procedures for handling documents		This document describes the IESG's procedures for handling documents
	submitted for RFC publication via the RFC Editor, subsequent to the		submitted for RFC publication via the RFC Editor, subsequent to the
	changes proposed by the IESG at the Seoul IETF, March 2004.		changes proposed by the IESG at the Seoul IETF, March 2004.
	NOTE IN DRAFT: These guidelines are proposed, not adopted. Comments		This document updates procedures described in RFC 2026 and RFC 3710.
	are welcome - please send them to iesg@ietf.org.
	1. Introduction and history		1. Introduction and history
	There are a number of different methods by which an RFC is published,		There are a number of different methods by which an RFC is published,
	some of which include review in the Internet Engineering Task Force		some of which include review in the Internet Engineering Task Force
	(IETF), and some of which include approval by the Internet		(IETF), and some of which include approval by the Internet
	Engineering Steering Group (IESG):		Engineering Steering Group (IESG):
	o IETF Working Group to Standards Track: Includes WG consensus,		o IETF Working Group (WG) to Standards Track: Includes WG consensus,
	review in the IETF, IETF Last Call and IESG approval		review in the IETF, IETF Last Call and IESG approval
	o IETF Working Group to Experimental/Informational: Includes WG		o IETF Working Group to Experimental/Informational: Includes WG
	consensus, review in the IETF and IESG approval		consensus, review in the IETF and IESG approval
	o AD Sponsored to Standards Track: Includes review in the IETF, IETF		o AD Sponsored to Standards Track: Includes review in the IETF, IETF
	Last Call and IESG approval		Last Call and IESG approval
	o AD Sponsored Individual to Experimental/Informational: Includes		o AD Sponsored Individual to Experimental/Informational: Includes
	some form of review in the IETF and IESG approval		some form of review in the IETF and IESG approval
	o Documents for which special rules exist		o Documents for which special rules exist
	o RFC Editor documents to Experimental/Informational		o RFC Editor documents to Experimental/Informational
	This memo is concerned with the IESG processing of the last category		This memo is concerned with the IESG processing of the last category
	only.		only.
	Special rules apply to some documents, including IAB documents, April		Special rules apply to some documents, including documents from the
	1st RFCs, and republication of documents from other SDOs. The IESG		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		and the RFC Editor keep a running dialogue, in consultation with the
	IAB, on these other documents and classification of them, but they		IAB, on these other documents and classification of them, but they
	are outside the scope of this memo.		are outside the scope of this memo.
	For the last few years, the IESG has reviewed all RFC Editor		For the last few years, the IESG has reviewed all RFC Editor
	documents (documents submitted by individuals to the RFC Editor for		documents (documents submitted by individuals to the RFC Editor for
	RFC publication) before publication. In 2003, this review was often a		RFC publication) before publication. In 2003, this review was often a
	full scale review of technical content, with the ADs attempting to		full scale review of technical content, with the ADs attempting to
	clear points with the authors, stimulate revisions of the documents,		clear points with the authors, stimulate revisions of the documents,
	encourage the authors to contact appropriate working groups and so		encourage the authors to contact appropriate working groups and so
	skipping to change at page 5, line 33 ¶		skipping to change at page 5, line 33 ¶
	NOTE TO RFC EDITOR: Please replace "RFC XXXX" with the actual RFC		NOTE TO RFC EDITOR: Please replace "RFC XXXX" with the actual RFC
	number of this document when published, and delete this sentence.		number of this document when published, and delete this sentence.
	5. Examples of cases where publication is harmful		5. Examples of cases where publication is harmful
	This section gives a couple of examples where it might be appropriate		This section gives a couple of examples where it might be appropriate
	to delay or prevent publishing of a document due to conflict with		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		IETF work. It forms part of the background material, not a part of
	the procedure.		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		Rejected Alternative Bypass: A WG is working on a solution to a
	problem, and a participant decides to ask for publication of a		problem, and a participant decides to ask for publication of a
	solution that the WG has rejected. Publication of the document will		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		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		finished. It seems better to have the WG product published first, and
	have the non-adopted document published later, with a clear		have the non-adopted document published later, with a clear
	disclaimer note saying that "the IETF technology for this function is		disclaimer note saying that "the IETF technology for this function is
	X". Example: Photuris (RFC 2522), which was published after IKE (RFC		X". Example: Photuris (RFC 2522), which was published after IKE (RFC
	2409).		2409).
	skipping to change at page 6, line 38 ¶		skipping to change at page 6, line 28 ¶
	with the respective roles of the IESG and RFC Editor. The IAB		with the respective roles of the IESG and RFC Editor. The IAB
	continues to monitor the range of organized discussions within the		continues to monitor the range of organized discussions within the
	IETF about potential adjustments to the IETF document publication		IETF about potential adjustments to the IETF document publication
	processes (e.g., NEWTRK working group), and recognizes that the		processes (e.g., NEWTRK working group), and recognizes that the
	process described in this document, as well as other general IETF		process described in this document, as well as other general IETF
	publication processes, and others may need to be adjusted in the		publication processes, and others may need to be adjusted in the
	light of the outcome of those discussions.		light of the outcome of those discussions.
	7. Security Considerations		7. Security Considerations
	The process change described in this memo has no bearing on the		The process change described in this memo has no direct bearing on
	security of the Internet.		the security of the Internet.
	8. Acknowledgements		8. Acknowledgements
	This document is a product of the IESG, and all its members deserve		This document is a product of the IESG, and all its members deserve
	thanks for their contributions to it.		thanks for their contributions to it.
	This document has been reviewed in the IETF, by the RFC Editor and		This document has been reviewed in the IETF, by the RFC Editor and
	the IAB; the IAB produced the text of section 6. Special thanks go to		the IAB; the IAB produced the text of section 6. Special thanks go to
	John Klensin, Keith Moore, Pete Resnick, Scott Bradner, Kurt		John Klensin, Keith Moore, Pete Resnick, Scott Bradner, Kurt
	Zeilenga, Eliot Lear, Paul Hoffman, Brian Carpenter and all other		Zeilenga, Eliot Lear, Paul Hoffman, Brian Carpenter and all other
	skipping to change at page 8, line 5 ¶		skipping to change at page 7, line 37 ¶
	o Changed "IETF review" to "IETF review and IESG approval" in bullet		o Changed "IETF review" to "IETF review and IESG approval" in bullet
	4 and 5 of section 3		4 and 5 of section 3
	o Clarified relative roles of RFC Editor and IESG at end of section		o Clarified relative roles of RFC Editor and IESG at end of section
	3		3
	o Used formulation of "decision to publish is not based on IETF		o Used formulation of "decision to publish is not based on IETF
	review" rather than "has not had IETF review" in standard IESG		review" rather than "has not had IETF review" in standard IESG
	notes		notes
	o Added section 6 with an IAB statement		o Added section 6 with an IAB statement
	o Added this section		o Added this section
			Appendix B. Changes from version -02 to -03
			This section should be removed by the RFC Editor.
			Added mention of 3710 and 2026 to the abstract
			Spelled out "IAB". Removed use of "SDO".
			Removed one example (Publish While Waiting)
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the IETF's procedures with respect to rights in IETF Documents can		on the IETF's procedures with respect to rights in IETF Documents can
	be found in BCP 78 and BCP 79.		be found in BCP 78 and BCP 79.
End of changes. 9 change blocks.
	21 lines changed or deleted		21 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/