rfc4858.txt		draft-ietf-proto-rfc4858bis.txt
	Network Working Group H. Levkowetz		PROTO Team H. Levkowetz
	Request for Comments: 4858 Ericsson		Internet-Draft Ericsson
	Category: Informational D. Meyer		Obsoletes: 4858 (if approved) D. Meyer
	Cisco/University of Oregon		Intended status: Informational Cisco/University of Oregon
	L. Eggert		Expires: January 14, 2008 L. Eggert
	Nokia		Nokia
	A. Mankin		A. Mankin
			July 13, 2007
	Document Shepherding from Working Group Last Call to Publication		Document Shepherding from Working Group Last Call to Publication
			draft-ietf-proto-rfc4858bis-00
	Status of This Memo		Status of this Memo
	This memo provides information for the Internet community. It does		By submitting this Internet-Draft, each author represents that any
	not specify an Internet standard of any kind. Distribution of this		applicable patent or other IPR claims of which he or she is aware
	memo is unlimited.		have been or will be disclosed, and any of which he or she becomes
			aware will be disclosed, in accordance with Section 6 of BCP 79.
			Internet-Drafts are working documents of the Internet Engineering
			Task Force (IETF), its areas, and its working groups. Note that
			other groups may also distribute working documents as Internet-
			Drafts.
			Internet-Drafts are draft documents valid for a maximum of six months
			and may be updated, replaced, or obsoleted by other documents at any
			time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
			The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt.
			The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
			This Internet-Draft will expire on January 14, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		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
	skipping to change at page 2, line 11		skipping to change at page 2, line 14
	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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Process Description . . . . . . . . . . . . . . . . . . . . . 4		3. Process Description . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 5		3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 5
	3.2. Document Shepherding during AD Evaluation . . . . . . . . 9		3.2. Document Shepherding during AD Evaluation . . . . . . . . 6
	3.3. Document Shepherding during IESG Evaluation . . . . . . . 10		3.3. Document Shepherding during IESG Evaluation . . . . . . . 8
	4. Shepherding the Document's IANA Actions . . . . . . . . . . . 13		4. Shepherding the Document's IANA Actions . . . . . . . . . . . 11
	5. Document Shepherding after IESG Approval . . . . . . . . . . . 14		5. Document Shepherding after IESG Approval . . . . . . . . . . . 12
	6. When Not to Use the Document Shepherding Process . . . . . . . 15		6. When Not to Use the Document Shepherding Process . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Appendix A. Example Document Announcement Write-Ups . . . . . . . 18		Appendix A. Example Document Announcement Write-Ups . . . . . . . 15
	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 . . . . . . . . . . . . . . 15
	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 . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
			Intellectual Property and Copyright Statements . . . . . . . . . . 19
	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
	skipping to change at page 5, line 29		skipping to change at page 5, line 30
	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.j) below to give the Responsible Area		answers a number of questions to give the Responsible Area Director
	Director insight into the working group process that applied to this		insight into the working group process that applied to this document.
	document. Note that while these questions may appear redundant in		Note that while these questions may appear redundant in some cases,
	some cases, they are written to elicit information that the		they are written to elicit information that the Responsible Area
	Responsible Area Director must be aware of (to this end, pointers to		Director must be aware of (to this end, pointers to relevant entries
	relevant entries in the WG archive are helpful). The goal here is to		in the WG archive are helpful). The goal here is to inform the
	inform the Responsible Area Director about any issues that may have		Responsible Area Director about any issues that may have come up in
	come up in IETF meetings, on the mailing list, or in private		IETF meetings, on the mailing list, or in private communication that
	communication that they should be aware of prior to IESG Evaluation		they should be aware of prior to IESG Evaluation of the shepherded
	of the shepherded document. Any significant issues mentioned in the		document. Any significant issues mentioned in the questionnaire will
	questionnaire will probably lead to a follow-up discussion with the		probably lead to a follow-up discussion with the Responsible Area
	Responsible Area Director.		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 both to the ballot for the IESG telechat and		Write-Up" that is input both to the ballot for the IESG telechat and
	to the eventual IETF-wide announcement message. Item number (1.k)		to the eventual IETF-wide announcement message.
	describes the elements of the Document Announcement Write-Up.
	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		The template for the Document Shepherd Write-Up is not included in
	below, but changes are expected over time. The latest version of		this document, because it is frequently modified to improve its
	this template is available from the IESG section of the IETF web		usefulness and clarity. The current version of this template is
	site.		available as an Internet Operational Note (ION) [RFC4693] named ion-
			doc-shepherd-writeup-wg-template.txt from the IESG section of the
	(1.a) Who is the Document Shepherd for this document? Has the		IETF web site [ION-TEMPLATE]. Document Shepherds SHOULD make sure
	Document Shepherd personally reviewed this version of the		their Write-Up follows the latest available template.
	document and, in particular, does he or she believe this
	version is ready for forwarding to the IESG for publication?
	(1.b) Has the document had adequate review both from key WG members
	and from key non-WG members? Does the Document Shepherd have
	any concerns about the depth or breadth of the reviews that
	have been performed?
	(1.c) Does the Document Shepherd have concerns that the document
	needs more review from a particular or broader perspective,
	e.g., security, operational complexity, someone familiar with
	AAA, internationalization, or XML?
	(1.d) Does the Document Shepherd have any specific concerns or
	issues with this document that the Responsible Area Director
	and/or the IESG should be aware of? For example, perhaps he
	or she is uncomfortable with certain parts of the document, or
	has concerns whether there really is a need for it. In any
	event, if the WG has discussed those issues and has indicated
	that it still wishes to advance the document, detail those
	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
	represent the strong concurrence of a few individuals, with
	others being silent, or does the WG as a whole understand and
	agree with it?
	(1.f) Has anyone threatened an appeal or otherwise indicated extreme
	discontent? If so, please summarize the areas of conflict in
	separate email messages to the Responsible Area Director. (It
	should be in a separate email because this questionnaire is
	entered into the ID Tracker.)
	(1.g) Has the Document Shepherd personally verified that the
	document satisfies all ID nits? (See
	http://www.ietf.org/ID-Checklist.html and
	http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
	not enough; this check needs to be thorough. Has the document
	met all formal review criteria it needs to, such as the MIB
	Doctor, media type, and URI type reviews? If the document
	does not already indicate its intended status at the top of
	the first page, please indicate the intended status here.
	(1.h) Has the document split its references into normative and
	informative? Are there normative references to documents that
	are not ready for advancement or are otherwise in an unclear
	state? If such normative references exist, what is the
	strategy for their completion? Are there normative references
	that are downward references, as described in [RFC3967]? If
	so, list these downward references to support the Area
	Director in the Last Call procedure for them [RFC3967].
	(1.i) Has the Document Shepherd verified that the document's IANA
	Considerations section exists and is consistent with the body
	of the document? If the document specifies protocol
	extensions, are reservations requested in appropriate IANA
	registries? Are the IANA registries clearly identified? If
	the document creates a new registry, does it define the
	proposed initial contents of the registry and an allocation
	procedure for future registrations? Does it suggest a
	reasonable name for the new registry? See [RFC2434]. If the
	document describes an Expert Review process, has the Document
	Shepherd conferred with the Responsible Area Director so that
	the IESG can appoint the needed Expert during IESG Evaluation?
	(1.j) Has the Document Shepherd verified that sections of the
	document that are written in a formal language, such as XML
	code, BNF rules, MIB definitions, etc., validate correctly in
	an automated checker?
	(1.k) The IESG approval announcement includes a Document
	Announcement Write-Up. Please provide such a Document
	Announcement Write-Up. Recent examples can be found in the
	"Action" announcements for approved documents. The approval
	announcement contains the following sections:
	Technical Summary
	Relevant content can frequently be found in the abstract
	and/or introduction of the document. If not, this may be
	an indication that there are deficiencies in the abstract
	or introduction.
	Working Group Summary
	Was there anything in the WG process that is worth noting?
	For example, was there controversy about particular points
	or were there decisions where the consensus was
	particularly rough?
	Document Quality
	Are there existing implementations of the protocol? Have a
	significant number of vendors indicated their plan to
	implement the specification? Are there any reviewers that
	merit special mention as having done a thorough review,
	e.g., one that resulted in important changes or a
	conclusion that the document had no substantive issues? If
	there was a MIB Doctor, Media Type, or other Expert Review,
	what was its course (briefly)? In the case of a Media Type
	Review, on what date was the request posted?
	Personnel
	Who is the Document Shepherd for this document? Who is the
	Responsible Area Director? If the document requires IANA
	experts(s), insert 'The IANA Expert(s) for the registries
	in this document are <TO BE ADDED BY THE AD>.'
	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, may lead to possible appeals, or is		may prove to be sensitive, may lead to possible appeals, or is
	personal needs to be written up, it SHOULD be sent in direct email to		personal information that needs to be written up, it SHOULD be sent
	the Responsible Area Director, because the Document Shepherd Write-Up		in direct email to the Responsible Area Director, because the
	is published openly in the ID Tracker. Question (1.f) of the		Document Shepherd Write-Up is published openly in the ID Tracker.
	Write-Up covers any material of this nature and specifies this 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
	skipping to change at page 13, line 44		skipping to change at page 11, line 36
	media types on the designated ietf-types mailing list.		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 [RFC2434].		the IANA process and IETF interaction are found in [RFC2434].
	At the time of this publication, RFC 2434 is under revision		At the time of this publication, RFC 2434 is under revision
	[RFC2434bis], and the updates are and will be of value to the		[I-D.narten-iana-considerations-rfc2434bis] and the updates are and
	Document Shepherd. Note that the Document Shepherd MUST determine		will be of value to the Document Shepherd. Note that the Document
	(by individual review and consultation with others) what is the most		Shepherd MUST determine (by individual review and consultation with
	recent and the most applicable IANA information and guidance for his		others) what is the most recent and the most applicable IANA
	or her document, be it the overall guidance, or external documents in		information and guidance for his or her document, be it the overall
	his or her area, or in other areas. An example of an external		guidance, or external documents in his or her area, or in other
	document is [RFC4020].		areas. An example of an external document is [RFC4020].
	Whenever an IANA request comes, during whatever phase of the		Whenever an IANA request comes, during whatever phase of the
	shepherding process, the requester from IANA MUST ensure that the		shepherding process, the requester from IANA MUST ensure that the
	Document Shepherd and the Responsible Area Director both receive the		Document Shepherd and the Responsible Area Director both receive the
	request. The Document Shepherd is responsible for responding as		request. The Document Shepherd is responsible for responding as
	rapidly as possible. He or she should discuss requests that		rapidly as possible. He or she should discuss requests that
	introduce any possible concerns with the working group. The Document		introduce any possible concerns with the working group. The Document
	Shepherd and the Responsible Area Director may decide in consultation		Shepherd and the Responsible Area Director may decide in consultation
	that an IANA request leads to a change that needs additional review		that an IANA request leads to a change that needs additional review
	or approval.		or approval.
	skipping to change at page 17, line 14		skipping to change at page 14, line 41
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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.
	10.2. Informative References		10.2. Informative References
			[RFC4693] Alvestrand, H., "IETF Operational Notes", RFC 4693,
			October 2006.
	[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of		[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
	Standards Track Code Points", BCP 100, RFC 4020,		Standards Track Code Points", BCP 100, RFC 4020,
	February 2005.		February 2005.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing		[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	an IANA Considerations Section in RFCs", BCP 26,		IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	RFC 2434, October 1998.		October 1998.
	[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards
	Track Documents may Refer Normatively to Documents at a
	Lower Level", BCP 97, RFC 3967, December 2004.
	[RFC2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing		[I-D.narten-iana-considerations-rfc2434bis]
	an IANA Considerations Section in RFCs", Work in		Narten, T. and H. Alvestrand, "Guidelines for Writing an
	Progress, March 2007.		IANA Considerations Section in RFCs",
			draft-narten-iana-considerations-rfc2434bis-06 (work in
			progress), March 2007.
	[IDTRACKER] "The IETF Internet-Draft Tracker", Web		[IDTRACKER]
			"The IETF Internet-Draft Tracker", Web
	Application: https://datatracker.ietf.org/, 2002.		Application: https://datatracker.ietf.org/, 2002.
			[ION-TEMPLATE]
			"Document Shepherd Write-Up Template for Working Group
			Documents", Internet Operational Note (ION) ion-doc-
			shepherd-writeup-wg-template.txt, Web Page: http://
			www.ietf.org/IESG/content/ions/
			ion-doc-shepherd-writeup-wg-template.txt.
	[PROTO] "The IESG PROcess and TOols (PROTO) Team", Web		[PROTO] "The IESG PROcess and TOols (PROTO) Team", Web
	Page: http://psg.com/~mrw/PROTO-Team, 2004.		Page: http://tools.ietf.org/group/proto/home/, 2004.
	[GEN-ART] "The General Area Review Team (GEN-ART)", Web Page:		[GEN-ART] "The General Area Review Team (GEN-ART)", Web Page:
	http://www.alvestrand.no/ietf/gen/		http://www.alvestrand.no/ietf/gen/review-guidelines.html,
	review-guidelines.html, 2005.		2005.
	Appendix A. Example Document Announcement Write-Ups		Appendix A. Example Document Announcement Write-Ups
	This appendix includes two examples of Document Announcement Write-		This appendix includes two examples of Document Announcement Write-
	Ups. Many more examples with Subject lines such as "Protocol Action"		Ups. Many more examples with Subject lines such as "Protocol Action"
	and "Document Action" can be found in the IETF-announce mailing list		and "Document Action" can be found in the IETF-announce mailing list
	archive.		archive.
			Note that these examples follow the structure of the Document
			Announcement Write-Up in the Document Shepherd Write-Up template that
			was current when this document was written. The current version of
			this template is available as an Internet Operational Note (ION)
			[RFC4693] named ion-doc-shepherd-writeup-wg-template.txt from the
			IESG section of the IETF web site [ION-TEMPLATE]. Document Shepherds
			SHOULD make sure their Write-Up follows the latest available
			template.
	A.1. Example Document Announcement Write-Up for		A.1. Example Document Announcement Write-Up for
	draft-ietf-avt-rtp-midi-format		draft-ietf-avt-rtp-midi-format
	Technical Summary		Technical Summary
	These documents define the RTP Payload format for MIDI (Musical		These documents define the RTP Payload format for MIDI (Musical
	Instrument Digital Interface), and additional guidelines on		Instrument Digital Interface), and additional guidelines on
	implementation specifically concerning the timing of reception and		implementation specifically concerning the timing of reception and
	transmission for best performance in different applications. MIDI		transmission for best performance in different applications. MIDI
	is a real-time media, which however is brittle to losses and		is a real-time media, which however is brittle to losses and
	errors. Therefore the RTP payload format defines recovery		errors. Therefore the RTP payload format defines recovery
	journals as a way of avoiding persistent audible errors, and		journals as a way of avoiding persistent audible errors, and
	discusses congestion control handling for these journals.		discusses congestion control handling for these journals.
	skipping to change at page 20, line 13		skipping to change at page 17, line 36
	requested by WG-chair (David Black) via Margaret Wasserman.		requested by WG-chair (David Black) via Margaret Wasserman.
	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
	Nokia Research Center		Nokia Research Center
	P.O. Box 407		P.O. Box 407
	Nokia Group 00045		Nokia Group 00045
	Finland		Finland
	Phone: +49 50 48 24461		Phone: +49 50 48 24461
	EMail: lars.eggert@nokia.com		Email: lars.eggert@nokia.com
	URI: http://research.nokia.com/people/lars_eggert		URI: http://research.nokia.com/people/lars_eggert/
	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 IETF Trust (2007).		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.
	skipping to change at page 21, line 45		skipping to change at page 19, line 45
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgement		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 28 change blocks.
	185 lines changed or deleted		115 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/