Subject: Re: criticality of extended conditions and actions

From: "Robert Moore" <[email-masked]>
Date: Mon, 23 Apr 2001 08:17:07 -0400

Mircea,

There's another alternative, which, given your
numbering scheme, would most appropriately be
numbered 0:

0. the entire aggregation tree of Policy Groups
   and Policy Rules containing the rule in
   question fails to load on the PDP or to be
   communicated to the PEP

The motivation for this alternative would be
concern about unpredictable (and potentially
undesirable) results if *anything* about the
entire "policy" (which I'm interpreting as the
entire aggregation tree, complete with its
priorities and execution strategies) is
unrecognized / unsupported.

This may result in a whole lot of cases where
policies don't load at all, because some
component or other of them is unrecognized /
unsupported.  But if your overriding goal
(maybe "overriding constraint" is a better way
to say it) with policy-based management is
"no surprises," then this is exactly how you'd
want it to work.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

"Mircea Pana" <[email-masked]>@raleigh.ibm.com on 04/20/2001
06:00:48 PM

Please respond to "Mircea Pana" <[email-masked]>

Sent by:  [email-masked]

To:   IETF Policy <[email-masked]>
cc:
Subject:  Re: criticality of extended conditions and actions

Marcus, in a previous message you suggested that in case of unsupported
components (conditions, actions) "the loading of the whole rule fails".
In the message below you suggest that "a unsupported action could be
regarded an action failure" which is different from the first one.
Please excuse me if I got it wrong!

In case of a set of actions aggregated in a rule, if an action is
unsupported on the PDP or PEP, then which one of the following cases is
the right one?

1. the entire rule fails to load on the PDP or to be communicated to the
PEP
2. the unsupported action is ignored and the others are executed in
conformance with the execution strategy.
3. the unsupported action is considered failed and depending on the
execution strategy, the other actions may be executed

Neither PCIM nor PCIMe define a clear behavior for a PDP and/or PEP
relative to unsupported extensions.

Regards,
Mircea.

Marcus Brunner wrote:
>
> Michael,
>
> I think in PCIMe we covered the case of failing Action by the
> ExecutionStrategy in CompoundActions (do until sucess, do until failure).
> So dealing with a unsupported action could be regarded an action failure.
>
> Marcus
>
> --On Friday, April 20, 2001 9:40 AM -0400 Michael See
> <[email-masked]> wrote:
>
> >
> >
> > Marcus Brunner wrote:
> >
> >> Lee, Mircea,
> >>
> >> I am not happy with the proposed solution, nevertheless we need to
deal
> >> with the problem of "unsupported" or "optional" elements in a policy
> >> rule.
> >>
> >> What does exclude a condition mean (Lees first handling)? replace it
by
> >> FALSE, by TRUE? or skip it?
> >>
> >> The second question is what entity detects a policy with unsupported
> >> conditions and actions? And at what point in the policy lifecycle it
> >> is/needs to be detected?
> >> 1) policy definition language to LDAP translator detects it (needs to
> >> know what policy engine is used)
> >> 2) at load time of policies from a database into the execution engine
> >> 3) at run-time, execution engine fails evaluating a condition or
> >> performing an action, because it is not known.
> >>
> >
> > There is also the case where the execution of a rule fails because the
> > action defined in the rule cannot be implemented.
> >
>
> --------------------------------------
> Dr. Marcus Brunner
> C&C Research Laboratories
> NEC Europe Ltd.
>
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.tik.ee.ethz.ch/~brunner
>
> Adenauerplatz 6
> D-69115 Heidelberg
> Germany
>
> Phone: +49 (0)6221/ 9051129
> Fax:   +49 (0)6221/ 9051155