draft-ietf-proto-wgchair-doc-shepherding-08.txt		draft-ietf-proto-wgchair-doc-shepherding.txt
	PROTO Team H. Levkowetz		PROTO Team H. Levkowetz
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational D. Meyer		Intended status: Informational D. Meyer
	Expires: April 25, 2007 Cisco/University of Oregon		Expires: July 28, 2007 Cisco/University of Oregon
	L. Eggert		L. Eggert
	NEC		Nokia
	A. Mankin		A. Mankin
	October 22, 2006		January 24, 2007
	Document Shepherding from Working Group Last Call to Publication		Document Shepherding from Working Group Last Call to Publication
	draft-ietf-proto-wgchair-doc-shepherding-08		draft-ietf-proto-wgchair-doc-shepherding-09
	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		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://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 April 25, 2007.		This Internet-Draft will expire on July 28, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes methodologies that have been designed to		This document describes methodologies that have been designed to
	improve and facilitate IETF document flow processing. It specifies a		improve and facilitate IETF document flow processing. It specifies a
	set of procedures under which a working group chair or secretary		set of procedures under which a working group chair or secretary
	serves as the primary Document Shepherd for a document that has been		serves as the primary Document Shepherd for a document that has been
	submitted to the IESG for publication. Before this, the Area		submitted to the IESG for publication. Before this, the Area
	Director responsible for the working group has traditionally filled		Director responsible for the working group has traditionally filled
	the shepherding role.		the shepherding role.
	skipping to change at page 3, line 16		skipping to change at page 3, line 16
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Process Description . . . . . . . . . . . . . . . . . . . . . 5		3. Process Description . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6		3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6
	3.2. Document Shepherding during AD Evaluation . . . . . . . . 10		3.2. Document Shepherding during AD Evaluation . . . . . . . . 10
	3.3. Document Shepherding during IESG Evaluation . . . . . . . 11		3.3. Document Shepherding during IESG Evaluation . . . . . . . 11
	4. Shepherding the Document's IANA Actions . . . . . . . . . . . 14		4. Shepherding the Document's IANA Actions . . . . . . . . . . . 14
	5. Document Shepherding after IESG Approval . . . . . . . . . . . 15		5. Document Shepherding after IESG Approval . . . . . . . . . . . 15
	6. When Not to Use the Document Shepherding Process . . . . . . . 16		6. When Not to Use the Document Shepherding Process . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	10. Informative References . . . . . . . . . . . . . . . . . . . . 17		10. Informative References . . . . . . . . . . . . . . . . . . . . 17
	Appendix A. Example Document Announcement Write-Ups . . . . . . . 18		Appendix A. Example Document Announcement Write-Ups . . . . . . . 18
	A.1. Example Document Announcement Write-Up for		A.1. Example Document Announcement Write-Up for
	draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 18		draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 19
	A.2. Example Document Announcement Write-Up for		A.2. Example Document Announcement Write-Up for
	draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19		draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19
	Appendix B. Working Documents . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	Intellectual Property and Copyright Statements . . . . . . . . . . 22		Intellectual Property and Copyright Statements . . . . . . . . . . 22
	1. Introduction		1. Introduction
	Early in 2004, the IESG undertook several experiments aimed at		Early in 2004, the IESG undertook several experiments aimed at
	evaluating whether any of the proposed changes to the IETF document		evaluating whether any of the proposed changes to the IETF document
	flow process would yield qualitative improvements in document		flow process would yield qualitative improvements in document
	throughput and quality. One such experiment, referred to as the		throughput and quality. One such experiment, referred to as the
	"PROTO process" or "PROTO" (because it was created by the "PROcess		"PROTO process" or "PROTO" (because it was created by the "PROcess
	and TOols" or PROTO [PROTO] team, is a set of methodologies designed		and TOols" or PROTO [PROTO] team), is a set of methodologies designed
	to involve working group chairs or secretaries more directly in their		to involve working group chairs or secretaries more directly in their
	documents' approval life cycle. In particular, the PROTO team		documents' approval life cycle. In particular, the PROTO team
	focused on improvements to the part of a document's life cycle that		focused on improvements to the part of a document's life cycle that
	occurs after the working group and document editor have forwarded it		occurs after the working group and document editor have forwarded it
	to the IESG for publication.		to the IESG for publication.
	By the end of 2004, the IESG had evaluated the utility of the PROTO		By the end of 2004, the IESG had evaluated the utility of the PROTO
	methodologies based on data obtained through several pilot projects		methodologies based on data obtained through several pilot projects
	that had run throughout the year, and subsequently decided to adopt		that had run throughout the year, and subsequently decided to adopt
	the PROTO process for all documents and working groups. This		the PROTO process for all documents and working groups. This
	skipping to change at page 6, line 35		skipping to change at page 6, line 35
	Section 6 discusses other instances in which the document shepherding		Section 6 discusses other instances in which the document shepherding
	process does not apply.		process does not apply.
	3.1. Document Shepherd Write-Up		3.1. Document Shepherd Write-Up
	When a working group decides that a document is ready for submission		When a working group decides that a document is ready for submission
	to the IESG for publication, it is the task of the Document Shepherd		to the IESG for publication, it is the task of the Document Shepherd
	to complete a "Document Shepherd Write-Up" for the document.		to complete a "Document Shepherd Write-Up" for the document.
	There are two parts to this task. First, the Document Shepherd		There are two parts to this task. First, the Document Shepherd
	answers questions (1.a) to (1.i) below to give the Responsible Area		answers questions (1.a) to (1.j) below to give the Responsible Area
	Director insight into the working group process that applied to this		Director insight into the working group process that applied to this
	document. Note that while these questions may appear redundant in		document. Note that while these questions may appear redundant in
	some cases, they are written to elicit information that the		some cases, they are written to elicit information that the
	Responsible Area Director must be aware of (to this end, pointers to		Responsible Area Director must be aware of (to this end, pointers to
	relevant entries in the WG archive are helpful). The goal here is to		relevant entries in the WG archive are helpful). The goal here is to
	inform the Responsible Area Director about any issues that may have		inform the Responsible Area Director about any issues that may have
	come up in IETF meetings, on the mailing list, or in private		come up in IETF meetings, on the mailing list, or in private
	communication that they should be aware of prior to IESG evaluation		communication that they should be aware of prior to IESG evaluation
	of the shepherded document. Any significant issues mentioned in the		of the shepherded document. Any significant issues mentioned in the
	questionnaire will probably lead to a follow-up discussion with the		questionnaire will probably lead to a follow-up discussion with the
	Responsible Area Director.		Responsible Area Director.
	The second part of the task is to prepare the "Document Announcement		The second part of the task is to prepare the "Document Announcement
	Write-Up" that is input to both the ballot for the IESG telechat and		Write-Up" that is input to both the ballot for the IESG telechat and
	to the eventual IETF-wide announcement message. Item number (1.i)		to the eventual IETF-wide announcement message. Item number (1.k)
	describes the elements of the Document Announcement Write-Up.		describes the elements of the Document Announcement Write-Up.
	A final sentence of the Document Announcement Write-Up, simply placed
	as a line at the end of the "Document Quality" section, can state the
	names of the Document Shepherd and the Responsible Area Director,
	because the announcement will not otherwise acknowledge them. The
	Document Shepherd SHOULD add this information and the Responsible
	Area Director SHOULD add it if it is not already there.
	Some examples of Document Announcement Write-Ups are included in		Some examples of Document Announcement Write-Ups are included in
	Appendix A, and there are many more examples with subject lines such		Appendix A, and there are many more examples with subject lines such
	as "Protocol Action" and "Document Action" in the IETF-announce		as "Protocol Action" and "Document Action" in the IETF-announce
	mailing list archive.		mailing list archive.
			The initial template for the Document Shepherd Write-Up is included
			below, but changes are expected over time. The latest version of
			this template is available from the IESG section of the IETF web
			site.
	(1.a) Who is the Document Shepherd for this document? Has the		(1.a) Who is the Document Shepherd for this document? Has the
	Document Shepherd personally reviewed this version of the		Document Shepherd personally reviewed this version of the
	document and, in particular, does he or she believe this		document and, in particular, does he or she believe this
	version is ready for forwarding to the IESG for publication?		version is ready for forwarding to the IESG for publication?
	(1.b) Has the document had adequate review both from key WG members		(1.b) Has the document had adequate review both from key WG members
	and from key non-WG members? Does the Document Shepherd have		and from key non-WG members? Does the Document Shepherd have
	any concerns about the depth or breadth of the reviews that		any concerns about the depth or breadth of the reviews that
	have been performed?		have been performed?
	skipping to change at page 7, line 39		skipping to change at page 7, line 37
	e.g., security, operational complexity, someone familiar with		e.g., security, operational complexity, someone familiar with
	AAA, internationalization or XML?		AAA, internationalization or XML?
	(1.d) Does the Document Shepherd have any specific concerns or		(1.d) Does the Document Shepherd have any specific concerns or
	issues with this document that the Responsible Area Director		issues with this document that the Responsible Area Director
	and/or the IESG should be aware of? For example, perhaps he		and/or the IESG should be aware of? For example, perhaps he
	or she is uncomfortable with certain parts of the document, or		or she is uncomfortable with certain parts of the document, or
	has concerns whether there really is a need for it. In any		has concerns whether there really is a need for it. In any
	event, if the WG has discussed those issues and has indicated		event, if the WG has discussed those issues and has indicated
	that it still wishes to advance the document, detail those		that it still wishes to advance the document, detail those
	concerns here.		concerns here. Has an IPR disclosure related to this document
			been filed? If so, please include a reference to the
			disclosure and summarize the WG discussion and conclusion on
			this issue.
	(1.e) How solid is the WG consensus behind this document? Does it		(1.e) How solid is the WG consensus behind this document? Does it
	represent the strong concurrence of a few individuals, with		represent the strong concurrence of a few individuals, with
	others being silent, or does the WG as a whole understand and		others being silent, or does the WG as a whole understand and
	agree with it?		agree with it?
	(1.f) Has anyone threatened an appeal or otherwise indicated extreme		(1.f) Has anyone threatened an appeal or otherwise indicated extreme
	discontent? If so, please summarise the areas of conflict in		discontent? If so, please summarise the areas of conflict in
	separate email messages to the Responsible Area Director. (It		separate email messages to the Responsible Area Director. (It
	should be in a separate email because this questionnaire is		should be in a separate email because this questionnaire is
	skipping to change at page 8, line 28		skipping to change at page 8, line 28
	so, list these downward references to support the Area		so, list these downward references to support the Area
	Director in the Last Call procedure for them [RFC3967].		Director in the Last Call procedure for them [RFC3967].
	(1.i) Has the Document Shepherd verified that the document IANA		(1.i) Has the Document Shepherd verified that the document IANA
	consideration section exists and is consistent with the body		consideration section exists and is consistent with the body
	of the document? If the document specifies protocol		of the document? If the document specifies protocol
	extensions, are reservations requested in appropriate IANA		extensions, are reservations requested in appropriate IANA
	registries? Are the IANA registries clearly identified? If		registries? Are the IANA registries clearly identified? If
	the document creates a new registry, does it define the		the document creates a new registry, does it define the
	proposed initial contents of the registry and an allocation		proposed initial contents of the registry and an allocation
	procedure for future registrations? Does it suggested a		procedure for future registrations? Does it suggest a
	reasonable name for the new registry? See		reasonable name for the new registry? See [RFC2434]. If the
	[I-D.narten-iana-considerations-rfc2434bis]. If the document		document describes an Expert Review process has Shepherd
	describes an Expert Review process has Shepherd conferred with		conferred with the Responsible Area Director so that the IESG
	the Responsible Area Director so that the IESG can appoint the		can appoint the needed Expert during the IESG Evaluation?
	needed Expert during the IESG Evaluation?
	(1.j) Has the Document Shepherd verified that sections of the		(1.j) Has the Document Shepherd verified that sections of the
	document that are written in a formal language, such as XML		document that are written in a formal language, such as XML
	code, BNF rules, MIB definitions, etc., validate correctly in		code, BNF rules, MIB definitions, etc., validate correctly in
	an automated checker?		an automated checker?
	(1.k) The IESG approval announcement includes a Document		(1.k) The IESG approval announcement includes a Document
	Announcement Write-Up. Please provide such a Document		Announcement Write-Up. Please provide such a Document
	Announcement Writeup? Recent examples can be found in the		Announcement Write-Up? Recent examples can be found in the
	"Action" announcements for approved documents. The approval		"Action" announcements for approved documents. The approval
	announcement contains the following sections:		announcement contains the following sections:
	Technical Summary		Technical Summary
	Relevant content can frequently be found in the abstract		Relevant content can frequently be found in the abstract
	and/or introduction of the document. If not, this may be		and/or introduction of the document. If not, this may be
	an indication that there are deficiencies in the abstract		an indication that there are deficiencies in the abstract
	or introduction.		or introduction.
	Working Group Summary		Working Group Summary
	skipping to change at page 9, line 29		skipping to change at page 9, line 29
	what was its course (briefly)? In the case of a Media Type		what was its course (briefly)? In the case of a Media Type
	review, on what date was the request posted?		review, on what date was the request posted?
	Personnel		Personnel
	Who is the Document Shepherd for this document? Who is the		Who is the Document Shepherd for this document? Who is the
	Responsible Area Director?		Responsible Area Director?
	The Document Shepherd MUST send the Document Shepherd Write-Up to the		The Document Shepherd MUST send the Document Shepherd Write-Up to the
	Responsible Area Director and iesg-secretary@ietf.org together with		Responsible Area Director and iesg-secretary@ietf.org together with
	the request to publish the document. The Document Shepherd SHOULD		the request to publish the document. The Document Shepherd SHOULD
	also send the entire Document Shepherd Write-up to the working group		also send the entire Document Shepherd Write-Up to the working group
	mailing list. If the Document Shepherd feels that information which		mailing list. If the Document Shepherd feels that information which
	may prove to be sensitive, lead to possible appeals or is personal		may prove to be sensitive, lead to possible appeals or is personal
	information needs to be written up, it SHOULD be sent in direct email		information needs to be written up, it SHOULD be sent in direct email
	to the Responsible Area Director, because the Document Shepherd		to the Responsible Area Director, because the Document Shepherd
	Write-Up is published openly in the tracker. Question 1(f) of the		Write-Up is published openly in the ID Tracker. Question (1.f) of
	Write-Up covers any material of this nature and specifies this more		the Write-Up covers any material of this nature and specifies this
	confidential handling.		more confidential handling.
	The Document Shepherd Write-Up is entered into the ID Tracker		The Document Shepherd Write-Up is entered into the ID Tracker
	[IDTRACKER] as a "Comment." The name and email address of the		[IDTRACKER] as a "Comment." The name and email address of the
	Document Shepherd are entered into the ID Tracker, currently as a		Document Shepherd are entered into the ID Tracker, currently as a
	"Brief Note" (this may change in the future). The email address of		"Brief Note" (this may change in the future). The email address of
	the Document Shepherd MUST also be added to the "State or Version		the Document Shepherd MUST also be added to the "State or Version
	Change Notice To" field (typically the email addresses of all working		Change Notice To" field (typically the email addresses of all working
	group chairs, authors and the Secretary will be added).		group chairs, authors and the secretary will be added).
	Entering the name and email of the Document Shepherd into the ID		Entering the name and email of the Document Shepherd into the ID
	Tracker is REQUIRED to ensure that he or she will be copied on the		Tracker is REQUIRED to ensure that he or she will be copied on the
	email exchange between the editors, chairs, the IESG, the IESG		email exchange between the editors, chairs, the IESG, the IESG
	secretariat, IANA and the RFC Editor during the review and approval		secretariat, IANA and the RFC Editor during the review and approval
	process. There are still manual steps required for these parties to		process. There are still manual steps required for these parties to
	ensure they include the Document Shepherd, but it is hoped that in		ensure they include the Document Shepherd, but it is hoped that in
	future, automated tools will ensure that Document Shepherds (and		future, automated tools will ensure that Document Shepherds (and
	others) receive necessary communications.		others) receive necessary communications.
	The contact information for the Document Shepherd is also important		The contact information for the Document Shepherd is also important
	for the Gen-ART [GEN-ART] Directorate and other directorates, so they		for the Gen-ART Directorate [GEN-ART] and other directorates, so they
	can know to whom to address reviews, in addition to the Responsible		can know to whom to address reviews, in addition to the Responsible
	Area Director.		Area Director.
	3.2. Document Shepherding during AD Evaluation		3.2. Document Shepherding during AD Evaluation
	The steps for document shepherding during AD Evaluation are as		The steps for document shepherding during AD Evaluation are as
	follows:		follows:
	(2.a) The Responsible Area Director reads, evaluates and comments on		(2.a) The Responsible Area Director reads, evaluates and comments on
	the document, as is the case when not using the document		the document, as is the case when not using the document
	skipping to change at page 10, line 45		skipping to change at page 10, line 45
	(2.d) The Document Shepherd sends the AD Evaluation comments to the		(2.d) The Document Shepherd sends the AD Evaluation comments to the
	editors and to the working group mailing list, in order to		editors and to the working group mailing list, in order to
	have a permanent record of the comments. It is RECOMMENDED		have a permanent record of the comments. It is RECOMMENDED
	that the Document Shepherd solicit from the editors an		that the Document Shepherd solicit from the editors an
	estimate on when the required changes will be complete and a		estimate on when the required changes will be complete and a
	revised document can be expected. Working groups that use		revised document can be expected. Working groups that use
	issue tracking SHOULD also record the issues (and eventually		issue tracking SHOULD also record the issues (and eventually
	their resolution) in their issue tracker.		their resolution) in their issue tracker.
	(2.e) During the production of a revised document that addresses the		(2.e) During the production of a revised document that addresses the
	AD Evaluation comments, it is strongly RECOMMENDED that the		AD Evaluation comments, it is RECOMMENDED that the editors
	editors keep a list showing how each comment was addressed and		keep a list showing how each comment was addressed and what
	what the revised text is. It is strongly RECOMMENDED that		the revised text is. It is RECOMMENDED that this list be
	this list be forwarded to the Responsible Area Director		forwarded to the Responsible Area Director together with the
	together with the revised document.		revised document.
	(2.f) In the event that the editors or working group disagrees with		(2.f) In the event that the editors or working group disagrees with
	a comment raised by the Responsible Area Director or has		a comment raised by the Responsible Area Director or has
	previously considered and dismissed the issue, the Document		previously considered and dismissed the issue, the Document
	Shepherd MUST resolve the issue with the Responsible Area		Shepherd MUST resolve the issue with the Responsible Area
	Director before a revised document can be submitted.		Director before a revised document can be submitted.
	(2.g) The Document Shepherd iterates with the editors (and working		(2.g) The Document Shepherd iterates with the editors (and working
	group, if required) until all outstanding issues have been		group, if required) until all outstanding issues have been
	resolved and a revised document is available. At this point,		resolved and a revised document is available. At this point,
	the Document Shepherd notifies the Responsible Area Director		the Document Shepherd notifies the Responsible Area Director
	and provides him or her with the revised document, the summary		and provides him or her with the revised document, the summary
	of issues and the resulting text changes.		of issues and the resulting text changes.
	(2.h) The Responsible Area Director verifies that the issues he or		(2.h) The Responsible Area Director verifies that the issues he or
	she found during AD Evaluation are resolved in the revised		she found during AD Evaluation are resolved in the revised
	version of the document by starting the process described in		version of the document by starting the process described in
	this section at step (2.a).		this section at step (2.a).
			(2.i) If the document underwent an IETF Last Call and the AD
			concludes that significant issues were raised during the Last
			Call, then steps (2.b) through (2.h) need to be applied
			addressing the Last Call issues. This requires the
			Responsible Area Director to present to the Document Shepherd
			those Last Call Issues raised only to the IESG.
	3.3. Document Shepherding during IESG Evaluation		3.3. Document Shepherding during IESG Evaluation
	During IESG Evaluation of a document, ADs can bring forward two kinds		During IESG Evaluation of a document, ADs can bring forward two kinds
	of remarks about a document: DISCUSS item and COMMENT items. A		of remarks about a document: DISCUSS item and COMMENT items. A
	DISCUSS blocks a document's approval process until it has been		DISCUSS blocks a document's approval process until it has been
	resolved; a COMMENT does not. This section details the steps that a		resolved; a COMMENT does not. This section details the steps that a
	Document Shepherd takes to resolve any DISCUSS and COMMENT items		Document Shepherd takes to resolve any DISCUSS and COMMENT items
	brought forward against a shepherded document during IESG Evaluation.		brought forward against a shepherded document during IESG Evaluation.
	Note that DISCUSS and COMMENT items are occasionally written in a		Note that DISCUSS and COMMENT items are occasionally written in a
	skipping to change at page 13, line 19		skipping to change at page 13, line 23
	| | Further AD/Document Shepherd		| | Further AD/Document Shepherd
	| | discussion required		| | discussion required
	+--------------------------+		+--------------------------+
	(3.e) The Document Shepherd then communicates the DISCUSS and		(3.e) The Document Shepherd then communicates the DISCUSS and
	COMMENT items to the document editors and the working group,		COMMENT items to the document editors and the working group,
	alerting them of any changes to the document that have		alerting them of any changes to the document that have
	accumulated during IESG processing, such as "Notes to the RFC		accumulated during IESG processing, such as "Notes to the RFC
	Editor." If any changes will be substantive, the Document		Editor." If any changes will be substantive, the Document
	Shepherd, in consultation with the Responsible Area Director,		Shepherd, in consultation with the Responsible Area Director,
	as during other stages, MUST seek working group consensus.		as during other stages, MUST confirm working group consensus
			or sometimes even IETF consensus.
	(3.f) After the editors resolve the DISCUSS and COMMENT items, the		(3.f) After the editors resolve the DISCUSS and COMMENT items, the
	Document Shepherd reviews the resulting new version of the		Document Shepherd reviews the resulting new version of the
	document, which will be a revised document, a set of "Notes to		document, which will be a revised document, a set of "Notes to
	the RFC Editor", or both, using his or her technical expertise		the RFC Editor", or both, using his or her technical expertise
	to ensure that all raised DISCUSS and COMMENT issues have been		to ensure that all raised DISCUSS and COMMENT issues have been
	resolved.		resolved.
	Note that the Document Shepherd MAY also suggest resolutions		Note that the Document Shepherd MAY also suggest resolutions
	to DISCUSS and COMMENT items, enter them into an issue		to DISCUSS and COMMENT items, enter them into an issue
	skipping to change at page 14, line 35		skipping to change at page 14, line 40
	If he or she deems the changes to the revised document		If he or she deems the changes to the revised document
	significant, there may be a new WG last call, or possibly a		significant, there may be a new WG last call, or possibly a
	new IETF last call. The document goes through a new full IESG		new IETF last call. The document goes through a new full IESG
	Evaluation process if there is a new IETF last call.		Evaluation process if there is a new IETF last call.
	4. Shepherding the Document's IANA Actions		4. Shepherding the Document's IANA Actions
	IETF working group documents often include considerations requiring		IETF working group documents often include considerations requiring
	actions by the IANA, such as creating a new registry or adding		actions by the IANA, such as creating a new registry or adding
	information to an existing registry, perhaps after consulting an		information to an existing registry, perhaps after consulting an
	IESG-appointed Expert. Sometimes the actions required are by the		IESG-appointed Expert. Sometimes, the IESG requires actions, such as
	IESG, such as appointment of a new Expert. IANA-related processing		appointment of a new Expert. IANA-related processing may also
	may also include a specified type of Expert review, such as review of		include a specified type of Expert review, such as review of proposed
	proposed MIME media types on the designated ietf-types mailing list.		MIME media types on the designated ietf-types mailing list.
	The IANA reviews IETF documents and requests responses at any or all		The IANA reviews IETF documents and requests responses at any or all
	of the following times: in response to IETF Last Call, during the		of the following times: in response to IETF Last Call, during the
	IESG Evaluation review of the document, and at the time when the IANA		IESG Evaluation review of the document, and at the time when the IANA
	performs actions in its web-based registry for the document, usually		performs actions in its web-based registry for the document, usually
	but not always after IESG approval of the document. More details of		but not always after IESG approval of the document. More details of
	the IANA process and IETF interaction are found in		the IANA process and IETF interaction are found in [RFC2434].
	[I-D.narten-iana-considerations-rfc2434bis].
	Whenever an IANA request comes, in whatever period, the requester		At the time of this publication, RFC2434 is under revision
	from IANA MUST ensure that the Document Shepherd and the Responsible		[I-D.narten-iana-considerations-rfc2434bis] and the updates are and
	Area Director both receive the request. The Document Shepherd is		will be of value to the Document Shepherd. Note that Document
	responsible for responding as rapidly as possible. He or she should		Shepherd MUST determine (by individual review and consultation with
	discuss requests that introduce any possible concerns with the		others) what is the most recent and the most applicable IANA
	Working Group. The Document Shepherd and the Responsible Area		information and guidance for his or her document, be it the overall
	Director may decide in consultation that an IANA request leads to a		guidance, or external documents in his or her area, or in other
	change that needs additional review or approval.		areas. An example of an external document is [RFC4020].
	In general, the Working Group Shepherd ensures that the IANA process		Whenever an IANA request comes, during whatever phase of the
			shepherding process, the requester from IANA MUST ensure that the
			Document Shepherd and the Responsible Area Director both receive the
			request. The Document Shepherd is responsible for responding as
			rapidly as possible. He or she should discuss requests that
			introduce any possible concerns with the working group. The Document
			Shepherd and the Responsible Area Director may decide in consultation
			that an IANA request leads to a change that needs additional review
			or approval.
			In general, the Document Shepherd ensures that the IANA process
	completes, checks that the registry is correct and that the IANA		completes, checks that the registry is correct and that the IANA
	Matrix (www.iana.org/numbers.html) is complete and consistent, and		Matrix (http://www.iana.org/numbers.html) is complete and consistent,
	troubleshoots when all is not well. At the end of IANA processing,		and troubleshoots when all is not well. At the end of IANA
	the Document Shepherd should be sure that the RFC Editor has		processing, the Document Shepherd should be sure that the RFC Editor
	acknowledged IANA conclusion, that the handoff has been made.		has acknowledged IANA conclusion, i.e., that the handoff has been
			made.
	In summary, the task of shepherding the IANA actions is overlooked		In summary, the task of shepherding the IANA actions is often
	but is as important to coordinate and manage as all the other		overlooked, but is as important to coordinate and manage as all the
	document reviews the Document Shepherd has managed. As with those,		other document reviews the Document Shepherd has managed. As with
	the Document Shepherd contributes greatly to quality and timeliness		those, the Document Shepherd contributes greatly to quality and
	of the document by effective and responsive shepherding of the IANA		timeliness of the document by effective and responsive shepherding of
	requests.		the IANA requests.
	5. Document Shepherding after IESG Approval		5. Document Shepherding after IESG Approval
	After the IESG Evaluation and resolution described in Section 3.3,		After the IESG evaluation and resolution described in Section 3.3,
	the IESG approves the document, and the Responsible Area Director		the IESG approves the document, and the Responsible Area Director
	uses the tracker to ask for any final changes to the Document		uses the ID Tracker to ask for any final changes to the Document
	Announcement Write-Up and to ask for it to be issued. The Document		Announcement Write-Up and for it to be issued. The Document Shepherd
	Shepherd may have some edits for the Responsible Area Director, such		may have some edits for the Responsible Area Director, such as minor
	as minor Notes to the RFC Editor, and this is the time to consult and		"Notes to the RFC Editor", and this is the time to consult and
	provide them.		provide them.
	The announcement goes to the general community and to the RFC Editor,		The IESG approval announcement goes to the general community and to
	and now the Document Shepherd (identified in the Announcemen		the RFC Editor, and now the Document Shepherd (identified in the
	Write-Up) continues to shepherd the document through its technical		Announcement Write-Up) continues to shepherd the document through its
	publication. The RFC Editor currently makes a number of types of		technical publication. The RFC Editor currently makes a number of
	requests to the authors, Document Shepherd and Responsible Area		types of requests to the authors, Document Shepherd and Responsible
	Director. The Document Shepherd SHOULD lead in responding to the RFC		Area Director. The Document Shepherd SHOULD lead in responding to
	editor and shepherding the document through its technical		the RFC Editor and shepherd the document during the post-approval
	publication, through the post-approval period. The RFC Editor		period to its publication.
	request types include: editorial queries about dangling, missing,
	informative and normative citations (good shepherding should try to		The RFC Editor request types include: editorial queries about
	pre-catch these, but they happen); requests for unedited source, e.g.		dangling, missing, informative and normative citations (good
	xml; occasional technical comments; and copy-edits for review and		shepherding should try to catch these earlier, but they happen);
	close scrutiny by the authors (AUTH48). On the latter, the Document		requests for the document source (e.g., XML or nroff); occasional
	Shepherd SHOULD lead in checking that copy-edits have in no case		technical comments; and copy-edits for review and close scrutiny by
	affected a consensus wording of the working group which prepared the		the authors (AUTH48). For the latter, the Document Shepherd SHOULD
	document, and in bringing speed to this checking by multiple co-		lead in checking that copy-edits have in no case affected a consensus
	authors. The Document Shepherd also consults with the Responsible		wording of the working group which prepared the document, and SHOULD
	Area Director in reviewing proposed post-approval changes to the		bring speed to this checking by multiple coauthors. The Document
	document by any authors. These may require Area Director approval,		Shepherd also consults with the Responsible Area Director on
	and they often need to be presented to the working group for consent		reviewing proposed post-approval changes to the document by any
	if not a full consensus procedure. As in other periods of document		author. These may require Area Director approval, and they often
	review, the Document Shepherd provides attentiveness and timeliness		need to be presented to the working group for consent if not a full
	by serving as the informed representative of the document and helping		consensus procedure.
	its advancement and its integrity.
			As in other phases of document shepherding, the Document Shepherd
			provides attentiveness and timeliness by serving as the informed
			representative of the document and helping its advancement and its
			integrity.
	6. When Not to Use the Document Shepherding Process		6. When Not to Use the Document Shepherding Process
	As mentioned in Section 3, the Document Shepherd SHOULD NOT be an		As mentioned in Section 3, the Document Shepherd SHOULD NOT be an
	editor of the shepherded document. If this cannot be avoided by		editor of the shepherded document. If this cannot be avoided by
	making another working group chair or secretary the Document		making another working group chair or secretary the Document
	Shepherd, the document shepherding process SHOULD NOT be used. There		Shepherd, the document shepherding process SHOULD NOT be used. There
	are several other cases in which the document shepherding process		are several other cases in which the document shepherding process
	SHOULD NOT be used. These include:		SHOULD NOT be used. These include:
	skipping to change at page 16, line 37		skipping to change at page 17, line 10
	3. Cases, where the working group itself is either very old, losing		3. Cases, where the working group itself is either very old, losing
	energy, or winding down, i.e., cases, where it would not be		energy, or winding down, i.e., cases, where it would not be
	productive to initiate new processes or procedures.		productive to initiate new processes or procedures.
	Finally, note that other cases exist in which using the document		Finally, note that other cases exist in which using the document
	shepherding process may not be productive. The final determination		shepherding process may not be productive. The final determination
	as to whether to use the document shepherding process or not is left		as to whether to use the document shepherding process or not is left
	to the Responsible Area Director. If the document shepherding		to the Responsible Area Director. If the document shepherding
	process is not used, the Responsible Area Director acts as Document		process is not used, the Responsible Area Director acts as Document
	Shepherd, just as he or she did in the past.		Shepherd, per the existing procedures of shepherding by Area
			Directors.
	7. Security Considerations		7. Security Considerations
	This document specifies a change to IETF document-processing		This document specifies a change to IETF document-processing
	procedures. As such, it neither raises nor considers protocol-		procedures. As such, it neither raises nor considers protocol-
	specific security issues.		specific security issues.
	8. IANA Considerations		8. IANA Considerations
	This document creates no new requirements on IANA namespaces or other		This document creates no new requirements on IANA namespaces or other
	IANA requirements.		IANA requirements.
	9. Acknowledgments		9. Acknowledgments
	This document is the product of PROTO team, which includes the		This document is the product of PROTO team, which includes the
	authors as well as Bill Fenner, Barbara Fuller, and Margaret		authors as well as Bill Fenner, Barbara Fuller, and Margaret
	Wasserman. Aaron Falk worked actively in PROTO till the start of		Wasserman. Aaron Falk worked actively in PROTO until the start of
	2006 and worked on earlier versions of the document.		2006 and worked on earlier versions of the document.
	The Document Shepherd Write-Up originated in an idea by John Klensin.		The Document Shepherd Write-Up originated in an idea by John Klensin.
	Thomas Narten and Margaret Wasserman implemented it for the entire		Thomas Narten and Margaret Wasserman implemented it for the entire
	Internet Area, and their template was the basis of the version used		Internet Area, and their template was the basis of the version used
	today.		today.
	Colin Perkins wrote the Document Announcement Write-Up for		Colin Perkins wrote the original Document Announcement Write-Up for
	draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black		draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black
	wrote the Document Announcement Write-Up for		wrote the original Document Announcement Write-Up for
	draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2.		draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. Both
			original announcements have been modified to reflect changes to the
			Document Announcement Write-Up template since they were written.
	Frank Ellermann and Olafur Gudmundsson have suggested improvements to		Frank Ellermann and Olafur Gudmundsson have suggested improvements to
	the document during IETF Last Call.		the document during IETF Last Call.
	10. Informative References		10. Informative References
			[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
			Standards Track Code Points", BCP 100, RFC 4020,
			February 2005.
			[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 2434,
			October 1998.
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, October 1996.		3", BCP 9, RFC 2026, October 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2418] Bradner, S., "IETF Working Group Guidelines and		[RFC2418] Bradner, S., "IETF Working Group Guidelines and
	Procedures", BCP 25, RFC 2418, September 1998.		Procedures", BCP 25, RFC 2418, September 1998.
	[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track		[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track
	skipping to change at page 19, line 4		skipping to change at page 19, line 36
	There is consensus in the WG to publish these documents.		There is consensus in the WG to publish these documents.
	Document Quality		Document Quality
	This RTP Payload format has been implemented during the		This RTP Payload format has been implemented during the
	development of the specification and successfully tested over an		development of the specification and successfully tested over an
	IP network between two remote sites, thus showing that the		IP network between two remote sites, thus showing that the
	technical solution is successfully working. It has been reviewed		technical solution is successfully working. It has been reviewed
	by the MIDI Manufacturers Association and their comments have been		by the MIDI Manufacturers Association and their comments have been
	addressed. Allison Mankin reviewed the document for the IESG,		addressed.
			Personnel
			Magnus Westerlund and Colin Perkins jointly shepherded this
			document. Allison Mankin reviewed the document for the IESG,
	including a careful review with the editor of the media types, in		including a careful review with the editor of the media types, in
	parallel with ietf-types list review requested on 2006-01-08,		parallel with ietf-types list review requested on 2006-01-08,
	which raised no issues.		which raised no issues.
	Magnus Westerlund and Colin Perkins jointly shepherded these
	documents.
	A.2. Example Document Announcement Write-Up for		A.2. Example Document Announcement Write-Up for
	draft-ietf-imss-ip-over-fibre-channel		draft-ietf-imss-ip-over-fibre-channel
	Technical Summary		Technical Summary
	This document specifies the encapsulation of IPv6, IPv4 and ARP		This document specifies the encapsulation of IPv6, IPv4 and ARP
	packets over Fibre Channel. This document also specifies the		packets over Fibre Channel. This document also specifies the
	methods for forming IPv6 link-local addresses and statelessly		methods for forming IPv6 link-local addresses and statelessly
	autoconfigured IPv6 addresses on Fibre Channel networks, and a		autoconfigured IPv6 addresses on Fibre Channel networks, and a
	mechanism to perform IPv4 address resolution over Fibre Channel		mechanism to perform IPv4 address resolution over Fibre Channel
	networks. This document (when published as RFC) obsoletes RFC2625		networks. This document (when published as RFC) obsoletes RFC2625
	and RFC3831.		and RFC3831.
	skipping to change at page 19, line 40		skipping to change at page 20, line 29
	this document both in the WG and from T11.		this document both in the WG and from T11.
	Document Quality		Document Quality
	This document replaces and consolidates two separate RFCs on IPv4		This document replaces and consolidates two separate RFCs on IPv4
	over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC		over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC
	3831). Most of its technical content is unchanged from those		3831). Most of its technical content is unchanged from those
	RFCs. The technical changes that have been made are primarily		RFCs. The technical changes that have been made are primarily
	based on implementation experience.		based on implementation experience.
	The protocol has been reviewed for the IESG by David L. Black (WG		Personnel
	chair).
	Also Bert Wijnen has reviewed this document for the IESG.
	In addition, Brian Haberman has done a review for the INT Area as		The protocol has been reviewed for the IESG by David L. Black (WG
			chair). Bert Wijnen has reviewed this document for the IESG. In
			addition, Brian Haberman has done a review for the INT Area as
	requested by WG-chair (David Black) via Margaret Wasserman.		requested by WG-chair (David Black) via Margaret Wasserman.
	Appendix B. Working Documents
	(This section should be removed by the RFC editor before
	publication.)
	The current working documents for this document are available at this
	web site:
	http://tools.ietf.org/wg/proto/
	draft-ietf-proto-wgchair-doc-shepherding/
	Authors' Addresses		Authors' Addresses
	Henrik Levkowetz		Henrik Levkowetz
	Torsgatan 71		Torsgatan 71
	Stockholm S-113 37		Stockholm S-113 37
	Sweden		Sweden
	Phone: +46 708 32 16 08		Phone: +46 708 32 16 08
	Email: henrik@levkowetz.com		Email: henrik@levkowetz.com
	David Meyer		David Meyer
	1225 Kincaid St		1225 Kincaid St
	Eugene, OR 97403		Eugene, OR 97403
	USA		USA
	Phone: +1 541 346 1747		Phone: +1 541 346 1747
	Email: dmm@1-4-5.net		Email: dmm@1-4-5.net
	Lars Eggert		Lars Eggert
	NEC Network Laboratories		Nokia Research Center
	Kurfuerstenanlage 36		P.O. Box 407
	Heidelberg 69115		Nokia Group 00045
	Germany		Finland
			Phone: +49 50 48 24461
			Email: lars.eggert@nokia.com
			URI: http://research.nokia.com/people/lars_eggert
	Phone: +49 6221 4342 143
	Fax: +49 6221 4342 155
	Email: lars.eggert@netlab.nec.de
	URI: http://www.netlab.nec.de/
	Allison Mankin		Allison Mankin
	Phone: +1-301-728-7199		Phone: +1-301-728-7199
	Email: mankin@psg.com		Email: mankin@psg.com
	URI: http://www.psg.com/~mankin		URI: http://www.psg.com/~mankin
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	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
End of changes. 49 change blocks.
	134 lines changed or deleted		155 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/