OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xacml] Possible future XACML TC work



> The performance improvement is possible by caching evaluation results of
> conditions.
> 
> E.g., consider two rules "r1" and "r2" that reference the same condition
> "c1",
> and assume that we have to evaluate the two conditions under the same
> request context.
 
I'm not sure this is really going to provide any kind of performance 
improvement given the tradeoff you're making. Requests can be very complex,
and they can be identical in value even when the XML text doesn't match.
Trying to compare two requests could be very expensive, and caching enough
requests to make this worthwhile is equally expensive. In order to make this
a performance improvement, many of the requsts would have to be the same to
justify the cost of equality checking on each/most request(s). There's also
the problem that a Condition could reference an attribute that isn't in the
request, and that changes over time (like time of day), so that two identical
requests could produce different results on the same Condition. To handle
this you'd need to consider each Condition and figure out if this is a
possible case, which may not be determinable.

I agree that using Condition references could cut down on Policy sizes, but
I think you'd need to demonstrate that a typical PDP gets a seriously large
number of requests that all look the same, and that typical Conditions are
deterministic. Otherwise, I think that the cost of checking each request and
storing a large number of requests for later comparison is just too great.  

Or am I missing something?


seth


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC