Subject: evaluation and execution order

From: [email-masked]
Date: Tue, 24 Jul 2001 09:32:57 +1000

hi there,

i'm trying to formalise  the specifications of a rules-based engine (RBE)
capable of interpreting PCIMe PolicySets.  i'd appreciate it if someone
can shed some lights on the following:

1. are there any assumptions in PCIMe as to the order of evaluation of
conditions and execution of actions? ie. can an RBE go through a
PolicySet, evaluating and executing as it unfolds the rules/rule-groups
and their components; or should an RBE first evaluate the conditions and
_then_ execute the actions for those rules that passed the evaluation.

2. (i guess this one is more or less related to the previous question). is
the notion of "evaluating" policy-sets a PDP (policy decision point)
function, while "executing" the correlated actions a PEP (policy
enforcement point) one?  if no, an implementation can be a PDP+PEP
simultaneously.  in such case, are there any precautions an implementor
should be aware of with regard to the impact of processing a policy-set
before another?

3. execution of actions is _always_ within a given "context" --that of the
PDP and/or the PEP.  shouldn't there be a formal representation
(abstraction) of that entity and how the (a) setup/tear-down, (b) access
to  and (c) modification of its content, relate to both the evaluation of
conditions and execution of related actions?

4. For co-operating actions --that are implemented separately-- to work
together, there must be some means of communicating 'intermediary'
results.  this can be achieved by referencing and managing one or more
entities in the runtime "context" of the PDP/PEP.  this though relies on a
knowledge that is (a) common to only those co-operating actions, and which
(b) limits the re-use of such actions in other arragements.  is the notion
of a "runtime stack" beneficial to the formal definition of actions?

if this is not the right forum to ask these questions, then i'd appreciate
it if i'm pointed to the right one(s).

TIA + cheers;
rsn
-----------------------------------------------------------------------
Raif S. Naffah
Forge Research Pty. Limited < http://www.forge.com.au >
-----------------------------------------------------------------------
The message contains privileged and confidential information intended
only for the use of the addressee named above.  If you are not the
intended recipient of this message you must not disseminate, copy or
take any action in reliance on it.  If you have received this message
in error please notify the sender immediately.  Any views expressed in
this message are those of the individual sender, except where the
sender specifically states them to be the views of another (including
a Body Corporate).
-----------------------------------------------------------------------

"Mircea Pana" <[email-masked]>
Sent by: [email-masked]
24/07/01 06:19
Please respond to "Mircea Pana"

        To:     IETF Policy <[email-masked]>
        cc:
        Subject:        Re: Result of the compoundPolicyAction

I'm re-posting this message because it may have been dropped by the
mailing list. Sorry if you receive it again.

Regards,
Mircea.

P.S. Bob, I have received your answer but I'm [re-]posting this for the
record.

"Pana, Mircea [CAR:5E20:EXCH]" wrote:
>
> Bob,
>
> I have interpreted "Do_Until_Failure" as: do one or more from a list of
> actions that is always or most of the time expected to fail at some
> point. One may want to take a different action only if none of the
> components was successful. Does this make sense?
>
> Regards,
> Mircea.
>
> > Do Until Failure:
> >   > All succeed --> the compound action succeeds
> >   > One fails --> the compound action fails
> >
> > We diverge from Mircea only in the case of
> > Do Until Failure.  We don't have a rigorous
> > argument for our alternative over hers
>
> ...actually "his" ;-)

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 25 Jul 2001 11:34:35 +0200

Raif,

1) The specification should allows a RBE both exection orders, you 
described. If you find some suspicious words in PCIMe please let us know.

2) Depending on you function allocation, you might want to optimize the 
evaluatuion order. PCIMe allows you that.

3) I don't understand this question

4) in PCIMe the basic Actions are non-cooperative. However, we allow 
sub-model to have cooperative actions (see for instance the QPIM draft).

Marcus

> it if i'm pointed to the right one(s).

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155