Subject: Re: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"]

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 09 Sep 2007 20:55:57 +0200

Hi all,

I have also reviewed 
http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt

Summary: The document does not only outline a model of AAA interworking 
but describes a model for service access that happens to be distributed 
using multicast. The model envisions that the user would interact with 
an NSP who then interacts with a content provider. The model is a bit 
questionable and I doubt it is inline with other work that is taking 
place in this field.

Before addressing the AAA part the entire model needs to be clarified 
and described in a good way. The current document does not really 
provide indication
(a) about what would be needed from RADIUS and/or Diameter and
(b) it does not consider state-of-the-art (my opinion)

Furthermore, the document has too many pages and does not contain a lot 
of relevant content.

A couple of comments below:

* There are many editorial issues. I strongly suggest to use XML2RFC.

* Abstract:

"... and to invoice
such customers in a reliable and efficient manner.
"

Hmmm. I guess that invoicing is largely outside the scope  of IETF work. 
I am also not sure what reliable and efficient could mean in this context.

* Section 2.1 Terminology

I suggest to replace most of the terms with references to  existing 
documents.

* Section 4.1 Framework

"
The CP
   hopes to collect accounting information related to the
   access of their content.
"

Why would the CP "HOPE"? The content provider can decide what is wants 
to charge the user.

"
The CP may choose to authenticate
   and authorize NSPs which are eligible to provide users
   access to its contents.
"

The CP does not really authenticate or authorize NSPs. It has IP 
connectivity and obviously need to have a business contract for doing that.

Additionally, I am curious why you use plural here (NSPs).

"
When the CP cannot (e.g. error or
   resource issues) or decides not (e.g. policy issues) to
   deliver content, the CP is responsible for notifying the
   NSP of the reason. It is up to the NSP how to relay or
   translate the messages to the user.

"

I doubt that the NSP cares. Why doesn't the CP send the message to the 
user right away. The user has interacted with the CP in the first place.

In fact, I find Figure 1 strange since it shows that the user interacts 
indirectly with the CP rather than directly. There is something wrong.

(Btw, the figure has no caption.)

"
The NSP is responsible for managing its network resources. 
   The NSP may perform admission control. It is also
   responsible for relaying the AAA messages from the CP
   whether the user is eligible to receive content
   (authentication by proxy),
"

Hmm. Why does the NSP relay AAA messages when the user interacts with 
the CP?

"
In certain cases the CP and NSP may
   have a contractual relationship in which the NSP is
   authorized to make the content authorization decision based
   on mutually predetermined criteria: in such cases the NSP-
   AAA may also make the content authorization decision
   without querying the CP-AAA.  When the NSP cannot or
   decides not to multicast to users, the NSP may notify the
   users of the reason. It is recommended that the NSP notify
   eligible users of the reason for not multicasting content
   when it is due network or content unavailability, for
   example.  The NSP may choose not to notify ineligible users
   of the reason for any case.
"

 From a AAA point of view it does not really matter whether the NSP and 
the CP have a contract. I don't understand why the NSP will make the 
content authorization decision. What authorization decision would that be?

The story that the NSP would notify the user about any content related 
issues seems really strange to me.

* Section 4.2

"
  The actual mapping rules for NSPs and CPs to map user IDs
   with the IDs in other provider domains is a matter for the
   providers.  A solution should provide an API between the
   providers to flexibly support various mapping methods. "

Why would one want to map identities?

* Section 4.3 Accounting

"
Standardization of the logs or messages to share content
   usage information is important to support a single NSP
   sharing accounting information with multiple CPs or a
   single CP receiving from multiple NSPs.
"
You envision that NSPs would send accounting information to the CP.

Just to understand you correctly did you have something like 
http://tools.ietf.org/wg/nsis/draft-dressler-nsis-metering-nslp-05.txt

Imagine the following case that there are multiple networks between the 
CP and the end host. Would each intermediate domain send accounting 
records to the CP?

* Section 5.1 Basic Connection Model

"
First a user that requests content
   sends an Access request to an NSP which then forwards it on
   to the appropriate CP for Authentication and Authorization
   purposes.
"

Why would a user send an "requst" to an NSP when it wants to get access 
to, for example, a video?

Figure 2 looks like something obtained from an ITU-T doc.
In the IETF you typically do not speak about interfaces but rather about 
protocols.

"
 multicast AAA server
"

What is this?

"
... access policy is downloaded to the
   NAS (conditional access policy control function.)
"

What policies do you want to download?

Figure 3: The entire discussion about Resource and Admission Control 
System (RACS) is most likely irrelevant for the AAA interaction. Are you 
referring to work outside the IETF or to the Diameter QoS work? 
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-01.txt

Ciao
Hannes

Hannes Tschofenig wrote:
> During the IETF#69 meeting I have also asked for reviewers. Two 
> persons offered help:
> * Jouni Korhonen
> * Tina Tsou
>
> Their review is still pending!
>
> -------- Original Message --------
> Subject:     Request for review of "AAA Framework for Multicasting"
> Date:     Sat, 18 Aug 2007 14:49:00 -0700
> From:     Bernard Aboba <[email-masked]>
> To:     [email-masked]
>
>
>
> A request for review has been received relating to the document "AAA 
> Framework for Multicasting" which is under development within the 
> MBONED WG. The document is available for inspection here:
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt 
>
>
> The Request for Review will last until September 5, 2007.  Please post 
> your comments on this document to the RADEXT WG mailing list, CC:'ing 
> the document authors.
>
> Information on the review request was previously posted to the RADEXT 
> WG mailing list:
> http://ops.ietf.org/lists/radiusext/2007/msg00528.html
>
>
>
> -- 
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime