RE: PCLS classes deprecated in PCELS

I would like to understand why you have a problem with PCELS inserting a new
class in the inheritance chain of a PCLS defined class. 
 
Let's take #6 for example: PCELS defines a new class pcimReusableContainer
and makes the existing pcimRepository a subclass of the new one. Thus,
once/if the PCELS schema is (incrementally) applied to the Directory server:
A. a PCLS implementation continues to handle pcimRepository entries just
like it did before
B. because a pcimRepository is also a pcimReusableContainer, a PCELS
implementation can also handle such entry correctly (i.e. as a container of
reusable policy components)
C. for a PCELS implementation, the presence of the pcimRepository class in a
pcimReusableContainer entry can trigger additional safeguards to allow the
entry to continue to be compatible with PCLS
D. a PCELS implementation that intends to comply with PCIMe would create
pcimReusableContainer entries that are not pcimRepository.

IMO, if it was the other way around (pcimReusableContainer defined as
subclass of pcimRepository) then D. would never be possible because a
pcimReusableContainer would also be a pcimRepository therefore violating the
PCIMe recommendation.

What situation did you have in mind when you stated that such change would
break PCLS or existing implementations?

Thanks,
Mircea.




> -----Original Message-----
> From: Ryan Moats [mailto:[email protected]]
> Sent: Thursday, September 11, 2003 8:21 PM
> To: David McTavish
> Cc: Pana, Mircea; '[email protected]'; '[email protected]'
> Subject: Re: [Policy] PCLS classes deprecated in PCELS
> 
> 
> On Thu, Sep 11, 2003 at 07:36:05PM -0400, David McTavish wrote:
> | I agree with Ryan for all points except point 6, although, 
> I believe that
> | this change would be easier to manage than in the initial proposal.
> | 
> | d.
> 
> David is right, I misread #6.  That has the same problem as #3-5.
> 
> Ryan
> 
> | -----Original Message-----
> | From: Ryan Moats [mailto:[email protected]]
> | Sent: Thursday, September 11, 2003 7:07 PM
> | To: Pana, Mircea
> | Cc: '[email protected]'; '[email protected]'
> | Subject: Re: [Policy] PCLS classes deprecated in PCELS
> | 
> | 
> | On Thu, Sep 11, 2003 at 05:21:42PM -0500, Pana, Mircea wrote:
> | | IMO the usage of schema items corresponding to deprecated 
> concepts would
> | be
> | | in conflict with the model (in this case PCIMe). 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:
> | | 
> | | 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". 
> | 
> | I can live with these two...
> | 
> | | 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.
> | 
> | I can't live with these three: they would require me to 
> change my working
> | implementation and change the PCLS schema. 
> | 
> | If you are going to do a subclass here and not break PCLS 
> or existing
> | implementations, you have to go the other way:
> | pcimPolicyRule is a subclass of pcimRule, 
> pcimConditionAssociation as a
> | subclass of pcimRuleConditionAssociation, etc.  This 
> changes Note #1 to
> | what are the issues for pcimPolicyRule...
> | 
> | | 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".
> | 
> | Again, I can live with #6.
> | 
> | Ryan
> | 
> | _______________________________________________
> | Policy mailing list
> | [email protected]
> | https://www1.ietf.org/mailman/listinfo/policy
> | 
> | _______________________________________________
> | Policy mailing list
> | [email protected]
> | https://www1.ietf.org/mailman/listinfo/policy
> 
> _______________________________________________
> Policy mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/policy
>