draft-ietf-mboned-multiaaa-framework-00.txt		draft-ietf-mboned-multiaaa-framework-01.txt
	Hiroaki Satou, NTT		Hiroaki Satou, NTT
	Internet Draft Hiroshi Ohta, NTT		Internet Draft Hiroshi Ohta, NTT
	Expires: October 6, 2006 Tsunemasa Hayashi, NTT		Expires: December 25, 2006 Tsunemasa Hayashi, NTT
	Haixiang He, Nortel Networks		Haixiang He, Nortel Networks
	April 4, 2006		June 23, 2006
	AAA Framework for Multicasting		AAA Framework for Multicasting
	<draft-ietf-mboned-multiaaa-framework-00.txt>		<draft-ietf-mboned-multiaaa-framework-01.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 October 6, 2006.		This Internet-Draft will expire on December 25, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006)		Copyright (C) The Internet Society (2006)
	Abstract		Abstract
	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 draft-ietf-mboned-maccnt-req-		meet the requirements presented in draft-ietf-mboned-maccnt-req-
	04.txt, "Requirements for Accounting, Authentication and		04.txt, "Requirements for Accounting, Authentication and
	Authorization in Well Managed IP Multicasting Services". In this		Authorization in Well Managed IP Multicasting Services". In this
	framework a user sends a request for multicast data to a network		framework a user sends a request for multicast data to a network
	service provider. The network service provider selects the		service provider. The network service provider selects the
	appropriate content provider to send the user's request. The		appropriate content provider to send the user's request. The request
	request is sent by the network service provider to the content		is sent by the network service provider to the content provider
	provider transparently in a way so that the network service provider		transparently in a way so that the network service provider and
	and content provider do not need to know the corresponding user id		content provider do not need to know the corresponding user id for
	for the same user in the other provider's domain. The content		the same user in the other provider's domain. The content provider
	provider then responds with an indication of "success" or "failure"		then responds with an indication of "success" or "failure" to the
	to the network provider and in the case of "success", the network		network provider and in the case of "success", the network provider
	provider may delivery the requested data to the user. The network		may delivery the requested data to the user. The network service may
	service may base its decision to deliver such data to the user based		base its decision to deliver such data to the user based on its
	on its bandwidth management policy. The framework is designed to be		bandwidth management policy. The framework is designed to be
	flexible and extendible, so it will be possible to implement		flexible and extendible, so it will be possible to implement
	partially enabled versions as well as fully enabled versions of the		partially enabled versions as well as fully enabled versions of the
	model. Also an additional entity may provide transit of requests		model. Also an additional entity may provide transit of requests
	between network service providers and content providers, either		between network service providers and content providers, either
	through relaying or tunneling.		through relaying or tunneling.
	1. Introduction		1. Introduction
	1.1 Purpose and Background		1.1 Purpose and Background
	skipping to change at page 3, line 4		skipping to change at page 2, line 40
	model. Also an additional entity may provide transit of requests		model. Also an additional entity may provide transit of requests
	between network service providers and content providers, either		between network service providers and content providers, either
	through relaying or tunneling.		through relaying or tunneling.
	1. Introduction		1. Introduction
	1.1 Purpose and Background		1.1 Purpose and Background
	IP multicasting is designed to serve cases where a single source of		IP multicasting is designed to serve cases where a single source of
	data content is to be concurrently streamed to multiple recipients.		data content is to be concurrently streamed to multiple recipients.
	In these types of cases, multicasting provides resource efficiencies		In these types of cases, multicasting provides resource efficiencies
	(both for the overall network and the content server) relative to		(both for the overall network and the content server) relative to
	unicasting. These efficiencies are possible because of the		unicasting. These efficiencies are possible because of the avoidance
	avoidance of unnecessary duplication of streams, video/audio		of unnecessary duplication of streams, video/audio processing, etc.
	processing, etc. Multicasting also provides resource efficiencies		Multicasting also provides resource efficiencies relative to IP
	relative to IP broadcasting in that content data is only delivered		broadcasting in that content data is only delivered to end hosts
	to end hosts which request it.		which request it.
	There are many real-life situations where IP multicasting is		There are many real-life situations where IP multicasting is selected
	selected as the technology used for concurrent content delivery of		as the technology used for concurrent content delivery of identical
	identical content data to multiple end-hosts. "Requirements for		content data to multiple end-hosts. "Requirements for Accounting,
	Accounting, Authentication and Authorization in Well Managed IP		Authentication and Authorization in Well Managed IP Multicasting
	Multicasting Services", (draft-ietf-mboned-maccnt-req-04.txt,		Services", (draft-ietf-mboned-maccnt-req-04.txt, hereafter MACCNT-
	hereafter MACCNT-REQ-draft) describes the requirements in CDN		REQ-draft) describes the requirements in CDN services using IP
	services using IP multicast[1]. "Issues Related to Receiver Access		multicast[1]. "Issues Related to Receiver Access Control in the
	Control in the Current Multicast Protocols" (draft-ietf-mboned-rac-		Current Multicast Protocols" (draft-ietf-mboned-rac-issues-03.txt,
	issues-02.txt, hereafter RAC-ISSUES-draft) discusses the		hereafter RAC-ISSUES-draft) discusses the requirements and existing
	requirements and existing support for commercial, large-scale		support for large-scale, multi-entity content delivery services[2].
	content delivery[2]. The requirements are derived from:		The requirements are derived from:
	- need for user tracking and billing capabilities		- need for user tracking and billing capabilities
	- need for network access control and/or content access control		- need for network access control and/or content access control
	to satisfy the requirements of the CP		to satisfy the requirements of the CP
	- methods for sharing information between the network service		- methods for sharing information between the network service
	provider and content provider to make it possible to fulfill the		provider and content provider to make it possible to fulfill the
	above two requirements.		above two requirements.
	Detailed requirements are presented in MACCNT-REQ-draft. These		Detailed requirements are presented in MACCNT-REQ-draft. These
	requirements include mechanisms for recording end-user requests and		requirements include mechanisms for recording end-user requests and
	provider responses for content-delivery, sharing user information		provider responses for content-delivery, sharing user information
	skipping to change at page 4, line 17		skipping to change at page 4, line 15
	Authorization: action for giving permission to access the content or		Authorization: action for giving permission to access the content or
	network to a user.		network to a user.
	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 distinguishable by a network ID such as MAC address		receiver may be distinguishable by a network ID such as MAC address
	or IP address.		or IP 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
	should not be confused.		not be confused.
	2.2 Abbreviations		2.2 Abbreviations
	For the purposes of this draft the following abbreviations apply:		For the purposes 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
	3. Issues in multicasting related to commercial and large-scale		3. Framework and Roles of Entities
	implementations
	This section lists issues related to receiver access control in
	current multicasting protocols which are especially important to
	commercial, large-scale multicasting. More details concerning the
	requirements related to these issues are provided in MACCNT-REQ-
	draft. References to that memo are provided as applicable below.
	3.1 Framework for multicast AAA allowing bandwidth Management		3.1 Framework for multicast AAA allowing bandwidth Management
	A general high-level framework can be represented as follows.		A general high-level framework can be represented as follows.
	+------------------------------+		+------------------------------+
	| user |		| user |
	| |		| |
	+------------------------------+		+------------------------------+
	| Access ^ Response		| Access ^ Response
	skipping to change at page 5, line 45		skipping to change at page 5, line 47
	entity.		entity.
	Description of Roles:		Description of Roles:
	The user selects a CP and a NSP when the user requests content. The		The user selects a CP and a NSP when the user requests content. The
	NSP may be automatically selected by a user terminal: e.g. a fixed		NSP may be automatically selected by a user terminal: e.g. a fixed
	line NSP for STB or a mobile NSP for mobile phone.		line NSP for STB or a mobile NSP for mobile phone.
	The CP is responsible for Authentication and Authorization of users'		The CP is responsible for Authentication and Authorization of users'
	access to content that the CP manages. The CP hopes to collect		access to content that the CP manages. The CP hopes to collect
	accounting information related to the access of their content.		accounting information related to the access of their content. The CP
			may choose to authenticate and authorize NSPs which are eligible to
			provide users access to its contents. When the CP cannot or decides
			not to provide content to be multicast to users, the CP is
			responsible for notifying the NSP of the reason.
	The NSP is responsible for managing its network resources. The NSP		The NSP is responsible for managing its network resources. The NSP
	may perform admission control to protect bandwidth resource and		may perform admission control to protect bandwidth resource and needs
	needs authorized information regarding user access for bandwidth		authorized information regarding user access for bandwidth
	management. It is also responsible for confirming (authentication by		management.
	proxy) with the CP whether the user is eligible to receive content.		It is also responsible for confirming (authentication by proxy) with
			the CP whether the user is eligible to receive content. When the NSP
	In addition to the three basic entities of user, NSP and CP, this		cannot or decides not to multicast to users, the NSP is responsible
	AAA framework for multicasting supports transit provision which		for notifying the users of the reason.
	transfers multicast streams from the CP to the NSP.		In addition to the three basic entities of user, NSP and CP, this AAA
			framework for multicasting supports transit provision which transfers
			multicast streams from the CP to the NSP.
	3.2 Multiple User IDs		3.2 Multiple User IDs
	Users may be assigned separate user IDs for each subscription for		Users may be assigned separate user IDs for each subscription for
	various NSPs and CPs. When the user wants to access content or		various NSPs and CPs. When the user wants to access content or
	otherwise use the network, the user registers the corresponding user		otherwise use the network, the user registers the corresponding user
	ID with a request for content, etc: web authentication is one		ID with a request for content, etc: web authentication is one
	possible method.		possible method.
	Terminal portability can be realized if the NSP authenticates a user		Terminal portability can be realized if the NSP authenticates a user
	using a user ID. This allows the user to access the content from		using a user ID. This allows the user to access the content from
	various network access points.		various network access points.
	Each CP may identify users by the user IDs that it has issued to		Each CP may identify users by the user IDs it has issued to them.
	them.
	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.
	3.3 Access Control and CP selection by NSP		3.3 Accounting
			The NSP should not manage multicast states on a subnet basis, but on
			a user basis because the NSP needs to notify start and stop times for
			accounting purposes. This means that the NSP sends an indication for
			Join and Leave on a user basis.
			The NSP should log both user and host information for each join and
			leave, indicating the corresponding multicast source for each action.
			It is important that such log use a standard format so that it can be
			shared with the CP. Intermittent logs between the join and leave
			also could serve useful in billing discrepancies, and disconnects
			without leaves. Ideally a solution would also provide standard ways
			for the NSP to share logged information with the CP. When shared it
			is important that the CP be able to match the user to the user within
			its domain.
			3.4 Access Control and CP selection by NSP
	When a NSP receives an access request from a user, it is necessary		When a NSP receives an access request from a user, it is necessary
	for the NSP to determine to which CP the request is directed. It is		for the NSP to determine to which CP the request is directed. It is
	necessary for the NSP to ensure that it is not spoofed by an		necessary for the NSP to ensure that it is not spoofed by an
	inappropriate CP.		inappropriate CP.
	3.4 Network Resource Management by NSP		3.5 Network Resource Management by NSP
	After authorizing a user request, the NSP may conduct admission		After authorizing a user request, the NSP may conduct admission
	control based on its bandwidth management policy. For example, if		control based on its bandwidth management policy. For example, if the
	the NSP manages the shared bandwidth of access lines, the NSP might		NSP manages the shared bandwidth of access lines, the NSP might
	calculate available bandwidth and necessary bandwidth, and based on		calculate available bandwidth and necessary bandwidth, and based on
	these calculations determine to accept or reject a user request.		these calculations determine to accept or reject a user request.
	3.5 Access Control and Distinguishing of Users by CP		3.6 Access Control and Distinguishing of Users by CP
	The user ID and authentication information are forwarded		The user ID and authentication information are forwarded
	transparently by the NSP so that the CP can distinguish the user, as		transparently by the NSP so that the CP can distinguish the user, as
	well as authenticate and authorize the request.		well as authenticate and authorize the request.
	3.6 Multicast Session Management for Accounting		3.7 Caching of AAA results
	The NSP should not manage multicast states on a subnet basis, but on		An NSP should be able to cache AAA results based an understanding
	a user basis because the NSP needs to notify start and stop times		between the NSP and a CP. The AAA cache would store information
	for accounting purposes. This means that the NSP sends an indication		about permissions of a specific user to receive multicast data from
	for Join and Leave on a user basis.		specified channel(s) up to specified expiration date(s) and time(s).
			If such caching is implemented, a method must exist for the CP to
			communicate this permission information to the NSP. The NSP refers
			to the AAA cache and if the cache indicates that the user has
			permission to receive multicast data from a specific channel at that
			time, the NSP may forward the data without querying the CP.
			It should be possible for a CP to send a directive to the NSP to
			refresh or change permissions for a user for specific channel(s).
			It is necessary for the NSP to requery the CP for authorization
			should a user be receiving content when the permission expires.
			It would be desirable to have a mechanism by which CPs could
			proactively push permission information to the cache even when not
			specifically queried by the NSP.
	4. Network Connection Model and Functional Components		4. Network Connection Model and Functional Components
	Section 3.1 introduces the high-level AAA framework for multicasting.		Section 3.1 introduces the high-level AAA framework for multicasting.
	This section provides more detail on the network connection model		This section provides more detail on the network connection model and
	and constituent functional components.		constituent functional components.
	4.1 Basic Connection Model		4.1 Basic Connection Model
	+-------------+		+-------------+
	| user |		| user |
	| |		| |
	+-------------+		+-------------+
	^ Access & Resource		^ Access & Resource
	| Request		| Request
	v		v
	+-------------+		+-------------+
	| NSP |		| NSP |
	| |		| |
	skipping to change at page 8, line 26		skipping to change at page 8, line 23
	| |		| |
	+-------------+		+-------------+
	^ Access		^ Access
	| Request		| Request
	v		v
	+-------------+		+-------------+
	| CP |		| CP |
	| |		| |
	+-------------+		+-------------+
	First a user desiring authorization sends an Access request to an		First a user desiring authorization sends an Access request to an NSP
	NSP which then forwards it on to the appropriate CP for		which then forwards it on to the appropriate CP for Authentication
	Authentication and Authorization. The CP responds with either		and Authorization. The CP responds with either "success" or
	"success" of "failure". If "success", the NSP may forward a success		"failure". If "success", the NSP may forward a success response
	response and stream multicast data to the user.		and 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.
	skipping to change at page 9, line 43		skipping to change at page 9, line 43
	| |		| |
	+-------------+		+-------------+
	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 NSP 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 NSP to connect to multiple TPs, and a single TP to
	multiple NSPs.		multiple NSPs.
	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 NSPs (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
	or more TPs.		more TPs.
	A solution will include a mechanism through which the NSPs know		A solution will include a mechanism through which the NSPs know which
	which TP(s) are to be used to communicate with which CP(s), and CPs		TP(s) are to be used to communicate with which CP(s), and CPs know
	know which TP(s) to use for which NSP(s). When a TP receives an		which TP(s) to use for which NSP(s). When a TP receives an access or
	access or resource request from an NSP or CP, it must relay the		resource request from an NSP or CP, it must relay the request to the
	request to the correct CP or NSP, respectively. Minimally, this		correct CP or NSP, respectively. Minimally, this means that it must
	means that it must reconstruct the request with translated address		reconstruct the request with translated address information. In this
	information. In this model therefore a TP must understand the		model therefore a TP must understand the format and meaning of the
	format and meaning of the requests.		requests.
	There may be multiple TPs between a NSP and CP so that a TP is		There may be multiple TPs between a NSP 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
	not directly from/to a NSP or CP.		directly from/to a NSP or CP.
	4.3 Transit with Tunnels		4.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 NSP and/or between the TP and the CP. So in this case
	case the TP will not directly need to process the contents of the		the TP will not directly need to process the contents of the access
	access and resource request (such as, header information), but		and resource request (such as, header information), but instead pass
	instead pass the request directly to the correct NSP or CP, using a		the request directly to the correct NSP or CP, using a separate
	separate protocol to wrap the original requests.		protocol to wrap the original requests.
	Below is a diagram, representing how a TP can provider tunneling		Below is a diagram, representing how a TP can provider tunneling
	between NSP(s) and CP(s).		between NSP(s) and CP(s).
	+-----------------+		+-----------------+
	| user |		| user |
	| |		| |
	+-----------------+		+-----------------+
	^ Access & Resource		^ Access & Resource
	| Request		| Request
	skipping to change at page 11, line 40		skipping to change at page 11, line 40
	| CP |		| CP |
	| |		| |
	| +---------+ |		| +---------+ |
	| | AAA | |		| | AAA | |
	| +---------+ |		| +---------+ |
	+------------------------------+		+------------------------------+
	In the fully enabled model the NSP provides proxying of		In the fully enabled model the NSP provides proxying of
	authentication and authorization between the NSP and CP, as well as		authentication and authorization between the NSP and CP, as well as
	user-based accounting. The AAA proxy server of the NSP communicates		user-based accounting. The AAA proxy server of the NSP communicates
	with the CP's AAA server. Although not show in the above diagram		with the CP's AAA server. Although not show in the above diagram for
	for the sake of simplicity, in addition to direct proxying between a		the sake of simplicity, in addition to direct proxying between a NSP
	NSP and CP, this proxying may be done through a TP. This means that		and CP, this proxying may be done through a TP. This means that the
	the transit provider too is able to support AAA proxying.		transit provider too is able to support AAA proxying.
	In the fully enabled model the NSP also includes a component that		In the fully enabled model the NSP also includes a component that
	provides network resource management (e.g. QoS management), as		provides network resource management (e.g. QoS management), as
	described in section 3.4, "Network Resource Management by NSP".		described in section 3.4, "Network Resource Management by NSP". When
	When a transit provider is used it may also provide Network Resource		a transit provider is used it may also provide Network Resource
	management of its own resources.		management of its own resources.
	4.5 Modularity of the framework		4.5 Modularity of the framework
	In the interest of flexibility, this framework is modular so that it		In the interest of flexibility, this framework is modular so that it
	is possible that partially enabled versions of the models are		is possible that partially enabled versions of the models are
	supported. A AAA-enabled version provides AAA functionality without		supported. A AAA-enabled version provides AAA functionality without
	Network Resource management. A Network-Resource-Management-enabled		Network Resource management. A Network-Resource-Management-enabled
	(QoS-enabled) version provides Network Resource management without		(QoS-enabled) version provides Network Resource management without
	AAA functionality. Similarly, the possibility of one or more layers		AAA functionality. Similarly, the possibility of one or more layers
	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.
	5. IANA considerations		5. IANA considerations
	This memo does not raise any IANA consideration issues.		This memo does not raise any IANA consideration issues.
	6. Security considerations		6. 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 should be protected in some way.		authentication with the CP should be protected in some way.
	Otherwise, this memo does not raise any new security issues which		Otherwise, this memo does not raise any new security issues which are
	are not already existing in the original protocols. Enhancement of		not already existing in the original protocols. Enhancement of
	multicast access control capabilities may enhance security		multicast access control capabilities may enhance security
	performance.		performance.
	7. Conclusion		7. 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
	service provider entities into their functional objects such as edge		provider entities into their functional objects such as edge devices,
	devices, AAA servers, etc.		AAA servers, etc.
	Normative References		Normative References
	[1] Hayashi, et. al., "Accounting, Authentication and Authorization		[1] Hayashi, et. al., "Accounting, Authentication and Authorization
	Issues in Well Managed IP Multicasting Services", draft-ietf-		Issues in Well Managed IP Multicasting Services", draft-ietf-
	mboned-maccnt-req-04.txt, February 2006, Work in Progress.		mboned-maccnt-req-04.txt, February 2006, Work in Progress.
	[2] Hayashi, et. al., "Issues Related to Receiver Access Control in		[2] Hayashi, et. al., "Issues Related to Receiver Access Control in
	the Current Multicast Protocols", draft-ietf-mboned-rac-issues-		the Current Multicast Protocols", draft-ietf-mboned-rac-issues-
	02.txt, March 2006, Work in Progress.		03.txt, April 2006, Work in Progress.
	Authors' Addresses		Authors' Addresses
	Hiroaki Satou		Hiroaki Satou
	NTT Network Service Systems Laboratories		NTT Network Service Systems Laboratories
	3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan		3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan
	Phone : +81 422 59 4683		Phone : +81 422 59 4683
	Email : satou.hiroaki@lab.ntt.co.jp		Email : satou.hiroaki@lab.ntt.co.jp
	Hiroshi Ohta		Hiroshi Ohta
	NTT Network Service Systems Laboratories		NTT Network Service Systems Laboratories
	3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan		3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan
	Phone : +81 422 59 3617		Phone : +81 422 59 3617
	Email: ohta.hiroshi@lab.ntt.co.jp		Email: ohta.hiroshi@lab.ntt.co.jp
	Tsunemasa Hayashi		Tsunemasa Hayashi
	NTT Network Innovation Laboratories		NTT Network Innovation Laboratories
	1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan		1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan
	Phone: +81 46 859 8790		Phone: +81 46 859 8790
	Email: hayashi.tsunemasa@lab.ntt.co.jp		Email: tsunemasa@gmail.com
	Haixiang He		Haixiang He
	Nortel		Nortel
	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
	skipping to change at page 14, line 13		skipping to change at page 14, line 13
	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		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on an
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	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.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed		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 ietf-
	ipr@ietf.org.		ipr@ietf.org.
	Expiration		Expiration
	This Internet-Draft will expire on October 6, 2006.		This Internet-Draft will expire on December 25, 2006.
	Acknowledgement		Acknowledgement
	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. 38 change blocks.
	124 lines changed or deleted		151 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/