Re: PCLS classes deprecated in PCELS

Ryan Moats <[email protected]> Tue, 9 Sep 2003 09:26:27 -0500
Newsgroups gmane.ietf.policy
Message-ID <[email protected]>
On Thu, Sep 04, 2003 at 05:09:46PM -0500, Pana, Mircea wrote:
| PCELS deprecates some of the PCLS classes and attributes for various
| reasons. In some cases, deprecation could have been avoided but in other
| cases this was dictated by PCIMe. (details discussed below) I agree that
| deprecation might create backward compatibility problems where PCELS and
| PCLS implementations attempt to cooperate. BTW, does anybody out there have
| such requirements? Given that PCIMe deprecates a significant number of
| concepts from PCIM, is such cooperation even possible?
| 
| The classes deprecated by PCELS are discussed below:
| 
| 1. The class pcimGroupContainmentAuxClass defined by PCLS provides a single,
| multi-valued attribute that references a set of pcimGroups. This unordered
| aggregation mechanism can not be reused in implementations of PCIMe because
| the model (PCIMe) requires PolicySetComponent associations to be
| prioritized:
| "  5.5. Priorities and Decision Strategies
|    [...] Unlike the earlier definition,
|    PolicySetComponent.Priority MUST have a unique value when compared
|    with others defined for the same aggregating PolicySet.  Thus, the
|    evaluation of rules within a set is deterministically specified. "
| If PCELS allowed pcimGroupContainmentAuxClass, then it would be conflicting
| with PCIMe.
|
| 2. The class pcimRuleContainmentAuxClass defined in PCLS is deprecated by
| PCELS for the same reasons.

Those are not reason to deprecate classes in the more general model.  That's
a reason to say "in this space, this other class should be used".

| 3. The pcimRule* classes defined by PCLS are deprecated and redefined as
| pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority
| property is deprecated. Therefore PCELS redefines the PolicyRule class
| mainly for removing the Priority attribute. An other option would have been
| to leave pcimRule* as they are and then PCELS would have had to specify that
| the pcimRulePriority attribute MUST NOT be used - a less formal solution
| that does not prevent accidental use of the deprecated attribute.
|
| An other reason for replacing the pcimRule* classes is the renaming of the
| attributes that serve in the Rule-Condition and Rule-Action associations.
| pcimRuleConditionList is replaced by pcimConditionList and
| pcimRuleActionList is replaced by pcimActionList. Thus, the new attributes
| along with the new association classes (discussed below) offer a generic
| mechanism for aggregating Conditions or Actions. The use the same
| Condition/Action aggregation mechanism for both Policy Rules and Compound
| Conditions/Action is an optimization in line with the Policy*Structure
| concepts defined by PCIMe.

Since you are rethinking subclass/deprication below, I'd argue rethink it
here.

| The deprecation of the pcimRule* classes is certainly not the only option
| but based on our experience implementing PCIMe this one seemed an acceptable
| compromise. However, any opinions or suggestions from the WG based on their
| experience would be greatly appreciated.
|
| 4. The class pcimRuleConditionAssociation defined by PCLS has probably less
| reasons to be deprecated. It was done simply to keep the Condition
| aggregation (into rules or compound conditions) limited to a single
| association class. Now, looking from this different prospective, I think
| that it is a good idea to retain it.
| 
| So, I suggest the modification of the pcimRuleConditionAssociation to become
| a subclass of the pcimConditionAssociation already defined in PCELS. The
| attributes of the pcimRuleConditionAssociation, all inherited from its
| superclass, would end up being the same ones as previously defined by PCLS.
| Thus, for aggregating Conditions into a Policy Rule, one would have the
| choice of using pcimConditionAssociation or pcimRuleConditionAssociation
| while Condition aggregation into a Compound Condition would be realized only
| through the pcimConditionAssociation class.
| 
| 5. pcimRuleActionAssociation - same suggestion as for the
| pcimRuleConditionAssociation class

This is a much better solution...

| 6. The pcimRepository class defined by PCLS is deprecated by PCELS for
| reasons described in PCIMe:
| "   Because of the potential for confusion with the Policy Framework
|    component Policy Repository (from the four-box picture: Policy
|    Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is
|    a bad name for the PCIM class representing a container of reusable
|    policy elements.  Thus the class PolicyRepository is being replaced
|    with the class ReusablePolicyContainer."

This could also be handled with a subclass.

Ryan