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