Hi Erik, I will pull up your responses for ease of readability: 1. Yes, but the question is which type of Indeterminate? {P}, {D} or {DP}? This was the issue which was posted on the comments list. I was addressing Paul's concern that: When a policy or policy-set target evaluates to Indeterminate, are we saying that the PDP must still evaluate the children and apply the combining-algorithm? I think that will result in a lot of extra evaluation for marginal benefits. I was trying to say that the amount of evaluation that needed to take place depended on the combining algorithm and the possible values that had been returned and that this evaluation strategy was the same for Rules, Policys, and PolicySets, at least with the extended algorithms. I then went on to discuss the explicit case of a Target indeterminate, and what potential impact that had on evaluating the children, and I said it was the same as if the first child evaluated to Indeterminate, one still needed to look at the combining alg and the results as one progressed to determine the first possible unambiguous break out time. 2. This is what Paul is proposing, but I think what I wrote is safer. See my other response to Paul. I don't see how what I was proposing , which was not a proposal, but an explanation of how it currently operates, at least, as I interpret it, could be in any way compared to Paul's proposal which recommended a change. As far as which type of Indeterminate to return to a XACML 2.0 environment, I think your proposed language addresses the problem properly, namely that you just drop the qualifier, and 2.0 can proceed w/o taking advantage of the additional information that is possible in 3.0 but not in 2.0 as specified. Thanks, Rich On 4/19/2011 2:58 PM, Erik Rissanen wrote:
4DADDB71.6090704@axiomatics.com type= cite >Hi Rich, See inline. On 2011-04-19 20:55, rich levinson wrote: Hi Paul, A quick response is that it is basically the same as the rule combining algorithms. For example, in a deny-overrides policy, you have to continue evaluating policies until you either: - find a deny, - or a permit with no deny (basically all permits), - or a permit and an indeterminate, which results in indeterminate. The only way to avoid evaluating all policies is if you encounter a deny, then you know the answer regardless of what the other policies might return. If the Target of the current PolicySet is Indeterminate, then I expect one would immediately return Indeterminate w/o evaluating the children, since they are all predicated on successful evaluation of the Target. Yes, but the question is which type of Indeterminate? {P}, {D} or {DP}? This was the issue which was posted on the comments list. This is distinct from the case where say there is a parent PolicySet that has n child PolicySets, then if one of the child PolicySets is Indeterminate, then you still need to evaluate the other child PolicySets using the algorithm above, where the breakout point depends on what the combining algorithm and the current set of child results imply at that point. Finally, I don't think finding Indeterminate in the parent PolicySet Target is ambiguous, because you would then look at the possible responses from its children and if they were only Permits it would be Ind(P), if they were only Denys then it would be Ind(D), and a mix would be Ind(DP). I don't think there is much point in this last case of actually evaluating the child Policies after the parent Target is Indeterminate, but there is a purpose in scanning them to determine what their possible returns would have been. This is what Paul is proposing, but I think what I wrote is safer. See my other response to Paul. Best regards, Erik Thanks, Rich On 4/19/2011 11:00 AM, Tyson, Paul H wrote: Erik, good job on the spec. I have some misgivings about the extended indeterminate solution for policy[set] targets. When a policy or policy-set target evaluates to Indeterminate, are we saying that the PDP must still evalua