[Gen-art] Review: draft-ietf-mboned-maccnt-req-10

["Joel M. Halpern" <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-mboned-maccnt-req-10
     Requirements for Multicast AAA coordinated between
         Content Provider(s) and Network Service Provider(s)
Reviewer: Joel M. Halpern
Review Date: 22-April-2011
IETF LC End Date: 5-May-2011	
IESG Telechat date: N/A

Summary: This document is not ready for publication as an Informational RFC.

Top Line: This document seems to assume a very specific deployment and a 
specific set of tools from our repertoire.  It also tends to make 
assumptions about the solution that it envisions, which confuse the 
requirements statements.  As such, it needs significant work before it 
may be suitable for publication.

Major issues:
1) The document assumes a specific set of protocols are used, and are 
the only tools used, for handling the problem space.  IGMP / MLD is not 
our only tool, and the document should not be written as if it is the 
only tool.
----  This was noted in a 2006 Discuss comment! ----

1') The document says that it is about Requirements for AAA related to 
Multicast.  It then repeatedly dives into QoS issues.  Other than the 
quesiton of enabling the AAA to provide the QoS information (which is 
never discussed at all), QoS should not appear in this document.

There seem to be a number of cases in section 4 of assuming a solution, 
rather than stating the requirements.

2) After postulating a business model in which the network operator and 
the content provider are distinct, the requirements then assert that 
content distribution control is the network's job.  Enabling the content 
provider to ensure that only authorized users get content is the 
network's job.  But the methods for doing so should be left to the 
solution, not the requirements.  (And then makign the requirement a 
network option makes it even more confusing.)

3) The item on Sharing Program Data seems to have some sort of 
assumption about how information is managed.  Since I can easily 
envision architectures for the separation, which allow multicast, which 
do not required what the document calls "Shard Programming data", there 
seems to be a problem here.

4) In section 5, the documents appears to assume that the network must 
and needs to unilaterally decide whether to admit users to multicast 
trees.  It also states that this is needed for QoS protection.  Given 
the nature of multicast, both statements are likely misleading.

5) The last paragraph of section 5 seems to assert that the operator 
could choose not to deliver some multicast streams to some subscribers 
if this would adversely affect the QoS experienced by other users.  I 
think that there are serious problems with such an assertion appearing 
in an IETF informational document.

6) The section on concomitant requirements mixes items of a different 
nature together.  It has one item that really belongs in this document, 
namely scale.  It has one very confusing item, namely Small Impact on 
the Existing Product.  And the rest of the items in teh section do not 
belong in this document at all.

6') On the "Small Impact" item, given that different operators have 
deployed different solutions, using different pieces of technology, it 
seems very hard to define a solution that has "small" impact on all 
operators.

7) What is section 9?  Is it a diagram  of some existing deployment 
architecture?  Is it an effort to define a solution?  It does not define 
any requirements.

Minor issues:
1) I find the approach the document takes to its "requirements" 
ingenuous, and misleading.  The document is actually a proposal for a 
business model that it wants supported.  This business model includes 
well-respected notions, such as the separation of content providers from 
network operators.  it also includes assumptions about the charging 
basis for the service, and who needs what visibility to whom.  While 
these may indeed be accurate assumptions, treating them as givens, on 
the basis of which a set of requirements can be asserted, seems 
inappropriate.

2) There is a related implicit assumption that individual user usage is 
somehow related to overall network consumption.  The whole point of 
using multicast is to avoid that coupling, i.e. the increase in network 
consumption is much lower than the increase in user consumption.

3) The paragraph in section 5 on the user edge stream join admissions 
seems to be about a particular view of how an operator would deliver 
suitable QoS to a subscriber.  This seems to assume certain 
relationships between the user's requests and the operators network, and 
certain operational behaviors.  They may or may not be accurate.  They 
also appear to be a local matter, having nothing to do with the rest of 
the document.

4) Given that section 6 calls for a method for deauthorization, it seems 
that there should be some additional explanation of why reauthorization 
is needed.  This also leads to the question of whether we are expecting 
the network to enforce the cotnent providers charging relationships with 
the end user, including expiration of prepaid quanta, and other 
complexities that are better left purely to the content provider.  A 
pure deauthorization model would seem sufficient.)

5) I do not understand what section 7, on performance requirements, is 
doing in thsi document.  It has a lot to do with whether a given network 
architecture is suitable for a given content provider's desired end 
customer interaction.  But it has nothing to do with the accounting or 
customer identification problems that this document says that it deals with.

Nits/editorial comments:
The document style does not make clear what the actual requirements are.