Subject: criticality of extended conditions and actions

From: "Mircea Pana" <[email-masked]>
Date: Wed, 18 Apr 2001 15:47:47 -0400

PCIM/PCLS recommend the specialization of the policyCondition and
policyAction as the preferred extension mechanism for creating
domain-specific models and schema.

However, it is unclear how a PDP/PEP should behave when it encounters an
unknown/unsupported element. For example let's say that an IPSec
specific policyAction is present in a policyRule loaded by a QPIM
capable PDP/PEP. Should this action be ignored or should it be
considered as failed? The way we interpret such situations may affect
execution of the other actions (see PCIMe execution strategy). A similar
situation can occur in with groups of heterogeneous policyRules.

I would suggest the addition (to policyCondition and policyAction in
PCIMe) of a "Criticality" property in order to allow an administratively
controlled behavior:
- a critical unknown/unsupported condition is evaluated FALSE.
- a critical unknown/unsupported action is considered Failed.
- a non-critical condition or action is ignored.

Thanks,
Mircea.

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 19 Apr 2001 11:03:28 +0200

> situation can occur in with groups of heterogeneous policyRules.

You used the wording IPSec specific policyAction is present in a policyRule 
loaded by a QPIM capable PDP/PEP". I think in most cases the loading 
already should encounter the problem. So it is not a matter of the 
execution engine.

My proposel is that the loading of the whole rule fails.

Marcus

> - a non-critical condition or action is ignored.

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

---

From: "Mircea Pana" <[email-masked]>
Date: Thu, 19 Apr 2001 11:25:06 -0400

The loading doesn't necessarily fail in case of vendorCondition or
vendorAction. Also, a PDP may support a specific types of conditions or
actions which are not supported by some of the PEPs served by this PDP
(PEP has limited capability).
IMO, the loading of a policyRule with unsupported components should not
fail. The condition(s) evaluation and action(s) execution should fail if
critical components are unsupported.

However, if the recommended behavior is to fail on loading rules that
contain unsupported components, then this should be explicitly added to
PCIMe. In that case:
1. the policyRule becomes an aggregation of homogenous, domain [and
optionally version] specific conditions and actions - this has serious
implications on the domain independence of the policyRule concept.
2. a mechanism should be added for improving the detection of the
policyRule specificity. Otherwise, one may have to "dig deep down"
through compound structures to find whether the rule is supported or
not.
3. the decision strategy for policyGroups with unsupported policyRules
should be defined as well.

I believe that the criticality flag is more valuable and it contributes
to the * heterogeneous * aspect of the policy framework stated among the
WG objectives.

Regards,
Mircea.

---

From: "Lee Rafalow" <[email-masked]>
Date: Thu, 19 Apr 2001 13:04:09 -0400

I'm not sure I understand the utility of having conditions and actions
flagged as optional or required (i.e., not critical and critical,
respectively).

If a condition is truly optional there are two ways to handle it in the
current model: 1) exclude it, or 2) have a second, lower priority rule that
excludes it (most likely with a different action).  That is, the model only
supports required conditions (and, I personally, don't understand optional
conditions).

For actions, we've already discussed and dismissed (at least for the time
being) the notion that we can specify recovery behavior (the transactional
support discussed last meeting).  You can think of it as only supporting
optional actions at this point because the behavior when a failure occurs is
submodel and/or implementation dependent.

I tend to agree with Marcus that rules that contain conditions or actions
for which there is no semantic routine should be rejected.  If the analog of
a compiler fits (and I think it does) then it can be argued that the whole
policy should be rejected (compilation error) since a single missing rule
may dramatically change the network behavior.   Actually, I think we should
have text that says the policy MUST be rejected.

Lee M. Rafalow
Voice: 1-919-254-4455; Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: [email-masked]
Home email: [email-masked]

---

From: John Strassner <[email-masked]>
Date: Thu, 19 Apr 2001 18:47:06 -0700

I have to agree with Lee here. I also don't understand the purpose or 
benefit of an optional condition as a dedicated construct instead of simply 
splitting the rule into multiple rules or even sub-rules.

I also don't understand the following statement of yours:

> > fail.

If the component is unsupported, how can the policyRule even be evaluated? 
I think that it has to fail (note that rejection is another form of failing).

I also don't see the need for adding this to PCIMe. You seem to be arguing 
that the policyRule is itself an aggregation of different conditions and 
actions that have different scopes and/or administrative domains. I'm 
unconvinced that we even have a use case for this, and even if there is 
one, I think that if the components of a policyRule are really that 
different, you're overloading the policyRule and it should be split into 
multiple rules.

I'd suggest you provide a detailed use case that clearly shows the benefits 
of optional rules and aggregating components that affect different PEPs or 
have different scopes. In doing that, I'd also be appreciative of you 
showing why existing constructs fail.

regards,
John

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 20 Apr 2001 10:34:52 +0200

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.

Marcus

--On Thursday, April 19, 2001 1:04 PM -0400 Lee Rafalow 
<[email-masked]> wrote:

> current model: 1) exclude it, or 2) have a second, lower priority rule
> that excludes it (most likely with a different action).  That is, the
> model only supports required conditions (and, I personally, don't
> understand optional conditions).
>
> optional actions at this point because the behavior when a failure occurs
> is submodel and/or implementation dependent.
>
> for which there is no semantic routine should be rejected.  If the analog
> of a compiler fits (and I think it does) then it can be argued that the
> whole policy should be rejected (compilation error) since a single
> missing rule may dramatically change the network behavior.   Actually, I
> think we should have text that says the policy MUST be rejected.
>
>
> Lee M. Rafalow

---

From: "Lee Rafalow" <[email-masked]>
Date: Fri, 20 Apr 2001 09:06:07 -0400

Marcus,

> FALSE, by TRUE? or skip it?

What I meant by "exclude it" is that if a policy author intends a condition
to be "optional" then the author should just exclude the condition (because
I don't understand an optional condition).  I do not think that there is ANY
machine interpretation for a condition for which there is no syntax or
semantics.  It's the same as telling a compiler that you want it generate
code for a nonexistant language element.  The compiler generates an error,
continues to parse as best it can flagging other errors but does not
generate any code.

> an action, because it is not known.

My answer is 1 and 2 above.  The Policy Management Tool may have an
opportunity to interact with the rule author but if it can't make sense of
the rule, then it shouldn't generate the policy.  The PDP should reject
policies that contain syntax and/or semantics that it does not understand
and the PEP should do likewise.  To do otherwise is to make assumptions
about the intent of the policy and if we could do that we wouldn't need the
rule author at all.  Run-time errors should be confined as best as possible
to errors caused by network state rather than by faulty rules.

Lee M. Rafalow

---

From: "Michael See" <[email-masked]>
Date: Fri, 20 Apr 2001 09:40:57 -0400

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

---

From: "Lee Rafalow" <[email-masked]>
Date: Fri, 20 Apr 2001 12:34:03 -0400

Yes, I understand that there are other cases than the optional case where a
policy component may not understand a condition or action.  My assertions
are meant to be general and not restricted to just the case where this
thread began.

As for your example of IPSP and RSVP semantics getting mixed together, I
believe this example helps makes my case.  Either the roles or the rules or
both were misdefined and the policy should not (MUST NOT, IMO) be enforced.
Like many technologies, policy has potential for both good and bad outcomes.
Even when policy is well-formed, it has potential for unanticipated (bad)
results; putting brakes in to prevent bad results from poorly-formed
policies is a good thing.

Cheers.

Lee M. Rafalow
----- Original Message -----
From: "Marcus Brunner" <[email-masked]>
To: "Lee Rafalow" <[email-masked]>; "IETF Policy"
<[email-masked]>
Sent: Friday, April 20, 2001 11:47 AM
Subject: Re: criticality of extended conditions and actions

> Lee,
>
> The problems are not optional conditions, but conditions, which are not
> supported in the execution engine. Think of the IPSP engine executing a
> RSVP-condition (the example may be odd)
>
> Marcus
>
> --On Friday, April 20, 2001 9:06 AM -0400 Lee Rafalow
> > What I meant by "exclude it" is that if a policy author intends a
> > condition to be "optional" then the author should just exclude the
> > condition (because I don't understand an optional condition).  I do not
> > think that there is ANY machine interpretation for a condition for which
> > there is no syntax or semantics.  It's the same as telling a compiler
> > that you want it generate code for a nonexistant language element.  The
> > compiler generates an error, continues to parse as best it can flagging
> > other errors but does not generate any code.
> >
> >>
> >> 1) policy definition language to LDAP translator detects it (needs to
> >> know what policy engine is used)
> > about the intent of the policy and if we could do that we wouldn't need
> > the rule author at all.  Run-time errors should be confined as best as
> > possible to errors caused by network state rather than by faulty rules.
> >
> >
> > Lee M. Rafalow

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 20 Apr 2001 17:45:06 +0200

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:

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

Adenauerplatz 6
D-69115 Heidelberg
Germany

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 20 Apr 2001 17:47:35 +0200

Lee,

Marcus

Adenauerplatz 6
D-69115 Heidelberg
Germany

---

From: "Mircea Pana" <[email-masked]>
Date: Fri, 20 Apr 2001 18:00:48 -0400

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.

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 23 Apr 2001 10:17:31 +0200

I aggree with Lee, that the whole rule should fail to load (your proposal 
number 1). He convinced me, that otherwise really bad things may happen in 
the network.

The question remains, what is the entity of loading, probably even the 
whole entity may fail to load (the entity of loading may be very 
implementation dependent). If a rule fails to load, it may be wise to 
disable the whole group the rule is in.

Marcus

--On Friday, April 20, 2001 6:00 PM -0400 Mircea Pana 
<[email-masked]> wrote:

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

Adenauerplatz 6
D-69115 Heidelberg
Germany