< draft-tschofenig-radext-qos-02.txt		draft-tschofenig-radext-qos-03.txt >
	RADIUS EXTensions (radext) H. Tschofenig		RADIUS EXTensions (radext) H. Tschofenig
	Internet-Draft Siemens		Internet-Draft Siemens
	Expires: April 25, 2006 A. Mankin		Expires: December 27, 2006 A. Mankin
	Shinkuro, Inc
	T. Tsenov		T. Tsenov
	Siemens
	A. Lior		A. Lior
	Bridgewater Systems		Bridgewater Systems
	October 22, 2005		June 25, 2006
	RADIUS Quality of Service Support		RADIUS Quality of Service Support
	draft-tschofenig-radext-qos-02.txt		draft-tschofenig-radext-qos-03.txt
	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 39 ¶		skipping to change at page 1, line 39 ¶
	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, 2006.		This Internet-Draft will expire on December 27, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document describes an extension to the RADIUS protocol that		This document describes an extension to the RADIUS protocol that
	performs authentication, authorization, and accounting for Quality-		performs authentication, authorization, and accounting for Quality-
	of-Service reservations.		of-Service reservations.
	The described extensions allow network elements to authenticate the		The described extensions allow network elements to authenticate the
	initiator of a reservation request (if desired), to ensure that the		initiator of a reservation request (if desired), to ensure that the
	reservation is authorized, and to account for established QoS		reservation is authorized, and to account for established QoS
	skipping to change at page 4, line 5 ¶		skipping to change at page 3, line 20 ¶
	belonging to these application flows and ensure that bandwidth,		belonging to these application flows and ensure that bandwidth,
	delay, and error rate requirements are met.		delay, and error rate requirements are met.
	This document is a complement to the ongoing work of the DIAMETER QoS		This document is a complement to the ongoing work of the DIAMETER QoS
	application described in [12]. It describes RADIUS protocol		application described in [12]. It describes RADIUS protocol
	extensions supporting AAA in an environment where better than best		extensions supporting AAA in an environment where better than best
	effort Quality of Service is desired. The suggested extensions to		effort Quality of Service is desired. The suggested extensions to
	the RFC 2865 [1], RFC 2866 [2], RFC 2869 [3] and RFC 3576 [4] satisfy		the RFC 2865 [1], RFC 2866 [2], RFC 2869 [3] and RFC 3576 [4] satisfy
	the requirements defined in [13].		the requirements defined in [13].
			Disclaimer: The content of this document will be aligned with the
			ongoing QoS work in the DIME working group. Additionally, the
			description of the data traffic that is experiencing the QoS
			treatment will be aligned with the [14]. Hence, the content of the
			attributes presented in this document are subject to change.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [5].		document are to be interpreted as described in RFC-2119 [5].
	3. Goals		3. Goals
	This document has a few ambitious goals, namely:		This document has a few ambitious goals, namely:
	skipping to change at page 6, line 11 ¶		skipping to change at page 6, line 11 ¶
	that need to be provided to the RADIUS server for authorization,		that need to be provided to the RADIUS server for authorization,
	the granularity of the QoS reservation (e.g., for an individual		the granularity of the QoS reservation (e.g., for an individual
	application flow, for an aggregate).		application flow, for an aggregate).
	4. RADIUS functional considerations		4. RADIUS functional considerations
	Being a value-added service, QoS provisioning SHOULD go along with		Being a value-added service, QoS provisioning SHOULD go along with
	explicit authorization, accounting and control over the QoS-featured		explicit authorization, accounting and control over the QoS-featured
	user session. Specifically, the management of the authorized session		user session. Specifically, the management of the authorized session
	with Session-Timeout(27) and Termination-Action(29) attributes raises		with Session-Timeout(27) and Termination-Action(29) attributes raises
	a number of issues, identified in [14]. The solution presented in		a number of issues, identified in [15]. The solution presented in
	this document aims to allow explicit control by the RADIUS server		this document aims to allow explicit control by the RADIUS server
	(Authorizing entity) over the authorization session and its		(Authorizing entity) over the authorization session and its
	parameters. In addition, it aims to support flexible deployment		parameters. In addition, it aims to support flexible deployment
	scenarios of QoS authorization and parameter provisioning by		scenarios of QoS authorization and parameter provisioning by
	Authorization entities, which know the user and its subscription		Authorization entities, which know the user and its subscription
	profile (Home AAA server) or can provide authorization for a session		profile (Home AAA server) or can provide authorization for a session
	requested by the user (Application server). QoS authorization and		requested by the user (Application server). QoS authorization and
	parameter provisioning MAY be incorporated into initial		parameter provisioning MAY be incorporated into initial
	authentication and authorization RADIUS exchange or MAY be triggered		authentication and authorization RADIUS exchange or MAY be triggered
	at a later moment by a reception of a QoS signalling message.		at a later moment by a reception of a QoS signalling message.
	5. Authorization and QoS parameter provision		5. Authorization and QoS parameter provision
	5.1. QoS enabled initial access authentication and authorization		5.1. QoS enabled initial access authentication and authorization
	QoS enabled RADIUS client (NAS) initiates the authentication and		QoS enabled RADIUS client (NAS) initiates the authentication and
	authorization process by sending a RADIUS Access-Request to the		authorization process by sending a RADIUS Access-Request to the
	user's Home AAA server. In addition to authentication related		user's Home AAA server. In addition to authentication related
	attributes, it includes the QSPEC(TBD) attribute, which MAY specify		attributes, it includes the QSPEC(TBD) attribute, which MAY specify
	the QoS-Model [15] supported by the NAS and description of the		the QoS-Model [16] supported by the NAS and description of the
	currently available QoS resources or description of the QoS		currently available QoS resources or description of the QoS
	explicitly requested by the user. In the second case, additional		explicitly requested by the user. In the second case, additional
	session and flow identification information MIGHT be included		session and flow identification information MIGHT be included
	together with the identity of the QoS authorizing application server.		together with the identity of the QoS authorizing application server.
	If the authentication process involves multiple Access-Requests (as		If the authentication process involves multiple Access-Requests (as
	in EAP), the RADIUS client MUST include the QSPEC(TBD) attribute and		in EAP), the RADIUS client MUST include the QSPEC(TBD) attribute and
	any additional QoS-authorization related information in at least the		any additional QoS-authorization related information in at least the
	last Access-Request of the authentication process.		last Access-Request of the authentication process.
	skipping to change at page 8, line 51 ¶		skipping to change at page 8, line 51 ¶
	In case that an Application server MUST be contacted for the QoS		In case that an Application server MUST be contacted for the QoS
	authorization, the Home server forwards the Access-Request to the		authorization, the Home server forwards the Access-Request to the
	indicated Application server, which processes the QoS authorization		indicated Application server, which processes the QoS authorization
	request.		request.
	5.2.2. Server-side initiated Re-Authorization		5.2.2. Server-side initiated Re-Authorization
	In order to take advantage of the dynamic authorization capabilities		In order to take advantage of the dynamic authorization capabilities
	of RADIUS as defined in [4], the Authorization entity (Home or		of RADIUS as defined in [4], the Authorization entity (Home or
	Application server) MUST be sure that the RADIUS client supports them		Application server) MUST be sure that the RADIUS client supports them
	too. An advertising approach proposed in [14] MIGHT be used.(TBD)		too. An advertising approach proposed in [15] MIGHT be used.(TBD)
	At any time during the QoS session the RADIUS server MAY send a		At any time during the QoS session the RADIUS server MAY send a
	Change-of-Authorization (CoA) message with Service-Type(6) attribute		Change-of-Authorization (CoA) message with Service-Type(6) attribute
	set to value "Authorize-ONLY" and session and flow identification		set to value "Authorize-ONLY" and session and flow identification
	information. The RADIUS client MUST respond with a Change-of-		information. The RADIUS client MUST respond with a Change-of-
	Authorization NACK message with Service-Type(6) attribute with value		Authorization NACK message with Service-Type(6) attribute with value
	"Authorize-ONLY" and Error-Cause(101) attribute set to value		"Authorize-ONLY" and Error-Cause(101) attribute set to value
	"Request-Initiated". The RADIUS client MUST then send an Access-		"Request-Initiated". The RADIUS client MUST then send an Access-
	Request containing Service-Type(6) attribute with value "Authorize-		Request containing Service-Type(6) attribute with value "Authorize-
	ONLY", QSPEC(TBD) attribute, session and flow identification		ONLY", QSPEC(TBD) attribute, session and flow identification
	information. This approach is compatible with the DIAMETER re-		information. This approach is compatible with the DIAMETER re-
	skipping to change at page 11, line 20 ¶		skipping to change at page 11, line 20 ¶
	o Identification of the flow that should receive QoS described in		o Identification of the flow that should receive QoS described in
	QSPEC		QSPEC
	o Attributes required to carry authorization information (e.g.,		o Attributes required to carry authorization information (e.g.,
	authorization tokens as specified in [6])		authorization tokens as specified in [6])
	7.1. QSPEC Attribute		7.1. QSPEC Attribute
	The generic QoS description is taken from QoS-NSLP QSpec Template		The generic QoS description is taken from QoS-NSLP QSpec Template
	[15] which aims to support QoS parameters for all QoS reservations		[16] which aims to support QoS parameters for all QoS reservations
	and is independent of a specific QoS model (QOSM). The QSPEC		and is independent of a specific QoS model (QOSM). The QSPEC
	template format is organized into QoS Control information, Requested,		template format is organized into QoS Control information, Requested,
	Reserved, Available and Minimum objects. Each of the objects		Reserved, Available and Minimum objects. Each of the objects
	contains a number of QSPEC parameters. For QoS authorization		contains a number of QSPEC parameters. For QoS authorization
	purposes only part of the parameters SHOULD be used, e.g., mainly		purposes only part of the parameters SHOULD be used, e.g., mainly
	those included into the QoS Desired and some of those included into		those included into the QoS Desired and some of those included into
	QoS Control information objects. In addition information for		QoS Control information objects. In addition information for
	duration of the authorized QoS SHOULD be provided.		duration of the authorized QoS SHOULD be provided.
	QSPEC parameters and QoS authorization session management parameters		QSPEC parameters and QoS authorization session management parameters
	skipping to change at page 13, line 17 ¶		skipping to change at page 13, line 17 ¶
	Length: variable, greater than 8		Length: variable, greater than 8
	String: The String value MUST be encoded as follows:		String: The String value MUST be encoded as follows:
	Sub-Type (=1): Sub-Type for QoS-Model ID attribute		Sub-Type (=1): Sub-Type for QoS-Model ID attribute
	Length : Length of QoS-Model ID attribute (= 6 octets)		Length : Length of QoS-Model ID attribute (= 6 octets)
	QoS-Model ID (QoSM ID):		QoS-Model ID (QoSM ID):
	Identifier of the used QoS signaling model.[15]		Identifier of the used QoS signaling model.[16]
	Sub-Type (=2): Sub-Type for Excess Treatment attribute		Sub-Type (=2): Sub-Type for Excess Treatment attribute
	Length : Length of Excess Treatment attribute (= 3 octets)		Length : Length of Excess Treatment attribute (= 3 octets)
	Excess Treatment:		Excess Treatment:
	Description of how the excess traffic to be processed (out-of-		Description of how the excess traffic to be processed (out-of-
	profile traffic). Excess traffic MAY be dropped, shaped and/or		profile traffic). Excess traffic MAY be dropped, shaped and/or
	remarked.		remarked.
	skipping to change at page 14, line 48 ¶		skipping to change at page 14, line 48 ¶
	Indicates the QoS class used in DiffServ per-hop behavior QoS		Indicates the QoS class used in DiffServ per-hop behavior QoS
	signaling [8].		signaling [8].
	Sub-Type (=10): Sub-Type for Y.1541 QoS class attribute		Sub-Type (=10): Sub-Type for Y.1541 QoS class attribute
	Length : Length of Y.1541 QoS class attribute (= 3 octets)		Length : Length of Y.1541 QoS class attribute (= 3 octets)
	Y.1541 QoS class:		Y.1541 QoS class:
	Indicates the Y.1541 QoS Class [16].		Indicates the Y.1541 QoS Class [17].
	Sub-Type (=11): Sub-Type for DSTE class attribute		Sub-Type (=11): Sub-Type for DSTE class attribute
	Length : Length of DSTE class attribute (= 3 octets)		Length : Length of DSTE class attribute (= 3 octets)
	DSTE Class:		DSTE Class:
	Indicates the QoS class used in DiffServ-enabled MPLS traffic		Indicates the QoS class used in DiffServ-enabled MPLS traffic
	engineering.[9].		engineering.[9].
	skipping to change at page 16, line 29 ¶		skipping to change at page 16, line 29 ¶
	Length : Length of Authorized volume attribute (IPv4 = 6		Length : Length of Authorized volume attribute (IPv4 = 6
	octets, IPv6= 18 octets)		octets, IPv6= 18 octets)
	Application server ID:		Application server ID:
	Application server ID indicates the address of the authorizing		Application server ID indicates the address of the authorizing
	Application Server.		Application Server.
	Provided QSPEC parameters list is not exhaustive and SHOULD be		Provided QSPEC parameters list is not exhaustive and SHOULD be
	updated according to [15].		updated according to [16].
	7.2. Flow Identification		7.2. Flow Identification
	Depending on the deployment and used QoS signaling protocol,		Depending on the deployment and used QoS signaling protocol,
	identification of the flow that SHOULD receive authorized QoS takes a		identification of the flow that SHOULD receive authorized QoS takes a
	different format. Signaling session Identifier (NSIS) or flow		different format. Signaling session Identifier (NSIS) or flow
	identifier and explicit filter specifications are used. The		identifier and explicit filter specifications are used. The
	Attribute QoS-Flow-ID is designated to encapsulate such information.		Attribute QoS-Flow-ID is designated to encapsulate such information.
	0 1 2 3		0 1 2 3
	skipping to change at page 17, line 32 ¶		skipping to change at page 17, line 32 ¶
	Sub-Type (=2): Flow-ID		Sub-Type (=2): Flow-ID
	Length : Length of Flow-ID attribute		Length : Length of Flow-ID attribute
	Flow-ID:		Flow-ID:
	The Flow-ID attribute is an application assigned identifier for an		The Flow-ID attribute is an application assigned identifier for an
	IP flow that identifies the IP flow in an application layer		IP flow that identifies the IP flow in an application layer
	session (e.g., SIP/SDP). It might be used in conjunction with a		session (e.g., SIP/SDP). It might be used in conjunction with a
	QoS-Filter-Rule [17] attribute for provision of flow description		QoS-Filter-Rule attribute for provision of flow description and
	and identification. Note that more than one Flow-ID sub-		identification. Note that more than one Flow-ID sub-attributes
	attributes MAY be present in the QoS-Flow-Id attribute.		MAY be present in the QoS-Flow-Id attribute.
	Sub-Type (=3): Flow-State		Sub-Type (=3): Flow-State
	Length : Length of Flow-State attribute		Length : Length of Flow-State attribute
	Flow-State:		Flow-State:
	The Flow-State attribute indicates the action that MUST be		The Flow-State attribute indicates the action that MUST be
	performed on the flow(s) to which QoS authorization message		performed on the flow(s) to which QoS authorization message
	exchange applies as identified by the QoS-Flow-Id. The flow could		exchange applies as identified by the QoS-Flow-Id. The flow could
	skipping to change at page 19, line 4 ¶		skipping to change at page 19, line 4 ¶
	Length : Length of Authorization-Token attribute		Length : Length of Authorization-Token attribute
	Authorization-Token:		Authorization-Token:
	The Authorization-Token sub-attribute is a container that		The Authorization-Token sub-attribute is a container that
	encapsulates an authorization token received via the QoS signaling		encapsulates an authorization token received via the QoS signaling
	message typically sent by the end host. The token is generated by		message typically sent by the end host. The token is generated by
	the Authorizing entity during the application layer signaling		the Authorizing entity during the application layer signaling
	exchange and identifies the application service session, for which		exchange and identifies the application service session, for which
	the QoS reservation request applies. A possible structure for the		the QoS reservation request applies. A possible structure for the
	authorization token is proposed in context of RSVP [6], with the		authorization token is proposed in context of RSVP [6] or using
	Open Settlement Protocol (OSP) [18] or using SAML as outlined in		SAML as outlined in [18] and [19]. The structure of the token is
	[19] and [20]. The structure of the token is considered to be out		considered to be out of the scope for this document.
	of the scope for this document.
	8. Diameter RADIUS Interoperability		8. Diameter RADIUS Interoperability
	In deployments where RADIUS clients communicate with DIAMETER servers		In deployments where RADIUS clients communicate with DIAMETER servers
	or DIAMETER clients communicate with RADIUS servers then a		or DIAMETER clients communicate with RADIUS servers then a
	translation agent will be deployed and operate. The DIAMETER-QoS		translation agent will be deployed and operate. The DIAMETER-QoS
	specification [12] provides a natural candidate for mapping the		specification [12] provides a natural candidate for mapping the
	RADIUS QoS related AVPs to DIAMETER AVPs and messages.		RADIUS QoS related AVPs to DIAMETER AVPs and messages.
	9. Examples		9. Examples
	skipping to change at page 28, line 50 ¶		skipping to change at page 28, line 50 ¶
	[10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den		[10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
	Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,		Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
	June 2005.		June 2005.
	[11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,		[11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
	"Diameter Base Protocol", RFC 3588, September 2003.		"Diameter Base Protocol", RFC 3588, September 2003.
	12.2. Informative References		12.2. Informative References
	[12] Alfano, F., "Diameter Quality of Service Application",		[12] Alfano, F., "Diameter Quality of Service Application",
	draft-alfano-aaa-qosprot-04 (work in progress), September 2005.		draft-tschofenig-dime-diameter-qos-00 (work in progress),
			March 2006.
	[13] Alfano, F., "Requirements for a QoS AAA Protocol",		[13] Alfano, F., "Requirements for a QoS AAA Protocol",
	draft-alfano-aaa-qosreq-01 (work in progress), October 2003.		draft-alfano-aaa-qosreq-01 (work in progress), October 2003.
	[14] Lior, A., "PrePaid Extensions to Remote Authentication Dial-In		[14] Congdon, P., "RADIUS Filter Rule Attribute",
	User Service (RADIUS)", draft-lior-radius-prepaid-extensions-08		draft-ietf-radext-filter-00 (work in progress), June 2006.
	(work in progress), July 2005.
	[15] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-06		[15] Lior, A., "Prepaid extensions to Remote Authentication Dial-In
	(work in progress), October 2005.		User Service (RADIUS)", draft-lior-radius-prepaid-extensions-10
			(work in progress), February 2006.
	[16] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using		[16] Ash, J., "QoS NSLP QSPEC Template", draft-ietf-nsis-qspec-10
			(work in progress), June 2006.
			[17] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using
	Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in		Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in
	progress), May 2005.		progress), May 2005.
	[17] Congdon, P., "RADIUS Extensions for IEEE 802",		[18] Peterson, J., "Trait-based Authorization Requirements for the
	draft-congdon-radext-ieee802-03 (work in progress),
	February 2005.
	[18] European Telecommunications Standards Institute,
	"Telecommunications and Internet Protocol Harmonization Over
	Networks (TIPHON); Open Settlement Protocol (OSP) for Inter-
	domain pricing, authorization, and usage exchange", TS 101
	321.
	[19] Peterson, J., "Trait-based Authorization Requirements for the
	Session Initiation Protocol (SIP)",		Session Initiation Protocol (SIP)",
	draft-ietf-sipping-trait-authz-01 (work in progress),		draft-ietf-sipping-trait-authz-02 (work in progress),
	February 2005.		January 2006.
	[20] Tschofenig, H., "Using SAML for SIP",		[19] Tschofenig, H., "SIP SAML Profile and Binding",
	draft-tschofenig-sip-saml-04 (work in progress), July 2005.		draft-ietf-sip-saml-00 (work in progress), June 2006.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.com
	Allison Mankin		Allison Mankin
	Shinkuro, Inc
	1025 Vermont Avenue		1025 Vermont Avenue
	Washington, DC 20005		Washington, DC 20005
	US		US
	Phone: +1 301-728-7199 (mobile)		Phone: +1 301-728-7199 (mobile)
	Email: mankin@psg.com		Email: mankin@psg.com
			URI: http://www.psg.com/~mankin/
	Tseno Tsenov		Tseno Tsenov
	Siemens		Sofia,
	Otto-Hahn-Ring 6		Bulgaria
	Munich, Bayern 81739
	Germany
	Email: tseno.tsenov@mytum.de		Email: tseno.tsenov@mytum.de
	Avi Lior		Avi Lior
	Bridgewater Systems Corporation		Bridgewater Systems Corporation
	303 Terry Fox Drive		303 Terry Fox Drive
	Ottawa, Ontario K2K 3J1		Ottawa, Ontario K2K 3J1
	Canada		Canada
	Phone: +1 613-591-6655		Phone: +1 613-591-6655
	skipping to change at page 31, line 41 ¶		skipping to change at page 31, line 41 ¶
	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 AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		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.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 27 change blocks.
	49 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/