Mr Dekok,
Thank you for your detailed feedback on the "AAA Framework for
Multicasting" draft. Last week we submitted a revised version of the
draft reflecting many of your suggestions.
http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-05.txt
A summary of changes:
* In section 4.1 we broke explanations down into the different use cases
of multiple CP - multiple NSPs, single to multiple, etc. The most
general case multiple CPs to mulitple NSPs was described as a time
sequence and the other cases where compared to this most general case.
* Section 4.2 elaboration of NSP assigned userID vs CP assigned userID
was added.
* In sections 4.3, 4.4 and 4.5 were largely rewritten to clarify AAA
characteristics specific to multicasting
Below we respond to your feedback inline:
> (1) I'm not sure why Section 2 defines the terms Accounting,
> Authentication, and Authorization. The document is already discussing
> AAA issues, so familiarity with the three A's should be assumed.
>
> Perhaps the intent was to give examples of how AAA would be used in
> this scenario?
Indeed, the intent is to give multicast-inferred examples so we have
decided to leave these definitions.
> (2) Section 4.1 is titled "Framework for multicast AAA". This may lead
> someone to conclude that the AAA protocol is being multicast. I don't
> think that's correct.
>
Agreed. We propose to rename the section "AAA Framework in
Multicast-Enabled Envrionments" in a future revision.
> (3)The diagram in that section appears to confuse the AAA process
with the
> later multicast data. My understanding is that the request/response for
> AAA is unicast, and the data that is being accessed is then sent via
> multicast.
>
We removed the label "multicast data" as suggested.
>
> (4) Perhaps a time-sequence diagram would be useful, to replace the
> diagram in Section 4.1.
> (4) The text in 4.1 is also awkward. It contains a series of
overlapping
> conditionals for setting behavior. The text should be expanded to
> describe specific scenarios in detail from start to finish, rather than
> discussing multiple scenarios simultaneously. Adding a time-sequence
> diagram for each scenario would be useful, too.
>
4.1 was reorganized and rewritten to describe the following cases:
multiple CPs connected multiple NSPS, multiple CPs to a single NSP,
single CP to multiple NSPs and single CP to multiple NSPs. The most
general case multiple CPs to mulitple NSPs was described as a time
sequence. Then the other cases were compared to the general case.
> (5) Section 4.2 Multiple User IDs is confusing. In AAA, each user
id is
> treated as a separate user. This document should avoid the term "user
> id", as it is easy to confuse with the term "user". Instead, maybe
> "access identifier" could be used. The definition could be added to
> Section 2.1.
>
We revised this section to better explain what we mean by multiple UIDs
and distinguish between NSP assigned userIDs and CP assigned userIDs.
Security considerations about handling the IDs are also addressed.
> (6) The relationships between the terms (1:N, M:N, etc.) should also be
> included in the definitions in Section 2.1. This lets the reader
> immediately know the relationships, independent of their use-cases. The
> later discussion of use cases can then become clearer.
>
We added separate sections for each use case to section 4.1 to better
describe the relationships.
> (7) Also, the document sometimes refers to "user", and sometimes to
"user
> id" in the same context. (e.g. Section 4.1, "the user requests
>
> content".) Later, the document clarifies that the user may have
> multiple user ID's. This is confusing, because the document first talks
> about users requesting content, and then switches to say no, it's not a
> user, it's a user id.
> (8) Instead, all discussion of access requests in the document
should be
> done using consistent terminology, such as "access identifier", rather
> than "user". In some cases, the user will map 1:1 with an access
> identifier. In others, it will be 1:N.
>
where appropriate we used the term userID
furthermore we elaborated on CP-assigned user ID and NSP-assigned user
ID in section 4.2
> (9)...
> 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.
> ...
>
> API's should be avoided. Instead, the Chargeable-User-Identity (RFC
> 4372) should be used to map identifiers to users. This is simpler,
> scalable, and already deployed.
>
Agreed. We removed mention of the API from the framework in section 4.2
>
> (10)
> Section 4.3:
>
> ...
> 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.
> ...
>
> The logs should not be standardized. Instead, the contents on the AAA
> messages should be standardized.
>
Agreed, we deleted any definitions of the log format from section 4.3
and instead further clarified the contents of the messages themselves.
> (11)...
> This framework specifies an accounting API provided by the
> NSP and accessed by the CP to allow for sharing user-
> behavior and content-reception information between the NSP
> AAA and CP AAA. This accounting API should be configurable
> to allow the CP to request only the logging information it
> actually requires.
> ...
>
> Negotiation of the contents of accounting messages is not a normal
> part of AAA. This requirement may be unnecessary, OR it may be very
> difficult to implement in existing AAA systems.
As indicated above 4.3 was rewritten. The section now specifies
accounting issues specific to multicasting such as recording multicast
join and leave.
> (12)
> ...
> When
> logging information is shared through the accounting API,
> it is important that the CP be able to match the user as
> described in the database operated by the NSP to the user
> as described in the database operated by the CP.
> ...
>
> This is already part of existing AAA systems. I'm not sure it's
> necessary to re-iterate this requirement here.
>
> Overall, Section 4.3 appears to re-state many common AAA requirements
> for accounting.
>
> The document also spends a lot of time talking about "needs". Is the
> document a framework, a model, or a requirements document? Or is it all
> three? The document should separate the model from the requirements
> more explicitly. The model should be discussed first, and then the
> requirements listed second.
>
this text was deleted.
>
> (13)...
> 4.4 Access Control and CP selection by NSP
>
> When a NSP receives an access request from a user, it is
> necessary for the NSP to determine to which CP the request
> is to be directed. It is necessary for the NSP to ensure
> that it is not spoofed by an inappropriate CP or user.
> ...
>
> Doesn't AAA already do this? What are the concrete requirements added
> by this document? Or is this document just introducing AAA concepts to
> people more familiar with multicast issues?
>
This section was revised to mention CP selection as a responsiblity of
the NSP.
> (14)
> ...
> 4.5 API for Admission Control Information by NSP
>
> After authorizing a user request, the NSP may have further
> conditions for determining its admission control decision.
> MACCNT-REQ-draft defines requirements for providing the
> network capability to conduct admission control based on
> the network bandwidth usage status and bandwidth management
> policy. (MACCNT-REQ-draft, 4.2.2, 4.2.3 & 4.9) Such QoS
> measurement and policy mechanisms themselves are out of the
> scope of this memo.
> ...
>
> These mechanisms are defined (or are in the process of being defined)
> in normal AAA. This document could refer to AAA specifications that
> meet its needs.
>
This section was greatly revised. Mention of an API was removed. More
detailed discussion of multicast-inferred bandwidth management was added
including traffic parameters of a multicast channel for admission
control which the NSP needs to know and the case of multicast and
unicast being provided on the same network.
>
> (15)
> ...
> However the NSP's AAA Server should be
> provided with an Admission control API that allows for
> interfacing so that additional conditions can be added to
> the admission control decision.
> ...
>
> I have no idea what this sentence means. "allows for interfacing" is
> extremely vague. Also, AAA protocols do not provide for much in the way
> of capability negotiation. The authors should double-check the
> requirements of this document against the functionality provided by an
> existing AAA protocol such as RADIUS. The requirements MAY be more than
> existing protocols can satisfy.
>
> In general, AAA clients provide a set of information to the AAA server
> in the access request, and the AAA server makes an accept/deny decision
> based on that information. AAA servers cannot negotiate for more
> information.
The text referred to above was deleted. Instead elaboration of
establishment of the connection conditioned on network resources and
channel requirements was added to section 4.5.
> (16)
> This document should define what information is available to the
> participants. It should discuss what information SHOULD be made
> available by the AAA client to the AAA server, and what information MUST
> be made available.
>
We agree that such info needs to be provided but not necessarily in this
draft as it is not a Requirements document.
> (17)...
> 4.6 Access Control and Distinguishing of Users by CP
>
> The user ID and authentication information are forwarded
> transparently by the NSP so that the CP can distinguish the
> user, as well as authenticate and authorize the request.
> ...
>
> Does this impose requirements on the behavior of the AAA systems? If
> so, what?
>
This does not introduce additional requirement for the AAA server.
>
> (18)...
> 4.7 Caching of AAA results
>
> An NSP should be able to cache AAA results based upon an
> agreement between the NSP and a CP. The AAA cache would
> store information about permissions of a specific user to
> receive multicast data from specified channel(s) up to
> specified expiration date(s) and time(s).
> ...
>
> This is not a cache, and should not be referred to as a cache.
> Instead, the NSP obtains a policy from the AAA server for a particular
> session, and applies that policy to that session, for the duration of
> the session. The term "cache" should be deleted from the document
entirely.>
> Further:
>
> ...
> If such caching is implemented,
> ...
>
> The functionality described as a "cache" MUST be implemented.
>
>
> ...
> It should be possible for a CP to send unsolicited requests
> to the NSP to refresh or change the permissions for a user
> for specific channel(s).
> ...
>
> This is possible using existing AAA protocols.
>
We changed "caching" terminology to proxy terminology throughout the
document.
> (19)
> ...
> When a user is receiving multicast content and the
> permission is about to expire, the NSP may send a
> notification to the user client that his session is about
> to expire, and that he will need to re-connect. The user
> will have to reestablish a connection.
> ...
>
> In AAA terms, the user will have to re-authenticate, not re-connect.
> There is no AAA "connection" between the user and the NSP.
>
Agreed. We changed to "re-authenticate"
Thank you
Hiroaki