[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