Subject: Re: mboned: l-D: Access Right Distribution Protocol (ARDP)

From: Toerless Eckert <[email-masked]>
Date: Tue, 28 Mar 2006 08:23:19 -0800

a couple of unrelated comments/questions:

1. I have no insight into which working group would be best to discuss this
   draft. I always thought Mboned is more for operational questions, and this
   draft looks like an explicit protocol proposal.

2. What is your expectation in bringing this to the IETF ?
   Like "i would like to have more DSLAM vendors that support this" ?

3. It's nice to see that your protocol already supports SSM for the
   actual TV channels, but if it where for me, then i would say that it should
   also support SSM for it's own distribution of data. Today you only
   specify a TV operator assigned MCAST group instead of TV operator assigned
   SSM channels.

4. On the same notion of supporting IETF standards, i bet someone will
   raise the need to support IPv6 also ;-) But hey, those type of
   generic extensions are what you should expect from the IETF ;-))

5. I personally always like consumer driven systems, but that's of course
   primarily because the web was such a success in giving consumers the
   freedom to choose their content by themselves. In your protocols model
   it is still the operator himself that needs to populate the system with
   explicitly known TV-operators, so it can not be driven by consumers
   learning about new TV programs they can (however) subscribe on, eg:
   the web through their STB and then receive them. I think it would be great
   if the protocol could be extended such that it can auto-provision
   in the face of new TV operators.

6. The protocol very strongly focusses on the DSLAM as the device to
   enforce access rights. I think if this is to be passed to the IETF,
   then this needs to be made more flexible. Not only is the DSLAM
   not always the last replication and thus control point (for example
   in VDSL deployments, the last replication point can easily be the
   access-switch on top of the DSLAM), but there are also protocol
   proposal such as L2CP to suggest putting the policy decision for
   multicast flow replication into such devices connecting to the DSLAM.

   In addition, i see absolutely no reason to engage in an effort to define
   such protocol unnecessarily only for DSL, if it can as well apply
   to also FTTx or even IPTV over docsis/cable. It's not even necessary
   to specify explicitly any such access technologies as long as the
   text does not try to be specific to just one of them. The best would be
   to really reword the appropriate sections of the text to indicte 
   solely that the client side of this application needs to be placed on
   a network element such that it can cause control of per-subscriber
   replication of the TV channels. That's it. No mentioning of DSLAM or
   the like in the normative section. The typical DSLAM usage case could
   be a good example deployment section though.

7. With all the information transmitted by this protocol it's really
   borderline EPC as well. Eg: Why not consider that the enforcement
   point can also act as a proxy to forward the per-subscriber information
   to that subscriber ? Just wondering whether this would allow to
   improve consistency between this type of EMM and the EBD data a
   STB has. After all, there's no signalling from the enforcment point to
   the STB if access control inhibits a TV program...

Cheers
    Toerless
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Alexandre Cassen <[email-masked]>
Date: Tue, 28 Mar 2006 19:17:58 +0200

>    Like "i would like to have more DSLAM vendors that support this" ?

my expectation is: we are currently running this protocol in production
(for 2years now over thousand of DSLAMs) to distribute our customers
TVoDSL access rights, I just/simply want to share this protocol and
request IETF experts feedback. THIS IS NOT A COMMERCIAL approach at all.
I just think this can be interresting for other people playing around
with kind of distributed authentication and people at IETF can bring new
ideas and/or fix/extend some thought we had... nothing else...

>    specify a TV operator assigned MCAST group instead of TV operator assigned

extension :)

>    generic extensions are what you should expect from the IETF ;-))

this is a very first draft attent :)

>    in the face of new TV operators.

This is not explicit in the document, but for TVoDSL system we
differenciate Set-Top-Box presentation interface from video stream
content (in our approach). I mean, a TV Operator manages its own
Assigned Mcast Group and streams, but it is responsibile to present to
customer for new programs/interactivity. Typically Set-Top-Box request
to TV Operator webserver for 'presentation content' (formerly HTML),
ARDP Access right provision must be done according to this presentation
=> TV service plane and TV Operator Webserver MUST be in adequation.

>    multicast flow replication into such devices connecting to the DSLAM.

sure you r right, it can be used on any equipments in charge with
multicast subscription management.

>    be a good example deployment section though.

definately agreed... :)

>    the STB if access control inhibits a TV program...

If we consider that STB doesn't have any smartcard and point of presence
into ARDP private plane (only upper equipment (DSLAM;)), has a presence
into this network). Physically there is no link between STB
signalization plane and ARDP plane to prevent against any kind of
malformed injection, that way enforcment point doesn't exist at all. The
point is, if you can't receive mcast streams then you can't enforce it
potential content scrambling (DVB-CSA), so you can potentially find EMM
related stuff to de-scramble stream only if you are allowed by ARDP to
receive that stream which is much more a commercial/politic
consideration than a security one.

Thanks a lot for your feedback,
Alexandre