draft-ietf-mmusic-media-loopback-09.txt		draft-ietf-mmusic-media-loopback-10.txt
	Internet Draft K. Hedayat		Internet Draft K. Hedayat
	Expires: January 28, 2009 Brix Networks		Expires: August 18, 2009 Brix Networks
	N. Venna		N. Venna
	Brix Networks		Brix Networks
	P. Jones		P. Jones
	Cisco Systems, Inc.		Cisco Systems, Inc.
	A. Roychowdhury		A. Roychowdhury
	Hughes Systique Corp.		Hughes Systique Corp.
	C. SivaChelvan		C. SivaChelvan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	N. Stratton		N. Stratton
	BlinkMind, Inc.		BlinkMind, Inc.
	July 28, 2008		February 18, 2009
	An Extension to the Session Description Protocol (SDP) for Media		An Extension to the Session Description Protocol (SDP) for Media
	Loopback		Loopback
	draft-ietf-mmusic-media-loopback-09		draft-ietf-mmusic-media-loopback-10
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with
	applicable patent or other IPR claims of which he or she is aware		the provisions of BCP 78 and BCP 79.
	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		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
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		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 August 18, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document.
	Abstract		Abstract
	The wide deployment of Voice over IP (VoIP), Real-time Text and		The wide deployment of Voice over IP (VoIP), Real-time Text and
	Video over IP services has introduced new challenges in managing		Video over IP services has introduced new challenges in managing
	and maintaining voice/real-time Text/video quality, reliability,		and maintaining voice/real-time Text/video quality, reliability,
	and overall performance. In particular, media delivery is an area		and overall performance. In particular, media delivery is an area
	that needs attention. One method of meeting these challenges is		that needs attention. One method of meeting these challenges is
	monitoring the media delivery performance by looping media back to		monitoring the media delivery performance by looping media back to
	the transmitter. This is typically referred to as "active		the transmitter. This is typically referred to as "active
	skipping to change at page 2, line 34		skipping to change at page 2, line 45
	serve as monitoring and troubleshooting tools by providing the		serve as monitoring and troubleshooting tools by providing the
	means for measurement of more advanced VoIP, Real-time Text and		means for measurement of more advanced VoIP, Real-time Text and
	Video Over IP performance metrics.		Video Over IP performance metrics.
	Table of Contents		Table of Contents
	1. Introduction..................................................3		1. Introduction..................................................3
	2. Terminology...................................................4		2. Terminology...................................................4
	3. Offering Entity Behavior......................................4		3. Offering Entity Behavior......................................4
	4. Answering Entity Behavior.....................................4		4. Answering Entity Behavior.....................................4
	5. SDP Constructs Syntax.........................................4		5. SDP Constructs Syntax ......................................... 5
	5.1 Loopback Type Attribute...................................4		5.1 Loopback Type Attribute ................................... 5
	5.2 Loopback Mode Attribute...................................6		5.2 Loopback Mode Attribute...................................6
	5.3 Generating the Offer for Loopback Session.................7		5.3 Generating the Offer for Loopback Session.................7
	5.4 Generating the Answer for Loopback Session................8		5.4 Generating the Answer for Loopback Session
	5.5 Offerer Processing of the Answer..........................9		5.5 Offerer Processing of the Answer ......................... 10
	5.6 Modifying the Session....................................10		5.6 Modifying the Session....................................10
	6. RTP Requirements.............................................10		6. RTP Requirements.............................................10
	7. Payload formats for Packet loopback..........................10		7. Payload formats for Packet loopback .......................... 11
	7.1 Encapsulated Payload format..............................11		7.1 Encapsulated Payload format..............................11
	7.2 Direct loopback RTP payload format.......................13		7.2 Direct loopback RTP payload format.......................13
	8. RTCP Requirements............................................14		8. RTCP Requirements ............................................ 15
	9. Congestion Control...........................................15		9. Congestion Control...........................................15
	10. Examples....................................................15		10. Examples....................................................15
	10.1 Offer for specific media loopback type..................15		10.1 Offer for specific media loopback type..................15
	10.2 Offer for choice of media loopback type.................16		10.2 Offer for choice of media loopback type.................16
	10.3 Offer for choice of media loopback type with		10.3 Offer for choice of media loopback type with
	rtp-start-loopback...........................................17		rtp-start-loopback...........................................17
	10.4 Response to INVITE request rejecting loopback media.....18		10.4 Response to INVITE request rejecting loopback media.....18
	10.5 Response to INVITE request rejecting loopback media with		10.5 Response to INVITE request rejecting loopback media with
	rtp-start-loopback...........................................18		rtp-start-loopback ........................................... 19
	11. Security Considerations.....................................19		11. Security Considerations ..................................... 20
	12. Implementation Considerations...............................20		12. Implementation Considerations...............................20
	13. IANA Considerations.........................................20		13. IANA Considerations.........................................20
	13.1 SDP Attributes..........................................20		13.1 SDP Attributes..........................................20
	13.2 MIME Types..............................................21		13.2 MIME Types..............................................21
	14. Acknowledgements............................................30		14. Acknowledgements............................................30
	15. Normative References........................................30		15. Normative References........................................30
	1. Introduction		1. Introduction
	The overall quality, reliability, and performance of VoIP,		The overall quality, reliability, and performance of VoIP,
	Real-time Text and Video over IP services rely on the performance		Real-time Text and Video over IP services rely on the performance
	and quality of the media path. In order to assure the quality of		and quality of the media path. In order to assure the quality of
	the delivered media there is a need to monitor the performance of		the delivered media there is a need to monitor the performance of
	the media transport. One method of monitoring and managing the		the media transport. One method of monitoring and managing the
	overall quality of VoIP, Real-time Text and Video over IP Services		overall quality of VoIP, Real-time Text and Video over IP Services
	is through monitoring the quality of the media in an active		is through monitoring the quality of the media in an active
	session. This type of "active monitoring" of services is a method		session. This type of "active monitoring" of services is a method
	of pro-actively managing the performance and quality of VoIP based
	services.		services.
	The goal of active monitoring is to measure the media quality of a		The goal of active monitoring is to measure the media quality of a
	VoIP, Real-time Text or Video over IP session. A way to achieve		VoIP, Real-time Text or Video over IP session. A way to achieve
	this goal is to request an endpoint to loop media back to the other		this goal is to request an endpoint to loop media back to the other
	endpoint and to provide media statistics (e.g., RTCP and RTCP XR		endpoint and to provide media statistics (e.g., RTCP and RTCP XR
	information). Another method involves deployment of special		information). Another method involves deployment of special
	endpoints that always loop incoming media back for sessions.		endpoints that always loop incoming media back for sessions.
	Although the latter method has been used and is functional, it does		Although the latter method has been used and is functional, it does
	not scale to support large networks and introduces new network		not scale to support large networks and introduces new network
	skipping to change at page 5, line 7		skipping to change at page 5, line 17
	Two new media attributes are defined: one indicates the type of		Two new media attributes are defined: one indicates the type of
	loopback and one indicates the mode of the loopback.		loopback and one indicates the mode of the loopback.
	5.1 Loopback Type Attribute		5.1 Loopback Type Attribute
	The loopback type is a property media attribute with the following		The loopback type is a property media attribute with the following
	syntax:		syntax:
	a=loopback:<loopback-type>		a=loopback:<loopback-type>
	Following is the Augmented BNF [RFC4234] for loopback-type:		Following is the Augmented BNF [RFC5234] for loopback-type:
	loopback-type = loopback-type-choices | loopback-type-choice-3		loopback-type = loopback-type-choices | loopback-type-choice-3
	loopback-choices = loopback-type-choice-1 | loopback-type-choice-2		loopback-choices = loopback-type-choice-1 | loopback-type-choice-2
	| loopback-type-choice-1 1*space loopback-type-choice-2 |		| loopback-type-choice-1 1*space loopback-type-choice-2 |
	loopback-type-choice-2 1*space loopback-type-choice-1		loopback-type-choice-2 1*space loopback-type-choice-1
	loopback-type-choice-1 = "rtp-pkt-loopback"		loopback-type-choice-1 = "rtp-pkt-loopback"
	loopback-type-choice-2 = "rtp-media-loopback"		loopback-type-choice-2 = "rtp-media-loopback"
	loopback-type-choice-3 = "rtp-start-loopback"		loopback-type-choice-3 = "rtp-start-loopback"
	The loopback type is used to indicate the type of loopback. The		The loopback type is used to indicate the type of loopback. The
	skipping to change at page 5, line 50		skipping to change at page 6, line 15
	Loopback-source and loopback-mirror are loopback modes defined in		Loopback-source and loopback-mirror are loopback modes defined in
	section 5.2. One example of this scenario is the presence of an		section 5.2. One example of this scenario is the presence of an
	RTP relay in the path of the media. RTP relays exist in VoIP		RTP relay in the path of the media. RTP relays exist in VoIP
	networks for purpose of NAT and Firewall traversal. If an RTP		networks for purpose of NAT and Firewall traversal. If an RTP
	relay is present, the loopback-source's packets are dropped by the		relay is present, the loopback-source's packets are dropped by the
	RTP relay until the loopback-mirror has started transmitting media		RTP relay until the loopback-mirror has started transmitting media
	and the media state within the RTP relay is established. This		and the media state within the RTP relay is established. This
	loopback attribute is used to specify the media type for		loopback attribute is used to specify the media type for
	transmitting media packets by the loopback-mirror prior to the		transmitting media packets by the loopback-mirror prior to the
	loopback process for the purpose of setting media state within the		loopback process for the purpose of setting media state within the
	network. In the presence of this loopback attribute the loopback-		network. In the presence of this loopback attribute the
	mirror will transmit media, according to the description that		loopback-mirror will transmit media, according to the description
	contains this attribute, until it receives media from the loopback-		that contains this attribute, until it receives media from the
	source. The loopback-mirror MAY include this attribute in the		loopback-source. The loopback-mirror MAY include this attribute in
	answer if it is not present in the offer. This may be necessary if		the answer if it is not present in the offer. This may be
	the loopback-mirror is aware of NAT's, firewalls, or RTP relays on		necessary if the loopback-mirror is aware of NAT's, firewalls, or
	the path of the call. In this case the loopback-source MUST accept		RTP relays on the path of the call. In this case the loopback-
	media according to rtp-start-loopback attribute. After the first		source MUST accept media according to rtp-start-loopback attribute.
	media packet is received from the loopback-source, the loopback-		After the first media packet is received from the loopback-source,
	mirror MUST terminate the transmission of rtp-start-loopback media		the loopback-mirror MUST terminate the transmission of
	and MUST start looping back media as defined by the other loopback		rtp-start-loopback media and MUST start looping back media as
	attributes present in the offer. If an offer includes the		defined by the other loopback attributes present in the offer. If
	rtp-start-loopback attribute it MUST also include at least one		an offer includes the rtp-start-loopback attribute it MUST also
	other attribute as defined in this section. The loopback-source is		include at least one other attribute as defined in this section.
	able to filter rtp-start-loopback packets from other types of		The loopback-source is able to filter rtp-start-loopback packets
	loopback with the payload type of the packet. The media port number		from other types of loopback with the payload type of the packet.
	for rtp-start-loopback MUST be the same as the corresponding		The media port number for rtp-start-loopback MUST be the same as
	loopback attribute that will take over after the reception of first		the corresponding loopback attribute that will take over after the
	media packet from the offering entity.		reception of first media packet from the offering entity.
	It is recommended that an offering entity specifying media with		It is recommended that an offering entity specifying media with
	either rtp-pkt-loopback or rtp-media-loopback attribute also		either rtp-pkt-loopback or rtp-media-loopback attribute also
	specify the rtp-start-loopback attribute unless the offering entity		specify the rtp-start-loopback attribute unless the offering entity
	is certain that its media will not be blocked by a network entity		is certain that its media will not be blocked by a network entity
	as explained above.		as explained above.
	5.2 Loopback Mode Attribute		5.2 Loopback Mode Attribute
	The loopback mode is a value media attribute that is used to		The loopback mode is a value media attribute that is used to
	skipping to change at page 6, line 45		skipping to change at page 7, line 12
	The loopback-mode values are loopback-source and loopback-mirror.		The loopback-mode values are loopback-source and loopback-mirror.
	loopback-source: This attribute specifies that the sender is the		loopback-source: This attribute specifies that the sender is the
	media source and expects the receiver to act as a loopback-mirror.		media source and expects the receiver to act as a loopback-mirror.
	loopback-mirror: This attribute specifies that the receiver will		loopback-mirror: This attribute specifies that the receiver will
	mirror (echo) all received media back to the sender of the RTP		mirror (echo) all received media back to the sender of the RTP
	stream. No media is generated locally by the receiver for		stream. No media is generated locally by the receiver for
	transmission in the mirrored stream unless rtp-start-loopback is		transmission in the mirrored stream unless rtp-start-loopback is
	requested.		requested by the loopback-source or included in the response by
			loopback-mirror.
	<fmt> is a media format description. The format descrption has the		<fmt> is a media format description. The format descrption has the
	semantics as defined in section 5.14 of RFC 4566[RFC4566]. When		semantics as defined in section 5.14 of RFC 4566[RFC4566]. When
	loopback-mode is specified as loopback-source, the media format		loopback-mode is specified as loopback-source, the media format
	corresponds to the RTP payload types the source is willing to send.		corresponds to the RTP payload types the source is willing to send.
	When loopback-mode is specified as loopback-mirror, the media		When loopback-mode is specified as loopback-mirror, the media
	format corresponds to the RTP payload types the mirror is willing		format corresponds to the RTP payload types the mirror is willing
	to receive. The payload types specified in m= line for a		to receive. The payload types specified in m= line for a
	loopback-source specify the payloads the source is willing to		loopback-source specify the payloads the source is willing to
	receive. Similarly, for the loopback-mirror these payload types		receive. Similarly, for the loopback-mirror these payload types
	specify the payloads it is willing to send.		specify the payloads it is willing to send.
	The loopback mode attribute does not apply to rtp-start-loopback		The loopback mode attribute does not apply to rtp-start-loopback
	attribute and MUST be ignored if received by the answering entity.		attribute and MUST be ignored if received by the answering entity.
	skipping to change at page 8, line 12		skipping to change at page 8, line 26
	Example: m=audio 41352 RTP/AVP 112		Example: m=audio 41352 RTP/AVP 112
	a=loopback:rtp-pkt-loopback		a=loopback:rtp-pkt-loopback
	a=loopback-source:0 8		a=loopback-source:0 8
	a=rtpmap:112 encaprtp/8000		a=rtpmap:112 encaprtp/8000
	Example: m=audio 41352 RTP/AVP 112		Example: m=audio 41352 RTP/AVP 112
	a=loopback:rtp-pkt-loopback		a=loopback:rtp-pkt-loopback
	a=loopback-source:0 8		a=loopback-source:0 8
	a=rtpmap:112 rtploopback/8000		a=rtpmap:112 rtploopback/8000
	Note: NAT devices may change the actual port number that is used
	for transmission and the expected receive port.
	5.4 Generating the Answer for Loopback Session		5.4 Generating the Answer for Loopback Session
	If an answerer wishes to accept the loopback request it MUST		If an answerer wishes to accept the loopback request it MUST
	include both the loopback mode and loopback type attribute in the		include both the loopback mode and loopback type attribute in the
	answer. If a stream is offered with loopback-source or		answer. If a stream is offered with loopback-source or
	loopback-mirror attributes, the corresponding stream MUST be		loopback-mirror attributes, the corresponding stream MUST be
	loopback-mirror or loopback-source respectively, provided that		loopback-mirror or loopback-source respectively, provided that
	answerer is capable of supporting the requested loopback-type.		answerer is capable of supporting the requested loopback-type.
	For example, if the offer contains:		For example, if the offer contains:
	skipping to change at page 9, line 44		skipping to change at page 10, line 11
	An offered stream with loopback-source MAY be rejected if the		An offered stream with loopback-source MAY be rejected if the
	loopback-type is not specified, the specified loopback-type is not		loopback-type is not specified, the specified loopback-type is not
	supported, or the endpoint cannot honor the offer for any other		supported, or the endpoint cannot honor the offer for any other
	reason. The Loopback request may be rejected by setting the media		reason. The Loopback request may be rejected by setting the media
	port number to zero in the answer as per RFC 3264 [RFC3264].		port number to zero in the answer as per RFC 3264 [RFC3264].
	5.5 Offerer Processing of the Answer		5.5 Offerer Processing of the Answer
	The answer to a loopback-source MUST be loopback-mirror. The		The answer to a loopback-source MUST be loopback-mirror. The
	answer to a loopback-mirror MUST be loopback-source. The loopback-		answer to a loopback-mirror MUST be loopback-source. The
	mode line MUST contain at least one codec the answerer is willing		loopback-mode line MUST contain at least one codec the answerer is
	to send or receive depending on whether it is the loopback-source		willing to send or receive depending on whether it is the loopback-
	or the loopback-mirror. In addition, the "m=" line MUST contain at		source or the loopback-mirror. In addition, the "m=" line MUST
	least one codec that the answerer is willing to send or receive		contain at least one codec that the answerer is willing to send or
	depending on whether it is the loopback-mirror or the loopback-		receive depending on whether it is the loopback-mirror or the
	source.		loopback-source.
	If the answer does not contain a=loopback-mirror or		If the answer does not contain a=loopback-mirror or
	a=loopback-source or contains any other standard mode attributes,		a=loopback-source or contains any other standard mode attributes,
	it is assumed that the loopback extensions are not supported by the		it is assumed that the loopback extensions are not supported by the
	target UA.		target UA.
	5.6 Modifying the Session		5.6 Modifying the Session
	At any point during the loopback session, either participant may		At any point during the loopback session, either participant may
	issue a new offer to modify the characteristics of the previous		issue a new offer to modify the characteristics of the previous
	session. In case of SIP this is defined in section 8 of RFC 3264		session. In case of SIP this is defined in section 8 of RFC 3264
	skipping to change at page 30, line 43		skipping to change at page 31, line 18
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, July 2003.		Applications", STD 64, RFC 3550, July 2003.
	[RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R.,		[RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R.,
	Duffield, N., Friedman, T., Hedayat, K., Sarac, K.		Duffield, N., Friedman, T., Hedayat, K., Sarac, K.
	and M. Westerlund, "RTP Control Protocol Extended		and M. Westerlund, "RTP Control Protocol Extended
	Reports (RTCP XR)", RFC 3611, November 2003.		Reports (RTCP XR)", RFC 3611, November 2003.
	[RFC4234] Crocker, P. Overell, "Augmented ABNF for Syntax		[RFC5234] Crocker, P. Overell, "Augmented ABNF for Syntax
	Specification: ABNF", RFC 4234, October 2005.		Specification: ABNF", RFC 5234, October 2005.
	[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.
	[RFC2736] Handley, M., Perkins, C., "Guidelines for Writers of		[RFC2736] Handley, M., Perkins, C., "Guidelines for Writers of
	RTP Payload Format Specifications", RFC 2736, BCP		RTP Payload Format Specifications", RFC 2736, BCP
	0036, December 1999.		0036, December 1999.
	[RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio		[RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio
	and Video Conferences with Minimial Control", STD 65,		and Video Conferences with Minimial Control", STD 65,
	skipping to change at page 32, line 32		skipping to change at page 33, line 4
	Chelliah SivaChelvan		Chelliah SivaChelvan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	2200 East President George Bush Turnpike		2200 East President George Bush Turnpike
	Richardson, TX 75082		Richardson, TX 75082
	US		US
	Phone: +1 972 813 5224		Phone: +1 972 813 5224
	EMail: chelliah@cisco.com		EMail: chelliah@cisco.com
	URI: http://www.cisco.com/		URI: http://www.cisco.com/
	Nathan Stratton		Nathan Stratton
	BlinkMind, Inc.		BlinkMind, Inc.
	2027 Briarchester Dr.		2027 Briarchester Dr.
	Katy, TX 77450		Katy, TX 77450
	Phone: +1 832 330 3810		Phone: +1 832 330 3810
	EMail: nathan@robotics.net		EMail: nathan@robotics.net
	URI: http://www.robotics.net/		URI: http://www.robotics.net/
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed
	to pertain to the implementation or use of the technology described
	in 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 made any independent effort to identify any such rights.
	Information on the procedures with respect to rights in RFC
	documents can be found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use
	of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
	Acknowledgement
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 23 change blocks.
	55 lines changed or deleted		60 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/