RE: For the record: Open Issues in PCELS-04 (all closed now)
"John Strassner" <[email protected]> Sun, 25 Apr 2004 23:59:48 -0600
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01C42B53.AEA0CBF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And for the record, I think that notes like this that document issues and their resolutions are very helpful. ;-) =20 regards, John -----Original Message----- From: [email protected] [mailto:[email protected]]=20 Sent: Wednesday, March 31, 2004 7:43 AM To: [email protected] 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=20 1. Should RFC 2119 be cited as normative reference? PCIM_EXT, PCLS=20 and other documents refer to RFC 2119 as an informative reference.=20 RESOLUTION: RFC2119 is cited as normative reference.=20 2. The object classes pcelsVendorVariable and pcelsVendorValue=20 defined in this document are not mapped from PCIM_EXT.=20 Pro: It is estimated that non-standard submodels and their LDAP=20 schema implementations will need to define a considerable number of=20 new PolicyVariable and PolicyValue subtypes. In order to avoid an=20 explosion of LDAP class definitions, the pcelsVendorVariable and=20 pcelsVendorValue classes introduce a value based extension mechanism=20 for handling new data types. These classes do not introduce a new=20 concept but rather a new extension mechanism for an existing concept. A similar mechanism is defined by PCIM and implemented by PCLS for=20 creating vendor specific PolicyCondition and PolicyAction entries.=20 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=20 map the PCIM_EXT model to an LDAP schema, therefore such=20 functionality is outside its scope.=20 RESOLUTION: classes preserved=20 =20 3. PolicyGroup is not explicitly mapped to an LDAP object class.=20 Pro: Since the PolicyRule has now the capability to aggregate other=20 PolicyRule instances, this class includes the functionality of the=20 PolicyGroup. Therefore, an explicitly implementation of the=20 PolicyGroup class is unnecessary.=20 Con: The PolicyRule and the PolicyGroup have different semantics so=20 they should be defined using different classes.=20 RESOLUTION: PolicyGroup is explicitly mapped to pcelsGroup.=20 4. pcelsReusableContainer is defined as a subclass of pcimRepository. Therefore the new class is an extension to the old one, not an=20 alternative to it.=20 Pro: As a subclass of pcimRepository, pcelsReusableContainer=20 is compatible with older implementations that expect containers of=20 reusable policy elements to be implemented as pcimRepository=20 entries. The new class extends the functionality of the=20 pcimRepository class by implementing the ContainedDomain aggregation. Con: pcelsReusableContainer as subclass of pcimRepository has=20 potentially detrimental implications on Object Oriented models.=20 RESOLUTION: inheritance from pcimRepository preserved=20 5. pcelsConditionAssociation is defined as a subclass of=20 pcimRuleConditionAssociation. It extends the applicability of=20 the old class to the aggregation of PolicyContition instances as=20 components of CompoundPolicyContitions.=20 Pro: The Condition aggregation mechanism can be reused in both Rule=20 and CompoundCondition, therefore making it possible to optimize=20 their implementation.=20 Con: Mapping of the PCIM_EXT aggregations is implicit therefore more=20 difficult for some implementations to detect.=20 RESOLUTION: current implementation preserved=20 =20 ------_=_NextPart_001_01C42B53.AEA0CBF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D389200205-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2>And for the record, I think that notes like this that document = issues and=20 their resolutions are very helpful. ;-)</FONT></SPAN></DIV> <DIV> </DIV> <DIV dir=3Dltr align=3Dleft> <P dir=3Dltr align=3Dleft><FONT face=3D"Times New Roman"><FONT=20 size=3D3>regards,<BR>John</FONT></FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3DTahoma size=3D2>-----Original=20 Message-----<BR><B>From:</B> [email protected]=20 [mailto:[email protected]] <BR><B>Sent:</B> Wednesday, March 31, = 2004 7:43=20 AM<BR><B>To:</B> [email protected]<BR><B>Subject:</B> [Policy] For the = record:=20 Open Issues in PCELS-04 (all closed now)<BR><BR></P></FONT></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <P><FONT size=3D2>The following section was included in the previous = revision of=20 PCELS but it has been removed in the current (-05) revision. For the = record,=20 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=20 reference? PCIM_EXT, PCLS</FONT> <BR><FONT size=3D2> and = other=20 documents refer to RFC 2119 as an informative reference.</FONT> = <BR><FONT=20 size=3D2> RESOLUTION: RFC2119 is cited as normative=20 reference.</FONT> </P> <P><FONT size=3D2> 2. The object classes = pcelsVendorVariable and=20 pcelsVendorValue</FONT> <BR><FONT size=3D2> defined in = this document=20 are not mapped from PCIM_EXT. </FONT><BR><FONT size=3D2> = Pro: It is=20 estimated that non-standard submodels and their LDAP</FONT> <BR><FONT=20 size=3D2> schema implementations will need to define a = considerable=20 number of</FONT> <BR><FONT size=3D2> new PolicyVariable = and=20 PolicyValue subtypes. In order to avoid an</FONT> <BR><FONT=20 size=3D2> explosion of LDAP class definitions, the=20 pcelsVendorVariable and</FONT> <BR><FONT size=3D2> = pcelsVendorValue=20 classes introduce a value based extension mechanism</FONT> <BR><FONT=20 size=3D2> for handling new data types. These classes do = not=20 introduce a new</FONT> <BR><FONT size=3D2> concept but = rather a new=20 extension mechanism for an existing concept.</FONT> <BR><FONT=20 size=3D2> A similar mechanism is defined by PCIM and = implemented by=20 PCLS for</FONT> <BR><FONT size=3D2> creating vendor = specific=20 PolicyCondition and PolicyAction entries.</FONT> <BR><FONT = size=3D2> =20 Con: Since PCIM_EXT does not define such classes this document = should</FONT>=20 <BR><FONT size=3D2> not do it either. The purpose of this = document=20 this document is to</FONT> <BR><FONT size=3D2> map the = PCIM_EXT=20 model to an LDAP schema, therefore such</FONT> <BR><FONT = size=3D2> =20 functionality is outside its scope.</FONT> <BR><FONT = size=3D2> =20 RESOLUTION: classes preserved</FONT> <BR><FONT size=3D2> =20 </FONT><BR><FONT size=3D2> 3. PolicyGroup is not = explicitly mapped=20 to an LDAP object class.</FONT> <BR><FONT size=3D2> Pro: = Since the=20 PolicyRule has now the capability to aggregate other</FONT> <BR><FONT=20 size=3D2> PolicyRule instances, this class includes the=20 functionality of the</FONT> <BR><FONT size=3D2> = PolicyGroup.=20 Therefore, an explicitly implementation of the</FONT> <BR><FONT=20 size=3D2> PolicyGroup class is unnecessary.</FONT> = <BR><FONT=20 size=3D2> Con: The PolicyRule and the PolicyGroup have = different=20 semantics so</FONT> <BR><FONT size=3D2> they should be = defined using=20 different classes.</FONT> <BR><FONT size=3D2> RESOLUTION:=20 PolicyGroup is explicitly mapped to pcelsGroup.</FONT> </P> <P><FONT size=3D2> 4. pcelsReusableContainer is defined as = a=20 subclass of pcimRepository.</FONT> <BR><FONT size=3D2> = Therefore the=20 new class is an extension to the old one, not an</FONT> <BR><FONT=20 size=3D2> alternative to it.</FONT> <BR><FONT = size=3D2> =20 Pro: As a subclass of pcimRepository, pcelsReusableContainer</FONT> = <BR><FONT=20 size=3D2> is compatible with older implementations that = expect=20 containers of</FONT> <BR><FONT size=3D2> reusable policy = elements to=20 be implemented as pcimRepository</FONT> <BR><FONT = size=3D2> entries.=20 The new class extends the functionality of the</FONT> <BR><FONT=20 size=3D2> pcimRepository class by implementing the = ContainedDomain=20 aggregation.</FONT> <BR><FONT size=3D2> Con: = pcelsReusableContainer=20 as subclass of pcimRepository has</FONT> <BR><FONT = size=3D2> =20 potentially detrimental implications on Object Oriented models.</FONT> = <BR><FONT size=3D2> RESOLUTION: inheritance from = pcimRepository=20 preserved</FONT> </P> <P><FONT size=3D2> 5. pcelsConditionAssociation is defined = as a=20 subclass of</FONT> <BR><FONT size=3D2> = pcimRuleConditionAssociation.=20 It extends the applicability of </FONT><BR><FONT size=3D2> = the old=20 class to the aggregation of PolicyContition instances as</FONT> = <BR><FONT=20 size=3D2> components of CompoundPolicyContitions.</FONT> = <BR><FONT=20 size=3D2> Pro: The Condition aggregation mechanism can be = reused in=20 both Rule</FONT> <BR><FONT size=3D2> and = CompoundCondition,=20 therefore making it possible to optimize </FONT><BR><FONT = size=3D2> =20 their implementation.</FONT> <BR><FONT size=3D2> Con: = Mapping of the=20 PCIM_EXT aggregations is implicit therefore more</FONT> <BR><FONT=20 size=3D2> difficult for some implementations to = detect.</FONT>=20 <BR><FONT size=3D2> RESOLUTION: current implementation=20 preserved</FONT> <BR><FONT size=3D2> =20 </FONT></P></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C42B53.AEA0CBF0--