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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]