Re: gpsPolicyGroup class in qos info model

["Luis A. Sanchez" <lsanchez@xxxxxxx>]

Folks, lets keep this discussion to the Policy Framework mailing list
only.

Luis

Marcus Brunner wrote:

> John,
>
> John Strassner wrote:
> >
> > PolicyRuleInPolicyRule is used to build sub-rules. We also
> > allow for PolicyGroupInPolicyRule to build a sub-rule, with
> > a policyGroup as a nested container. This capability is not
> > in PCIM.
> >
>
> Do you have an example, motivating why the rule in the rule is useful?
> Is there a specific application of this modeling for QPIM?
> I personally do not like having a rule playing so many different role.
> The containment is dealt with in the policy group, why should a policy
> rule also be a container for sub-rules?
>
> > As far as the context, sub-rules execute before their
> > containing rules, as explained in the draft.
> >
>
> Thank you, I have not found this in the draft.
>
> > I not only don't like conditions in gpsPolicyGroup, I don't
> > think they work.
> >
>
> I do not like the as well.
>
> Marcus
>
> > regards,
> > John
> > ----- Original Message -----
> > From: "Marcus Brunner" <brunner@xxxxxxxxxxxx>
> > To: "Ron Cohen" <ronc@xxxxxxxxx>
> > Cc: "Mahadevan Iyer" <iyermahadevan@xxxxxxxxx>;
> > <policy@xxxxxxxxxxxxxxx>; <ipsec-policy@xxxxxxxx>
> > Sent: Thursday, December 07, 2000 9:29 PM
> > Subject: 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