Subject: RE: policyValidityPeriodCondition

From: Andrea Westerinen <[email-masked]>
Date: Thu, 18 Feb 1999 15:31:36 -0800

This is getting scary.  If you have multiple validity periods that should be
analyzed together in an ORed combination then you have an implicit DNF
condition structure....

(period1 OR period2 OR period3 ...) AND (other policyConditions)

So, why don't we just stick with the DNF/CNF structure?  

Otherwise, how do you support the more generic case of: 

(period1) OR (other policyConditions)

For example, IF (M-F, 8-5) OR (Joe is logged in) THEN (forward traps to
Joe's email).

Andrea

-----Original Message-----
From: Glenn Waters [mailto:[email-masked]]
Sent: Thursday, February 18, 1999 6:36 AM
To: Black, David
Cc: Andrea Westerinen; [email-masked]
Subject: RE: policyValidityPeriodCondition

the solution you (david) propose is exactly the same technically as was in
the -00 draft. the difference is that we are now calling the
policyValidtyPeriod by a new name.  whatever we call the validity period, i
agree with you. have a pointer to the validity period in the rule and state
that it is ANDed at the top level.

the pointer should be multi-value so that there can be multiple validity
periods for a rule.  the rule is valid in ANY of the validity periods are
valid and the condition is valid. (this was in a post -00 version of the
draft, but was changed before the -01 version was released.)

/gww

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Black, David
> Sent: Wednesday, February 17, 1999 16:59
> To: 'Andrea Westerinen'; [email-masked]
> Cc: [email-masked]
> Subject: RE: policyValidityPeriodCondition
>
>
> > To get the ball rolling on policyValidityPeriodCondition, I
> still maintain
> > that including the validity period as a Condition is the right generic
> > answer.  In some scenarios, it should be ANDed and in others,
> ORed.  There
> > is no single answer.  So, it is subclassed from policyCondition and
> > therefore, can be included in a rule's DNF/CNF.
>
> Just in case it's not clear, I agree 100% that this is necessary.
> policyValidityPeriodCondition
> is a condition, and hence subclassing it from policyCondition is the right
> thing to do.
>
> > However, I do understand the issue when the canonical form is
> DNF but the
> > validity period is an exception to this and should be ANDed.
>
> Right, the point is to represent the validity period once, rather
> than once
> per
> clause that is ORed (latter representation makes it too easy to
> get validity
> periods
> in the various clauses that are just slightly different, leading to
> unintended results).
>
> > Here is a compromise...  Add an attribute to policyRule as follows:
>
> Unfortunately, this cure is worse than the disease because it changes the
> structure of the DNF/CNF (any policyValidityPeriodCondition buried in the
> structure suddenly assumes global scope if this attribute is on).  In
> particular,
> the results when there are multiple policyValidityPeriodConditions in
> different
> clauses of the DNF/CNF is confusing/counterintuitive (bad news).
>
> My preferred solution is to make the policyValidityPeriodCondition for the
> rule
> an attribute of the rule -- add an attribute to the policyRule
> class that is
> a
> DN reference to the policyValidityPeriodCondition that is ANDed at the top
> level - if null, there is no such condition.  This is similar to the
> policyRuleEnabled
> attribute that we already have, and allows parts of the rule to use
> policyValidityPeriodConditions that are different from that which
> applies to
> the
> entire rule.
>
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
> [email-masked]
> ---------------------------------------------------
>
>