Subject: Re: PCIMe: GroupNumber deprecation

From: "Mircea Pana" <[email-masked]>
Date: Mon, 23 Jul 2001 17:21:47 -0400

I'm re-posting this message because it may have been dropped by the
mailing list. Sorry if you receive it again.

Regards,
Mircea.

"Pana, Mircea [CAR:5E20:EXCH]" wrote:
> 
> Bob,
> 
> While evolution is a sine-qua-non principle, supporting the legacy is
> always a challenge that gets in the way. Difficult decisions are
> eventually made in order to break the vicious cycle.
> 
> PCIMe includes concepts deprecation in favor of new, more efficient
> ones. For example PolicyRule.Priority is deprecated in favor of the more
> manageable PolicySetInSystem.Priority or PolicySetComponent.Priority.
> Similarly, the proposed deprecation of
> CompoundedPolicyCondition.GroupNumber in favor of a simpler aggregation
> method has its value.
> 
> In conclusion, while I sustain the proposal, I also understand the
> difficulties related to its adoption therefore I agree that the decision
> should belong to the entire WG.
> 
> Best regards and many thanks,
> Mircea.
> 
> Robert Moore wrote:
> >
> > Mircea,
> >
> > Your comments have gotten the PCIMe authors talking
> > among ourselves, which, I suppose, is a Good Thing.
> > We've pretty much reached an impasse, though, so it's
> > time to see what comments we get from the list.
> >
> > Very briefly, you've proposed an alternative way of
> > combining PolicyConditions.  There are two places
> > where this alternative method might be applied:
> >
> > A. In aggregating conditions into a PolicyRule,
> >    where we already (in RFC 3060) have a method
> >    that uses GroupNumber.
> >
> > B. In aggregating conditions into a
> >    CompoundPolicyCondition, which appeared earlier
> >    in QPIM, but is looking to be standardized for
> >    the first time in PCIMe.
> >
> > Among the PCIMe authors, we have two firmly held
> > positions:
> >
> > 1. Because of successful implementation experience
> >    with RFC 3060, we don't want to change to your
> >    method for A.  However, we have no problem with,
> >    and in fact see some merit, in changing to your
> >    method for B.
> >
> > 2. What's most important is that we use the same
> >    method for aggregating conditions in both A
> >    and B.  It's less important which method it is,
> >    so long as it's the same in both places.
> >
> > Taken together, these positions mean that we don't
> > use your method at all, but instead stay with the
> > existing method for both A and B.  But this call
> > belongs to the WG as a whole, not to the authors.
> >
> > Other opinions?
> >
> > Regards,
> > Bob
> >
> > Bob Moore
> > Advanced Design and Technology
> > Application Integration Middleware Division
> > IBM Software Group
> > +1-919-254-4436
> > [email-masked]
> >
> > "Mircea Pana" <[email-masked]>@raleigh.ibm.com on 07/11/2001
> > 04:18:19 PM
> >
> > Please respond to "Mircea Pana" <[email-masked]>
> >
> > Sent by:  [email-masked]
> >
> > To:   Lee Rafalow <[email-masked]>
> > cc:   IETF Policy <[email-masked]>
> > Subject:  Re: PCIMe: GroupNumber deprecation
> >
> > 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)
> >
> >   |
> >
> >   +-(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)
> >
> > one could have:
> >
> >  Rule_0
> >
> >   |
> >
> >   +-(1..1)->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)
> >
> > 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.
> >
> > Lee Rafalow wrote:
> >
> > >
> >
> > > 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.