RE: PCLS classes deprecated in PCELS

Please see comments inline.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     +1.719.785.0644
email:    [email protected]

-----Original Message-----
From: Pana, Mircea [mailto:[email protected]] 
Sent: Thursday, September 11, 2003 4:22 PM
To: '[email protected]'
Cc: '[email protected]'; '[email protected]'
Subject: RE: [Policy] PCLS classes deprecated in PCELS

IMO the usage of schema items corresponding to deprecated concepts would be
in conflict with the model (in this case PCIMe).

<js> Au contraire, it is inappropriate to deprecate LDAP schema.

You have a tough choice - try and design a true update of PCLS, or say "Gee,
since PCIMe changed the playing rules, so can we. Unfortunately, what you've
done is try to do both - build a new design under the guise of an "update",
and it doesn't work. You need to choose one approach or the other. And if
you choose update, then you need to be compatible with PCLS. Currently,
you're not. </js>

However, a "peaceful co-existence" would be a very good reason for
compromise. The following proposal gets PCELS out of the "policing business"
and where compliance with PCIMe requires PCLS classes or attributes not to
be used, this is noted with the specific indication "for compliance with
PCIMe implementations shall/shall not use ..." (or rather SHALL / SHALL
NOT). I hope you will find the following acceptable:

<js> But you STILL need to choose one approach or the other, see below </js>

1. Replace the pcimGroupContainmentAuxClass class deprecation with a
paragraph to indicate that "for compliance with PCIMe, implementations shall
use the pcimPolicySet.pcimPolicySetComponentList attribute and a
subordinated pcimPolicySetAssociation entry instead of an attached
pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy Group,
Rule or System".
2. Replace the pcimRuleContainmentAuxClass class deprecation with a
paragraph to indicate that "for compliance with PCIMe,  implementations
shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a
subordinated pcimPolicySetAssociation entry instead of an attached
pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy Group,
Rule or System". 

<js> Upper case SHALL, or just a plain "shall"? </js>

3. The pcimRule* classes would not be deprecated. Instead, the abstract
class pcimRule would be modified to become a subclass of the abstract class
pcimPolicyRule defined in PCELS. A note would be added to indicate that "for
compliance with PCIMe, implementations shall not use the
pcimRule.pcimRulePriority attribute". See also Note_1 below.
4. The class pcimRuleConditionAssociation would be modified to become
subclass of the pcimConditionAssociation class. 
5. The class pcimRuleActionAssociation would be modified to become subclass
of the pcimActionAssociation class. 
6. The pcimRepository* classes would not be deprecated. Instead the abstract
class pcimRepository would be modified to become subclass of the abstract
class pcimReusableContainer defined in PCELS. PCELS would indicate that "for
compliance with PCIMe, the pcimReusableContainer* classes shall be used
instead of the pcimRepository* classes".

<js> These are exactly backwards. A PolicyRule is-a special type of Rule.
Same problem with 4 and 5 - for example, in the old QPIM work, we had
defined the concept of a condition in a condition. Thus, there is (or at
least could be) a marked difference between a condition and a ruleCondition.

Regarding pcimRepository, it shares two things with the other classes in 3-5
- in the LDAP sense, it is exactly backwards, and your proposal ensures
incompatibility. </js>

Note_1: 
Without other changes, the pcimRule would end up having redundant
functionality: 
- pcimRuleConditionList and pcimConditionList for aggregating conditions 
- pcimRuleActionList and pcimActionList for aggregating actions 
etc. 

<js> This assumes that the semantics of aggregating a condition in a rule
are the same as aggregating a condition in other types of objects. I, for
one, disagree with that assumption. </js>

A. One option would be to do nothing about it but this may lead to ambiguous
situations :-( 
B. A second option would be to use the pcimRuleConditionAssociation and the
pcimRuleActionAssociation attributes and the association classes defined by
PCLS in the definition of the pcimPolicyRule. In this case the
pcimPolicyRule* and pcimCompound*AuxClass would not use the same attributes
and association classes to aggregate Conditions and Actions :-(
C. A third option would be to change the pcimPolicyRule definition to: 
   ( [...] SUP pcimPolicySet 
     ABSTRACT 
     MAY ( pcimRuleName 
         $ pcimRuleEnabled 
         $ pcimRuleValidityPeriodList 
         $ pcimRuleUsage 
         $ pcimRuleMandatory ) 
   ) 
(Condition and Action aggregation attributes removed from the Rule class) 
In this case, PCELS would recommend the use of attached
pcimCompound*AuxClass instances as means to aggregate multiple
Actions/Conditions to a Rule.
D. A mix of the previous two: Option B with a note that implementations MAY
choose to support only C. 
Comments and suggestions would be greatly appreciated? Also, I would greatly
appreciate the PCIMe author's opinion wrt. the [non]deprecation.

<js> Your choice depends on whether you believe that we're done, or that
their may be future implementations that want to further refine the
semantics that PCIMe has defined. Your choice must also consider
compatibility with previous PCLS implementations. Since I'm working on one
of those "future" implementations, I would rather see a generic condition
aggregation defined, with the particular case of a policyCondition
aggregated by a policyRule treated as a specialization of that generic
aggregation. </js>

Thanks, 
Mircea. 

  
> -----Original Message----- 
> From: Ryan Moats [mailto:[email protected]] 
> Sent: Tuesday, September 09, 2003 10:26 AM 
> To: Pana, Mircea 
> Cc: '[email protected]'; '[email protected]' 
> Subject: Re: [Policy] PCLS classes deprecated in PCELS 
> 
> 
> 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 
> 
> _______________________________________________ 
> Policy mailing list 
> [email protected] 
> https://www1.ietf.org/mailman/listinfo/policy 
>