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

From: Hiroaki Sato <[email-masked]>
Date: Tue, 15 Jul 2008 11:05:24 +0900

Hi all,

I was sending a following response to DIME-ML.
I missed CC to MBONED-ML, so forward it.

Hannes,

Thank you for your feedback.  We just released a new version of
ietf-mboned-multiaaa-framework (07).

Please see responses to
http://www.ietf.org/mail-archive/web/dime/current/msg02007.html inline.

<snip>
>
> * Abstract:
>
>
> "... and to invoice
> such customers in a reliable and efficient manner.
> "
>
changed to
"There is indeed a need for service and content providers to identify
users(if not authenticate, especially within the context of enforcing
electronic payment schemes) and account for content and network usage. "

> Hmmm. I guess that invoicing is largely outsFrom [email-masked]  Mon Jul 14 19:05:00 2008
Date: Tue, 15 Jul 2008 11:05:24 +0900
From: Hiroaki Sato <[email-masked]>
To: [email-masked]
Subject: [MBONED] [Fwd: Re: [Dime] [Fwd: Request for review of "AAA
	Framework for	Multicasting"]]
Sender: [email-masked]

Hi all,

I was sending a following response to DIME-ML.
I missed CC to MBONED-ML, so forward it.

Hannes,

Thank you for your feedback.  We just released a new version of
ietf-mboned-multiaaa-framework (07).

Please see responses to
http://www.ietf.org/mail-archive/web/dime/current/msg02007.html inline.

<snip>
>
> * Abstract:
>
>
> "... and to invoice
> such customers in a reliable and efficient manner.
> "
>
changed to
"There is indeed a need for service and content providers to identify
users(if not authenticate, especially within the context of enforcing
electronic payment schemes) and account for content and network usage. "

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

Changed to:
"There is indeed a need for service and content providers to identify
users (if not authenticate, especially within the context of enforcing
electronic payment schemes) and account for content and network usage. "

> * Section 2.1 Terminology
>
>
> I suggest to replace most of the terms with references to existing
documents.
Join and Leave definitions were updated to reference 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.
changed to:

"As defined in [I-D.mboned-maccnt-req]the CP requires collection of
accounting information related to the access of its content."

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

 Authentication and authorization of NSP by CP is an optional part of
the framework and therefore we use "may." The CP in some case may be
linked to multiple NSPs as described in section 4.1 and there may be
different trust relationships between different providers. CPs in some
cases want to keep their content from being copied.

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

that is true in the case of unicast.  Multicasting potentially can use a
large amount of the NSP’s resources, and therefore the NSP should have
the final decision of accepting or rejecting the request based on
ability to fulfill the request.  In the case of unicast if the CP
accepts requests even though overloaded it will only end up dropping
packets.  However with multicasting accepting such requests when
overloaded can result in a DOS attack on the NSP router.

>
> "
> 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?

For the same reasons described above.

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

The NSP does not make the content authorization decision,tside the scope of IETF
work. I am also not sure what reliable and efficient could mean in this
context.

Changed to:
"There is indeed a need for service and content providers to identify
users (if not authenticate, especially within the context of enforcing
electronic payment schemes) and account for content and network usage. "

> * Section 2.1 Terminology
>
>
> I suggest to replace most of the terms with references to existing
documents.
Join and Leave definitions were updated to reference 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.
changed to:

"As defined in [I-D.mboned-maccnt-req]the CP requires collection of
accounting information related to the access of its content."

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

 Authentication and authorization of NSP by CP is an optional part of
the framework and therefore we use "may." The CP in some case may be
linked to multiple NSPs as described in section 4.1 and there may be
different trust relationships between different providers. CPs in some
cases want to keep their content from being copied.

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

that is true in the case of unicast.  Multicasting potentially can use a
large amount of the NSP’s resources, and therefore the NSP should have
the final decision of accepting or rejecting the request based on
ability to fulfill the request.  In the case of unicast if the CP
accepts requests even though overloaded it will only end up dropping
packets.  However with multicasting accepting such requests when
overloaded can result in a DOS attack on the NSP router.

>
> "
> 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?

For the same reasons described above.

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

The NSP does not make the content authorization decisio but multicast
usage decision.  However it relays the content authorization decision of
the CP if its multicast usage decision is positive.

> * 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?

With the version you reviewed (v4) the explanations about mappings were
insufficient.  These reasons are addressed in the current draft’s
sections 4.2.1 (CP-assigned user ID )　and 4.2.2 (NSP-assigned user ID)

> * 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?

Log standardization was removed in subsequent versions.

> * 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?

The user is not requesting content from NSP, but requesting multicast (S,G).

Changed to: First a user requesting multicast content sends an access
request (multicast (S,G)) to an NSP which then forwards it on to the
appropriate CP for Authentication and Authorization purposes.

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

 We envision protocol discussion to take place in solution documents,
and interfaces appropriate for the framework level.

> "
> 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?
>

Access control list for Joins

Changed to:
The multicast AAA function may be provided by a mAAA which may include
the function by which the the access control list for Joins is
downloaded to the NAS (called conditional access policy control function.)

>
> 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
>
> http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-05.txt

The current version of our framework doc no longer refers to RACS,
instead to MACF (multicast admission control function.)
Solutions will be considered further in a solution draft.

Thanks

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

-- 
************************************
NTT Network Service Systems Lab.
Hiroaki Sato
TEL:0422-59-4683 (+81-422-59-4683)
FAX:0422-59-5636 (+81-422-59-5636)
************************************

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

n, but multicast
usage decision.  However it relays the content authorization decision of
the CP if its multicast usage decision is positive.

> * 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?

With the version you reviewed (v4) the explanations about mappings were
insufficient.  These reasons are addressed in the current draft’s
sections 4.2.1 (CP-assigned user ID )　and 4.2.2 (NSP-assigned user ID)

> * 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?

Log standardization was removed in subsequent versions.

> * 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?

The user is not requesting content from NSP, but requesting multicast (S,G).

Changed to: First a user requesting multicast content sends an access
request (multicast (S,G)) to an NSP which then forwards it on to the
appropriate CP for Authentication and Authorization purposes.

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

 We envision protocol discussion to take place in solution documents,
and interfaces appropriate for the framework level.

> "
> 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?
>

Access control list for Joins

Changed to:
The multicast AAA function may be provided by a mAAA which may include
the function by which the the access control list for Joins is
downloaded to the NAS (called conditional access policy control function.)

>
> 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
>
> http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-05.txt

The current version of our framework doc no longer refers to RACS,
instead to MACF (multicast admission control function.)
Solutions will be considered further in a solution draft.

Thanks

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

-- 
************************************
NTT Network Service Systems Lab.
Hiroaki Sato
TEL:0422-59-4683 (+81-422-59-4683)
FAX:0422-59-5636 (+81-422-59-5636)
************************************

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned