Subject: Re: PCIMe: GroupNumber deprecation

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 11 Jul 2001 10:52:28 -0400

Mircia,

Sorry for the delay in responding to this concern.  As long as we confine
the proposed change to CompoundPolicyCondition and
PolicyConditionInPolicyCondition I think it's fine.  I'd rather not modify
PolicyConditionInPolicyRule however because there are implementations that
would have migration problems if we removed the capability to use the PCIM
method.

So, for specifics, I'd suggest we rename CompoundedPolicyCondition to
PolicyConditionStructure and include IsNegated in that superclass.  Then in
the PolicyConditionInPolicyRule subclass, we add the GroupNumber but not in
the PolicyConditionInPolicyCondition subclass.

(I'd like to see a similar renaming of CompoundedPolicyAction as well since,
for both, the PolicyXXXinPolicyRule subclass is not compounded.)

Regards, Lee
----- Original Message -----
From: "Mircea Pana" <[email-masked]>
To: "IETF Policy" <[email-masked]>
Sent: Wednesday, June 13, 2001 3:16 PM
Subject: PCIMe: GroupNumber deprecation

> In PCIMe:
>
> Is the GroupNumber property in the CompoundedPolicyCondition really
> necessary? IMO this grouping mechanism unnecessarily overloads the
> CompoundPolicyCondition semantics. Therefore, I'd like to suggest its
> deprecation.
>
> Without GroupNumber, the CompoundPolicyCondition would represent a
> single level (instead of the current two level) aggregation of
> PolicyConditions. Through CompoundPolicyConditions aggregated by other
> CompoundPolicyConditions one could still build arbitrary complex policy
> conditions.
>
> For example, given a condition like this:
> FlowDirection=IN AND (Source=10.2.0.0/16 OR Source=10.5.0.0/16)
>
> A. With GroupNumber this can be represented as follows:
>
> CompoundC_0 (type=CNF)
>  |
>  +-(group#=1)-> SimpleC_1 (FlowDirection=IN)
>  |
>  +-(group#=2)-> SimpleC_2 (Source=10.2.0.0/16)
>  |
>  +-(group#=2)-> SimpleC_3 (Source=10.5.0.0/16)
>
>
> B. Without grouping, the condition may look like:
>
> CompoundC_0 (type=AND)
>  |
>  +-> SimpleC_1 (FlowDirection=IN)
>  |
>  +-> CompoundC_01 (type=OR)
>       |
>       +-> SimpleC_2 (Source=10.2.0.0/16)
>       |
>       +-> SimpleC_3 (Source=10.5.0.0/16)
>
> Option B seems more intuitive since the aggregation tree and the
> evaluation tree map better to each other.
>
> Regards,
> Mircea Pana.

---

From: "Mircea Pana" <[email-masked]>
Date: Wed, 11 Jul 2001 16:18:19 -0400

Lee,

I agree with your proposal to extend the original model "in a way that,
to the extent possible, preserves interoperability with implementations
of the original PCIM model." (as stated in PCIMe, 1. Introduction).

However, a more radical view would also "spin off" a  PolicyCondition
and a PolicyAction (exactly one of each) from the PolicyRule semantics.
Since CompoundPolicyXXX deals with the aggregation of (one or more)
PolicyXXX instances, it is unnecessary to provide the same aggregation
capabilities in the PolicyRule as well. The PolicyRule instead would be
involved in a one-to-one PolicyXXXInPolicyRule aggregation.

This can be looked at in this way: In PCIM, the PolicyRule includes an
implicit [compound]condition and an implicit [compound]action. In PCIMe
these semantics are fully covered by explicit concepts. Therefore, the
implicit ones are redundant and may be deprecated.

For example instead of:

 Rule_0 (type=CNF)
  |

one could have:

 Rule_0
  |
  +-(1..1)->CompoundC_0 (type=AND)
             |

This would require the deprecation of several properties in the
PolicyRule, change the PolicyXXXInPolicyRule aggregations and a complex
PCIM->PCIMe data migration.

How about making this scenario as a recommended one (SHOULD) in PCIMe?

Regards,
Mircea.

---

From: "Ron Cohen" <[email-masked]>
Date: Thu, 12 Jul 2001 13:01:45 +0200

Mircea,

The compound policy condition and the compound action are needed in order
to provide a mechanism to have reusable conditions and actions. A policy
writer that writes a complex condition needs to be able to keep this
condition in a folder, and reuse it as a condition (or sub-condition)
within several rules. It is not acceptable to allow only one line (one
group) reusable conditions and actions.

Regards
Ron

---

From: "Mircea Pana" <[email-masked]>
Date: Thu, 12 Jul 2001 10:11:34 -0400

Ron,

My arguments are for clarity and explicit semantics. IMO the CompoundXXX
concept does not need to include multiple levels of components
(CompoundedXXX).

This does not exclude the ability to create arbitrarily complex
[reusable] instances. One can achieve this goal by aggregating
CompoundXXX in CompoundXXX by the means of the CompoundedXXX
aggregation. In my previous example both CompoundC_0 and CompoundC_01
may be stored in a folder as reusable conditions. Meanwhile, CompoundC_0
represents a multi-level condition: (C1 AND (C2 OR C3)).

Regards,
Mircea.