[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gpsPolicyGroup class in qos info model



Ron,

I agree with Mahadevan, that I do not like the policyRuleInPolicyRule method, 
because 
a) there are now two different grouping models,
b) it is unclear what happens to the context when the ruleInrule is executed 
(full new start of execution engine or reuse the context)
c) I do not see the need for rulesInrules, what makes them different compared to 
the grouping already available

However, I do not agree to add a condition to the group. I think what is 
available is enough.

Marcus  

Quoting Ron Cohen <ronc@xxxxxxxxx>:

> Mahadevan,
>
> Can you provide more details why you prefer to change the gpsPolicyGroup
> than using the current policyRuleInPolicyRule method?
>
> Thanks
> Ron
>
>
> >I would like to suggest an update to the
> >gpsPolicyGroup class.
> >This also relates to the PolicyRuleInPolicyRule usage.
> >
> >I need to indicate that a group of policy rules should
> >be checked only if the traffic matches some aggregate
> >conditions. These aggregate conditions summarize the
> >conditions within the policy rules.
> >
> >I would like to specify the aggregate conditions at
> >the level of the gpsPolicyGroup. An alternative is to
> >use the PolicyRule + PolicyRuleInPolicyRule instead of
> >the gpsPolicyGroup. However I prefer to use the
> >gpsPolicyGroup.
> >
> >I would suggest adding an aggregate policy condition
> >to the gpsPolicyGroup. This condition would typically
> >be a gpsPolicyCompoundCondition.
> >
> >
> >Thanks
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Shopping - Thousands of Stores. Millions of Products.
> >http://shopping.yahoo.com/
>
> 



Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: brunner@xxxxxxxxxxxx
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