Comments of John Vollbrecht on: Grammar for Polices 1. In section 2.3 it says "It is the responsibility of the AAA server to keep track of all the decision processes." I think this means that the RBE keeps track during the evaluation, but after the evaluation is done it is up to the AAA server. If so, this might be clarified. Presumably also this means that your intent is that if a "session" based on the request is to last for a while it is the AAA server, not the RBE subsystem, that would track the "session". Right, but I do not want to talk about "sessions" in this draft. A "session" is not yet clearly defined in the context of AAA and I think this draft is not the proper place to define it. 2. In sections 2.4, 2.5 and 2.6 it talks about Authentication authorization and accounting use cases. In my understanding this is not specifically covered without ASMs in your model. So somewhere this should be covered. This is kind of a nit, but if there is a way to clarify it I think the document would be better. Added some remarks after section 2.6 3. In section 3.2 you define "Action". This is the area where I have the most problem. An action can be a Boolean, String, Procedure, Driving Policy. Which means that an Action may or may not be able to be evaluated as true or false in a Policy. On one hand an action seems to be something that is done, so I am not sure what a Boolean action would be. An Action is something to be done. There are no Actions like Boolean or String, you may define assignments of (local) variables to Boolean or String. 4. On another hand if a policy contains: DrivingPolicy ::= if (X then A || B) ...Else (policy3) Where I have substituted expressions for Action1 and Action2 - I am not sure what this would mean. Neither do I. Do you mean: if( X || B ) then( A ) else( policy3 ), which is a well formed policy 5. Also with Actions, I think that (trying to do) doing an ActionList could result in failure. There does not seem to be a way to handle this in the language. Right, see the remarks in section 3.3 6. In section 3.2.1 it talks about Procedures. I am not clear about what happens when a procedure calls and ASM which goes to a remote server and never returns to the Driving policy. Is there a timeout? Do you expect the procedure to have a timeout? Right, the RBE should apply a timeout in calling ASMs. This is an implementation specification. Added in line 3 of section 3.3 7. In section 3.2.3 it talks about procedures. This says that if a procedure returns a Boolean it does not return other variables. My assumption has been that a procedure could return truth values and variables. I don't see why this couldn't fit with the grammar you have - so perhaps that could be fixed. It is not specified what a Procedure may return. In two situations the return value of a Procedure is of importance. Firstly if the procedure is part of a Boolean expression, and secondly if the Procedure is the right value of an assignment. Made some extra remaks in section 3.2.3. I also have some thoughts about the grammar as a whole and future changes. Many of these I am sure people are aware of, but I mention them just for purposes of getting them on paper. 1. The grammar itself describes how a set of "Actions" is to be done. While the assumption here is that when an authorization is done the AAA server will take over and the AAA server will manage a session if there is one. I suggest thinking about extending the RBE to support long term sessions. I think this is proposed in the prototype document (section 4.5). The language would then need to include timers and the ability to accept signals that specify changes in resources. I am curious about what you think of this possibility. This subject should be discussed in the prototype document and I wander if the grammar needs to be changed. 2. If one assumes that there will be an Authentication ASM (or other), and that there may be several of them, it seems necessary to support an "API" to Authentication routines which is given information from different places (e.g. the Request.Userid) and returns a boolean and perhaps a certificate. This does not seem needed for this document because it is at a high level, but it does seem necessary to define how to use this in a general engine. 3. The policy language could use some sort of generic procedures define for it. Again, this is not needed in this document, but a administrator trying to write policy would not have an easy time getting this right. It needs some bigger blocks. Already supported. Made more explicit in the first line of section 3.2.3. 4. This language is a lot like a resource control language. I almost think that "Actions" should be limited to resource activities, procedures with variables perhaps, and the return should always be a Boolean (succeed or fail) and perhaps some variables. This would make it clearer that the goal is to evaluate some stuff and do some stuff. Already the case. 5. The evaluation of variable does not specifically take into account trust/security information. That is there is no explicit description that variable "dev1.speed" is really from dev1. This is part of what I think the AUTHZ groups at GGF are defining, and perhaps the WSDL and associated security are defining. I think this is a very important issue. 6. The language does not define how one determines which remote user to contact (for example) for authorization. Presumably this is the role of an ASM. The role of an ASM with the proper arguments applied, or a generic AAA function call. 7. A generic procedure to send a request to a remote AAA server and process a reply seems important in order to build an infrastructure of AAA servers. No list of generic AAA functions is defined yet. Should be done. 8. The language itself seems to do more than many people need. I think creating a generic procedure that does XCML might be very interesting. I would be interested in understanding the security requirements for RBE (if any) and AAA server (if any) in doing this. 9. I like this very much - the comments are in part because it seems very good and I would like to incorporate it into future implementations and am trying to understand what is possible. --John