RE: response to comments on PCELS-05/May 06
"Joel M. Halpern" <[email protected]> Fri, 04 Jun 2004 09:37:01 -0400
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <5.1.0.14.0.20040604092953.0241bb58@localhost> |
--===============0181992527== Content-Type: text/html; charset="us-ascii" <html> I have looked this over again, and I think I understand the question.<br><br> From an object mapping and class definition perspective, it appears to me that extending the definition of pcimRuleValidityAssociation to point to a pcelsRule is probably not appropriate.<br><br> It seems to me thinking about this that adding a different association class for the pcelsRule - time-period relationship will not adversely affect either existim PCLS implementors or future PCELS implementors. Ruding churn in an I-D before publication is not a good reason to avoid making a technically correct change.<br><br> However, I could easily have missed multiple aspects of this.<br> If there are folks looking at implementing PCELS who have an opinion on the complexity of either the current "extension" or the proposed additional class, please speak up.<br> If there are LDAP folks (other than John, who has been very helpful) who can shed light or opinions on this, I would love to hear from them.<br><br> Given how many times we have been around the block on this, I would like to ask folks to respond within one week. If we hear nothing, I will ask Mircea and company if they can make this one last change, and hand the document to Bert for publication.<br><br> And then we will officially close the working group!<br><br> Yours,<br> Joel M. Halpern<br><br> At 07:55 PM 6/3/2004 -0600, John Strassner wrote:<br> <blockquote type=cite class=cite cite>Subject: RE: response to comments on PCELS-05/May 06<br> To: "Pana, Mircea" <[email protected]><br> Cc: <[email protected]>,<br> <x-tab> </x-tab><[email protected]>,<br> <x-tab> </x-tab><[email protected]><br><br> <font size=2 color="#0000FF">Hi Mircea,<br> </font> <br> <font size=2 color="#0000FF">thanks for your thoughtful response.<br> </font> <br> <font size=2 color="#0000FF">Regarding the first issue, I still disagree. The definition of the class doesn't allow this, even though the semantics remain unchanged. Since we are at an impasse, I'm happy to let Joel rule one way or the other.<br> </font> <br> <font size=2 color="#0000FF">Regarding changing the note in section 5.4, I agree with the change.<br> </font> <br> <font size=2 color="#0000FF">Regarding the DIT containment issue, I'm happy with your suggestion.<br> </font> <br><br> <font face="Times New Roman, Times">regards,<br> John Strassner</font> <dl><font face="tahoma" size=2> <dd>-----Original Message----- <dd>From: Pana, Mircea [<a href="mailto:[email protected]" eudora="autourl">mailto:[email protected]</a>] <dd>Sent: Friday, May 28, 2004 8:16 AM <dd>To: John Strassner <dd>Cc: [email protected]; [email protected]; [email protected] <dd>Subject: RE: response to comments on PCELS-05/May 06<br><br> </font><font face="arial" size=2 color="#008000"> <dd>Look for my responses in <mircea4></mircea4>. Sorry, I'm slow to respond as well. <dd>Regards, <dd>Mircea.</font> <dd> <font face="tahoma" size=2> <dd>-----Original Message----- <dd>From: John Strassner [<a href="mailto:[email protected]" eudora="autourl">mailto:[email protected]</a>] <dd>Sent: Saturday, May 22, 2004 5:49 PM <dd>To: [email protected]; John Strassner <dd>Cc: [email protected]; [email protected]; [email protected] <dd>Subject: RE: response to comments on PCELS-05/May 06<br><br> </font><font size=2 color="#0000FF"> <dd>Please see inline, look for <js3>..</js3>. Sorry, as usual, for the delay in responding...looks like we're down to two issues now...<br><br> </font><font face="Times New Roman, Times"> <dd>regards, <dd>John Strassner <dd>TeleManagement Forum Advisory Director<br><br> <dd>John Strassner</font> <font face="Times New Roman, Times"> <dd>Chief Strategy Officer</font> <font face="Times New Roman, Times"> <dd>Intelliden Inc.</font> <font face="Times New Roman, Times"> <dd>90 South Cascade Avenue</font> <font face="Times New Roman, Times"> <dd>Colorado Springs, CO 80906 USA</font> <font face="Times New Roman, Times"> <dd>phone: +1.719.785.0648</font> <font face="Times New Roman, Times"> <dd> fax: +1.719.785.0644</font> <font face="Times New Roman, Times"> <dd>email: <a href="mailto:[email protected]">[email protected]</a></font><font face="tahoma" size=2> <dd>-----Original Message----- <dd>From: [email protected] [<a href="mailto:[email protected]" eudora="autourl">mailto:[email protected]</a>] <dd>Sent: Wednesday, May 12, 2004 5:02 PM <dd>To: John Strassner <dd>Cc: [email protected]; [email protected]; [email protected] <dd>Subject: response to comments on PCELS-05/May 06<br><br> </font><font face="arial" size=2 color="#0000FF"> <dd>John, See my comments tagged <mircea3></mircea3>.</font> <dd> <font face="arial" size=2 color="#0000FF"> <dd>Thank You, <dd>Mircea</font><font face="tahoma" size=2> <dd>-----Original Message----- <dd>From: John Strassner [<a href="mailto:[email protected]" eudora="autourl">mailto:[email protected]</a>] <dd>Sent: Thursday, May 06, 2004 3:44 AM <dd>To: [email protected]; John Strassner <dd>Cc: [email protected]; [email protected] <dd>Subject: RE: your comments on PCELS-05 / April 26<br><br> </font><font size=2 color="#0000FF"> <dd>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/></font> <dd> <font face="Times New Roman, Times" color="#0000FF"> <dd>[...]</font> <dd> <font face="Times New Roman, Times" color="#0000FF"> <dd>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<br><br> </font><font size=2 color="#0000FF"> <dd></mircea> <br><br> <dd><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></font><font face="arial" size=2 color="#0000FF"> <dd><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."<br><br> <dd>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><br><br> <dd><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> <br><br> <dd><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.</font> </dl><font color="#FF0000"><js3> Technically correct, but we need to use a little imagination here ;-) Of course if you search for that string it won't appear because the RFC doesn't use prefixes. This maps to "PolicyRuleValidityPeriod" which is defined in Section 7.7, page 51. And if you read this section, it defines PolicyRuleValidityPeriod as an aggregation. </js></font><font face="arial" color="#FF0000"> </font> <dl> <dd>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> </dl><font color="#FF0000"><js3> Huh? Look at your class hierarchy. And look at your reply in Mircea2 ("...extending [sic] its applicability to pcelsRule.") That's fine for a fluffy spec, but this is a spec of a DATA MODEL, and one must not make such assumptions. Strictly speaking, since they are siblings, this aggregation does NOT apply to pcelsRule. Therefore, you must either define a new association (preferred) or change something).<br><br> Note also that I completely disagre with your logic saying that "this and this SHOULD happen". You (well, PCIMe) altered the picture in the definition of these classes, and we can't simply wave our hands saying that this should happen by magic without specifying it rigorously in the data model. </js></font><font face="arial" color="#FF0000"> </font><font face="arial" color="#0000FF"><br> <br> </font><font face="arial" color="#008000"><mircea4>I think that I understand the issue now: You are arguing that, because pcimRuleValidityAssociation is defined to be associated (and subordinated) to a pcimRule, a submodel is NOT allowed to use it anywhere else even if its semantics (i.e. PolicyRuleValidityPeriod) are preserved. This is somewhat similar to our previous argument about LDAP attribute type re-use. It is, indeed, "elegant" to define new classes/attributes as soon as the slightest context change is introduced.<br><br> However, in order to reduce the churn (and this has been requested by PCELS reviewers) I have a strong preference for the current proposal. I believe that it is the most *practical* approach to the problem.<br><br> Wrt. the text at the end of note 1 in section 5.4 of PCELS ("pcimRuleValidityAssociation SHOULD be expected..."), for clarity, I suggest changing it to: "If DIT structure rules and name forms are written for a PCELS implementation (as suggested in section 5.5 of [PCLS]), they would require that an instance of the pcimRuleValidityAssociation class have as its superior an instance of the pcelsRule class or, if applicable, an instance of the pcimRule class. Any structure rules and name forms that require an instance of the pcimRuleValidityAssociation class to have as its superior only an instance of the pcimRule class, are in conflict and MUST be removed."</mircea4></font></blockquote></html> --===============0181992527== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Policy mailing list [email protected] https://www1.ietf.org/mailman/listinfo/policy --===============0181992527==--