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

[Hiroaki Sato <[e-mail]>]

Mark, Andy, Tom, Pat, Han, Doug,

Thank you for your response.
I respond inline.
We will reflect your comments on I-Ds.

Thank you,
Hiroaki

>
> 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)
>

We add above description to Section 8 " Concomitant requirements".

>> 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.
>
>

We add the new section "Support for reauthorization/ deauthorization "

>> 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])
************************************