Subject: Re: evaluation and execution order

From: [email-masked]
Date: Thu, 26 Jul 2001 09:54:36 +1000

hi Marcus,

my response is embedded hereafter.

thanks for taking the time to respond + 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).
-----------------------------------------------------------------------

Marcus Brunner <[email-masked]>
25/07/01 19:34

        To:     [email-masked], IETF Policy <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: evaluation and execution order

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.

----- [ rsn

i had in mind the following paragraph (end of section 4.5.2, of PCIMe 
draft
v2):

    "So, regardless of how a rule engine is implemented, it MUST NOT 
include
    any side effects of condition evaluation in the evaluation of 
conditions
    for either of the decision strategies. For both the AllMatching 
decision
    strategy and for the nesting of rules within rules (either directly or
    indirectly) where the actions of more than one rule may be enforced, 
any
    side effects of the enforcement of actions MUST NOT be included in
    condition evaluation on the same evaluation pass."

for a RBE it's sometimes impossible to know if/how an action may affect 
the
context within which the evaluation+execution will occur.  for example:

    RG1: AM (AllMatching)
       R1: if (locA equals 2) then (locA++);
       R2: if (locA equals 3) then (locA++);

RBE-1 does evaluation-then-execution (EtE), while RBE-2 does
evaluation-and-execution (EaE) as it goes.  assuming that locA is bound to
the value 2 at the start of execution, processing such a policy-set 
through
those 2 engines would yield different results (locA ends up being 3 in the
case of RBE-1 and 4 in case of RBE-2).  is this accepted?

unless i'm missing something, it sounds like we're putting an unfair
restriction on the RBE to guarantee immutability of the context while it 
is
not capable of checking/predicting if/how an action can alter this
context.  if however, RBEs operate _always_ in EtE mode, then the result
will be the same independently of the RBE implementation.

----- ] rsn

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

----- [ rsn

the document (PCIMe) refers to an execution "context" (eg. last paragraph
of section 4.4.1).

it also goes into (too much, IMHO) details about the explicit and implicit 

variables and "standard" types.  in practice a RBE should be made aware of 

how/where the bindings of all the variables, needed to process the policy 
sets, are.  an encoding of a relation 
PolicyVariableBindingInEvaluationContext 
to PolicyVariableBinding is what i was alluding to.

btw, why were the VendorSpecificCondition and VendorSpecificAction deemed
insufficient so as to add all these classes? (pointing me to a previous 
email
exchange in the archives would be enough if this subject has been already
visited).

----- ] rsn

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

----- [ rsn

is that
<http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-03.txt>?

---- ] rsn

Marcus

--On Tuesday, July 24, 2001 9:32 AM +1000 [email-masked] wrote:

> 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" ;-)
>
>

--------------------------------------
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