Re: diffs between Austin IDL and current draft

["jb" <jbarkley@nist.gov>]

hi carol,

<We can apparently apply multiple policies by name to a single resource (by
<name).  We do this with the PolicyEvaluatorAdmin interface.  Since this is
<a "PolicyEvaluatorAdmin", it would stand to reason that we expect the
<PolicyEvaluator we administered to be able to evaluate potentially multiple
<encapsulated policies.   When I have to define what a method does with
<if-then-else logic, I start to suspect we've made a mistake - either in the
<model or the methods.  PolicyEvaluatorAdmin::apply_policy() imho has this
<problem at the moment.

Let me try to amplify/correct what I said previously (really badly in haste)
about PolicyName and the PolicyEvaluatorAdmin interface.

What we seem to generally have so far is that for each resource, there can
be one or more evaluators. Each evaluator can be one of two general types:

A. Just a process which represents a single policy: That policy is totally
encapsulated within the process. The process only needs to the arguments
from evaluate() in order to do its job. An example might be some Java
Classes.

B. An interpreter of some script: The script might be some language like SQL
or it might just be some tabular information like an ACL. This type of
evaluator not only needs the arguments from evaluate() but also the
"policies", i.e., scripts that represent the policies, in order to do its
job.

If an evaluator is of type (A), then there need not be a
PolicyEvaluatorAdmin interface. Such and interface makes no sense because
the complete "policy" in encapsulated within the evaluator. In other words,
the policy is the the evaluator for type (A) evaluators.

If an evaluator is of type (B), then a PolicyEvaluatorAdmin makes sense. For
a resource, one can associate not only an evaluator of type (B) but also
several scripts, i.e., "policies" that that evaluator must evaluate for that
resource. In the PolicyEvaluatorAdmin interface, the scripts are identified
by PolicyName.

As I understand it, one of your concerns is that you don't want an evaluator
implementation to have to be concerned with "naming" the policies. One
possible way around this is to change the name PolicyName to the name
"Policy" and then let the evaluator implementation decide whether it wants
to pass the policy name or the policy itself to the PolicyEvaluatorAdmin
interface, e.g., the name of an ACL or the ACL itself like the ACLs you
defined in a previous draft. One could further this idea by making the type
of the parameter Policy an opaque or defined by the evaluator
implementation.

Then there is the problem of what should happen when there is more than one
policy for each policy evaluator. One possible solution is that it is up the
evaluator to combine its multiple policies for a resource. The results of
its combining of its multiple policies for the given resource is returned by
evaluate().

jb

----------------
Broadcast message to hrac-rfp from "jb" <jbarkley@nist.gov>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.