Comments of John Vollbrecht on:
Generic AAA Prototype draft <draft-irtf-aaaarch-prototype-00.txt>


1. In section 1 I appreciate your calling out the concept of AAA Driving Policy as a key new part.   I agree.  I wonder if you could define the difference between a Driving Policy and other policy engines, and between a Driving Policy and a Job Manager.  I think such a clarification would make talking about this to others a lot easier.

A Driving Policy and a Job Manager have common features but are not the same. The definition in the introduction is clear. A Driving Policy determines under what conditions (e.g. authentication, authorization etc ) a certain job (ASM) may be run. Other aspects of a Job Manager like on line viewing and managing of running jobs does not fit into this draft.

2. In section 2.1 it says that  ãService Equipment, the device that actually delivers the service requested, that determines the authorization sequenceä.  I think that actually the RBE associated with a request determines the sequence.  I am not sure what is meant by this statement ö the device may require a particular type or may support several.  An AAA may support one or more type.  Anyway, this is confusing.

I agree, this sentence has been removed.

3. In section 2.1.2  it talks about different protocols for different functions.  E.g. it is different to get a certificate than to send a request.  I agree that this is often the case, but it is also possible (in some hypothetical cases at least) to use the same protocol.  So I think the inclusion of protocols in this discussion make it confusing.  Perhaps a nit.



4. In section 3 toward the end it says ãAll three AAA servers have in principle their own Driving Policyä.  I think ãin principleä should be removed.

Ok

5. In your  example policy you use LambdaBoDRequest as a name.  I would prefer LamdaPathRequest or something like it.  Whatever you do you should define what it means early on.  I may have missed something, but I didnât find a definition of BoD till late in the document.

Fixed

6. There is nothing in the document that describes how trust between servers, between user and server, and of particular variables received from other place is determined and maintained.  I am thinking the intent is to use OASIS style security, but this is not clear, and it is not clear exactly how it would apply.

Added to the last section (5).

7. I would be interested in how you handle errors ö timeouts, invalid arithmetic, etc.

This belongs to the specification of the RBE. The policy draft has a section dealing with this. But a reference to a draft is not allowed.

8. I think the backout capability could be described better.  Particularly, what happens if A is done once and B is started but A fails before B gets started?


9. I see no ãgeneric AAA proceduresä in this.  I think some are warranted, in particular one to call other AAA servers, another to do some brand of authentication.

They are not in the examples.  Generic AAA procedures should be defined in future documents as well as the specification of a RBE.

10. In section 4.5 you suggest that ã a special attribute in the Request Tagä could be used to specify that a persistent ãsessionä be established.  I think this is a cool idea, and while it does not belong in this document, I would be interested in understanding the implications of this.

11. In Section 5 you discuss conclusions and possible future research.  One thing I would like to suggest is that one have a Driver Policy that first calls a Resource Allocator which determines which Resources to use for this Application/RBE, the the RBE uses the Resources.

12. In Section 5 you suggest that the value of this is at the business level between organizations.  However in your example you show AAA servers directly talking to Resources/Resource code.  I donât see why it doesnât support both business and resource issues.  In particular I think that having a high level place, A1 in your example, that decides what resources from what domain are to be used could not be based on evaluations of what is available at various domains.  I would be interested in comments on this.

13. The idea of integrating this with Web Services protocols seems very strong.  I would like to see a followup on precisely how this would be done and how the security/trust from that would support the trust in the AAA types (push, pull, agent).