Re: [MBONED] I-D Action:draft-ietf-mboned-multiaaa-framework-10.txt

[Hiroaki Sato <[e-mail]>]

Mark,

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

Hiroaki

>
> Hiroaki,
> Here a few notes that we had on AAA and Admission Control Framework for
> Multicasting (draft-ietf-mboned-multiaaa-framework-10).
>
> 1.  Is there a mechanism to prevent the sharing of authorization (e.g.,
> sharing an S,G among end users)?
>

-> Our assumption is that the NSP identifies the user on L2 (such as 
VLAN or PPP) And it would be
problematic for NSP if more than two receivers for the same user 
accessed the same channel and one
is accepted but the other is rejected on L2 or L3.   Prevention of 
unauthorized content sharing could be
handled on the application layer by the CP: e.g. could distinguish among 
receivers and distribute encryption
keys so that non-authorized receivers can not make use of the content.

Do you have any ideas related to preventing the sharing of 
authorization?  Do you have any proposals of
how the NSP might effectively distinguish among receivers on the same 
line (is it necessary)?

> 2.  Section 4.1.1 states that "...NSP will forward multicast traffic
> towards the user only when the NSP has 1) made sure the user is entitled
> to access the network resources operated by the NSP, 2) received a
> confirmation from the CP that the user is entitled to access the content
> and (possibly) 3) determined that the network resources (e.g.,
> bandwidth) are sufficient to deliver the multicast traffic to the user
> with the relevant level of quality."  When the third condition is not
> satisfied and an end-user is prevented from joining the multicast
> stream, should the CP be notified as part of accounting?
>

-> Content delivery starts after 2 conditions are met 1) the CP confirms
authorization and NSP confirm admission control (possibly including
network resource check, etc.)
Our assumption is that NSP will send an accounting start notification
once the traffic delivery starts. Therefore as the draft is now no
notification would be sent in the case of access being denied because of
access resource issues. Do you think a notification in the third case
should be included?


> 3.  The heading to Section 4.1.3 is incorrect.  It should be "A single
> CP is connected to multiple NSPs."
>

->It's a typo. we will correct it.

> 4.  On page 19, the reference in the text to Figure 3 should be to
> Figure 4.  The text should read:  "In the fully enabled model (Figure 4)
> resource management and admission control is provided by MACF (Multicast
> Admission Control Function)."
>

->It's a typo. we will correct it.

> 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 Hiroaki Sato
> Sent: Wednesday, August 05, 2009 1:07 AM
> To: [e-mail]
> Subject: Re: [MBONED] I-D
> Action:draft-ietf-mboned-multiaaa-framework-10.txt
>
> Marshall and all,
>
> I submitted the muliticast AAA framework draft.
> As I said at IETF75, we just extend the expire date and the cotent is
> not changed.
> We'd like chairs to check it again as Marshall told at the mboned
> meeting.
>
> Thank you
> Hiroaki
>
>> 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           : AAA and Admission Control Framework for
> Multicasting
>> 	Author(s)       : T. Hayashi, et al.
>> 	Filename        : draft-ietf-mboned-multiaaa-framework-10.txt
>> 	Pages           : 22
>> 	Date            : 2009-08-04
>>
>> IP multicast-based services, such as TV broadcasting or
>> videoconferencing raise the issue of making sure that potential
>> customers are fully entitled to access the corresponding contents.
>> There is indeed a need for service and content providers to identify
>> users (if not authenticate, especially within the context of
>> enforcing electronic payment schemes) and to retrieve statistical
>> information for accounting purposes, as far as content and network
>> usage are concerned.  This memo describes the framework for
>> specifying the Authorization, Authentication and Accounting (AAA)
>> capabilities that could be activated within the context of the
>> deployment and the operation of IP multicast-based services.  This
>> framework addresses the requirements presented in "Requirements for
>> Accounting, Authentication and Authorization in Well Managed IP
>> Multicasting Services" [I-D.ietf-mboned-maccnt-req].  The memo
>> provides a basic AAA enabled model as well as an extended fully
>> enabled model with resource and admission control coordination.
>>
>> A URL for this Internet-Draft is:
>>
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework
> -10.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])
************************************