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.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf