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

Summary: Needs a YES.

Lars Eggert No Objection

Alvaro Retana No Record

Benjamin Kaduk No Record

Erik Kline No Record

Francesca Palombini No Record

John Scudder No Record

Martin Duke No Record

Martin Vigoureux No Record

Murray Kucherawy No Record

Robert Wilton No Record

Roman Danyliw No Record

Warren Kumari No Record

Zaheduzzaman Sarker No Record

Éric Vyncke No Record

(Brian Carpenter; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2006-12-14 for -)
No email
send info
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.

(Chris Newman; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2007-09-13 for -)
No email
send info
Carrying forward Ted's discuss comment.

(Jari Arkko; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2006-12-14 for -)
No email
send info
> 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.

(Sam Hartman; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2006-12-14 for -)
No email
send info
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.

(Ted Hardie; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2006-12-13 for -)
No email
send info
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.

(David Kessens; former steering group member) Yes

Yes ( for -)
No email
send info

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ( for -)
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Mark Townsley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Bill Fenner; former steering group member) Abstain

Abstain (2006-12-13 for -)
No email
send info
Does this document reflect a WG consensus?

It mixes together QoS, AAA, etc. in ways that seem nonsensical; e.g., some of the examples say that the goal could be accomplished in unicast with RSVP; why can't you use RSVP in the exact same way for multicast, given that RSVP was designed to operate just as well with multicast as with unicast?

I agree with Brian's general sense that this doesn't seem like something that should be happening at layer 3, and with many of the questions of the AAA Reviewer.

I don't see a way to fix this, so I am abstaining.

(Cullen Jennings; former steering group member) Abstain

Abstain ( for -)
No email
send info

(Russ Housley; former steering group member) Abstain

Abstain (2006-12-14 for -)
No email
send info
  The authors did not respond to Bernard Aboba's IETF Last Call comments.

  I am concerned by the comments from Bill Fenner, Jari Arkko, and
  Brian Carpenter.