Subject: Re: criticality of extended conditions and actions

From: "Robert Moore" <[email-masked]>
Date: Fri, 20 Apr 2001 10:55:54 -0400

First, let me say that I agree with Lee and some of the
other authors, that this capability isn't something that
we need in PCIMe.  That said, let me bring into the
discussion an example of an area where something like this
capability does make sense.

In CMIP / GDMO, we have a general extension mechanism for
EventReports and Actions called ManagementExtension.
A ManagementExtension contains 3 elements: an OID to
identify which extension it is, an ANY DEFINED BY whose
format and semantics are determined by the OID, and a
boolean field called "significance" which corresponds, to
some extent, to the Criticality property we're discussing
here.  The "significance" field works like this:

  - If "significance" = TRUE, then if the receiver doesn't
    understand the ManagementExtension, it is supposed to
    behave as if it never received the Action or
    EventReport containing the ManagementExtension.
  - If "significance" = FALSE, then if the receiver
    doesn't understand the ManagementExtension, it is
    supposed to process the Action or EventReport as if
    it did not contain that particular ManagementExtension.

A use case for "significance" = FALSE would be a
ManagementExtension for an alarm to report the detecting
module.  (Actually, this may be in the standard alarm -- I
just don't remember.  But you get the idea.)  The desired
behavior is for an alarm receiver that doesn't understand
this ManagementExtension to process the remainder of the
alarm.

A use case for "significance" = TRUE would be a boolean
ManagementExtension "isFictional".  If an alarm receiver
doesn't understand this ManagementExtension, it should
ignore the alarm completely.  (This is what went wrong
with the famous Orson Welles "War of the Worlds"
broadcast -- listeners who didn't understand that
isFictional was TRUE acted on the "alarm" anyway.)  It's
safe for a vendor, or another standard, to introduce a
ManagementExtension like isFictional precisely because
the "significance" field for ManagementExtension is
defined in the core GDMO model.

Now if we tried very hard, we *might* be able to construct
a case where we'd like our PolicyRules to work this way.
But I can't do this for Policy nearly as easily I can for
the CMIP Actions and EventReports.  Hence my assessment
that this is a complication we should not be adding to
our PCIM / PCIMe model.

Regards,
Bob

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

"Lee Rafalow" <[email-masked]>@raleigh.ibm.com on 04/20/2001
09:06:07 AM

Please respond to "Lee Rafalow" <[email-masked]>

Sent by:  [email-masked]

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

Marcus,

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

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.

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

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
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: "Mircea Pana" <[email-masked]>
Date: Mon, 23 Apr 2001 11:01:13 -0400

I have to agree that in most cases the Policy Model already has
mechanisms for expressing the optional aspect of various components. I
did try very hard (at Bob's suggestion ;-) but only came up with
impractical use cases where "criticality" would be the only way out.
This isn't worth the WG's attention at this point - may have been a "red
herring".

Regards,
Mircea

P.S.
Whether or not unsupported components should be acceptable in
policyRules, is a different question. I'll address it in an other
message.

Robert Moore wrote:
[snip]