Re: gpsPolicyGroup class in qos info model

["John Strassner" <jstrassn@xxxxxxxxx>]

Hi Mahadevan,

I'm still not quite sure I understand your reasoning for the
putting an aggregate condition in the gpsPolicyRule class. I
also don't think that this works. Let me explain.

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. At the very minimum,
this means that you also have to copy the decision
strategies that are applied to each group of conditions.
Remember that QPIM defines multiple decision strategies, so
you now have to re-create the decision strategies defined at
each container and apply them to the conditions at each
level of containment. Yuck.

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.

Finally, putting in such optimizations sets a dangerous
standard - where do we stop? Does every relationship and
every different case get standardized, or is this better
handled in an application-specific way?

So in summary, I don't think this can work for QPIM, and
doubt that it can work for PCIM in general. Please explain
how you solve the above problems.

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


> Hello Marcus, Ron,
>
>   there are 2 issues mentioned in you responses.
>
> 1. Why not use the PolicyRuleInPolicyRule instead of
> ..
>
>    I must say that if we had started out saying that
> any collection of policies can be logically thought of
> as "a policy"(which I find attractive) I wouldn't have
> minded using this class.
>    However we seemed to have clearly called out the
> notion of a "collection of policies" to be a
> policyGroup. This too has its benefits. This has led
> me to think of the of the PolicyRule as an "atomic"
> class to be aggregated using PolicyGroups.
>
> 2. Why do we need a condition at the level of a
> "collection of policies" ...
>
>    This is an optimization which could be leveraged in
> almost all applications. A PDP can do this on its own
> by analysing the conditions in the contained rules.
> However the administrator can configure far more
> optimal and powerful aggregation of conditions. It is
> possible that these aggregations might be a subset or
> a superset of the aggregation derived by analysing the
> conditions.
>
> Thanks
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of
Products.
> http://shopping.yahoo.com/