Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s)
draft-ietf-mboned-maccnt-req-10

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s)) to Informational RFC


The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document:
- 'Requirements for Multicast AAA coordinated between Content Provider(s)
  and Network Service Provider(s)'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-05-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mboned-maccnt-req/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mboned-maccnt-req/

Technical Summary

This memo presents requirements in the area of accounting and access
control for IP multicasting. The scope of the requirements is
limited to cases where Authentication, Accounting and Authorization
(AAA) functions are coordinated between Content Provider(s) and
Network Service Provider(s).

In order to describe the new requirements of a multi-entity Content
Deliver System(CDS) using multicast, the memo presents three basic
business models: 1) the Content Provider and the Network Provider are
the same entity, 2) the Content Provider(s) and the Network
Provider(s) are separate entities and users are not directly billed,
and 3) the Content Provider(s) and the Network Provider(s) are
separate entities and users are billed based on content consumption
or subscriptions. The requirements of these three models are listed
and evaluated as to which aspects are already supported by existing
technologies and which aspects are not.

General requirements for accounting and admission control
capabilities including quality-of-service (QoS) related issues are
listed and the constituent logical functional components are
presented.

This memo assumes that the capabilities can be realized by
integrating AAA functionalities with a multicast CDS system, with
IGMP/MLD at the edge of the network.

Working Group Summary

This document is a product of the mboned working group.

Document Quality

This latest revision is being resubmitted after extensive review and
comment from a previous AD review.

Personnel

Lenny Giuliano is the Document Shepherd. Ron Bonica is the Responsible
Area Director

[Ballot comment]
Carry forward Ted's DISCUSS comment:

The document says:

    In many commercial multicast situations, NSPs would like to be
    able to precisely grasp network resource consumption and CPs would
    like to be able to precisely grasp the content consumption by end-
    users.  Such information might be used for identifying highly
    viewed content for advertising revenue, ratings calculations,
    programming decisions, etc., as well as billing and auditing
    purposes. Also content and network providers may wish to provide
    users with access to their usage history.

    To assemble such an understanding of end-user behavior, it is
    necessary to precisely log information such as who (host/user) is
    accessing what content at what time (join action) until what time
    (leave action).

The examples given (highly viewed content for advertising revenue,
ratings calculations, programming decisions) do not match necessarily
match the need to track this information by user.  These decisions are
commonly made in other environments based on aggregate data, which does
not reveal individual user preferences. This document  recommends this
more extensive tracking rather than aggregrated data, but it does not
justify the more intrusive tracking.  If the authors wish to retain
this aspect of the recommendations, a section on privacy considerations
should be added to the security considerations.  Those should cover both
authorization models described in the follow-on sections.

[Ballot comment]
The authors did not respond to Bernard Aboba's IETF Last Call comments.

  I am concerned by the comments from Bill Fenner, Jari Arkko, and
  Brian Carpenter.

[Ballot comment]
The authors did not respond to Bernard Aboba's IETF Last Call comments.

  I am concerned by the comments from Bill Fenner, Jari Arkko, and
  Brian Carpenter.

[Ballot discuss]
Bernard Aboba provided a security directorate review as last call
comments.  I have not seen a response to these comments.  The issues
he raise seem serious and I'd like to see the WG's response before I
can fully evaluate this document.

[Ballot discuss]
> However, multicasting
> according to current standards (e.g., IGMPv3[1] and MLDv2[2]) has
> drawbacks compared to unicasting when one applies it to commercial
> services.  Accounting of each user's actions is not possible with
> multicasting as it is with unicasting.

This statement is not universally true. For instance,
in DSL or cellular or any other environment with a
point-to-point nature, it *is* possible to track
what each user does with multicast. More importantly,
however, there are application-level multicast
controls (such as access to the decryption keys)
that deal with the most pressing problems in
content delivery. Such tools appear to be
a much better fit to the problem at hand --
the ISP should be checking if they have a
subscriber X and whether that subscriber
is within his bandwidth limits, NOT whether
the subscriber is entitled to look at
football. This is the task of an application
provider. Of course, ISP and application provider
may exist in the same company... but marrying
the routing and forwarding technology to
end-to-end content authorization process
would make it impossible to separate them.

> The requirements defined in this memo apply to solutions that 
> provide user separation either through physical separation 
> provided by dedicated access media between the user and multicast
> router  (see  Fig.  1) or else through logical separation in cases
> of shared physical access media (e.g. using VLAN). However, IP
> multicast solutions with shared Layer 2 access media between the
> user and multicast router and no logical user separation (e.g.
> Ethernet with shared links and no VLAN) are out of scope of this
> memo.
> ...
> With current protocols (IGMP/MLD), the sender cannot distinguish
> which receivers (end hosts) are actually receiving the information. 

I do not understand why, given the scope, the first hop router
simply cannot look up which interface this message came from
and determine whether the customer behind that interface
is allowed to use multicast/this particular stream/this
much bandwidth?

> Since the CP and NSP are different business entities, they need to
> share the revenue.

That would be only one of the many business models. The
NSP could also be operating as a bit pipe, for instance.

[Ballot comment]
1. Introduction
...
    It is proposed that this I-D be used as a
    starting point for a discussion on these issues.

This sentence seems unnecessary in an RFC. It also occurs
in the Abstract.

[Ballot discuss]
3.1  Accounting Issues
...
    In other words, the current standards do
    not provide multicasting with authorization or access control
    capabilities sufficient to meet the requirements of accounting.
    ...
    This is the major reason why multicasting is only used for cases
    where no user-based accounting capabilities are necessary.   

This is a circular argument. It's perfectly reasonable to argue that
some multicast applications need AAA, but where is the evidence that
lack of IP-level AAA has been the blocking factor?

I believe that the picture drawn in Fig. 2 is very restrictive.
The users need a AAA relationship with the content providers, but
it is not always correct to show the content providers inside
peer networks, with an NNI to the customers' NSP; they may well
be outside all peer networks, with no network being part of the
customer/provider relationship.

In summary I don't believe that this document describes generic
requirements; it describes requirements for a subset of deployment
models for which a network-based AAA solution may be appropriate.
Somehow this needs to be made clear in the title, abstract and
introduction.

[Ballot comment]
Does this document reflect a WG consensus?

It mixes together QoS, AAA, etc. in ways that seem nonsensical; e.g., some of the examples say that the goal could be accomplished in unicast with RSVP; why can't you use RSVP in the exact same way for multicast, given that RSVP was designed to operate just as well with multicast as with unicast?

I agree with Brian's general sense that this doesn't seem like something that should be happening at layer 3, and with many of the questions of the AAA Reviewer.

I don't see a way to fix this, so I am abstaining.

[Ballot discuss]
The document says:

    In many commercial multicast situations, NSPs would like to be
    able to precisely grasp network resource consumption and CPs would
    like to be able to precisely grasp the content consumption by end-
    users.  Such information might be used for identifying highly
    viewed content for advertising revenue, ratings calculations,
    programming decisions, etc., as well as billing and auditing
    purposes. Also content and network providers may wish to provide
    users with access to their usage history.

    To assemble such an understanding of end-user behavior, it is
    necessary to precisely log information such as who (host/user) is
    accessing what content at what time (join action) until what time
    (leave action).

The examples given (highly viewed content for advertising revenue, ratings calculations,
programming decisions) do not match necessarily match the need to track
this information by user.  These decisions are commonly made in other environments
based on aggregate data, which does not reveal individual user preferences.
This document  recommends this more extensive tracking rather than aggregrated data,
but it does not justify the more intrusive tracking.  If the authors wish to retain
this aspect of the recommendations, a section on privacy considerations should
be added to the security considerations.  Those should cover both authorization
models described in the follow-on sections.

[Ballot comment]
[I don't know what my ballot is going to be on this one yet, but I wanted to get the comment out.]

1. Introduction
...
    It is proposed that this I-D be used as a
    starting point for a discussion on these issues.

This sentence seems unnecessary in an RFC.

3.1  Accounting Issues
...
    In other words, the current standards do
    not provide multicasting with authorization or access control
    capabilities sufficient to meet the requirements of accounting.
    ...
    This is the major reason why multicasting is only used for cases
    where no user-based accounting capabilities are necessary.   

This is a circular argument. It's perfectly reasonable to argue that
some multicast applications need AAA, but where is the evidence that
lack of IP-level AAA has been the blocking factor?

I believe that the picture drawn in Fig. 2 is very restrictive.
The users need a AAA relationship with the content providers, but
it is wrong to portray the content providers as being inside
peer networks with an NNI to the customers' NSP; they may well
be outside all peer networks, with no network being part of the
customer/provider relationship.

I am far from convinced that this is a problem that belongs
at layer 3. That isn't to say the listed requirements are wrong
in themselves. But IMHO they should be met in a bilateral way
between the customer and the CP, without involving the network.

PROTO Write-up

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?  Which chair is the WG
        Chair Shepherd for this document?

I reviewed the document and feel that it is ready for forwarding to the IESG.
Marshall Eubanks is the Shepherding Chair.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

Yes. After some earlier work, the original (-01) version of this draft was accepted and published on Oct. 13, 2005. After the Fall, 2005, IETF meeting, the -02 version went through WGLC, which engendered a lot of discussion on the MBONED Mailing List. After the comments, the document was revised, with the -04 version appearing Feb 15th, 2006. There was consensus on the mailing list to go forward after this version appeared.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, internationalization,
        XML, etc.)?

No. The subsequent draft draft-ietf-mboned-multiaaa-framework-02.txt carries this
work forward, and might be useful to read it in conjunction with this one.


  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No, I do not have any specific concern. This is a new direction for MBONED, applying
unicast type of AAA controls to multicast, for which there seems to be considerable interest in the AAA community.

  1.e) How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

I believe the consensus is acceptable level.  There are not
many comments on the ML but none of the comments are negative.


  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.  (It should be
        separate email because this questionnaire will be entered into
        the tracker).

No. The WG appears to be solidly behind this.

  1.g) Have the chairs verified that the document checks out against
        all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
        Boilerplate checks are not enough; this check needs to be
        thorough.

Yes. The nit result is appended at the bottom of this document.

  1.h) Has the document split its references into normative and
        informative?  Are there normative references to IDs, where the
        IDs are not also ready for advancement or are otherwise in an
        unclear state?  The RFC Editor will not publish an RFC with
        normative references to IDs (will delay the publication until
        all such IDs are also ready for RFC publicatioin).  If the
        normative references are behind, what is the strategy for their
        completion?  On a related matter, are there normative references
        that are downward references, as described in BCP 97, RFC 3967
        RFC 3967 [RFC3967]?  Listing these supports the Area Director in
        the Last Call downref procedure specified in RFC 3967.

Yes; there are only two references and they are both RFCs and both normative.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

Multicast, by its nature, has lacked the ability to control and measure
both the sourcing and the receiving of streams that are common to unicast content delivery. This draft provides general requirements for such accounting capabilities including quality-of-service (QoS) related issues.  Finally, cases for Content Delivery Services (CDS) are described as application examples which could benefit from multicasting accounting and access control capabilities are described.  It is intended that this I-D be used as a starting point for further discussion on these issues. The subsequent draft draft-ietf-mboned-multiaaa-framework-02.txt carries this work forward, and might be useful to read it in conjunction with this one.

It is not clear to what extend these proposals will be adopted; there is considerable interest in the community (particularly for IPTV) but I am not aware of any definite plans for implementations.

        *    Working Group Summary

There was not any controversy about this document after the -04 revision.


        *    Protocol Quality

This document, as a requirements document, does not propose any new protocol.


  1.j) Please provide such a write-up.  Recent examples can be found in
        the "Action" announcements for approved documents.

  1.k) Note:

        *    The relevant information for the technical summary can
            frequently be found in the abstract and/or introduction of
            the document.  If not, this may be an indication that there
            are deficiencies in the abstract or introduction.

        *    For the Working Group Summary: Was there anything in WG
            process that is worth noting?  For example, was there
            controversy about particular points, decisions where
            consensus was particularly rough, etc.

        *    For the protocol quality, useful information includes:

            +    Are there existing implementations of the protocol?

            +    Have a significant number of vendors indicated they
                  plan to implement the specification?

----------------------- idnits -----------------------

idnits 1.116

tmp/draft-ietf-mboned-maccnt-req-04.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
   
    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.

    No nits found.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
    Nothing found here (but these checks do not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:
    None.

  Experimental warnings:
    None.

    No nits found.

----------------------- end -----------------------