Subject: Re: gpsPolicyGroup class in qos info model

From: Mahadevan Iyer <[email-masked]>
Date: Sun, 10 Dec 2000 20:26:41 -0800 (PST)

--- John Strassner <[email-masked]> 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/

---

From: "John Strassner" <[email-masked]>
Date: Mon, 11 Dec 2000 11:25:57 -0800

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" <[email-masked]>
To: "John Strassner" <[email-masked]>; "Marcus Brunner"
<[email-masked]>; "Ron Cohen" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Sunday, December 10, 2000 8:26 PM
Subject: Re: gpsPolicyGroup class in qos info model