Subject: mboned: comments on draft-ietf-mboned-rac-issues-01

From: Pekka Savola <[email-masked]>
Date: Sun, 6 Nov 2005 20:03:03 +0200 (EET)

substantial
-----------

4. Issues in multicasting related to commercial and large-scale
    implementations

==> do you describe ones here which aren't mentioned in the other document? 
Or important facts that weren't described there?   In the interest of
minimizing duplication, I'd suggest removing the whole section 4 from this
document and adding material if necessary to the other document.

5.2 IGMP/MLD plus L2/L3 Authentication with Access Control Policy

==> here you describe either Layer 2 or L3 authentication, but in many
places in the rest of the document you refer to this approach just as L2
auth (beginning with the figure in this section).

==> note that this approach can also be used separate from L2/L3 network
authentication (e.g., using PPPoE or 802.1x).  You could, for example, just
have NSP's or CPs provide a web service which would perform the ACL download
etc. features, right?  I'm not sure whether these two approaches are
different enough to warrant separating or not.

5.3 Unicast Control with IGMP/MLD

    The receiver first sends a unicast request to the sender which
    resides in the CP's domain.  This method is the same as that used in
    unicast video-on Vdemand (VoD) systems.  If authorization is
    successful the sender sends the multicast address information via
    unicast.

==> you don't describe this approach well enough, I think.  I don't see how
unicast control here could give the benefits you later describe.  After all,
the only thing the control server can give the user is the group address,
and this seems like security by obscurity (i.e., the user can inform his/her
friend about the group as well, and the friend would get free access)?
So, there's probably something you didn't describe here.

(If the
    interface is fixed to the receiver then the join-log can be used, but
    this would mean portability is sacrificed.  Moreover, this method is
    not applicable to a case where the CSP and NSP are different
    companies because CSP cannot access this join-log.)

==> I'm not sure what you mean with "interface is fixed ... but portability
is sacrificed".  You'll probably need to clarify that.  Note that sharing of
join log could be done with a yet-to-be defined standard mechanism/format
(you have this as a requirement in the reqs document)

    -IGMP/MLD with Unicast control :
    Even if a quick leave is possible, changing to a new channel using
    Unicast Control is slow (latency problem).

==> is this a problem in practice?  I'd suspect that a typical offering
would not be content specific, but that by paying for watching content X,
you'd be allowed to watch other (similar) content from the same provider as
well?  (well, I guess this depends on the service offering, but that's what
kind of service we have here in Finland)

    -L2/L3 authentication with access control policy:
    In this solution, the leave action is not recorded unless some
    additional mechanism such as IGMP/MLD snooping is used.  In some
    cases, users disconnect their terminals without sending leave
    messages.  In this case, it is not possible to determine when each
    user's entry in the ACL should be deactivated.

==> I don't think the latter is a problem.  MLD/IGMP reports/joins need to
be refreshed periodically.  The ACL entry can be deactivated if the user no
longer refreshes the report/join.

editorial
---------

    CSP: Content Service Provider

==> the other doc uses "CP", pick one which is used on both docs

The I-D
    draft-ietf-mboned-maccnt-00.txt provides more detail of the multiple
    versus single entity CDS network model.

==> make this as a reference in []'s.

    With a basic implementation of IGMP/MLD implementation, no

==> remove one "implementation"

    policy sever.  For example, users which are not on the ACL are

==> s/sever/server/

    point of attachment to the network, for example, using 802.X.

==> s/X/1x/

    unicast video-on Vdemand (VoD) systems.  If authorization is

==> remove an unprintable character (shows as 'V' above)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/