[RTG-DIR] RtgDir review: draft-ietf-mboned-maccnt-req-10.txt

[Geoff Huston <[e-mail]>]

Hello,

  I have been selected as the Routing Directorate reviewer for this
  draft. The Routing Directorate seeks to review all routing or
  routing-related drafts as they pass through IETF last call and IESG
  review, and sometimes on special request. The purpose of the review is
  to provide assistance to the Routing ADs. For more information about
  the Routing Directorate, please see
  http://www.ietf.org/iesg/directorate/routing.html

  Although these comments are primarily for the use of the Routing ADs,
  it would be helpful if you could consider them along with any other
  IETF Last Call comments that you receive, and strive to resolve them
  through discussion or by updating the draft.

Document: draft-ietf-mboned-maccnt-req-10.txt
Reviewer: Geoff Huston
Review Date: 9 May 2011
IETF LC End Date: 
Intended Status: Informational

Summary:

    I have some minor concerns about this document that I think should
    be resolved before publication.

Comments:

    The document tends to be narrowly focussed and while it considers
    one particular scenario in depth the reviewer was left wondering
    about all the other potential business scenarios regarding content
    delivery and AAA that the document does not note, even if to state
    that all such scenarios outside of this limited scope are not to be
    considered here.

Major Issues:

    I suppose the largest unanswered question is: Why is the AAA task
    for multicast content DIFFERENT than that used to allow the User
    access to the NSP's network in the first place? The draft appears to
    assume that there is a seperate multicast AAA enrolment going on
    here, but there is no motivation for this, and the reviewer is left
    wondering why there this appears to be distinct from the initial
    user authentication process for unicast network services. The text
    could do with some revision to explicitly address this
    consideration.


Minor Issues:

    In Section 4 I felt that the draft should note the limitations of
    the models considered here. Noteably, where the Content Providers do
    NOT directly connect to the same network as the end users of the
    content, then this draft does not address the business or technical
    requirements. Should it?  i.e. where users of service provider A
    attempt to connect content that is delivered from service provider B
    what guidance does this document offer?

    Also on page 12 Figure 3 is completely unreadable - perhaps it
    should be broken into a number of figures? The accompanying text is
    also unhelpful to decode the Figure. When the fogure is revised,
    this text would also be revised.

Nits:

page 1
   Because many
   services such as television broadcasting require huge bandwidth
   (e.g., 6Mbit/s) 

6Mbps is NOT "huge"   

   IP
   multicast is used as an efficient delivery mechanism for CDS.
   
s/is/may/   

page 2
   This memo lists the requirements of a business model in which the NSP
   provides CDS using multicast as one such contractible service.
   
please define "NSP" with the first use.

2.1.  Definitions

      Authentication: action for identifying a user as a genuine one.
      
is there a better term other than "genuine"? perhaps "correctly
identifying the end user"

      Authorization: action for giving permission for a user to access
      content or the network.

page 3

      User-based accounting: actions for grasping each user's behavior,
      when she/he starts/stops to receive a channel, which channel
      she/he receives, etc.
      
I have no idea what "grasping" is intended to mean in this context.

page 5

   In this model the networks for CDS contain three different types of
   entities: Content Provider (CP), Network Service Provider (NSP), and
   user clients.

please expand the acroynums on FIRST use only.


page 7


      With current protocols (IGMP/MLD), the sender cannot distinguish
      which receivers (end hosts) are actually receiving the
      information.  The sender must rely on the information from the
      multicasting routers.  This can be complicated if the sender and
      routers are maintained by different entities.  Furthermore, the
      current user associated with receiver must be identified.

What is the purpose of this paragraph? I thought that the section was
"Information Required by Entities to Support the Proposed Business Model"
and not part of the motivation section