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

From: Hiroshi Ohta <[email-masked]>
Date: Wed, 04 Jan 2006 17:24:16 +0900

Marshall,

Thank you very much for your review and your comments for
draft-ietf-mboned-maccnt-req-02.txt.

To address your concern related to the "well-managed IP multicasting"
terminology we would like to propose replacing the current last paragraph
of section 1 with the following text:

  This I-D will present general functional requirements related to
  accounting, authentication and authorization issues in IP multicasting
  networks. A multicast network which fulfills all of these requirements
  will be called a "fully AAA enabled" IP multicasting network.
  Fulfillment of all or some of the requirements will make possible more
  robust management of IP multicasting networks, and as such these
  capabilities contribute to the provision of well-managed IP
  multicasting services.

Does this satisfactorily address your concerns? 

Does anyone else have any feelings related to this?

And, thank you for your checking as below.

>Nit : On Page 10 :
>
>Another contract is between the CP and end
>     user to permit the user to subscribe multicast content.
>
>s/to subscribe/to subscribe to/

Best regards,

Hiroshi

At 13:38 05/12/29 -0500, Marshall Eubanks wrote:
>Hello;
>
>I read through this document thoroughly. It is very well written,  
>free of errors as far as I can tell
>(I have one comment and one nit), and gives a very complete  
>description of the requirements around multicast AAA in a business  
>environment.
>
>I fully believe this document is ready to go to the IETF.
>
>Comment : In the Introduction it says,
>
>     This I-D will present general functional requirements related to
>     accounting, authentication and authorization issues in IP
>     multicasting networks, and a multicast network which fulfills  
>these
>     requirements will be called a "well managed" IP multicasting
>     network.
>
>But it is clear that not all situations will need everything in this  
>document. This is mentioned towards
>the end on page 13
>
>     Another application example is the case where the content provider
>     (CP) and network service provider (NSP) are the same entity
>     (company) as shown in Fig. 3.  In the case that the CP and NSP are
>     the same entity, some of the requirements indicated in 4.1 are not
>     required.
>
>
>but also, in some cases NSP's and CP's may decide that they do not  
>need or want certain requirements - for example, a multicast video  
>system at a University, such as the U. of Wisconsin DATN
>
>http://datn.wisc.edu/about/ , may feel that in a University  
>environment there is no  need to implement
>DRM related authentication, or that authentication might be better  
>done using existing protocols.
>
>The point I would like to make is that calling these systems not  
>"well managed" because they chose to forgo
>or do not need certain aspects of the complete AAA system is likely  
>not to be well received.
>
>I would suggest that the author's consider either changing the term  
>("Fully AAA Enabled" would be more accurate)
>or allow for partial implementations to be considered "Well Managed".
>
>Nit : On Page 10 :
>
>Another contract is between the CP and end
>     user to permit the user to subscribe multicast content.
>
>s/to subscribe/to subscribe to/
>
>Regards
>Marshall Eubanks
>
>
>On Dec 16, 2005, at 12:46 AM, David Meyer wrote:
>
>>        Folks
>>
>>        This note starts the WG Last Call for comments on
>>        draft-ietf-mboned-maccnt-req-02.txt, "Requirements for
>>        Accounting, Authentication and Authorization in Well
>>        Managed IP Multicasting Services".  It can be found on
>>        
>>        http://www.ietf.org/internet-drafts/draft-ietf-mboned-maccnt- req-02.txt
>>
>>        The document's proposed status is Informational.
>>
>>        Please review the document carefully, and send your
>>        feedback to the list.  Please also indicate whether or
>>        not you believe that this document is ready to go to the
>>        IESG.
>>
>>        This Last Call will end on 29 Dec 2005 at 1400 PDT (UTC/GMT-7).
>>
>>        Thanks,
>>
>>        Dave
>>
>>
>>
>>
>>
>>
>>

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

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 4 Jan 2006 17:17:26 -0500

Dear Hiroshi;

On Jan 4, 2006, at 3:24 AM, Hiroshi Ohta wrote:

> multicasting

> Does this satisfactorily address your concerns?

Yes, it does. I assume that you keep the rest of the text as is,  
which means that the
the full set of services constitute a "well managed" IP multicasting  
service, without implying that
other networks are not well managed.

My understanding, by the way, is that for an editorial, as opposed to  
a technical, change such as this,
it is not necessary to redo the last call process. I certainly do not  
feel that it is. I am sure that the
AD can advise us on that.

>> s/to subscribe/to subscribe to/

Regards
Marshall

---

From: Hiroshi Ohta <[email-masked]>
Date: Thu, 05 Jan 2006 19:55:17 +0900

Dear Marshall,

Thank you for your response.

>other networks are not well managed.

Yes, you are right.  My proposal is to modify that paragraph 
only and keep the rest of the I-D.

>AD can advise us on that.

I appreciate guidances from Dave or the AD.

Thank you.

Hiroshi

At 17:17 06/01/04 -0500, Marshall Eubanks 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).
>>>>
>>>>       Thanks,
>>>>
>>>>       Dave
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>

---

From: David Meyer <[email-masked]>
Date: Thu, 5 Jan 2006 08:39:43 -0800

> I appreciate guidances from Dave or the AD.

	This can be fixed in AUTH48, so no need to repsin
	it. However, IMO, its useful to get a more final version
	on the I-D repository before sending to the IESG, since
	the same issues may come up during IESG review. My advice
	is to issue another revision.

	Dave

---

From: David Kessens <[email-masked]>
Date: Fri, 6 Jan 2006 18:13:28 -0800

> 	is to issue another revision.

I agree with Dave. See below for a bit of background on my view as an
AD on issues like this:

It is always possible to fix editorial problems in the AUTH48 stage.
However, you have to realize that people like IETF last call
reviewers, the general area review team, the full IESG and the RFC
editor will all stumble over the same issue. They are all going to
find these errors and report them which easily diverts attention from
the actual technical content from the draft. In addition, for many
reviewers, lots of editorial problems often serve a bit as a red flag
as one can easily suspect that a document did not get the kind of
review that one expects from an IETF document. And finally, I believe
that it is best to have the fewest possible changes happening late in
the process so that the document is as close as possible to what the
working group actually intended to get published. To summarize: it is
your document and it is your responsibility to get it in the best
possible shape as opposed to letting the rfc editor do the writing.

As you say, it is indeed not necessary to have a new working group
last call for minor editorial changes. It is up to the chairperson to
make a judgement on what minor is and/or whether a chairperson for
example potentially wants to give a few extra days to the working
group in the form of a mini last call. Basically, we expect
(chair)people to use common sense as opposed to making this a huge
bureaucratic nightmare ;-).

I hope this helps,

David Kessens
Operations and Management AD
---
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Pekka Savola <[email-masked]>
Date: Sat, 7 Jan 2006 10:52:29 +0200 (EET)

On Thu, 15 Dec 2005, David Meyer wrote:
> 	http://www.ietf.org/internet-drafts/draft-ietf-mboned-maccnt-req-02.txt
>

(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.

-- 
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/

---

From: Hiroshi Ohta <[email-masked]>
Date: Mon, 09 Jan 2006 23:13:24 +0900

Dave (Kessens), Dave (Meyer) and mboned members,

Thank you very much for your guidance.  I fully understand.  I 
just submitted a revised version of the I-D (-03.txt version).  
I assume this will appear shortly at:

http://www.ietf.org/internet-drafts/draft-ietf-mboned-maccnt-req-03.txt

In addition to reflecting Marshall Eubanks comments we have 
made a few other editorial changes as described below:

1) Abstract
  deleted the following sentence because the corresponding sentence no
longer exists in the body:
  "This I-D assumes that these capabilities can be realized by functions
implemented at edges of a network based on IGMP or MLD."

2) Section 1 
   To reflect Marshall's comments, edited what was originally the last
paragraph, moved it to the beginning of the section, replacing the
original first paragraph which was deleted because it was redundant.

3) Section 4
   Changed subtitle section 
    old: "General functional requirements for well managed IP
multicasting" 
     -->
    new:"General AAA-related functional requirements for IP
multicasting "

4) Section 4, item (2.2)
delete the extraneous word "both"
old: "The network may need to control the combined bandwidth for all
groups both at the physical port of the edge router or switch so that
these given physical entities are not overflowed with traffic."
-->
new: "The network may need to control the combined bandwidth for all
groups at the physical port of the edge router or switch so that these
given physical entities are not overflowed with traffic."

5) Subsection 5.1.1

6) Section 6
Merged the second "acknowledgement" at the very end of this I-D 
into this section, i.e., moved the following sentence into section 6:

"Funding for the RFC Editor function is currently provided by 
the Internet Society."

7) Conclusion
deleted the following sentence because the corresponding sentence no
longer exists in the body:
"with the goal of finding a solution implemented at edges of the network
based on IGMP or MLD."

Thank you,

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 9 Jan 2006 12:12:48 -0500

I will read this draft as soon as I can, at least to check these  
changes. Can you send it to me ?

Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 13 Jan 2006 11:34:46 -0500

On Jan 7, 2006, at 3:52 AM, Pekka Savola wrote:

> 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.

Ask, and ye shall receive.

Pekka asked for some more thought about this, so I read the document  
again. I found a few more nits (bottom), and there are two places I  
think need some more text (provided).

This is an important document, and I agree with Pekka that the WG  
should focus attention on it.

Here is the goal of this work :

      As such, the same level of user-based accounting capabilities as
      provided in unicast networks should be provided in multicast
      networks.

I think that this is absolutely  necessary, I have had people request  
this, and
so I think that this work is necessary and should be pursued.

Since MBoneD does not do protocols, I wonder if this will require a  
new WG in due course ?

Note that unicast does not in general restrict the ability to reach  
customers, it just allows for such restrictions. That is an important  
point. At times, I think that the author's may be thinking  
exclusively in terms of "walled gardens." Given that multicasting  
should allow (and Zipf's law suggests that there is demand for)  
literally 100,000's of channels, I think that any Multicast AAA must  
have the potential to co-exist with sources from outside the walled  
garden.

I know, for example, that I would love any accounting I can get for  
my streams, but I am not in general going to pay for it in advance.  
So, in Section 12

      (12) Small impact on the existing products

      Impact on the existing products (e.g., protocols, software, etc.)
      should be as minimal as possible.

      Ideally the NSP should be able to use the same infrastructure  
(such
      as access control) to support commercial multicast services for  
the
      so called "triple play" services: voice (VoIP), video, and
      broadband Internet access services.

I would add a paragraph as follows :

Just as for unicast, multicast allows for content sourced by CPs  
without a contractual relation with the NP. While NP's may chose to  
limit access to their networks, the Multicast AAA design should not  
inherently limit the ability of unsupported content to reach the  
consumer. NP's may also offer tiered services, with higher QOS,  
accounting, authentication, etc., for CPs with contracts, or with  
higher level contracts, and it is therefore important that Multicast  
AAA be as modular as possible, so that, e.g., accounting can be  
offered without requiring authentication.

Another change :

In Section 4 :

      (4) User authorization

      The network, at its option, should be able to authorize a user's
      access to content or a multicast group, so as to meet any demands
      by a CP to prevent content access by ineligible users.  In the  
case
      that the NSP may wish to provide a service based on guaranteed
      delivery, the NSP would not want to waste its network resources on
      ineligible users.  Eligibility can be defined in several ways.   
The
      definition of an "eligible user" should be discussed further.

I had missed the missing text. I do not see how you can get out of  
last call with missing text, so here is a suggestion.

Replace :

The definition of an "eligible user" should be discussed further.

With

Users may be eligible because of 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.

Regards
Marshall

-------- Nits follow -------

Nit Page 1 (also page 14) :

6. Acknowledgements.............................................15

s/Acknowledgements/Acknowledgments/

Nit :

3.1  Accounting issues

      In unicast communications, the server (information source) can
      identify the client (information receiver) and only permits
      connection by an eligible client when this type of access control
      is necessary.  In addition, when necessary, the server can grasp
      what the client is doing (e.g., connecting to the server, starting
      reception, what information the client is receiving, terminating
      reception, disconnecting from the server).

      On the other hand, in multicast communication with current
      standards (e.g., IGMPv3[1] or MLDv2[1]) the server just feeds its

s/MLDv2[1]/MLDv2[2]/

Nit : Page 6

      The network should be able to apply necessary access controlling
      actions when an eligible user requests.  The network should be  
able

s/requests/requests an action (such as a join or a leave)/

      to reject any action requested from an ineligible user.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 13 Jan 2006 18:49:14 +0200 (EET)

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:
>> 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.
>
> Pekka asked for some more thought about this, so I read the document again. I 
> found a few more nits (bottom), and there are two places I think need some 
> more text (provided).
>
> This is an important document, and I agree with Pekka that the WG should 
> focus attention on it.
>
> I think that this is absolutely  necessary, I have had people request this, 
> and
> Since MBoneD does not do protocols, I wonder if this will require a new WG in 
> due course ?
>
> customers, it just allows for such restrictions. That is an important point. 
> At times, I think that the author's may be thinking exclusively in terms of 
> "walled gardens." Given that multicasting should allow (and Zipf's law 
> suggests that there is demand for) literally 100,000's of channels, I think 
> that any Multicast AAA must have the potential to co-exist with sources from 
> outside the walled garden.
>
> I know, for example, that I would love any accounting I can get for my 
> streams, but I am not in general going to pay for it in advance. So, in 
> Section 12
>
>    Ideally the NSP should be able to use the same infrastructure (such
>    as access control) to support commercial multicast services for the
> Just as for unicast, multicast allows for content sourced by CPs without a 
> contractual relation with the NP. While NP's may chose to limit access to 
> their networks, the Multicast AAA design should not inherently limit the 
> ability of unsupported content to reach the consumer. NP's may also offer 
> tiered services, with higher QOS, accounting, authentication, etc., for CPs 
> with contracts, or with higher level contracts, and it is therefore important 
> that Multicast AAA be as modular as possible, so that, e.g., accounting can 
> be offered without requiring authentication.
>
> Another change :
>
> In Section 4 :
>
>    (4) User authorization
>
>    by a CP to prevent content access by ineligible users.  In the case
>    ineligible users.  Eligibility can be defined in several ways.  The
> I had missed the missing text. I do not see how you can get out of last call 
> with missing text, so here is a suggestion.
>
> Replace :
>
> Users may be eligible because of 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.
>
> Regards
> Marshall
>
>    actions when an eligible user requests.  The network should be able
>

---

From: Carlos Garcia Braschi <[email-masked]>
Date: Fri, 13 Jan 2006 19:48:26 +0100

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.

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 13 Jan 2006 14:57:55 -0500

Here is another thing relevant to MBoneD and  draft-ietf-mboned- 
maccnt-req

There is a L3VPN multicast requirements draft in last call,
draft-ietf-l3vpn-ppvpn-mcast-reqts-03

You can find my comments and corrections
on this document at

http://www.americafree.tv/papers/draft-ietf-l3vpn-ppvpn-mcast- 
reqts-03-tme.txt

1.) I would urge MBoners to look at this draft.

2.) These two requirements documents need to coexist. The Multicast  
AAA of draft-ietf-mboned-maccnt-req
needs to operate over M-VPNs. I have not settled in my mind
which document needs a sentence stating this, but one does.

Regards
Marshall

---

From: Hiroaki Satou <[email-masked]>
Date: Fri, 20 Jan 2006 16:09:10 +0900

Marshall

Thank you for getting the discussion started on rechartering.

I would be happy if the mboned group would prioritize the discussion of QoS
related topics.  As a co-author of draft-ietf-mboned-maccnt-req-03.txt,
we are dealing with authorization which is necessary for admission
control and therefore related to QoS.  However if by OA&M (operations,
administration, and management) you mean traceability, etc. this is not
something that our draft has dealt with.  But this area is something
definitely worth discussing.

I also believe it is a good idea to survey the needs of the wider
community as you suggested.

Thank you
Hiroaki

>Here is another thing relevant to MBoneD and  draft-ietf-mboned- maccnt-req
>
>http://www.americafree.tv/papers/draft-ietf-l3vpn-ppvpn-mcast- reqts-03-tme.txt
>

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 20 Jan 2006 02:28:23 -0500

Dear Hiroaki;

> Thank you for getting the discussion started on rechartering.

You are welcome.

> definitely worth discussing.

I would agree. I think that sometimes OA&M is used as a synonym for  
AAA but
that is not really correct.

> community as you suggested.

Good. I would hope that you and your colleagues could help  
disseminate this survey,
once it is prepared, into the wider community in Japan and elsewhere.

Regards
Marshall