Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s)
draft-ietf-mboned-maccnt-req-10

3.1  Accounting Issues
...
     In other words, the current standards do 
     not provide multicasting with authorization or access control 
     capabilities sufficient to meet the requirements of accounting. 
     ... 
     This is the major reason why multicasting is only used for cases 
     where no user-based accounting capabilities are necessary.    

This is a circular argument. It's perfectly reasonable to argue that
some multicast applications need AAA, but where is the evidence that
lack of IP-level AAA has been the blocking factor? 

I believe that the picture drawn in Fig. 2 is very restrictive.
The users need a AAA relationship with the content providers, but
it is not always correct to show the content providers inside
peer networks, with an NNI to the customers' NSP; they may well 
be outside all peer networks, with no network being part of the 
customer/provider relationship.

In summary I don't believe that this document describes generic
requirements; it describes requirements for a subset of deployment
models for which a network-based AAA solution may be appropriate.
Somehow this needs to be made clear in the title, abstract and
introduction.

Carrying forward Ted's discuss comment.

> However, multicasting 
> according to current standards (e.g., IGMPv3[1] and MLDv2[2]) has 
> drawbacks compared to unicasting when one applies it to commercial 
> services.  Accounting of each user's actions is not possible with 
> multicasting as it is with unicasting. 

This statement is not universally true. For instance,
in DSL or cellular or any other environment with a
point-to-point nature, it *is* possible to track
what each user does with multicast. More importantly,
however, there are application-level multicast
controls (such as access to the decryption keys)
that deal with the most pressing problems in
content delivery. Such tools appear to be
a much better fit to the problem at hand --
the ISP should be checking if they have a
subscriber X and whether that subscriber
is within his bandwidth limits, NOT whether
the subscriber is entitled to look at
football. This is the task of an application
provider. Of course, ISP and application provider
may exist in the same company... but marrying
the routing and forwarding technology to
end-to-end content authorization process
would make it impossible to separate them.

> The requirements defined in this memo apply to solutions that  
> provide user separation either through physical separation  
> provided by dedicated access media between the user and multicast 
> router  (see  Fig.  1) or else through logical separation in cases 
> of shared physical access media (e.g. using VLAN). However, IP 
> multicast solutions with shared Layer 2 access media between the 
> user and multicast router and no logical user separation (e.g. 
> Ethernet with shared links and no VLAN) are out of scope of this 
> memo. 
> ...
> With current protocols (IGMP/MLD), the sender cannot distinguish 
> which receivers (end hosts) are actually receiving the information.  

I do not understand why, given the scope, the first hop router
simply cannot look up which interface this message came from
and determine whether the customer behind that interface
is allowed to use multicast/this particular stream/this
much bandwidth?

> Since the CP and NSP are different business entities, they need to 
> share the revenue. 

That would be only one of the many business models. The
NSP could also be operating as a bit pipe, for instance.

Bernard Aboba provided a security directorate review as last call
comments.  I have not seen a response to these comments.  The issues
he raise seem serious and I'd like to see the WG's response before I
can fully evaluate this document.

The document says:

     In many commercial multicast situations, NSPs would like to be 
     able to precisely grasp network resource consumption and CPs would 
     like to be able to precisely grasp the content consumption by end-
     users.  Such information might be used for identifying highly 
     viewed content for advertising revenue, ratings calculations, 
     programming decisions, etc., as well as billing and auditing 
     purposes. Also content and network providers may wish to provide 
     users with access to their usage history. 

     To assemble such an understanding of end-user behavior, it is 
     necessary to precisely log information such as who (host/user) is 
     accessing what content at what time (join action) until what time 
     (leave action). 

The examples given (highly viewed content for advertising revenue, ratings calculations,
programming decisions) do not match necessarily match the need to track
this information by user.  These decisions are commonly made in other environments
based on aggregate data, which does not reveal individual user preferences.
This document  recommends this more extensive tracking rather than aggregrated data,
but it does not justify the more intrusive tracking.  If the authors wish to retain
this aspect of the recommendations, a section on privacy considerations should
be added to the security considerations.  Those should cover both authorization
models described in the follow-on sections.