Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn ical meeting, 1/24/01 - 1/26/01)

From: "Mircea Pana" <[email-masked]>
Date: Thu, 8 Feb 2001 18:19:21 -0500

I agree that the Priority should be placed on the association instead of the
container. What I actually intended to suggest is that (from the component
ordering point of view) there are two types of containers: PolicySet and
PolicySequence. Wrt. the Decision Strategy, a PolicySet should be treated
differently from a PolicySequence.
 
IMO the Decision Strategy is not applicable to a Set (which should have a
"All" behavior), while it makes perfect sense on a PolicySequence. In
addition, a PolicySequence could be restricted to strict-ordering of its
components (equal priority not allowed), therefore avoiding the ambiguity
described by:
> > <js> 
> > This begs the question, "What happens if there are multiple 
> > PolicyRules of the same priority"? Then the DecisionStrategy 
> > property doesn't help. So, looking at the paragraph below, I 
> > *guess* that your answer would be that it doesn't matter 
> > which PolicyRule executes, as long as only one executes. 
> > This behavior is inconsistent with introducing the property 
> > in the first place. 
> > </js> 

Thanks,
Mircea.

-----Original Message-----
From: Yoram Snir [mailto:[email-masked]]
Sent: Thursday, February 08, 2001 2:48 PM
To: Pana, Mircea [CAR:5E20:EXCH]; 'policy'
Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn
ical meeting, 1/24/01 - 1/26/01)

IMO, the priority should be placed int he association and not with the
container.The obvious example for why the association is the right place is
when a policy rule is used with in 2 different policy groups. The priority
is a property of the association, not the container and not the rule (since
the same rule is used by different containers, in different sequence/
priority.
Yoram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Mircea Pana
Sent: Tuesday, February 06, 2001 11:02 PM
To: policy
Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn
ical meeting, 1/24/01 - 1/26/01)

My 2c. worth comments on Priority: 

The "migration" of the Priority property from PolicyRule (in QPIM also
present in a gpsPolicyGroup) to the PolicyXXXInPolicyXXX (or PolicySet, or
PrioritizedPolicyComponent) changes its aspect from global to local. This,
definitely, makes it more flexible.

However, IMO, the focus should be placed on the container instead of its
components. I.e. The concept required here is a container with *sequenced*
policy components (I would call it: PolicySequence). The Priority property,
placed on the associations is just a way to implement it.

For example: 
Consider a PolicyGroup with two PolicyRules as components: PR1 (higher
priority) and PR2 (lowed priority). The results of applying this PolicyGroup
to a policy target is the same in all the following cases:

- 100 (PR1) and 1 (PR2) 
- 2 (PR1) and 1 (PR2) 
- or "HIGH" (PR1) and "LOW" (PR2) 
the only thing that matters is the sequence. 

I also realize that in some cases the order is not important. In such cases
a PolicySet would be the appropriate concept.

Regards, 
Mircea. 

> -----Original Message----- 
> From: Lee Rafalow [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Tuesday, February 06, 2001 12:17 PM 
> To: policy 
> Subject: Decision Strategies (Re: Preliminary results from PCIMe 
> technical meeting, 1/24/01 - 1/26/01) 
> 
> 
> John, Here are some responses to your comments on priorities 
> and decision 
> strategies.  Cheers, Lee 
> 
> > >  2.2.6. Priorities and Decision Strategies 
> > > 
> > > Drawing from both QPIM and ICIM, the priority property 
> > > has been deprecated in PolicyRule, and placed instead on 
> > > the associations PolicyRuleInPolicyGroup, 
> > > PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, and 
> > > PolicyRuleInPolicyRule. (Obvious question: would it be 
> > > better to introduce a superclass 
> > > PrioritizedPolicyComponent for these four associations, 
> > > just to contain the priority property?  The answer is 
> > > probably "yes".)  The QPIM rules for resolving relative 
> > > priorities across nested PolicyGroups and PolicyRules 
> > > have been incorporated into PCIMe as well. 
> > 
> > <js> 
> > What's the point of having a PrioritizedPolicyComponent 
> > aggregation (these are aggregations, not associations)? This 
> > only makes sense if there is also a 
> > NonPrioritizedPolicyComponent aggregation. Because 
> > eventually, someone is going to want order or some other 
> > semantic added to one or more of these aggregations, and 
> > then we are going to have to go through the hell of 
> > deprecating things again. Since this is clearly an 
> > optimization, why not wait and get some implementation 
> > experience first? 
> > </js> 
> 
> Bob was, I think, correctly hinting at re-examining some of 
> the inheritance 
> hierarchy for a couple of classes.  While working on the section about 
> decision strategies, I found myself writing about decision 
> strategy sets, 
> i.e., the abstraction for PolicyGroup and PolicyRule that 
> contain other 
> policy groups and rules and have a homogeneous decision 
> strategy.  This 
> abstraction is natural for the inheritance hierarchy in that 
> a PolicySet 
> (pick a better name of you like) is an abstraction for PolicyGroup and 
> PolicyRule and it defines the PolicyDecisionStrategy 
> property.  It would 
> then have the PolicySetComponent aggregation (my rename of Bob's 
> PrioritizedPolicyComponent) as an abstraction for the 
> PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, 
> PolicyRuleInPolicyGroup 
> and PolicyRuleInPolicyRule aggregations wherein the Priority 
> property is 
> defined.  With the complexity being added to groups and rules, this 
> abstraction makes it much easier to think about the concepts 
> of decision 
> strategies and priorities. I've asked the other authors to 
> render an opinion 
> on this suggestion but I haven't heard back yet.  Opinions 
> from the broader 
> community are also welcome. 
> 
> > > With the removal of the priority property from 
> > > PolicyRule, a new modeling dependency has been 
> > > introduced: in order to prioritize a PolicyRule 
> > > relative to other PolicyRules, the rules must be 
> > > placed in a PolicyGroup. 
> > 
> > <js> 
> > I think you missed the reusable case. Assuming that you do 
> > add explicit text saying that you can put anything in a 
> > PolicyRepository, then what if you have a PolicyRule that 
> > contains two reusable PolicyRules? Here, you use the 
> > association (not aggregation) 
> > PolicyElementInPolicyRepository to associate any subclass of 
> > Policy to a PolicyRepository. Therefore, if you REALLY want 
> > to do this, you should add the 
> > PolicyElementInPolicyRepository association, defined in 
> > QPIM, to PCIMe. 
> > 
> > Note that this produces a LOT of additional complexity. I'm 
> > not sure it's a Good Thing. But the facility is there if you 
> > want to explore it. 
> > </js> 
> 
> What Bob missed in his summary was that rules can be in other 
> rules in the 
> proposed rule structure.  But the essential point that rules 
> need a context 
> to have priority is correct and, as a byproduct of the agreement to 
> deprecate the use of PolicyRule.Priority, that context is 
> proposed to be 
> explicitly defined by the aggregation discussed above. 
> PolicyElementInPolicyRepository has nothing to do with priority...the 
> repository (or "ReusablePolicyContainer" or whatever we call 
> it) does not 
> establish a context for priority evaluation; it's simply a 
> container for 
> reusable policy components.  The context for priority is tied to the 
> decision strategy on a containing group or rule.  Hopefully, 
> this will all 
> be clearer when I've written the section in the new draft. 
> 
> > >    In the absence of any clear, general criterion for 
> > > detecting policy conflicts, the PCIM restriction stating 
> > > that priorities are relevant only in the case of 
> > > conflicts has been removed.  In its place, a 
> > > DecisionStrategy property has been added to PolicyGroup 
> > > class, to allow the policy administrator to select one 
> > > of two behaviors with respect to rule evaluation: either 
> > > perform the actions for all PolicyRules whose 
> > > conditions evaluate to TRUE, or perform the actions 
> > > only for the highest-priority PolicyRule whose conditions 
> > > evaluate to TRUE. The QPIM rules for applying decision 
> > > strategies to a nested set of PolicyGroups and 
> > > PolicyRules were also imported. 
> > 
> > <js> 
> > This begs the question, "What happens if there are multiple 
> > PolicyRules of the same priority"? Then the DecisionStrategy 
> > property doesn't help. So, looking at the paragraph below, I 
> > *guess* that your answer would be that it doesn't matter 
> > which PolicyRule executes, as long as only one executes. 
> > This behavior is inconsistent with introducing the property 
> > in the first place. 
> > </js> 
> 
> Yes.  For "FirstMatching" only one rule gets executed, so if 
> the submodel 
> and adminstrator decide to permit non-deterministic rules, 
> then it up to the 
> implementation to decide which of the equal priority rules to 
> execute when 
> more than one matches. 
> 
> I don't understand how this behavior is inconsistent with the 
> introduction 
> of a priority property.  I don't personally recommend that 
> derived models 
> permit non-deterministic priorities, but when they do, this 
> is the only 
> reasonable interpretation.  The PCIM notion that priority 
> applies only to 
> conflicts has two problems: 1) it doesn't explain the 
> "FirstMatching" use of 
> priority and 2) it relies on an undefined notion of 
> "conflicting."  The 
> obvious conflicts (e.g., set DSCP to x and set DSCP to y are 
> still resolved 
> by priority in both a FirstMatching and AllMatching strategy; 
> either only 
> one gets executed or both get executed and the one evaluated 
> last wins (an 
> interesting notion of priority, I admit).  Perhaps we should 
> rename the 
> Priority property to EvaluationOrder?  (We discussed this as well and 
> decided to leave it alone, but I'm guessing we could be persuaded 
> otherwise.) 
> 
> Again, hopefully this will all be clear when I've written the 
> section in the 
> new draft.  We discussed having 3 decision strategies: FirstMatching, 
> AllMatching, AllNonConflictingMatching and decided to only 
> have two...unless 
> someone can define the AllNonConflictingMatching strategy and 
> the underlying 
> definition of "conflicting." 
> 
> > >    The question of whether to require unique priority 
> > > values for the PolicyRules in a PolicyGroup was raised and 
> > > discussed, but the decision was to allow these values to 
> > > collide within a PolicyGroup, to indicate "don't care". 
> > > Submodels of PCIMe are free to add the restriction that 
> > > priority values not collide within a PolicyGroup. 
> > > 
> 
> 
>

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 09 Feb 2001 15:18:33 +0100

>I agree that the Priority should be placed on the association instead of the container. >What I actually intended to suggest is that
>(from the component ordering point of view) there are two types of containers: PolicySet >and PolicySequence. Wrt. the Decision
>Strategy, a PolicySet should be treated differently from a PolicySequence.

If I recall our meeting correctly, we discussed about the difference,
but decided to go only with the priority. The meaning is a little
different depending on the decision strategy of the group.

Marcus
-- 

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: "Yoram Snir" <[email-masked]>
Date: Fri, 9 Feb 2001 21:35:35 +0200

RE: Decision Strategies (Re: Preliminary results from PCIMe technical
meeting, 1/24/01 - 1/26/01)IMO, policy set should be modeled by a policy
group with a set of rules with identical priority. I don't see the reason
for complicating this by adding another class.
Yoram,
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Mircea Pana
  Sent: Friday, February 09, 2001 1:19 AM
  To: 'ysnir'; 'policy'
  Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn
ical meeting, 1/24/01 - 1/26/01)

  I agree that the Priority should be placed on the association instead of
the container. What I actually intended to suggest is that (from the
component ordering point of view) there are two types of containers:
PolicySet and PolicySequence. Wrt. the Decision Strategy, a PolicySet should
be treated differently from a PolicySequence.

  Thanks,
  Mircea.

    -----Original Message-----
    From: Yoram Snir [mailto:[email-masked]]
    Sent: Thursday, February 08, 2001 2:48 PM
    To: Pana, Mircea [CAR:5E20:EXCH]; 'policy'
    Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe
techn ical meeting, 1/24/01 - 1/26/01)

      -----Original Message-----
      From: [email-masked]
[mailto:[email-masked]]On Behalf Of Mircea Pana
      Sent: Tuesday, February 06, 2001 11:02 PM
      To: policy
      Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe
techn ical meeting, 1/24/01 - 1/26/01)

      However, IMO, the focus should be placed on the container instead of
its components. I.e. The concept required here is a container with
*sequenced* policy components (I would call it: PolicySequence). The
Priority property, placed on the associations is just a way to implement it.

      For example:

      - 100 (PR1) and 1 (PR2)
      - 2 (PR1) and 1 (PR2)

      I also realize that in some cases the order is not important. In such
cases a PolicySet would be the appropriate concept.

      Regards,
      Mircea.

      > From: Lee Rafalow [mailto:[email-masked]]