Subject: RE: policyValidityPeriodCondition

From: Andrea Westerinen <[email-masked]>
Date: Thu, 18 Feb 1999 16:03:53 -0800

Let me try restating your position just to be sure that I got it:

policyValidityPeriod would be a subclass of policyCondition and MAY be
included in the DNF/CNF or MAY be specially tied to the policyRule via
another attribute.  IE, it is in the policyRuleConditionList or in another
attribute on policyRule.

In CIM, that would translate to 2 associations from policyValidityPeriod to
policyRule.  One is the ContainedPolicyCondition (already defined and
inherited to policyValidityPeriod), and the other might be an
ANDedPolicyValidityPeriod.  policyValidityPeriods associated using
ContainedPolicyConditions follow the DNF/CNF of the Rule.
ANDedPolicyValidityPeriods are DNF'ed with the result of the
ContainedPolicyConditions. If the ANDedPolicyValidityPeriod associations can
have cardinality "many to many" (ie, are multi-valued), you start to impose
even more DNF structure to it.

How is this different than any set of conditions that you want to AND/OR
together in various combintations?  Are we now able to state that any
arbitrary set of conditions follow DNF/CNF and another arbitrary set is then
DNF'ed with the result? 

I think that this is a very slippery slope and could lead to lots of
confusion.
Andrea

-----Original Message-----
From: Black, David [mailto:[email-masked]]
Sent: Wednesday, February 17, 1999 1:59 PM
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]
---------------------------------------------------