Re: gpsPolicyGroup class in qos info model

["John Strassner" <jstrassn@xxxxxxxxx>]

Hi Mahadevan,

I'm still confused. It sounds like you want to copy the
conditions inside different rules that are contained in
different groups to a higher level of containment in order
to trim the tree, right? This is what I meant when I said:

  "As you say, a policyRule is an atomic object. You're
   asking to "peek inside" a group of policyRules in a
   policyGroup and copy their aggregate conditions out
   into a higher-level condition that you can then
   trap on."

Now, while this may work for PCIM, for QPIM I don't think it
can work, because at the very minimum, this means that you
also have to copy the decision strategies that are applied
to each group of conditions. QPIM provides the ability to
CHANGE decision strategies at each containment level. This
means that you now have to re-create the decision strategies
defined at each container and apply them to the conditions
at each level of containment. You haven't addressed how this
will be done.

In addition, in QPIM, we have nested rules as well as
sub-rules. You can't flatten out the condition in these
cases, or you lose the hierarchy of the structure of the
rules. You also haven't addressed how this will be done.

That's why I continue to have questions.

regards,
John

----- Original Message -----
From: "Mahadevan Iyer" <iyermahadevan@xxxxxxxxx>
To: "John Strassner" <johns@xxxxxxxxx>; "Marcus Brunner"
<brunner@xxxxxxxxxxxx>; "Ron Cohen" <ronc@xxxxxxxxx>
Cc: <policy@xxxxxxxxxxxxxxx>; <ipsec-policy@xxxxxxxx>
Sent: Sunday, December 10, 2000 8:26 PM
Subject: Re: gpsPolicyGroup class in qos info model


> --- John Strassner <jstrassn@xxxxxxxxx> wrote:
> > Hi Mahadevan,
> >
> > I'm still not quite sure I understand your reasoning
> > for the
> > putting an aggregate condition in the gpsPolicyRule
> > class.
>
> Hello John,
>
> there are 2 parts to this reply :
>
>   1. Issues raised in your response,
>   2. Explanation of the requirement.
>
> Issues raised in your response ...
>
>   1. There is no "peeking" inside the rules, it is an
> administrator generated condition. This should answer
> most of your issues related to aggregating conditions
> and decisions.
>
>   2. The PolicyRuleInPolicyRule can satisfy the
> requirement. I have explained my reservations
> regarding using this class in my earlier email.
>
> Explanation of the requirement ...
>
>   1. The requirements is driven from the practical
> issues at the PDP. I have a whole tree of policies and
> nothing but the priority to decide how I traverse the
> tree(at the group level). This could be a very
> expensive. I need to have a quick way of narrowing
> down the possibilities at the top of the tree(where
> the policyGroups are defined). It is a lot more than
> an optimization, it would be a requirement when
> defining policy trees for a carrier network.
>
> Do you see this as a problem that needs to be
> addressed at this level ?
>
>
> Thanks
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of
Products.
> http://shopping.yahoo.com/