draft-ietf-mboned-multiaaa-framework-02.txt		draft-ietf-mboned-multiaaa-framework-03.txt
	Hiroaki Satou, NTT
	Internet Draft Hiroshi Ohta, NTT
	Expires: April 26, 2007 Christian Jacquenet, France Telecom
	Tsunemasa Hayashi, NTT
	Haixiang He, Nortel Networks
	October 23, 2006		MBONED WG Hiroaki Satou, NTT
			Internet-Draft Hiroshi Ohta, NTT
			Proposed Status: Informational Christian Jacquenet, France Telecom
			Expires: September 2, 2007 Tsunemasa Hayashi, NTT
			Haixiang He, Nortel Networks
			March 4, 2007
	AAA Framework for Multicasting		AAA Framework for Multicasting
	<draft-ietf-mboned-multiaaa-framework-02.txt>		<draft-ietf-mboned-multiaaa-framework-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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as 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
	months and may be updated, replaced, or obsoleted by other documents		and may be updated, replaced, or obsoleted by other documents at any
	at any time. It is inappropriate to use Internet-Drafts as		time. It is inappropriate to use Internet-Drafts as reference
	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 26, 2007.		This Internet-Draft will expire on September 2, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006)		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	IP multicast-based services, such as TV broadcasting or		IP multicast-based services, such as TV broadcasting or
	videoconferencing raise the issue of making sure that potential		videoconferencing raise the issue of making sure that potential
	customers are fully entitled to access the corresponding contents.		customers are fully entitled to access the corresponding
	There is indeed a need for service and content providers to identify		contents. There is indeed a need for service and content
	(if not authenticate, especially within the context of enforcing		providers to identify (if not authenticate, especially within the
	electronic payment schemes) and to invoice such customers in a		context of enforcing electronic payment schemes) and to invoice
	reliable and efficient manner. This memo describes the framework for		such customers in a reliable and efficient manner. This memo
	specifying the Authorization, Authentication and Accounting (AAA)		describes the framework for specifying the Authorization,
	capabilities that could be activated within the context of the		Authentication and Accounting (AAA) capabilities that could be
	deployment and the operation of IP multicast-based services. This		activated within the context of the deployment and the operation
	framework addresses the requirements presented in draft-ietf-mboned-		of IP multicast-based services. This framework addresses the
	maccnt-req-04.txt, "Requirements for Accounting, Authentication and		requirements presented in draft-ietf-mboned-maccnt-req-04.txt,
	Authorization in Well Managed IP Multicasting Services".		"Requirements for Accounting, Authentication and Authorization in
			Well Managed IP Multicasting Services".
	1. Introduction		1. Introduction
	1.1 Purpose and Background		1.1 Purpose and Background
	IP multicasting is designed to serve cases of group communication		IP multicasting is designed to serve cases of group communication
	schemes of any kind, such as 1-to-n (case of TV broadcasting		schemes of any kind, such as 1-to-n (case of TV broadcasting
	services for example) or n-to-p (case of videoconferencing services,		services for example) or n-to-p (case of videoconferencing services,
	for example).		for example).
	In these environments, IP multicast provides a better resource		In these environments, IP multicast provides a better resource
	optimization than using a unicast transmission scheme, where data		optimization than using a unicast transmission scheme, where data
	skipping to change at page 4, line 29		skipping to change at page 4, line 41
	Authorization: The set of capabilities that need to be activated to		Authorization: The set of capabilities that need to be activated to
	make sure a given requesting customer is (1) what he claims to be		make sure a given requesting customer is (1) what he claims to be
	(identification purposes), and (2) is fully entitled to access a set		(identification purposes), and (2) is fully entitled to access a set
	of services (authentication purposes).		of services (authentication purposes).
	Receiver: an end-host or end-client which receives content. A		Receiver: an end-host or end-client which receives content. A
	receiver may be identified by a network ID such as MAC address or IP		receiver may be identified by a network ID such as MAC address or IP
	address.		address.
	User: a human with a user account. A user may possibly use multiple		User: a human with a user account. A user may possibly use multiple
	reception devices. Multiple users may use the same reception device.		reception devices. Multiple users may use the same reception
			device.
	Note: The definition of a receiver (device) and a user (human)		Note: The definition of a receiver (device) and a user (human)
	should not be confused.		should not be confused.
	2.2 Abbreviations		2.2 Abbreviations
	For the purpose of this draft the following abbreviations apply:		For the purpose of this draft the following abbreviations apply:
	ACL: Access Control List		ACL: Access Control List
	CDN: Content Delivery Network		CDN: Content Delivery Network
	CDS: Content Delivery Services		CDS: Content Delivery Services
	CP: Content Provider		CP: Content Provider
	NSP: Network Service Provider		NSP: Network Service Provider
	TP: Transit Provider		TP: Transit Provider
	skipping to change at page 5, line 14		skipping to change at page 6, line 14
	3. Common use models and network architecture implications		3. Common use models and network architecture implications
	In some cases a single entity may design and be responsible for a		In some cases a single entity may design and be responsible for a
	system that covers the various common high-level requirements of a		system that covers the various common high-level requirements of a
	multicasting system such as 1) content serving, 2) the		multicasting system such as 1) content serving, 2) the
	infrastructure to multicast it, 3) network and content access		infrastructure to multicast it, 3) network and content access
	control mechanisms. In many cases however the content provision and		control mechanisms. In many cases however the content provision and
	network provision roles are divided between separate entities. The		network provision roles are divided between separate entities. The
	MACCNT-REQ-draft provides more detail of the multiple versus single		MACCNT-REQ-draft provides more detail of the multiple versus single
	entity CDS network model.		entity CDS network models.
	As such it should not be assumed that the entity responsible for the		As such it should not be assumed that the entity responsible for the
	multicasting structure and the entity responsible for content		multicasting structure and the entity responsible for content
	serving are the same. Indeed because the infrastructure for		serving are the same. Indeed because the infrastructure for
	multicasting is expensive and many content holders are not likely to		multicasting is expensive and many content holders are not likely to
	be competent at building and maintaining complicated infrastructures		be competent at building and maintaining complicated infrastructures
	necessary for multicasting, many content holders would prefer to		necessary for multicasting, many content holders would prefer to
	purchase transport and management services from a network service		purchase transport and management services from a network service
	provider and thus share the infrastructure costs with other content		provider and thus share the infrastructure costs with other content
	holders.		holders.
	skipping to change at page 7, line 17		skipping to change at page 8, line 17
	the AAA messages from the CP whether the user is eligible to receive		the AAA messages from the CP whether the user is eligible to receive
	content (authentication by proxy), and the NSPs relevant AAA server		content (authentication by proxy), and the NSPs relevant AAA server
	will make the final decision of whether the connection can be		will make the final decision of whether the connection can be
	established. When the NSP cannot or decides not to multicast to		established. When the NSP cannot or decides not to multicast to
	users, the NSP is responsible for notifying the users of the reason.		users, the NSP is responsible for notifying the users of the reason.
	4.2 Multiple User IDs		4.2 Multiple User IDs
	Users may hold multiple user IDs: IDs which have been separately		Users may hold multiple user IDs: IDs which have been separately
	assigned for each subscription they may have for various NSPs and		assigned for each subscription they may have for various NSPs and
	CPs. When the user wants to access content or otherwise use the		CPs. The NSPs and CPs control the user IDs for their respective
	network, the user registers the corresponding user ID with a request		domains. The user IDs are only meaningful in the context of each
	for content, etc: web authentication is one possible method.		domain.
	Terminal portability can be realized if the NSP authenticates a user		When the user wants to access content, the user registers the
	using a user ID. This allows the user to access the content from		corresponding user ID (including its CP domain information) with a
	various network access points.		request for content, etc: web authentication is one possible method.
	Each CP may identify users by the user IDs that it has issued to		Each CP may identify users by the user IDs that it has issued to
	them.		them.
			Terminal portability can be realized if the NSP authenticates a user
			using a NSP-domained user ID. This allows the user to access the
			content from various network access points.
	The NSP and CP do not need to know the corresponding user id for the		The NSP and CP do not need to know the corresponding user id for the
	same user in the other provider's domain, and it is not necessary		same user in the other provider's domain, and it is not necessary
	that there is a one to one relationship. It is quite possible for		that there is a one to one relationship. It is quite possible for
	one person to hold multiple user ids for the same provider.		one person to hold multiple user ids for the same provider.
			The actual mapping rules for NSPs and CPs to map user IDs with the
			IDs in other provider domains is a matter for the providers. A
			solution should provide an API between the providers to flexibly
			support various mapping methods.
	4.3 Accounting		4.3 Accounting
	MACCNT-REQ-draft defines requirements for Accounting and Billing.		MACCNT-REQ-draft defines requirements for Accounting and Billing.
	These include the requirement for the NSP to log user behavior such		These include the requirement for the NSP to log user behavior such
	as the join action and the leave action, as well as the result of		as the join action and the leave action, as well as the result of
	the access-control decision. (MACCNT-REQ-draft, 4.5) MACCNT-REQ-		the access-control decision. (MACCNT-REQ-draft, 4.5) MACCNT-REQ-
	draft also specifies that there should be a standardized format for		draft also specifies that there should be a standardized format for
	sharing with the CP the user behavior and content reception		sharing with the CP the user behavior and content reception
	information which the NSP is logging.(MACCNT-REQ-draft, 4.5.1)		information which the NSP is logging.(MACCNT-REQ-draft, 4.5.1)
	In order to provide the granularity of user-behavior and actual		In order to provide the granularity of user-behavior and actual
	content reception information as specified in MACCNT-REQ-draft, the		content reception information as specified in MACCNT-REQ-draft, the
	NSP should not manage multicast states on a subnet basis, but on a		NSP should not manage multicast states on a subnet basis, but on a
	user basis (see in MACCNT-REQ-draft, 4.1 "User identification")		user basis (see in MACCNT-REQ-draft, 4.1 "User identification")
	because the NSP needs to be able to notify the CP of a user's start		because the NSP needs to be able to notify the CP of a user's start
	and stop times for accounting purposes. This means that the NSP		and stop times for accounting purposes. This means that the NSP
	sends to the CP AAA an indication for Join and Leave on a user basis.		sends to the CP AAA an indication for Join and Leave on a user
			basis.
	This framework specifies an accounting API provided by the NSP and		This framework specifies an accounting API provided by the NSP and
	accessed by the CP to allow for sharing user-behavior and content-		accessed by the CP to allow for sharing user-behavior and content-
	reception information between the NSP AAA and CP AAA. This		reception information between the NSP AAA and CP AAA. This
	accounting API should be configurable to allow the CP to request		accounting API should be configurable to allow the CP to request
	only the logging information it actually requires. Such an API		only the logging information it actually requires. Such an API
	would allow for realtime accounting information sharing by the NSP		would allow for realtime accounting information sharing by the NSP
	to the CP. When logging information is shared through the accounting		to the CP. When logging information is shared through the accounting
	API, it is important that the CP be able to match the user as		API, it is important that the CP be able to match the user as
	described in the database operated by the NSP to the user as		described in the database operated by the NSP to the user as
	skipping to change at page 9, line 44		skipping to change at page 11, line 7
	5.1 Basic Connection Model		5.1 Basic Connection Model
	+-------------+		+-------------+
	| user |		| user |
	| |		| |
	+-------------+		+-------------+
	^ Access & Resource		^ Access & Resource
	| Request		| Request
	v		v
	+-------------+		+-------------+
	| NSP |		| NSP= NAP |
	| |		| |
	+-------------+		+-------------+
	^ Access		^ Access
	| Request		| Request
	v		v
	+-------------+		+-------------+
	| CP |		| CP |
	| |		| |
	+-------------+		+-------------+
	First a user that requests content sends an Access request to an NSP		In this case the NSP is the sole entity providing Network Service
	which then forwards it on to the appropriate CP for Authentication		Provision including Network Access Provision to the User. First a
	and Authorization purposes. The CP responds with either "success" or		user that requests content sends an Access request to an NSP which
			then forwards it on to the appropriate CP for Authentication and
			Authorization purposes. The CP responds with either "success" or
	"failure". If "success", the NSP may forward a success response and		"failure". If "success", the NSP may forward a success response and
	stream multicast data to the user.		stream multicast data to the user.
	In this model the user selects the NSP to which to send its content		In this model the user selects the NSP to which to send its content
	request. Based on this request the NSP selects an appropriate CP to		request. Based on this request the NSP selects an appropriate CP to
	which it forwards the request. The CP responds to the NSP's request:		which it forwards the request. The CP responds to the NSP's request:
	it may not respond to another NSP in regards to the request.		it may not respond to another NSP in regards to the request.
	In this model, as described in section 3.1, the relationship between		In this model, as described in section 3.1, the relationship between
	NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple		NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple
	networks, and networks have multiple users.		networks, and networks have multiple users.
	5.2 Transit Provision		5.2 Transit Provision
	The diagram below shows that a Transit Provider(hereafter, TP) may		The diagram below shows that Network Service Provision may include
	relay requests between NSPs and CPs.		both Network Access Provision to the User and also Transit Provision
			(request relay) between the Network Access Provider (NAP) and the CP.
			Transit Provision is the responsibility of the NSP which may or may
			not contract out this service to a separate NSP that acts as the
			Transit Provider. The existence of the Transit Provider is
			transparent to the user.
	+-------------+		+-------------+
	| user |		| user |
	| |		| |
	+-------------+		+-------------+
	^ Access & Resource		^ Access & Resource
	| Request		| Request
	v		v
	+-------------+		+- - - - - - - - - - - - - - +
	| NSP |		|+----------------+
	| |		| Network Access | |
	+-------------+		|| Provision | Network Service
	^ Access & Resource		+----------------+ | Provision
	| Request		| ^ Access & Resource
	v		| Request |
	+-------------+		| v
	| TP |		+-------------+ |
	| |		|| Transit |
	+-------------+		| Provision | |
			|+-------------+
			+- - - - - - - - - - - - - - +
	^ Access		^ Access
	| Request		| Request
	v		v
	+-------------+		+-------------+
	| CP |		| CP |
	| |		| |
	+-------------+		+-------------+
	For the sake of simplification the above diagram shows a 1-1		For the sake of simplification the above diagram shows a 1-1
	relationship between an NSP and a TP. However it is also possible		relationship between an NAP and a TP. However it is also possible
	for a single NSP to connect to multiple TPs, and a single TP to		for a single NAP to connect to multiple TPs, and a single TP to
	multiple NSPs.		multiple NAPs.
	A single TP may connect to one or more CPs. Similarly just as a		A single TP may connect to one or more CPs. Similarly just as a
	single CP may connect to multiple NSPs (as described in the general		single CP may connect to multiple NAPs (as described in the general
	high-level framework, section 3.1), a single CP may connect to one		high-level framework, section 3.1), a single CP may connect to one
	or more TPs.		or more TPs.
	A solution will include a mechanism through which the NSPs know		A solution will include a mechanism through which the NAPs know
	which TP(s) are to be used to communicate with which CP(s), and CPs		which TP(s) are to be used to communicate with which CP(s), and CPs
	know which TP(s) to use for which NSP(s). When a TP receives an		know which TP(s) to use for which NAP(s). When a TP receives an
	access or resource request from an NSP or CP, it must relay the		access or resource request from an NAP or CP, it must relay the
	request to the correct CP or NSP, respectively. Minimally, this		request to the correct CP or NSP, respectively. Minimally, this
	means that it must reconstruct the request with translated address		means that it must reconstruct the request with translated address
	information. In this model therefore a TP must understand the		information. In this model therefore a TP must understand the
	format and meaning of the requests.		format and meaning of the requests.
	There may be multiple TPs between a NSP and CP so that a TP is		There may be multiple TPs between a NAP and CP so that a TP is
	actually receiving from and/or sending requests to another TP and		actually receiving from and/or sending requests to another TP and
	not directly from/to a NSP or CP.		not directly from/to a NAP or CP.
	5.3 Transit with Tunnels		5.3 Transit with Tunnels
	In addition to the above model of request relaying, a TP may		In addition to the above model of request relaying, a TP may
	communicate requests through tunneling based on the contract between		communicate requests through tunneling based on the contract between
	the TP and the NSP and/or between the TP and the CP. So in this		the TP and the NAP and/or between the TP and the CP. So in this
	case the TP will not directly need to process the contents of the		case the TP will not directly need to process the contents of the
	access and resource request (such as, header information), but		access and resource request (such as, header information), but
	instead pass the request directly to the correct NSP or CP, using a		instead pass the request directly to the correct NSP or CP, using a
	separate protocol to wrap the original requests.		separate protocol to wrap the original requests.
	Below is a diagram, representing how a TP can provide tunneling		Below is a diagram, representing how a TP can provide tunneling
	between NSP(s) and CP(s).		between NAP(s) and CP(s).
	+-----------------+		+-----------------+
	| user |		| user |
	| |		| |
	+-----------------+		+-----------------+
	^ Access & Resource		^ Access & Resource
	| Request		| Request
	v		v
			+ - - - - - - - - - - +
	+------------------+		+------------------+
	| NSP |		|| NAP | |
	| |		| |
	+------------------+		|+------------------+ | Network
	|^|		|^|
			| |:| | Service
	|:|		|:|
	|:|		|+-|:|--------------+ | Provision
	+-|:|--------------+
	| |:| TP |		| |:| TP |
	| |:| |		|| |:| | |
	+-|:|--------------+		+-|:|--------------+
	|:|		+ -|:|- - - - - - - - +
	|:| Tunnel		|:| Tunnel
	|:|		|:|
	|V|		|V|
	+------------------+		+------------------+
	| CP |		| CP |
	| |		| |
	+------------------+		+------------------+
	In this model too, the relationship between NSP and TP and between		In this model too, the relationship between NAP and TP and between
	transit provider and CP can be 1:1, 1:N or M:N.		TP and CP can be 1:1, 1:N or M:N.
	5.4 Constituent Logical Functional Components of the fully enabled AAA		5.4 Constituent Logical Functional Components of the fully enabled AAA
	Framework		Framework
	Section 3.1 introduces the high-level AAA framework for multicasting.		Section 3.1 introduces the high-level AAA framework for multicasting.
	Below is a diagram of a fully enabled multicasting network with AAA,		Below is a diagram of a fully enabled multicasting network with AAA,
	including the logical components within the various entities.		including the logical components within the various entities.
	+-------------------------------+		+-------------------------------+
	| user |		| user |
	skipping to change at page 14, line 20		skipping to change at page 16, line 20
	of transit provision between an NSP and CP is in the interest of		of transit provision between an NSP and CP is in the interest of
	modularity and extendibility.		modularity and extendibility.
	6. IANA considerations		6. IANA considerations
	This memo does not raise any IANA consideration issues.		This memo does not raise any IANA consideration issues.
	7. Security considerations		7. Security considerations
	Refer to section 3.3. Also the user information related to		Refer to section 3.3. Also the user information related to
	authentication with the CP must be protected in some way. Otherwise,		authentication with the CP must be protected in some way.
	this memo does not raise any new security issues which are not		Otherwise, this memo does not raise any new security issues which
	already addressed by the original protocols. Enhancement of		are not already addressed by the original protocols. Enhancement of
	multicast access control capabilities should enhance security		multicast access control capabilities should enhance security
	performance.		performance.
	8. Conclusion		8. Conclusion
	This memo provides a generalized framework for solution standards to		This memo provides a generalized framework for solution standards to
	meet the requirements presented in MACCNT-REQ-draft. Further work		meet the requirements presented in MACCNT-REQ-draft. Further work
	should be done to break down the content provider and network		should be done to break down the content provider and network
	service provider entities into their functional objects such as edge		service provider entities into their functional objects such as edge
	devices, AAA servers, etc.		devices, AAA servers, etc.
	skipping to change at page 16, line 5		skipping to change at page 18, line 5
	600 Technology Park Drive		600 Technology Park Drive
	Billerica, MA 01801, USA		Billerica, MA 01801, USA
	Phone: +1 978 288 7482		Phone: +1 978 288 7482
	Email: haixiang@nortel.com		Email: haixiang@nortel.com
	Comments		Comments
	Comments are solicited and should be addressed to the mboned working		Comments are solicited and should be addressed to the mboned working
	group's mailing list at mboned@lists.uoregon.edu_and/or the authors.		group's mailing list at mboned@lists.uoregon.edu_and/or the authors.
	Full Copyright Statement		Intellectual Property Statement
	Copyright (C) The Internet Society (2006).
	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 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		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed to
	to pertain to the implementation or use of the technology described		pertain to the implementation or use of the technology described in
	in this document or the extent to which any license under such		this document or the extent to which any license under such rights
	rights might or might not be available; nor does it represent that		might or might not be available; nor does it represent that it has
	it has made any independent effort to identify any such rights.		made any independent effort to identify any such rights. Information
	Information on the procedures with respect to rights in RFC		on the procedures with respect to rights in RFC documents can be
	documents can be found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use		attempt made to obtain a general license or permission for the use of
	of 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		specification can be obtained from the IETF on-line IPR repository at
	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 ietf-		this standard. Please address the information to the IETF at
	ipr@ietf.org.		ietf-ipr@ietf.org.
	Expiration		Disclaimer of Validity
	This Internet-Draft will expire on April 26, 2007.		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.
	Acknowledgement		Copyright Statement
			Copyright (C) The IETF Trust (2007). 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.
			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. 44 change blocks.
	107 lines changed or deleted		123 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/