response to comments on PCELS-05/May 06
[email protected] Wed, 12 May 2004 18:02:13 -0500
| 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_01C43875.296E0225 Content-Type: text/plain; charset="iso-8859-1" John, See my comments tagged <mircea3></mircea3>. Thank You, Mircea -----Original Message----- From: John Strassner [mailto:[email protected]] Sent: Thursday, May 06, 2004 3:44 AM To: [email protected]; John Strassner Cc: [email protected]; [email protected] Subject: RE: your comments on PCELS-05 / April 26 I've just pulled up the remaining problems to make it easier to deal with. I'm copying Joel and Bert so that they know that I am responding, albeit slowly...look for <js2/> [...] Sixth, why is there no pcelsRuleValidityAssociation subclass? At this point, <mircea>I do not understand the issue. PCELS reuses pcimRuleValidityAssociation that is defined in PCLS </mircea> <js> True, this is addressed in Note 1 in page 27 of the draft. Looking at your class structure, since you subclassed other associations, I was surprised that you didn't subclass this one as well. This is because pcelsRule and pcimRule are siblings, and pcimRuleValidityPeriod (in PCIM) is defined to exist between pcimRule and policyConditionTimePeriod only. So, how do pcelsRule instances use a policyConditionTimePeriod? </js> <mircea2>PCELS adopts pcimRuleValidityAssociation extending its applicability to pcelsRule. I.e. PCELS recommends the use of pcimRuleValidityAssociation instances subordinated to pcelsRule entries for associating pcimTPCAuxClass instances to a Rule. Note that PCELS also recommends that: "As result, the class pcimRuleValidityAssociation SHOULD be expected (and allowed) to have instances of pcelsRule as superior entries." This isn't a change of semantics for the pcimRuleValidityAssociation class. In a PCELS implementation, this class continues to represent the PolicyRuleValidityPeriod aggregation. Other association classes defined in PCIM are subclassed in PCELS for the purpose of extending their semantics (and for changing their names ;-)</mircea2> <js2> The above logic is incorrect. Look at how pcimRuleValidityPeriod is defined in RFC3060. It is NOT a representation of a PolicyRuleValidityPeriod, it is a representation of the *association* between a PolicyRuleValidityPeriod and a PolicyRule. So, the problem is that you have defined a pcelsPolicySet to be a sibling of pcimRule (to which pcimRuleValidityPeriod applies). Therefore, pcimRuleValidityPeriod does NOT apply to pcelsPolicySet (and thus not to pcelsRule). Therefore, you have to either redefine this association, or create a new one. You did neither. </js2> <mircea3>I must be missing something... You say that pcimRuleValidityPeriod is defined in RFC3060 but in PCIM I can not find any reference to pcimRuleValidityPeriod. PCLS (RFC3703) does not define such class either. You also mention the association between a PolicyRuleValidityPeriod and a PolicyRule but I can not find anything in either PCIM or PCLS that implements such association. However, in PCIM I read that PolicyRuleValidityPeriod is defined as "A class representing the aggregation of PolicyTimePeriodConditions by a PolicyRule". In PCLS I read that "The policyRuleValidityPeriod aggregation is mapped to the PCLS pcimRuleValidityAssociation class." So, I conclude that pcimRuleValidityAssociation is used to associate TimePeriodConditions to a Rule. For PCLS this means associating instances of pcimTPCAuxClass to a pcimRule. For PCELS this would mean associating instances of pcimTPCAuxClass to a pcelsRule. I really don't see the problem. </mircea3> [...] - page 7 - you state: "The LDAP object classes defined in this document are a direct mapping from the corresponding classes and, in some cases, the associations defined in [PCIM_EXT] ". Not strictly true, as you are also seeking to update RFC 3703 (e.g., where is pcimSubtreesPtrAuxClass defined in RFC 3460?). <mircea>The text in section 4.1 will be revised for a better description of the mapping techniques utilised by PCELS. However, I do not understand your reference to pcimSubtreesPtrAuxClass. That class is not defined in PCELS. <mircea> <js> If you look at RFC3703, we defined two aux classes (pcimElementAuxClass and pcimSubtreesPtrAuxClass) to simplify navigation through the DIT, as well as retrieval of entries found more efficient. I think that you should take another look at the rationale behind these classes, and consider again whether they should be included in this draft. </js> <mircea2>The fact that PCELS does not explicitly discuss these classes does not mean that implementations should not use them. Actually, PCELS application will likely implement them as well as pcimPolicyInstance, pcimConditionVendorAuxClass and many other PCLS classes. Are you suggesting that all these classes should be explicitly listed? IMO sections 2 and 3 of PCELS already address this issue.</mircea2> <js2> It wasn't apparent to me or my developers that you were including these classes. A few sentences here couldn't hurt! </js2> <mircea3>We will add a subsection 4.x or an appendix that lists the PCLS classes that should be used by PCELS implementations.</mircea3> [...] - pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They aren't listed in this table, and better be, if you are "updating" RFC 3703. <mircea>The two tables list PCIM_EXT classes mapped by PCELS. Why should the tables include PCLS classes? </mircea> <js> Because this draft is supposed to be updating RFC3703, which means that you need to deal with classes defined in that RFC (such as pcimSubtreesPtrAuxClass) as well as your own classes. Or, at the very least, state why these classes do not need to be defined. </js> <mircea2>Do we understand different things by "updates"? By "updates" we mean that PCELS makes incremental changes and additions to PCLS. So, I fail to see why PCELS should re-define classes that do not change.</mircea2> <js2> Perhaps this is a semantic difference. I think that an "update" should address all issues, and explicitly state whether something is good as is, or needs to be updated and why. Bert and Joel, your views? </js2> <mircea3>We will add a subsection 4.x that lists the PCLS classes that should be used by PCELS implementations.</mircea3> [...] - Page 11 - the reader will wonder why ReusablePolicy and PolicyRoleCollectionInSystem are only implementable via DIT containment, when every other association has an association defined (independent of whether DIT containment could be used). <mircea>I fail to see the issue. </mircea> <js> Good schemata are consistent. Why are these two associations only implementable via DIT containment? </js> <mircea2>For ReusablePolicy, DIT containment has the best scalability (btw, PCLS does the same thing). PolicyRoleCollectionInSystem, is still open for suggestions ;-) </mircea2> <js2> But, my issue of consistency still holds. You are preventing the developer from having a choice here. I would suggest defining both and then stating, editorially, that DIT containment is preferred here. </js2> <mircea3>I have reviewed the PCIMe definitions for these two associations and I think that mapping them to LDAP classes/attributes is unnecessary (or even wrong). A PolicyRoleCollection if it exists, it only exists in the context of a System, therefore the obvious LDAP implementation for PolicyRoleCollectionInSystem is DIT containment. ReusablePolicy places a policy element in a *container*. Once again, the obvious choice is DIT containment. In addition, one could also argue that mapping ReusablePolicy only to DIT containment is consistent with PCLS (see Policy*InPolicyRepository association mappings in PCLS).</mircea3> - Section 4.2, line 3, you write: "The concept of an ordered set of policies...". LDAP doesn't have ordered sets. How are you going to implement this? <mircea>replaced "ordered" with "coherent" (from PCIM_EXT) </mircea> <js> That's certainly better than incoherent ;-) but I don't see how this solves the problem, as the two aren't synonymous. </js> <mircea2> See note at the end of section 5.1 (page 26).</mircea2> <js2> I'm still not satisfied. Joel and Bert? </js2> <mircea3>We will make the change suggested by Joel: "[...] (pcelsPolicySet) provides a set of policies with additional information that allow the application to apply appropriate ordering to the information."</mircea3> [...] - Page 23, note above Section 5.2, is slightly incorrect. Only those implementations that WANT TO BE COMPATIBLE WITH PCELS should use this aggregation mechanism instead of those defined by PCLS. Not every implementation mechanism is going to want to change. <mircea>Revised. The section defining pcelsRule for example will include the following compatibility note: "Note 2: PCELS implementations SHOULD support pcelsRule and its two subclasses and MAY also support pcimRule and its two subclasses [PCLS]. Applications that choose to support pcelsRule and its two subclasses MUST use the aggregation mechanism provided by pcelsPolicySetAssociation for aggregating policy groups or policy rules in policy rules represented as instances of pcelsRule. Applications that intend to be compatible with [PCIM_EXT] MUST support pcelsRule and its two subclasses." </mircea> <js> The last MUST contradicts the first SHOULD in the above statement; please change it to SHOULD. The first MUSt in the above statement is OK. </js> <mircea2> How about replacing the last statement with: "Note that pcelsRule and its subclasses are compatible with [PCIM_EXT] while pcimRule and its subclasses are not.</mircea2> <js2> How about deleting it entirely? This statement doesn't really help, it's stating the obvious. </js2> <mircea3>OK.</mircea3> [...] - Same section, you write: "...realizes a (subclass of) PolicySetComponent aggregation [sic]. When subordinated to (subclass of) dlm1System...realizes a PolicySetInSystem association [sic]". How can the same element realize an aggregation in one usage and an association in another usage? This is semantically inconsistent. <mircea>I fail to see the issue. The semantics of pcelsPolicySetAssociation are context sensitive. </mircea> <js> The point is that there is a pronounced difference between an aggregation and an association. Although it is sadly commonplace to call everything an association. ;-( I would suggest changing your text to either only use "association" or only use "aggregation" in the same paragraph. </js> <mircea2>...So, would it be acceptable to call PolicySetComponent an association, when PCIMe defines it as aggregation?</mircea2> <js2> No, of course not, in a perfect world. I'm suggesting 1 of 2 courses: - easiest: replace "aggregation" with "association" everywhere - this has the advantage of being imprecise, or - go through the document and call things aggregations when they are aggregations. The problem is that you call the same object both an association and an aggregation, which is confusing to some people. </js2> <mircea3>OK. We'll call them all "associations".</mircea3> [...] regards, John Strassner ------_=_NextPart_001_01C43875.296E0225 Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <TITLE>Message</TITLE> <META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD> <BODY> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=034421723-10052004>John, See my comments tagged <mircea3></mircea3>.</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=034421723-10052004></SPAN></FONT> </DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=034421723-10052004>Thank You,</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=034421723-10052004>Mircea</SPAN></FONT></DIV> <BLOCKQUOTE dir=ltr style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> John Strassner [mailto:[email protected]]<BR><B>Sent:</B> Thursday, May 06, 2004 3:44 AM<BR><B>To:</B> [email protected]; John Strassner<BR><B>Cc:</B> [email protected]; [email protected]<BR><B>Subject:</B> RE: your comments on PCELS-05 / April 26<BR><BR></FONT></DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN class=365492107-06052004>I've just pulled up the remaining problems to make it easier to deal with. I'm copying Joel and Bert so that they know that I am responding, albeit slowly...look for <js2/></SPAN></FONT></DIV> <DIV><FONT face="Courier New" color=#0000ff size=2></FONT> </DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><FONT face="Times New Roman" color=#000000></FONT></FONT> </DIV> <DIV><FONT face="Courier New" size=2><FONT size=+0><FONT face="Times New Roman" color=#0000ff><SPAN class=365492107-06052004>[...]</SPAN></FONT></FONT></FONT></DIV> <DIV><FONT face="Courier New" size=2><FONT size=+0><FONT face="Times New Roman" color=#0000ff><SPAN class=365492107-06052004></SPAN></FONT></FONT></FONT> </DIV> <DIV><FONT face="Courier New" color=#0000ff size=2><FONT size=+0><FONT face="Times New Roman"><SPAN class=365492107-06052004></SPAN>Sixth, why is there no pcelsRuleValidityAssociation subclass? At this point, <mircea>I do not understand the issue. PCELS reuses pcimRuleValidityAssociation that is defined in PCLS</FONT></FONT></DIV> <P></mircea> <SPAN class=745254702-26042004><FONT face="Courier New"> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><js> True, this is addressed in Note 1 in page 27 of the draft. Looking at your class structure, since you subclassed other associations, I was surprised that you didn't subclass this one as well. This is because pcelsRule and </FONT> <FONT face="Courier New">pcimRule are siblings, and pcimRuleValidityPeriod (in PCIM) is defined to exist between pcimRule and policyConditionTimePeriod only. So, how do pcelsRule instances use a policyConditionTimePeriod? </js><SPAN class=879044212-27042004><FONT face=Arial> </FONT></SPAN></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN class=879044212-27042004><FONT face=Arial><mircea2></FONT></SPAN></FONT></SPAN><SPAN class=745254702-26042004><FONT face=Arial><SPAN class=879044212-27042004>PCELS adopts pcimRuleValidityAssociation extending its applicability to pcelsRule. I.e. PCELS recommends the use of pcimRuleValidityAssociation instances subordinated to pcelsRule entries for associating pcimTPCAuxClass instances to a Rule. Note that PCELS also recommends that: "As result, the class pcimRuleValidityAssociation SHOULD be expected (and allowed) to have instances of pcelsRule as superior entries."</SPAN></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face=Arial><SPAN class=879044212-27042004>This isn't a change of semantics for the pcimRuleValidityAssociation class. In a PCELS implementation, this class continues to represent the PolicyRuleValidityPeriod aggregation. Other association classes defined in PCIM are subclassed in PCELS for the purpose of extending their semantics (and for changing their names ;-)</SPAN></FONT></SPAN><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN class=879044212-27042004><FONT face=Arial></mircea2></FONT></SPAN></FONT></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><js2> The above logic is incorrect. Look at how pcimRuleValidityPeriod is defined in RFC3060. It is NOT a representation of a PolicyRuleValidityPeriod, it is a representation of the *association* between a PolicyRuleValidityPeriod and a PolicyRule. So, the problem is that you have defined a pcelsPolicySet to be a sibling of pcimRule (to which pcimRuleValidityPeriod applies). Therefore, pcimRuleValidityPeriod does NOT apply to pcelsPolicySet (and thus not to pcelsRule). Therefore, you have to either redefine this association, or create a new one. You did neither. </js2><SPAN class=034421723-10052004> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004><mircea3>I must be missing something... You say that pcimRuleValidityPeriod is defined in RFC3060 but in PCIM I can not find any reference to pcimRuleValidityPeriod. PCLS (RFC3703) does not define such class either. You also mention the association between a PolicyRuleValidityPeriod and a PolicyRule but I can not find anything in either PCIM or PCLS that implements such association.</SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004>However, in PCIM I read that PolicyRuleValidityPeriod is defined as "A class representing the aggregation of PolicyTimePeriodConditions by a PolicyRule". In</SPAN></FONT></SPAN></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004> PCLS I read that "The policyRuleValidityPeriod aggregation is mapped to the PCLS pcimRuleValidityAssociation class." So, I conclude that pcimRuleValidityAssociation is used to associate TimePeriodConditions to a Rule. For PCLS this means associating instances of pcimTPCAuxClass to a pcimRule. For PCELS this would mean associating instances of pcimTPCAuxClass to a pcelsRule. I really don't see the problem. </mircea3> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004></SPAN></FONT></SPAN></SPAN></SPAN> </P> <P><FONT face=Arial><SPAN class=879044212-27042004> [...]</SPAN></FONT></P> <P><FONT face=Arial><SPAN class=879044212-27042004> </SPAN></FONT> - page 7 - you state: "The LDAP object classes defined in this document <BR> are a direct mapping from the corresponding classes and, in some <BR> cases, the associations defined in [PCIM_EXT] ". Not strictly true, <BR> as you are also seeking to update RFC 3703 (e.g., where is <BR> pcimSubtreesPtrAuxClass defined in RFC 3460?). <BR><mircea>The text in section 4.1 will be revised for a better description of the mapping techniques utilised by PCELS. However, I do not understand </P> <P>your reference to pcimSubtreesPtrAuxClass. That class is not defined in PCELS. <BR><mircea> <SPAN class=745254702-26042004><FONT face="Courier New"> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><js> If you look at RFC3703, we defined two aux classes (pcimElementAuxClass and pcimSubtreesPtrAuxClass) to simplify navigation through the DIT, as well as retrieval of entries found more efficient. I think that you should take another look at the rationale behind these classes, and consider again whether they should be included in this draft. </js><SPAN class=879044212-27042004><FONT face=Arial> </FONT></SPAN></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN class=879044212-27042004><FONT face=Arial><mircea2></FONT></SPAN></FONT></SPAN><SPAN class=745254702-26042004><FONT size=+0><FONT face=Arial size=2><SPAN class=879044212-27042004>The fact that PCELS does not explicitly discuss these classes does not mean that implementations should not use them. Actually, PCELS application will likely implement them as well as pcimPolicyInstance, pcimConditionVendorAuxClass and many other PCLS classes. Are you suggesting that all these classes should be explicitly listed? IMO sections 2 and 3 of PCELS already address this issue.</SPAN></FONT></FONT></SPAN><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN class=879044212-27042004><FONT face=Arial></mircea2></FONT> </SPAN></FONT></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><js2> It wasn't apparent to me or my developers that you were including these classes. A few sentences here couldn't hurt! </js2><SPAN class=034421723-10052004> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004><mircea3>We will add a subsection 4.x or an appendix that lists the PCLS classes that should be used by PCELS implementations.</mircea3> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004></SPAN></FONT></SPAN></SPAN></SPAN> </P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT face=Arial><SPAN class=879044212-27042004>[...]</SPAN></FONT></FONT></SPAN></P> <P> - pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They <BR> aren't listed in this table, and better be, if you are "updating" <BR> RFC 3703. <BR><mircea>The two tables list PCIM_EXT classes mapped by PCELS. Why should the tables include PCLS classes? <BR></mircea><SPAN class=745254702-26042004><FONT face="Courier New"> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><js> Because this draft is supposed to be updating RFC3703, which means that you need to deal with classes defined in that RFC (such as pcimSubtreesPtrAuxClass) as well as your own classes. Or, at the very least, state why these classes do not need to be defined. </js></FONT> </SPAN><SPAN class=745254702-26042004> <SPAN class=879044212-27042004><FONT face=Arial> </FONT></SPAN></SPAN></P> <P><SPAN class=879044212-27042004><FONT face=Arial><mircea2></FONT></SPAN><FONT face=Arial><SPAN class=879044212-27042004>Do we understand different things by "updates"? By "updates" we mean that PCELS makes incremental changes and additions to PCLS. So, </SPAN></FONT><FONT face=Arial><SPAN class=879044212-27042004>I fail to see why PCELS should re-define classes that do not change.</SPAN></FONT><SPAN class=879044212-27042004><FONT face=Arial></mircea2></FONT> </SPAN></P> <P><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><js2> Perhaps this is a semantic difference. I think that an "update" should address all issues, and explicitly state whether something is good as is, or needs to be updated and why. Bert and Joel, your views? </js2><SPAN class=034421723-10052004> </SPAN></FONT></SPAN></SPAN></P> <P><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004><mircea3>We will add a subsection 4.x that lists the PCLS classes that should be used by PCELS implementations.</mircea3></SPAN></FONT></SPAN></SPAN></SPAN> </SPAN></FONT></SPAN></SPAN></P> <P><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004></SPAN></FONT></SPAN></SPAN> </P> <P><SPAN class=879044212-27042004>[...]</SPAN></P> <P><FONT face=Arial><SPAN class=879044212-27042004> </SPAN></FONT> - Page 11 - the reader will wonder why ReusablePolicy and <BR> PolicyRoleCollectionInSystem are only implementable via DIT <BR> containment, when every other association has an association defined <BR> (independent of whether DIT containment could be used). <BR><mircea>I fail to see the issue. <BR></mircea> <SPAN class=745254702-26042004><FONT face="Courier New"> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><js> Good schemata are consistent. Why are these two associations only implementable via DIT containment? </js></FONT> <SPAN class=879044212-27042004><FONT face=Arial> </FONT></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial><mircea2></FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial>For ReusablePolicy, DIT containment has the best scalability (btw, PCLS does the same thing).</FONT></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial>PolicyRoleCollectionInSystem, is still open for suggestions ;-) </FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial></mircea2></FONT> </SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><js2> But, my issue of consistency still holds. You are preventing the developer from having a choice here. I would suggest defining both and then stating, editorially, that DIT containment is preferred here. </js2><SPAN class=034421723-10052004> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004><mircea3>I have reviewed the PCIMe definitions for these two associations and I think that mapping them to LDAP classes/attributes is unnecessary (or even wrong). A <SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial>PolicyRoleCollection if it exists, it only exists in the context of a System, therefore the obvious LDAP implementation for <SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial>PolicyRoleCollectionInSystem </FONT></SPAN></SPAN>is DIT containment. ReusablePolicy places a policy element in a *container*. Once again, the obvious choice is DIT containment. In addition, one could also argue that mapping ReusablePolicy only to DIT containment is consistent with PCLS (see Policy*InPolicyRepository association mappings in PCLS).</FONT></SPAN></SPAN></mircea3> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004></SPAN></FONT></SPAN></SPAN></SPAN> </P> <P> - Section 4.2, line 3, you write: "The concept of an ordered set of <BR> policies...". LDAP doesn't have ordered sets. How are you going to <BR> implement this? <BR><mircea>replaced "ordered" with "coherent" (from PCIM_EXT) <BR></mircea> <SPAN class=745254702-26042004><FONT face="Courier New"> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff><js> That's certainly better than incoherent ;-) but I don't see how this solves the problem, as the two aren't synonymous. </js><SPAN class=879044212-27042004><FONT face=Arial color=#000000> </FONT></SPAN></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN class=879044212-27042004><FONT face=Arial><mircea2> </FONT></SPAN></FONT></SPAN><SPAN class=745254702-26042004><FONT face="Courier New"><FONT face=Arial><SPAN class=879044212-27042004>See note at the end of section 5.1 (page 26).</SPAN></FONT></FONT></SPAN><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN class=879044212-27042004><FONT face=Arial></mircea2></FONT> </SPAN></FONT> <SPAN class=879044212-27042004><FONT face=Arial> </FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004> </SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><js2> I'm still not satisfied. Joel and Bert? </js2><SPAN class=034421723-10052004> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004><mircea3>We will make the change suggested by Joel: "[...] (pcelsPolicySet) provides a set of policies with additional information that allow the application to apply appropriate ordering to the information."</mircea3> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004></SPAN></FONT></SPAN></SPAN></SPAN> </P> <P><FONT face=Arial><SPAN class=879044212-27042004> [...]</SPAN></FONT></P> <P><FONT face=Arial><SPAN class=879044212-27042004> </SPAN></FONT> - Page 23, note above Section 5.2, is slightly incorrect. Only those <BR> implementations that WANT TO BE COMPATIBLE WITH PCELS should use <BR> this aggregation mechanism instead of those defined by PCLS. Not <BR> every implementation mechanism is going to want to change. <BR><mircea>Revised. The section defining pcelsRule for example will include the following compatibility note: </P> <P> "Note 2: PCELS implementations SHOULD support pcelsRule and its two <BR> subclasses and MAY also support pcimRule and its two subclasses <BR> [PCLS]. Applications that choose to support pcelsRule and its two <BR> subclasses MUST use the aggregation mechanism provided by <BR> pcelsPolicySetAssociation for aggregating policy groups or policy <BR> rules in policy rules represented as instances of pcelsRule. <BR> Applications that intend to be compatible with [PCIM_EXT] MUST <BR> support pcelsRule and its two subclasses." </P> <P></mircea> <SPAN class=745254702-26042004><FONT face="Courier New"> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff><js> The last MUST contradicts the first SHOULD in the above statement; please change it to SHOULD. The first MUSt in the above statement is OK. </js><SPAN class=879044212-27042004><FONT face=Arial color=#000000> </FONT></SPAN></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN class=879044212-27042004><FONT face=Arial><mircea2> </FONT></SPAN></FONT></SPAN><SPAN class=745254702-26042004><FONT size=+0><FONT face=Arial size=2><SPAN class=879044212-27042004>How about replacing the last statement with: "Note that pcelsRule and its subclasses are compatible with [PCIM_EXT] while pcimRule and its subclasses are not.</SPAN></FONT></FONT></SPAN><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN class=879044212-27042004><FONT face=Arial></mircea2></FONT></SPAN></FONT></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><js2> How about deleting it entirely? This statement doesn't really help, it's stating the obvious. </js2><SPAN class=034421723-10052004> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004><mircea3>OK.</mircea3> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN class=034421723-10052004></SPAN></FONT></SPAN></SPAN></SPAN> </P> <P><SPAN class=745254702-26042004><FONT face=Arial><SPAN class=879044212-27042004><SPAN class=365492107-06052004>[...]</SPAN></SPAN></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN class=879044212-27042004></SPAN></FONT></SPAN></P> <P> - Same section, you write: "...realizes a (subclass of) <BR> PolicySetComponent aggregation [sic]. When subordinated to (subclass <BR> of) dlm1System...realizes a PolicySetInSystem association [sic]". <BR> How can the same element realize an aggregation in one usage and an <BR> association in another usage? This is semantically inconsistent. <BR><mircea>I fail to see the issue. The semantics of pcelsPolicySetAssociation are context sensitive. <BR></mircea> <SPAN class=745254702-26042004><FONT face="Courier New"> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><js> The point is that there is a pronounced difference between an aggregation and an association. Although it is sadly commonplace to call everything an association. ;-( I would suggest changing your text to either only use "association" or only use "aggregation" in the same paragraph. </js></FONT> <SPAN class=879044212-27042004><FONT face=Arial> </FONT></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial><mircea2></FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial>...So, would it be acceptable to call PolicySetComponent an association, when PCIMe defines it as aggregation?</FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial></mircea2></FONT> </SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><js2> No, of course not, in a perfect world. I'm suggesting 1 of 2 courses:<BR> - easiest: replace "aggregation" with "association" everywhere - this has the advantage of being imprecise, or<BR> - go through the document and call things aggregations when they are aggregations.</FONT></SPAN></SPAN></SPAN></P> <P><FONT face=Arial><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004>The problem is that you call the same object both an association and an aggregation, which is confusing to some people. </SPAN></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT size=+0></js2></FONT><FONT size=2><SPAN class=034421723-10052004> </SPAN></FONT></SPAN></SPAN></SPAN></FONT></P> <P><FONT face=Arial><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT size=2><SPAN class=034421723-10052004><FONT size=3><mircea3>OK. We'll call them all "associations".</mircea3></FONT> </SPAN></FONT></SPAN></SPAN></SPAN></FONT></P> <P><FONT face=Arial><SPAN class=879044212-27042004>[...]</SPAN></FONT></P></FONT> <DIV dir=ltr align=left> <P dir=ltr align=left><FONT face="Times New Roman"><FONT size=3>regards,<BR>John<SPAN class=050114416-03022004> Strassner</SPAN></FONT></FONT></P></DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C43875.296E0225--