RE: [Policy] For the record: Open Issues in PCELS-04 (all closed now)

["John Strassner" <[e-mail]>]

And for the record, I think that notes like this that document issues
and their resolutions are very helpful. ;-)
 

regards,
John

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, March 31, 2004 7:43 AM
To: [e-mail]
Subject: [Policy] For the record: Open Issues in PCELS-04 (all closed
now)



The following section was included in the previous revision of PCELS but
it has been removed in the current (-05) revision. For the record, these
are the PCELS-04 Open Issues (now all closed):

Appendix B: Open Issues 

   1. Should RFC 2119 be cited as normative reference? PCIM_EXT, PCLS 
   and other documents refer to RFC 2119 as an informative reference. 
   RESOLUTION: RFC2119 is cited as normative reference. 

   2. The object classes pcelsVendorVariable and pcelsVendorValue 
   defined in this document are not mapped from PCIM_EXT. 
   Pro: It is estimated that non-standard submodels and their LDAP 
   schema implementations will need to define a considerable number of 
   new PolicyVariable and PolicyValue subtypes. In order to avoid an 
   explosion of LDAP class definitions, the pcelsVendorVariable and 
   pcelsVendorValue classes introduce a value based extension mechanism 
   for handling new data types. These classes do not introduce a new 
   concept but rather a new extension mechanism for an existing concept.

   A similar mechanism is defined by PCIM and implemented by PCLS for 
   creating vendor specific PolicyCondition and PolicyAction entries. 
   Con: Since PCIM_EXT does not define such classes this document should

   not do it either. The purpose of this document this document is to 
   map the PCIM_EXT model to an LDAP schema, therefore such 
   functionality is outside its scope. 
   RESOLUTION: classes preserved 
   
   3. PolicyGroup is not explicitly mapped to an LDAP object class. 
   Pro: Since the PolicyRule has now the capability to aggregate other 
   PolicyRule instances, this class includes the functionality of the 
   PolicyGroup. Therefore, an explicitly implementation of the 
   PolicyGroup class is unnecessary. 
   Con: The PolicyRule and the PolicyGroup have different semantics so 
   they should be defined using different classes. 
   RESOLUTION: PolicyGroup is explicitly mapped to pcelsGroup. 

   4. pcelsReusableContainer is defined as a subclass of pcimRepository.

   Therefore the new class is an extension to the old one, not an 
   alternative to it. 
   Pro: As a subclass of pcimRepository, pcelsReusableContainer 
   is compatible with older implementations that expect containers of 
   reusable policy elements to be implemented as pcimRepository 
   entries. The new class extends the functionality of the 
   pcimRepository class by implementing the ContainedDomain aggregation.

   Con: pcelsReusableContainer as subclass of pcimRepository has 
   potentially detrimental implications on Object Oriented models. 
   RESOLUTION: inheritance from pcimRepository preserved 

   5. pcelsConditionAssociation is defined as a subclass of 
   pcimRuleConditionAssociation. It extends the applicability of 
   the old class to the aggregation of PolicyContition instances as 
   components of CompoundPolicyContitions. 
   Pro: The Condition aggregation mechanism can be reused in both Rule 
   and CompoundCondition, therefore making it possible to optimize 
   their implementation. 
   Con: Mapping of the PCIM_EXT aggregations is implicit therefore more 
   difficult for some implementations to detect. 
   RESOLUTION: current implementation preserved