Subject: [Policy] PCLS classes deprecated in PCELS

From: "Pana, Mircea" <[email-masked]>
Date: Thu, 4 Sep 2003 17:09:46 -0500

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.

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.

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.

Opinions?

5. pcimRuleActionAssociation - same suggestion as for the
pcimRuleConditionAssociation class

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."

Best Regards,
Mircea.

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Friday, August 29, 2003 11:15 AM
> To: [email-masked]
> Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> 
> 
> What an underwhelming interest in this document.
> 
> When I start reading it, I see in the abstract:
>    This document defines a number of changes and extensions to the
>    Policy Core LDAP Schema [PCLS] based on the specifications of the
>    Policy Core Information Model Extensions [PCIM_EXT]. The changes
>    include additional object classes previously not covered, 
> deprecation
>    of some object classes and changes to the object class hierarchy
>    defined in [PCLS].
> 
> And so I immediately wonder... is it really OK that this document
> deprecates some object classes ??
> 
> Possibly so... but I'd like to hear some of the PCIM, PCIM-EXT and
> PCLS authors/ediotrs to explicitly say so. PLEASE!
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: vrijdag 15 augustus 2003 11:45
> > To: [email-masked]
> > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> > 
> > 
> > Joel asked from the WG:
> > > -----Original Message-----
> > > From: Joel M. Halpern [mailto:[email-masked]]
> > > Sent: woensdag 6 augustus 2003 17:33
> > > To: [email-masked]
> > > Subject: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> > > 
> > > 
> > > The revised Internet draft is now available in the I-D repository:
> > > http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ex
> > > t-schema-03.txt
> > > 
> > > I believe it is appropriate for this document to go forward as an 
> > > individual contribution that has been reviewed by a (our) 
> > working group.
> > > As such, I will give folks one more chance to comment 
> > before indicating 
> > > that the author's can (and should) contact the AD for this.
> > > Please respond by August 20 (preferably sooner) with any 
> comments, 
> > > concerns, issues, etc.  It would even be helpful if folks 
> > would merely 
> > > indicate that they had read and liked the document.
> > > 
> > 
> > So did anyone actually READ (or even BROWSE) the document???
> > 
> > PLEASE be active and participate!
> > 
> > Bert
> > > Thank you,
> > > Joel M. Halpern
> > 
> > _______________________________________________
> > Policy mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/policy
> > 
> 
> _______________________________________________
> Policy mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/policy
>

---

From: Ryan Moats <[email-masked]>
Date: Tue, 9 Sep 2003 09:26:27 -0500

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