Re: [MBONED] I-D ACTION:draft-ietf-mboned-maccnt-req-08.txt

["ALTOM, MARK W (ATTLABS)" <[e-mail]>]

Hiroaki,
Thank you for your comments.  Our responses are inline.
Please let us know if you have questions or if you need 
additional details.

Thanks,
Mark Altom
Andy Huang
Tom Imburgia
Pat McCrink
Han Nguyen
Doug Nortz
AT&T Labs
(Contact Mark Altom: [e-mail]; [phone])

-----Original Message-----
From: Hiroaki Sato [mailto:[e-mail]] 
Sent: Thursday, February 18, 2010 7:06 AM
To: ALTOM, MARK W (ATTLABS)
Cc: [e-mail]
Subject: Re: [MBONED] I-D ACTION:draft-ietf-mboned-maccnt-req-08.txt

Mark,

Thank you for your draft review and feedback.  I will respond inline.

Hiroaki

>
> The following are our comments on "Requirements for Multicast AAA
> coordinated between Content Provider(s) and Network Service
> Provider(s)(draft-ietf-mboned-maccnt-req-08)"
>
> 1. A requirement should be added that the AAA mechanisms that are
> specified should be applicable to AMT multicast as well as end-to-end
> native multicast.
> http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-09
>

-> We are open to including the requirements for AMT to the document but

-> are not ourselves familiar with AMT.  Would anyone from your team be 
-> willing to write the requirements and become a coauthor of ID-maccnt?

The following is suggested wording for a requirement that the AAA 
Mechanisms should also apply to AMT multicast.  The requirement 
could be included in section 7, "Concomitant Requirements."

Support for Tunneled Multicast
The AAA requirements specified in this document should apply to both 
end-to-end native multicast and to tunnel-enabled multicast, such as
AMT multicast: 
(http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-09)

> 2. How do you "unauthorize" an end user after the end user has been
> authenticated and authorized to join a multicast stream?  For example:
>
> 	* An end-user may only be authorized to join a multicast stream
> for a specific amount of time.  How do you drop a user from the stream
> when the user has "timed out?"
> 	* An end-user may be authorized to access only a certain amount
> of content.  How do you drop a user from the stream when the user has
> exceeded the specified amount of content?
>
> This suggests that at a minimum, the elements to authorization should
> include:
> 	* Stream (S,G or *,G)
> 	* Time
> 	* Bandwidth or amount of content
>

-> We will add requirements for unauthorize by timeout
-> We think bandwidth overflow and exceeding max number of channels can
be 
-> rejected at 1st Join.

A scenario that we were considering for unauthorizing an end-user is one

where an end-user has a subscription or has paid for a certain amount of

content (e.g., 1 Gb of content).  What happens if the end-user reaches 
such a limit, while the end-user has already joined a multicast stream?

Could the end-user be unauthorized while in the middle of a stream based

on reaching a preset amount of downloaded content as well as reaching a 
time limit?  Perhaps the mechanism for periodic re-authorization could
be
used in this case.


> 3. Are there any mechanisms for re-authentication and
re-authorization?
>

-> We agree this is necessary and will add the requirements for 
-> re-authentication.

> 4. Section 3 is titled "Current Business Models," but only 2 business
> models are described:
>
> 	* A single entity model where CP (Content Provider) and NSP
> (Network Service Provider) are the same entity
> 	* Multiple entity model without direct content-based billing
>
> However, these are not the only current business models.  Maybe a
better
> title for section 3 is "Common Business Models."
>

-> Agreed, we will change the title to "Common Business Models".

> 5. Section 4 describes a proposed model with direct billing of the end
> user.  However, the proposed AAA mechanisms would also be applicable
to
> scenarios where the CP or NSP wants to restrict access, but does not
> necessarily require direct billing of the end user (for example
support
> for closed user groups).
>

-> We will change the section title to "Proposed Model: Multity-entity 
-> CDS"  and explain that there are cases with and without direct
customer 
-> billing.

> Please let us know if you have questions or if you need additional
> details.
> Thanks,
> Mark Altom
> Andy Huang
> Tom Imburgia
> Pat McCrink
> Han Nguyen
> Doug Nortz
> AT&T Labs
> (Contact Mark Altom: [e-mail]; [phone])
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
Behalf
> Of [e-mail]
> Sent: Wednesday, January 14, 2009 1:30 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [MBONED] I-D ACTION:draft-ietf-mboned-maccnt-req-07.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the MBONE Deployment Working Group of the
> IETF.
>
> 	Title		: Requirements for Multicast AAA coordinated
> between Content Provider(s) and Network Service Provider(s)
> 	Author(s)	: H. Ohta, H. Satou, S. Vaidya, T. Hayashi, H.
> He
> 	Filename	: draft-ietf-mboned-maccnt-req-07.txt
> 	Pages		: 23
> 	Date		: 2009-1-12
> 	
> This memo presents requirements in the area of accounting and
>       access control for IP multicasting.  The scope of the
>       requirements is limited to cases that Authentication,
>       Accounting and Authorization (AAA) functions are coordinated
>       between Content Provider(s) and Network Service Provider(s).
>       General requirements for accounting and admission control
>       capabilities including quality-of-service (QoS) related issues
>       are listed.  This memo assumes that these capabilities can be
>       realized by functions implemented at edges of a network based
>       on IGMP or MLD.  Finally, cases for Content Delivery Services
>       (CDS) are described as application examples which could benefit
>       from multicasting accounting and access control capabilities as
>       described in this memo.
>
>       This memo defines requirements related to AAA issues for multi-
>       entity provider models in which the network service provider and
>       content provider cooperate to provide CDS and various related
AAA
>       functions for purposes such as protecting and accounting for the
>       access to content and network resources.  The requirements are
>       generally not relevant to cases in which there is not a reason
to
>       share AAA functions between separate entities.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-mboned-maccnt-req-07.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned
>
>
>


-- 
************************************
NTT Network Service Systems Lab.
Hiroaki Sato
TEL:[phone] ([phone])
FAX:[phone] ([phone])
************************************