Re: 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