Subject: Re: mboned: WGLC for draft-ietf-mboned-maccnt-req-02.txt

From: Hiroaki Satou <[email-masked]>
Date: Wed, 01 Feb 2006 15:04:06 +0900

Dear Carlos

Thank you for your comments.
Sorry this took a long time to reply.  It took awhile to coordinate 
text on our side.

In answer to your mail, for both the authorization and accounting and
requirements, the solution is supposed to be run only over dedicated
access media.  We will make this explicit by adding a new section to the
Problem statement.

3.3  Regarding Access Media

The requirements defined in this memo apply to solutions run only
over dedicated access media between the user and multicast router (see
Fig. 1). IP multicast solutions with shared access media between the
user and multicast router are out of scope of this memo. Nevertheless,
some of the requirements in this memo defined for multicasting over
dedicated access media may also be relevant to multicasting over shared
access media.  Therefore in the interest of modularity and flexibility,
solutions addressing the requirements of this memo may also take into
account their application to multicasting over shared access media.

Does this satisfactorily address your comments?

Thanks,

>This may be somewhat an "outsider" question, as I was not on previous
>draft discussions, but may be that's what you are asking for...
>
> From the reading the draft I am not sure what the requirements are in
>the case of shared access media to multicast (that is, the connection
>between the user and the multicast router is shared between some
>users), regarding to 4.(2.1) Access control, 4.(4) User authorization
>and 4(5) Accounting.
>The draft is clearly oriented to a dedicated access media, that is, a
>DSL acces or an Ethernet access connected to a switch/router. But the
>world still has some shared access media able to run IP multicast, be
>it Wireless LAN, the old 10Base2 or a non-routed, non-snooping
>Ethernet bridge.
>
>As IP multicasting over shared access media effectively makes user
>authorization only partially achievable (any user can listen the
>neighbour's channels, and even if denied the join would have access if
>a neighbour is granted access), I don't know if the requirement would
>be to:
>
>1) The solution is  supposed to be run only over dedicated access
>media. That is, this is a non-issue. In that case, maybe some mention
>about this should be done on the 3. Problem statement. It is only
>implicitly stated in figure 1.
>
>2) In the case of shared access media, the solution should do a
>best-effort solution to prevent unauthorized access, but will leave
>open the possibility that a non-conforming implementation would have
>access to some neighbouring multicasts by passive listening.
>
>3) In the case of shared access media, the solution should enforce
>that only authorised users can access the multicast content, barring
>users listening passively or actively from accessing multicasted
>content, be it via encryption o other means.
>
>Regarding accounting, the same three-pronged choices exists, being
>1) The solution is  supposed to be run only over dedicated access media.
>
>2) All users in a shared access media that request the same channel
>are counted as just one user.
>
>3) Each user joining the same channel in a shared access media should
>be accounted separately.
>
>I think the solution was thought for point 1), but it is not so
>obvious from the draft. Or perhaps "any of the above".
>
>Regards,
>Carlos.
>
>2006/1/13, Pekka Savola <[email-masked]>:
> > Thanks a lot Marshall!
> >
> > As a requirements document, this will have major impact on the
> > follow-on work.
> >
> > Please folks (if you aren't mentioned in the document's
> > Acknowledgements section, this means YOU too! ;-), take a quick look
> > at this NOW, so we know the requirements are good enough at this
> > point.
> >
> >
> > On Fri, 13 Jan 2006, Marshall Eubanks wrote:
> > > On Jan 7, 2006, at 3:52 AM, Pekka Savola wrote:
> > >
> > >> On Thu, 15 Dec 2005, David Meyer wrote:
> > >>> 
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-maccnt-req-02.txt
> > >>>
> > >>>     This Last Call will end on 29 Dec 2005 at 1400 PDT (UTC/GMT-7).
> > >>
> > >> (I waited for the WGLC to close before sending this..)
> > >>
> > >> I personally think the document is "good enough" at this 
> point, but I think
> > >> it still needs more eyeballs from the WG.  If we could get, for example,
> > >> two thorough reviews by members of the WG who haven't sent comments on it
> > >> in the past, I think the document could likely be much better off.
> > >
>
>_______________________________________________________________
>user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
>web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

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

---

From: Hiroaki Satou <[email-masked]>
Date: Wed, 01 Feb 2006 15:10:20 +0900

Dear Marshall

Thank you for your review and suggestions.Sorry for the amount of 
time it has taken us to respond.
I will respond inline.

 > ----------------------- Original Message -----------------------
 >  From:    Marshall Eubanks <[email-masked]>
  ...snip...
 >  Date:    Fri, 13 Jan 2006 11:34:46 -0500
 >  Subject: Re: mboned: WGLC for draft-ietf-mboned-maccnt-req-02.txt
 > ----

<snip>

 > Note that unicast does not in general restrict the ability to reach
 > customers, it just allows for such restrictions. That is an important
  ...snip...
 > AAA be as modular as possible, so that, e.g., accounting can be
 > offered without requiring authentication.

Thank you, we have added a bit to your suggestion.  What do you think?

When a CP requires the NSP to provide a level of QoS surpassing "best
effort" delivery or to provide special services (e.g., to  limited users
with specific attributes), certain parameters of the CDS may be defined
by a contractual relation between the NSP and the CP.  However, just as
for best-effort unicast, multicast allows for content sourced   by CPs
without a contractual relation with the NSP.  Therefore,  solutions
addressing the requirements defined in this memo should  not make
multicasting without AAA features obsolete. NSPs may offer tiered
services, with higher QOS,accounting, authentication, etc., depending on
contractual relation with the CPs. It is therefore important that
Multicast AAA and QoS functions be as modular and flexible as possible.

 > Another change :
 >
 > In Section 4 :
 >
 >       (4) User authorization
 >
 >       The network, at its option, should be able to authorize a user's
  ...snip...
 > licensed for distribution to certain countries), and, of course, a
 > mix of attributes may be required for eligibility or ineligibility.

OK, we propose adding the following to the definitions section, and
deleting "The definition of an "eligible user" should be discussed further":

Eligible user: Users may be eligible (permitted) to access resources
because of the attributes they have (e.g., delivery may require
possession of the correct password or digital certificate), their
equipment has (e.g., content may only be eligible to players that can
decode H.264 or 3GPP streams), their edge network has (e.g., HD content
may only be eligible to users with 10 Mbps or faster edge connections),
or because of where they are in network topology (e.g., HD content may
not be eligible for users across congested links) or in actual geography
(e.g., content may only be licensed for distribution to certain countries),
and, of course, a mix of attributes may be required for eligibility or
ineligibility.

Also thank you for the NITS.

<NITS snipped>

 > --------------------- Original Message Ends --------------------

Thank you

---

From: Carlos Garcia Braschi <[email-masked]>
Date: Wed, 1 Feb 2006 10:52:18 +0100

> Does this satisfactorily address your comments?

Yes, it does address them completely.

On a nit level, I'm not sure if the term "shared access media" is
self-evident and perhaps the second sentence could be "IP multicast
solutions with shared access media (like unencrypted WLAN or Ethernet
bridges) between the user and the multicast router are out of scope of
this memo". But for me it's difficult to say, as I started using the
term "access media" as the most obvious.

> Thanks,
Regards,
Carlos
--
Telefónica Empresas

---

From: Hiroaki Satou <[email-masked]>
Date: Fri, 03 Feb 2006 15:26:43 +0900

Dear Carlos

>term "access media" as the most obvious.

A shared L2 is out of scope but not shared case such as VLAN user 
separation is in scope.
So we will revise descriptions.

Thanks

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 26 Feb 2006 22:53:39 -0500

Hello;

Sorry for the delay in responding. I have no trouble with the new  
version and I support its publication.

Minor comments inline.

> Multicast AAA and QoS functions be as modular and flexible as  

I like this.

> and, of course, a mix of attributes may be required for eligibility or

This is fine.

> > --------------------- Original Message Ends --------------------

You are welcome. This document is on the whole very well written.

Regards
Marshall