RE: FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt
[email protected] Wed, 5 May 2004 08:30:40 -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_01C432A5.285D1CC0 Content-Type: text/plain; charset="ISO-8859-1" John, Is there going to be a follow-up on this message thread? If not, we will issue one more (minor) revision of PCELS to address the "MUST contradicts the first SHOULD" issue as discussed below. Then, we would ask for Joel's recommendation wrt. advancing the draft to the next stage. Thanks, Mircea. -----Original Message----- From: [email protected] [mailto:[email protected]]On Behalf Of [email protected] Sent: Tuesday, April 27, 2004 10:05 PM To: [email protected]; [email protected] Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt John, Thank you for your comments and clarifications. I've added my responses inline embedded in <mircea2></mircea2>. Regards, Mircea. -----Original Message----- From: John Strassner [mailto:[email protected]] [...] Third, the lack of an overall diagram makes it very difficult to evaluate the correctness of this model. This draft is not complete enough to construct such a model. <mircea>Can you be more specific. The document includes several diagrams and tables. What is it missing? </mircea> <js> True, there are several diagrams and tables. However, the draft lacks an overall conceptual model. For example, if you look at RFC3060, Figure 1 shows an overview of all of the classes and their relationships. Note that there is no need to show attributes in such a picture - I'm just looking for a **visual** overview of how the different classes fit together. </js> <mircea2>A more appropriate place for an overall conceptual model diagram would have been RFC3460. Such diagram is somewhat out of scope for PCELS. Wrt. the LDAP mapping of PCIMe concepts, the case studies in section 4.x include several instance diagrams that illustrate the implementation options. There are many variations and they could hardly fit in a single diagram. This being said, I am certainly not against the inclusion of an overall class diagram. So, should someone out there volunteer to make such a contribution to the document, I would gladly include it in a new revision of PCELS.</mircea2> [...] Fifth, why is there a pcelsRule and a pcimRule class? <mircea>I do not understand the issue. </mircea> <js> Sorry for not being clearer. I understand that you wanted to create your own class (pcelsRule) because the semantics of RFC3460 were different (for PolicyRules) than those of RFC3460. I support your mentioning both in the draft, since there was feedback (e.g., from Ryan) that some implementations were still using pcimRule. However, I think that given this feedback, this draft needs some guidelines as to when one would use pcelsRule and one would use pcimRule, and what the implications of doing this are (e.g., how priority is implemented). </js> <mircea2>PCELS recommends the use of pcelsRule. While the use of pcimRule is not prevented by PCELS, I do not see why this document would state any reasons in favour of this class. It is outside the scope of PCELS to make recommendations in this matter. Should RFC3460 be revised, this is where such issue should be addressed.</mircea2> 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> [...] - 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> [...] - 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> [...] <mircea> ...means that the PolicySetComponent aggregation is realised by a pcelsPolicySetComponentList value in the aggregating pcelsPolicySet. This attribute value is a DN reference to a pcelsPolicySetAsociation entry. The pcelsPolicySetAsociation entry includes a pcelsPolicySetDN attribute value that is a reference to the aggregated pcelsPolicySet. The details are in section 5. The table only gives an overview of the mapping. </mircea> <js> OK, that makes sense, but I suggest you add a note saying "See section 5.x" so the impatient reader won't get frustrated. ;-) </js> <mircea2>"4.1 Summary of Class and Association Mappings [...] The details of this mapping are discussed case by case in section 5."</mircea2> [...] - 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> - 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> [...] - 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> - Page 23, Section 5.2, says "The pcelsPolicySetAssociation class is used to aggregate instances of pcelsPolicySet into other entries." This is incorrect, as pcelsPolicySet is abstract and thus cannot be instantiated. <mircea> I fail to see a problem with "instance of <abstract_class>". It is obvious that it means "instance of non-abstract subclass of <abstract_class>". The "non-abstract subclass of" is superfluous and has been omitted in order to improve the text readabilitiy. PCLS, for instance, uses such expressions on several occasions. E.g.: (PCLS page 50 first paragraph) "instances of pcimRules". Note that "pcimRules" is not a class name. </mircea> <js> I still disagree (and with PCLS page 50 as well) - it is imprecise. </js> <mircea2> Note 6 in section 5 warns the reader about the imprecise language. (page 23)</mircea2> - 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> [...] ------_=_NextPart_001_01C432A5.285D1CC0 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=290062513-05052004>John,</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=290062513-05052004></SPAN></FONT> </DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=290062513-05052004>Is there going to be a follow-up on this message thread? If not, we will issue one more (minor) revision of PCELS to address the "<FONT face="Courier New">MUST contradicts the first SHOULD</FONT>" issue as discussed below. Then, we would ask for Joel's recommendation wrt. advancing the draft to the next stage.</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=290062513-05052004></SPAN></FONT> </DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=290062513-05052004>Thanks,</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=290062513-05052004>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> [email protected] [mailto:[email protected]]<B>On Behalf Of </B>[email protected]<BR><B>Sent:</B> Tuesday, April 27, 2004 10:05 PM<BR><B>To:</B> [email protected]; [email protected]<BR><B>Subject:</B> RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt<BR><BR></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004>John,</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004></SPAN></FONT> </DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004>Thank you for your comments and clarifications. I've added my responses inline embedded in <mircea2></mircea2>.</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004></SPAN></FONT> </DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004>Regards,</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004>Mircea.</SPAN></FONT></DIV> <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004></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 size=2><FONT face=Tahoma>-----Original Message-----<BR><B>From:</B> John Strassner [mailto:[email protected]]<BR><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff> <FONT face=Tahoma color=#000000>[...]</FONT></FONT></SPAN></FONT></FONT></DIV> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT size=2><FONT face=Tahoma><SPAN class=879044212-27042004> </SPAN></FONT>Third, the lack of an overall diagram makes it very difficult to evaluate the correctness of this model. This draft is not complete enough to construct such a model.</FONT></DIV> <BLOCKQUOTE dir=ltr style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <P><FONT size=2><mircea>Can you be more specific. The document includes several diagrams and tables. What is it missing?</FONT> <BR><FONT size=2></mircea> <SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff> </FONT></SPAN></FONT></P> <P><FONT size=2><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff><js> True, there are several diagrams and tables. However, the draft lacks an overall conceptual model. For example, if you look at RFC3060, Figure 1 shows an overview of all of the classes and their relationships.</FONT> <FONT face="Courier New" color=#0000ff> Note that there is no need to show attributes in such a picture - I'm just looking for a **visual** overview of how the different classes fit together. </js></FONT></SPAN></FONT></P> <P><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff><mircea2></FONT></SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004>A more appropriate place for an overall conceptual model diagram would have been RFC3460. Such diagram is somewhat out of scope for PCELS. Wrt. the LDAP mapping of PCIMe concepts, the case studies in section 4.x include several instance diagrams that illustrate the implementation options. There are many variations and they could hardly fit in a single diagram.</SPAN></FONT></P> <P><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004>This being said, I am certainly not against the inclusion of an overall class diagram. So, </SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004>should someone out there volunteer to make such a contribution to the document, I would gladly include it in a new revision of PCELS.</SPAN></FONT><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff></mircea2></FONT> </SPAN></FONT></P> <P><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004></SPAN></FONT> </P> <P><FONT size=2><SPAN class=879044212-27042004>[...]</SPAN></FONT></P> <P><FONT size=2><SPAN class=879044212-27042004></SPAN></FONT><FONT size=2>Fifth, why is there a pcelsRule and a pcimRule class?</FONT> <BR><FONT size=2><mircea>I do not understand the issue.</FONT> <BR><FONT size=2></mircea> <SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff> </FONT></SPAN></FONT></P> <P><FONT size=2><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff><js> Sorry for not being clearer. I understand that you wanted to create your own class (pcelsRule) because the semantics of RFC3460 were different (for PolicyRules) than those of RFC3460. I support your mentioning both in the draft, since there was feedback (e.g., from Ryan) that some implementations were still using pcimRule. However, I think that given this feedback, this draft needs some guidelines as to when one would use pcelsRule and one would use pcimRule, and what the implications of doing this are (e.g., how priority is implemented). </js></FONT></SPAN></FONT></P> <P><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff><mircea2></FONT></SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004>PCELS recommends the use of pcelsRule. While the use of pcimRule is not prevented by </SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004>PCELS, I do not see why this document would state any reasons in favour of this class. It is outside the scope of PCELS to make recommendations in this matter. Should RFC3460 be revised, this is where such issue should be addressed.</SPAN></FONT><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff></mircea2></FONT> </SPAN></FONT></P> <P><FONT size=2><SPAN class=879044212-27042004> </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></P> <P><FONT size=2></mircea> <SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff> </FONT></SPAN></FONT></P> <P><SPAN class=745254702-26042004><FONT size=2><FONT face="Courier New" color=#0000ff><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"><FONT color=#0000ff>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></FONT></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT size=2><FONT face="Courier New"><FONT color=#0000ff><SPAN class=879044212-27042004><FONT face=Arial><mircea2></FONT></SPAN></FONT></FONT></FONT></SPAN><SPAN class=745254702-26042004><FONT face=Arial color=#0000ff size=2><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 color=#0000ff size=2><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 size=2><FONT face="Courier New"><FONT color=#0000ff><SPAN class=879044212-27042004><FONT face=Arial></mircea2></FONT></SPAN></FONT></FONT></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT size=2><FONT face="Courier New"><FONT face=Arial color=#0000ff><SPAN class=879044212-27042004></SPAN></FONT></FONT></FONT></SPAN> </P> <P><FONT size=2><FONT face=Arial color=#0000ff><SPAN class=879044212-27042004> [...]</SPAN></FONT></FONT></P> <P><FONT size=2><FONT face=Arial color=#0000ff><SPAN class=879044212-27042004> </SPAN></FONT> - page 7 - you state: "The LDAP object classes defined in this document</FONT> <BR><FONT size=2> are a direct mapping from the corresponding classes and, in some </FONT><BR><FONT size=2> cases, the associations defined in [PCIM_EXT] ". Not strictly true, </FONT><BR><FONT size=2> as you are also seeking to update RFC 3703 (e.g., where is </FONT><BR><FONT size=2> pcimSubtreesPtrAuxClass defined in RFC 3460?).</FONT> <BR><FONT size=2><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 </FONT></P> <P><FONT size=2>your reference to pcimSubtreesPtrAuxClass. That class is not defined in PCELS.</FONT> <BR><FONT size=2><mircea></FONT> <SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff size=2> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT color=#0000ff><FONT size=2><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></FONT></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT color=#0000ff><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial><mircea2></FONT></SPAN></FONT></FONT></FONT></SPAN><SPAN class=745254702-26042004><FONT size=+0><FONT color=#0000ff><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></FONT></SPAN><SPAN class=745254702-26042004><FONT face="Courier New"><FONT color=#0000ff><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial></mircea2></FONT> </SPAN></FONT></FONT></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT color=#0000ff><FONT face=Arial size=2><SPAN class=879044212-27042004></SPAN></FONT></FONT></FONT></SPAN> </P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT color=#0000ff><FONT face=Arial size=2><SPAN class=879044212-27042004>[...]</SPAN></FONT></FONT></FONT></SPAN></P> <P><FONT size=2> - pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They</FONT> <BR><FONT size=2> aren't listed in this table, and better be, if you are "updating"</FONT> <BR><FONT size=2> RFC 3703.</FONT> <BR><FONT size=2><mircea>The two tables list PCIM_EXT classes mapped by PCELS. Why should the tables include PCLS classes?</FONT> <BR><FONT size=2></mircea><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff> </FONT></SPAN></FONT></P> <P><FONT color=#0000ff><FONT size=2><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></FONT><SPAN class=745254702-26042004> <SPAN class=879044212-27042004><FONT face=Arial size=2> </FONT></SPAN></SPAN></FONT></P> <P><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff><mircea2></FONT></SPAN></FONT><FONT face=Arial color=#0000ff size=2><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 color=#0000ff size=2><SPAN class=879044212-27042004>I fail to see why PCELS should re-define classes that do not change.</SPAN></FONT><FONT size=2><SPAN class=879044212-27042004><FONT color=#0000ff><FONT face=Arial></mircea2></FONT> </FONT></SPAN></FONT></P> <P><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004></SPAN></FONT> </P> <P><FONT size=2><SPAN class=879044212-27042004>[...]</SPAN></FONT></P> <P><FONT size=2><SPAN class=879044212-27042004></SPAN></FONT><FONT size=2><mircea> ...means that the PolicySetComponent aggregation is realised by a pcelsPolicySetComponentList value in the aggregating pcelsPolicySet. This attribute value is a DN reference to a pcelsPolicySetAsociation entry. The pcelsPolicySetAsociation entry includes a pcelsPolicySetDN attribute value that is a reference to the aggregated pcelsPolicySet. The details are in section 5. The table only gives an overview of the mapping.</FONT></P> <P><FONT size=2></mircea></FONT> <SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff size=2> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff size=2><js> OK, that makes sense, but I suggest you add a note saying "See section 5.x" so the impatient reader won't get frustrated. ;-) </js></FONT> <SPAN class=879044212-27042004><FONT face=Arial size=2> </FONT></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff size=2><mircea2></FONT></SPAN></SPAN><FONT color=#0000ff><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial size=2>"</FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial size=2>4.1 Summary of Class and Association Mappings</FONT></SPAN></SPAN></FONT></P> <P><FONT color=#0000ff><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial size=2>[...]</FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial size=2> The details of this mapping are discussed case by case in section 5."</FONT></SPAN></SPAN></FONT><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT color=#0000ff><FONT face=Arial size=2></mircea2></FONT> </FONT></SPAN></SPAN></P> <P><FONT size=2><FONT face=Arial><SPAN class=879044212-27042004> [...]</SPAN></FONT></FONT></P> <P><FONT size=2><FONT face=Arial><SPAN class=879044212-27042004> </SPAN></FONT> - Page 11 - the reader will wonder why ReusablePolicy and </FONT><BR><FONT size=2> PolicyRoleCollectionInSystem are only implementable via DIT </FONT><BR><FONT size=2> containment, when every other association has an association defined</FONT> <BR><FONT size=2> (independent of whether DIT containment could be used).</FONT> <BR><FONT size=2><mircea>I fail to see the issue.</FONT> <BR><FONT size=2></mircea></FONT> <SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff size=2> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff size=2><js> Good schemata are consistent. Why are these two associations only implementable via DIT containment? </js></FONT> <SPAN class=879044212-27042004><FONT face=Arial size=2> </FONT></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff size=2><mircea2></FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff size=2>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 color=#0000ff size=2>PolicyRoleCollectionInSystem, is still open for suggestions ;-) </FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT color=#0000ff><FONT face=Arial size=2></mircea2></FONT> </FONT></SPAN></SPAN></P> <P><FONT size=2> - Section 4.2, line 3, you write: "The concept of an ordered set of</FONT> <BR><FONT size=2> policies...". LDAP doesn't have ordered sets. How are you going to</FONT> <BR><FONT size=2> implement this?</FONT> <BR><FONT size=2><mircea>replaced "ordered" with "coherent" (from PCIM_EXT)</FONT> <BR><FONT size=2></mircea></FONT> <SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff size=2> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff><FONT size=2><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></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff><mircea2> </FONT></SPAN></FONT></FONT></SPAN><SPAN class=745254702-26042004><FONT face="Courier New"><FONT face=Arial color=#0000ff size=2><SPAN class=879044212-27042004>See note at the end of section 5.1 (page 26).</SPAN></FONT></FONT></SPAN><FONT color=#0000ff><SPAN class=745254702-26042004><FONT face="Courier New"><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial></mircea2></FONT> </SPAN></FONT></FONT> <SPAN class=879044212-27042004><FONT face=Arial size=2> </FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004> </SPAN></SPAN></FONT></P> <P><FONT face=Arial color=#0000ff size=2><SPAN class=745254702-26042004><SPAN class=879044212-27042004></SPAN></SPAN></FONT> </P> <P><FONT size=2><FONT face=Arial><SPAN class=879044212-27042004> [...]</SPAN></FONT></FONT></P> <P><FONT size=2><FONT face=Arial><SPAN class=879044212-27042004> </SPAN></FONT> - Page 23, note above Section 5.2, is slightly incorrect. Only those</FONT> <BR><FONT size=2> implementations that WANT TO BE COMPATIBLE WITH PCELS should use</FONT> <BR><FONT size=2> this aggregation mechanism instead of those defined by PCLS. Not</FONT> <BR><FONT size=2> every implementation mechanism is going to want to change.</FONT> <BR><FONT size=2><mircea>Revised. The section defining pcelsRule for example will include the following compatibility note:</FONT> </P> <P><FONT size=2> "Note 2: PCELS implementations SHOULD support pcelsRule and its two</FONT> <BR><FONT size=2> subclasses and MAY also support pcimRule and its two subclasses</FONT> <BR><FONT size=2> [PCLS]. Applications that choose to support pcelsRule and its two</FONT> <BR><FONT size=2> subclasses MUST use the aggregation mechanism provided by</FONT> <BR><FONT size=2> pcelsPolicySetAssociation for aggregating policy groups or policy</FONT> <BR><FONT size=2> rules in policy rules represented as instances of pcelsRule.</FONT> <BR><FONT size=2> Applications that intend to be compatible with [PCIM_EXT] MUST</FONT> <BR><FONT size=2> support pcelsRule and its two subclasses."</FONT> </P> <P><FONT size=2></mircea></FONT> <SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff size=2> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff><FONT size=2><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></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff><mircea2> </FONT></SPAN></FONT></FONT></SPAN><SPAN class=745254702-26042004><FONT size=+0><FONT face=Arial color=#0000ff 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"><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff></mircea2></FONT></SPAN></FONT></FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff><FONT size=2><SPAN class=879044212-27042004> </SPAN></FONT></FONT> </SPAN></P> <P><FONT size=2> - Page 23, Section 5.2, says "The pcelsPolicySetAssociation class is </FONT><BR><FONT size=2> used to aggregate instances of pcelsPolicySet into other entries."</FONT> <BR><FONT size=2> This is incorrect, as pcelsPolicySet is abstract and thus cannot be</FONT> <BR><FONT size=2> instantiated.</FONT> <BR><FONT size=2><mircea> I fail to see a problem with "instance of <abstract_class>". It is obvious that it means "instance of non-abstract subclass of <abstract_class>". The "non-abstract subclass of" is superfluous and has been omitted in order to improve the text readabilitiy. PCLS, for instance, uses such expressions on several occasions. E.g.: (PCLS page 50 first paragraph) "instances of pcimRules". Note that "pcimRules" is not a class name.</FONT></P> <P><FONT size=2></mircea></FONT> <SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff size=2> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff size=2><js> I still disagree (and with PCLS page 50 as well) - it is imprecise. </js></FONT> <SPAN class=879044212-27042004><FONT face=Arial size=2> </FONT></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff size=2><mircea2> </FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff size=2>Note 6 in section 5 warns the reader about the imprecise language. (page 23)</FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT color=#0000ff><FONT face=Arial size=2></mircea2></FONT> </FONT></SPAN></SPAN></P> <P><FONT size=2> - Same section, you write: "...realizes a (subclass of)</FONT> <BR><FONT size=2> PolicySetComponent aggregation [sic]. When subordinated to (subclass </FONT><BR><FONT size=2> of) dlm1System...realizes a PolicySetInSystem association [sic]".</FONT> <BR><FONT size=2> How can the same element realize an aggregation in one usage and an</FONT> <BR><FONT size=2> association in another usage? This is semantically inconsistent.</FONT> <BR><FONT size=2><mircea>I fail to see the issue. The semantics of pcelsPolicySetAssociation are context sensitive.</FONT> <BR><FONT size=2></mircea></FONT> <SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff size=2> </FONT></SPAN></P> <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff size=2><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 size=2> </FONT></SPAN></SPAN></P> <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff size=2><mircea2></FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial color=#0000ff size=2>...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 color=#0000ff><FONT face=Arial size=2></mircea2></FONT> </FONT></SPAN></SPAN></P> <P><FONT face=Arial size=2><SPAN class=879044212-27042004>[...]</SPAN></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C432A5.285D1CC0--