For the record: Open Issues in PCELS-04 (all closed now)
[email protected] Wed, 31 Mar 2004 08:42:44 -0600
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4172E.6DAD1290 Content-Type: text/plain; charset="ISO-8859-1" 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 ------_=_NextPart_001_01C4172E.6DAD1290 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DISO-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2653.12"> <TITLE>For the record: Open Issues in PCELS-04 (all closed = now)</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>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):</FONT></P> <P><FONT SIZE=3D2>Appendix B: Open Issues</FONT> </P> <P><FONT SIZE=3D2> 1. Should RFC 2119 be cited as normative = reference? PCIM_EXT, PCLS</FONT> <BR><FONT SIZE=3D2> and other documents refer to RFC 2119 = as an informative reference.</FONT> <BR><FONT SIZE=3D2> RESOLUTION: RFC2119 is cited as = normative reference.</FONT> </P> <P><FONT SIZE=3D2> 2. The object classes = pcelsVendorVariable and pcelsVendorValue</FONT> <BR><FONT SIZE=3D2> defined in this document are not mapped = from PCIM_EXT. </FONT> <BR><FONT SIZE=3D2> Pro: It is estimated that non-standard = submodels and their LDAP</FONT> <BR><FONT SIZE=3D2> schema implementations will need to = define a considerable number of</FONT> <BR><FONT SIZE=3D2> new PolicyVariable and PolicyValue = subtypes. In order to avoid an</FONT> <BR><FONT SIZE=3D2> explosion of LDAP class definitions, = the pcelsVendorVariable and</FONT> <BR><FONT SIZE=3D2> pcelsVendorValue classes introduce a = value based extension mechanism</FONT> <BR><FONT SIZE=3D2> for handling new data types. These = classes do not introduce a new</FONT> <BR><FONT SIZE=3D2> concept but rather a new extension = mechanism for an existing concept.</FONT> <BR><FONT SIZE=3D2> A similar mechanism is defined by PCIM = and implemented by PCLS for</FONT> <BR><FONT SIZE=3D2> creating vendor specific = PolicyCondition and PolicyAction entries.</FONT> <BR><FONT SIZE=3D2> Con: Since PCIM_EXT does not define = such classes this document should</FONT> <BR><FONT SIZE=3D2> not do it either. The purpose of this = document this document is to</FONT> <BR><FONT SIZE=3D2> map the PCIM_EXT model to an LDAP = schema, therefore such</FONT> <BR><FONT SIZE=3D2> functionality is outside its = scope.</FONT> <BR><FONT SIZE=3D2> RESOLUTION: classes preserved</FONT> <BR><FONT SIZE=3D2> </FONT> <BR><FONT SIZE=3D2> 3. PolicyGroup is not explicitly mapped = to an LDAP object class.</FONT> <BR><FONT SIZE=3D2> Pro: Since the PolicyRule has now the = capability to aggregate other</FONT> <BR><FONT SIZE=3D2> PolicyRule instances, this class = includes the functionality of the</FONT> <BR><FONT SIZE=3D2> PolicyGroup. Therefore, an explicitly = implementation of the</FONT> <BR><FONT SIZE=3D2> PolicyGroup class is = unnecessary.</FONT> <BR><FONT SIZE=3D2> Con: The PolicyRule and the PolicyGroup = have different semantics so</FONT> <BR><FONT SIZE=3D2> they should be defined using different = classes.</FONT> <BR><FONT SIZE=3D2> RESOLUTION: PolicyGroup is explicitly = mapped to pcelsGroup.</FONT> </P> <P><FONT SIZE=3D2> 4. pcelsReusableContainer is defined as = a subclass of pcimRepository.</FONT> <BR><FONT SIZE=3D2> Therefore the new class is an extension = to the old one, not an</FONT> <BR><FONT SIZE=3D2> alternative to it.</FONT> <BR><FONT SIZE=3D2> Pro: As a subclass of pcimRepository, = pcelsReusableContainer</FONT> <BR><FONT SIZE=3D2> is compatible with older = implementations that expect containers of</FONT> <BR><FONT SIZE=3D2> reusable policy elements to be = implemented as pcimRepository</FONT> <BR><FONT SIZE=3D2> entries. The new class extends the = functionality of the</FONT> <BR><FONT SIZE=3D2> pcimRepository class by implementing = the ContainedDomain aggregation.</FONT> <BR><FONT SIZE=3D2> Con: pcelsReusableContainer as subclass = of pcimRepository has</FONT> <BR><FONT SIZE=3D2> potentially detrimental implications on = Object Oriented models.</FONT> <BR><FONT SIZE=3D2> RESOLUTION: inheritance from = pcimRepository preserved</FONT> </P> <P><FONT SIZE=3D2> 5. pcelsConditionAssociation is defined = as a subclass of</FONT> <BR><FONT SIZE=3D2> pcimRuleConditionAssociation. It = extends the applicability of </FONT> <BR><FONT SIZE=3D2> the old class to the aggregation of = PolicyContition instances as</FONT> <BR><FONT SIZE=3D2> components of = CompoundPolicyContitions.</FONT> <BR><FONT SIZE=3D2> Pro: The Condition aggregation = mechanism can be reused in both Rule</FONT> <BR><FONT SIZE=3D2> and CompoundCondition, therefore making = it possible to optimize </FONT> <BR><FONT SIZE=3D2> their implementation.</FONT> <BR><FONT SIZE=3D2> Con: Mapping of the PCIM_EXT = aggregations is implicit therefore more</FONT> <BR><FONT SIZE=3D2> difficult for some implementations to = detect.</FONT> <BR><FONT SIZE=3D2> RESOLUTION: current implementation = preserved</FONT> <BR><FONT SIZE=3D2> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C4172E.6DAD1290--