RE: response to comments on PCELS-05/May 06
"Pana, Mircea" <[email protected]> Fri, 28 May 2004 10:15:39 -0400
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============0770111807== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C444BE.40B052B4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C444BE.40B052B4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Look for my responses in <mircea4></mircea4>. Sorry, I'm slow to respond = as well. Regards, Mircea. =20 -----Original Message----- From: John Strassner [mailto:[email protected]] Sent: Saturday, May 22, 2004 5:49 PM To: [email protected]; John Strassner Cc: [email protected]; [email protected]; [email protected] Subject: RE: response to comments on PCELS-05/May 06 Please see inline, look for <js3>..</js3>. Sorry, as usual, for the = delay in responding...looks like we're down to two issues now... regards, John Strassner TeleManagement Forum Advisory Director John Strassner=20 Chief Strategy Officer=20 Intelliden Inc.=20 90 South Cascade Avenue=20 Colorado Springs, CO 80906 USA=20 phone: +1.719.785.0648=20 fax: +1.719.785.0644=20 email: [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]]=20 Sent: Wednesday, May 12, 2004 5:02 PM To: John Strassner Cc: [email protected]; [email protected]; [email protected] Subject: response to comments on PCELS-05/May 06 John, See my comments tagged <mircea3></mircea3>. =20 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/> =20 [...] =20 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> =20 <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>=20 <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>=20 <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.=20 <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>=20 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>=20 <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). 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> =20 <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. 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. 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> [...] - Page 11 - the reader will wonder why ReusablePolicy and=20 PolicyRoleCollectionInSystem are only implementable via DIT=20 containment, when every other association has an association defined = (independent of whether DIT containment could be used).=20 <mircea>I fail to see the issue.=20 </mircea> =20 <js> Good schemata are consistent. Why are these two associations only = implementable via DIT containment? </js> =20 <mircea2>For ReusablePolicy, DIT containment has the best scalability = (btw, PCLS does the same thing). PolicyRoleCollectionInSystem, is still open for suggestions ;-) = </mircea2>=20 <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>=20 <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>=20 <js3> You're on dangerous ground here...I thought it was obvious that a = User shouldn't be subclassed from a Computer, but more than one software = company has disagreed with this. ;-) Once again, this is a DATA MODEL. I = (amd my programmers) don't think that ANYTHING shoudl be left to = guesswork - and it isn't hard to add another line or two specifying = this. If you believe so strongly that DIT containment is the ONLY = CORRECT mechanism for implementers, say so and prove it. (And yes, the = above argument didn't convince me, though I **want** to agree with you.) = </js> =20 <mircea4>PolicyRoleCollectionInSystem is a weak association and weak = associations map well to DIT containment ("DMTF LDAP Schema for the CIM = v2.5 Core Information Model", section 2.8.2.4). It is true that DIT = containment is not the only way to map a weak association but you have = to agree that in the absence of additional constraints this (DIT = containment) is the obvious choice. On the other hand I think that the = spec. should not offer unnecessary choices. Redundant options make the = spec. ambiguous and hard to implement. So, please consider one of the = following two options: (1, preferred) add a note to indicate that DIT = containment was chosen as the optimal mapping for the = PolicyRoleCollectionInSystem weak association -or- (2) define a = additional single-value DN attribute to be used in pcelsRoleCollection = instances for representing the PolicyRoleCollectionInSystem. ReusablePolicy: I do not see the need to prove or justify the choice: = whatever reasons the authors of PCLS had for choosing DIT containment = are valid for PCELS too. However, as you suggest, it doesn't hurt to add = a note so I propose to say that DIT containment was chosen here for = scalability reasons and for consistency with PCLS.</mircea4> =20 ------_=_NextPart_001_01C444BE.40B052B4 Content-Type: text/html; charset="iso-8859-1" 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=3Diso-8859-1"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial color=3D#008000 size=3D2><SPAN = class=3D704483922-27052004>Look=20 for my responses in <mircea4></mircea4>. Sorry, I'm slow to = respond=20 as well.</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20 class=3D704483922-27052004>Regards,</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20 class=3D704483922-27052004>Mircea.</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D704483922-27052004></SPAN></FONT> </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> John Strassner=20 [mailto:[email protected]]<BR><B>Sent:</B> Saturday, May = 22, 2004=20 5:49 PM<BR><B>To:</B> [email protected]; John Strassner<BR><B>Cc:</B> = [email protected]; [email protected]; = [email protected]<BR><B>Subject:</B>=20 RE: response to comments on PCELS-05/May 06<BR><BR></FONT></DIV> <DIV><SPAN class=3D568004315-22052004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2>Please see inline, look for <js3>..</js3>. Sorry, = as usual,=20 for the delay in responding...looks like we're down to two issues=20 now...</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft> <P dir=3Dltr align=3Dleft><FONT face=3D"Times New Roman"><FONT=20 size=3D3>regards,<BR>John<SPAN class=3D050114416-03022004>=20 Strassner</SPAN><BR><SPAN class=3D050114416-03022004>TeleManagement=20 Forum Advisory Director<BR></P></SPAN></FONT></FONT> <P><FONT size=3D3><FONT face=3D"Times New Roman">John Strassner</FONT> = <BR><FONT=20 face=3D"Times New Roman">Chief Strategy Officer</FONT> <BR><FONT=20 face=3D"Times New Roman">Intelliden Inc.</FONT> <BR><FONT=20 face=3D"Times New Roman">90 South Cascade Avenue</FONT> <BR><FONT=20 face=3D"Times New Roman">Colorado Springs, CO 80906 = USA</FONT>=20 <BR><FONT face=3D"Times New Roman">phone: +1.719.785.0648</FONT> = <BR><FONT=20 face=3D"Times New Roman"> fax: =20 +1.719.785.0644</FONT> <BR><FONT=20 face=3D"Times New Roman">email: <A=20 = href=3D"mailto:[email protected]">[email protected]= om</A></FONT></FONT></P></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT=20 face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20 [email protected] [mailto:[email protected]] <BR><B>Sent:</B> = Wednesday,=20 May 12, 2004 5:02 PM<BR><B>To:</B> John Strassner<BR><B>Cc:</B>=20 [email protected]; [email protected];=20 [email protected]<BR><B>Subject:</B> response to comments on = PCELS-05/May=20 06<BR><BR></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D034421723-10052004>John, See my comments tagged=20 <mircea3></mircea3>.</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D034421723-10052004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D034421723-10052004>Thank You,</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D034421723-10052004>Mircea</SPAN></FONT></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> John Strassner = [mailto:[email protected]]<BR><B>Sent:</B> Thursday, = May 06,=20 2004 3:44 AM<BR><B>To:</B> [email protected]; John=20 Strassner<BR><B>Cc:</B> [email protected];=20 [email protected]<BR><B>Subject:</B> RE: your comments on = PCELS-05 /=20 April 26<BR><BR></FONT></DIV> <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2><SPAN=20 class=3D365492107-06052004>I've just pulled up the remaining = problems to=20 make it easier to deal with. I'm copying Joel and Bert so that = they know=20 that I am responding, albeit slowly...look for=20 <js2/></SPAN></FONT></DIV> <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2><FONT=20 face=3D"Times New Roman" = color=3D#000000></FONT></FONT> </DIV> <DIV><FONT face=3D"Courier New" size=3D2><FONT size=3D+0><FONT=20 face=3D"Times New Roman" color=3D#0000ff><SPAN=20 class=3D365492107-06052004>[...]</SPAN></FONT></FONT></FONT></DIV> <DIV><FONT face=3D"Courier New" size=3D2><FONT size=3D+0><FONT=20 face=3D"Times New Roman" color=3D#0000ff><SPAN=20 = class=3D365492107-06052004></SPAN></FONT></FONT></FONT> </DIV> <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2><FONT = size=3D+0><FONT=20 face=3D"Times New Roman"><SPAN = class=3D365492107-06052004></SPAN>Sixth, why is=20 there no pcelsRuleValidityAssociation subclass? At this point,=20 <mircea>I do not understand the issue. PCELS reuses=20 pcimRuleValidityAssociation that is defined in = PCLS</FONT></FONT></DIV> <P></mircea> <SPAN class=3D745254702-26042004><FONT=20 face=3D"Courier New"> </FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier = New"><js>=20 True, this is addressed in Note 1 in page 27 of the draft. Looking = at your=20 class structure, since you subclassed other associations, = I was=20 surprised that you didn't subclass this one as well. This is = because=20 pcelsRule and </FONT> <FONT face=3D"Courier New">pcimRule are = siblings,=20 and pcimRuleValidityPeriod (in PCIM) is defined to exist between = pcimRule=20 and policyConditionTimePeriod only. So, how do pcelsRule instances = use a=20 policyConditionTimePeriod? </js><SPAN = class=3D879044212-27042004><FONT=20 face=3DArial> </FONT></SPAN></FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier = New"><SPAN=20 class=3D879044212-27042004><FONT=20 face=3DArial><mircea2></FONT></SPAN></FONT></SPAN><SPAN=20 class=3D745254702-26042004><FONT face=3DArial><SPAN=20 class=3D879044212-27042004>PCELS adopts=20 pcimRuleValidityAssociation extending its applicability to=20 pcelsRule. I.e. PCELS recommends the use=20 = of pcimRuleValidityAssociation instances subordinated to=20 pcelsRule entries for associating pcimTPCAuxClass instances = to a=20 Rule. Note that PCELS also recommends that: "As result, = the=20 class pcimRuleValidityAssociation SHOULD be expected (and allowed) = to have=20 instances of pcelsRule as superior = entries."</SPAN></FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3DArial><SPAN=20 class=3D879044212-27042004>This isn't a change of semantics = for the=20 pcimRuleValidityAssociation class. In a PCELS implementation, = this=20 class continues to represent the PolicyRuleValidityPeriod=20 aggregation. Other association classes defined in PCIM are = subclassed=20 in PCELS for the purpose of extending their semantics (and for = changing=20 their names ;-)</SPAN></FONT></SPAN><SPAN = class=3D745254702-26042004><FONT=20 face=3D"Courier New"><SPAN class=3D879044212-27042004><FONT=20 face=3DArial></mircea2></FONT></SPAN></FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><js2> The = above logic is=20 incorrect. Look at how pcimRuleValidityPeriod is defined in = RFC3060. It is=20 NOT a representation of a PolicyRuleValidityPeriod, it is a = representation=20 of the *association* between a PolicyRuleValidityPeriod and a = PolicyRule.=20 So, the problem is that you have defined a pcelsPolicySet to be a = sibling=20 of pcimRule (to which pcimRuleValidityPeriod applies). Therefore,=20 pcimRuleValidityPeriod does NOT apply to pcelsPolicySet (and thus = not to=20 pcelsRule). Therefore, you have to either redefine this = association, or=20 create a new one. You did neither. </js2><SPAN=20 = class=3D034421723-10052004> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN=20 class=3D034421723-10052004><mircea3>I must be missing = something... You=20 say that pcimRuleValidityPeriod is defined in RFC3060 but in PCIM = I can=20 not find any reference to pcimRuleValidityPeriod. PCLS (RFC3703) = does=20 not define such class either. You also mention the=20 association between a PolicyRuleValidityPeriod and a PolicyRule = but I can=20 not find anything in either PCIM or PCLS that implements such=20 association.<SPAN class=3D568004315-22052004><FONT=20 face=3D"Courier = New"> </FONT></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></P></BLOCKQU= OTE></BLOCKQUOTE> <P dir=3Dltr><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004><SPAN=20 class=3D568004315-22052004><FONT color=3D#ff0000><FONT=20 face=3D"Courier New"><js3> Technically correct, but we need to = use a=20 little imagination here ;-) Of course if you search for that string it = won't=20 appear because the RFC doesn't use prefixes. This maps to=20 "PolicyRuleValidityPeriod" which is defined in Section 7.7, page 51. = And if=20 you read this section, it defines PolicyRuleValidityPeriod as an = aggregation.=20 = </js></FONT> </FONT></SPAN></SPAN></FONT></SPAN></SPAN></SPAN>= </P> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff = 2px solid; MARGIN-RIGHT: 0px"> <P><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN=20 class=3D034421723-10052004>However, in PCIM I read=20 that PolicyRuleValidityPeriod is defined as "A class = representing the=20 aggregation of PolicyTimePeriodConditions by a PolicyRule".=20 In</SPAN></FONT></SPAN></SPAN></SPAN><SPAN = class=3D745254702-26042004><SPAN=20 class=3D879044212-27042004><SPAN class=3D365492107-06052004><FONT=20 face=3DArial><SPAN class=3D034421723-10052004> PCLS I read = that "The=20 policyRuleValidityPeriod aggregation is mapped to the PCLS=20 pcimRuleValidityAssociation class." So, I conclude that=20 pcimRuleValidityAssociation is used to=20 associate TimePeriodConditions to a Rule. For PCLS = this means=20 associating instances of pcimTPCAuxClass to a pcimRule. For PCELS = this=20 would mean associating instances of pcimTPCAuxClass to a = pcelsRule. I=20 really don't see the problem.=20 = </mircea3> </SPAN></FONT></SPAN></SPAN></SPAN></P></BLOCKQUOTE= ></BLOCKQUOTE><SPAN=20 class=3D745254702-26042004><SPAN class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004> <P dir=3Dltr><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004><SPAN=20 class=3D568004315-22052004><FONT color=3D#ff0000><FONT=20 face=3D"Courier New"><js3> Huh? Look at your class = hierarchy. And=20 look at your reply in Mircea2 ("...extending [sic] its = applicability to=20 pcelsRule.") That's fine for a fluffy spec, but this is a spec of a = DATA=20 MODEL, and one must not make such assumptions. Strictly speaking, = since they=20 are siblings, this aggregation does NOT apply to pcelsRule.=20 Therefore, you must either define a new association (preferred) = or change=20 something).<BR><BR>Note also that I completely disagre with your logic = saying=20 that "this and this SHOULD happen". You (well, PCIMe) altered the = picture=20 in the definition of these classes, and we can't simply wave our hands = saying=20 that this should happen by magic without specifying it rigorously = in the=20 data model. </js></FONT> </FONT><FONT = color=3D#0000ff><SPAN=20 = class=3D704483922-27052004> </SPAN></FONT></SPAN></SPAN></FONT></SPA= N></SPAN></SPAN></P> <P dir=3Dltr><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004><SPAN=20 class=3D568004315-22052004><FONT color=3D#008000><SPAN=20 class=3D704483922-27052004><mircea4>I think that I = understand the=20 issue now: You are arguing that, = because pcimRuleValidityAssociation is=20 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.=20 PolicyRuleValidityPeriod) are preserved. This is somewhat similar to = our=20 previous argument about LDAP attribute type re-use. It=20 is, indeed, "elegant" to define new classes/attributes as = soon as=20 the slightest context change is=20 = introduced.</SPAN></FONT></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></P> <P dir=3Dltr><FONT color=3D#008000><SPAN = class=3D745254702-26042004><SPAN=20 class=3D879044212-27042004><SPAN class=3D365492107-06052004><FONT = face=3DArial><SPAN=20 class=3D034421723-10052004><SPAN = class=3D568004315-22052004><FONT><SPAN=20 class=3D704483922-27052004>However, in order to reduce the=20 churn (and this has been requested by PCELS reviewers) = I have a=20 strong preference for the current proposal. I believe that = it is the=20 most *practical* approach to the=20 = problem.</SPAN></FONT></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></FONT></= P> <P dir=3Dltr><FONT color=3D#008000><SPAN = class=3D745254702-26042004><SPAN=20 class=3D879044212-27042004><SPAN class=3D365492107-06052004><FONT = face=3DArial><SPAN=20 class=3D034421723-10052004><SPAN = class=3D568004315-22052004><FONT><SPAN=20 class=3D704483922-27052004>Wrt. the text at the end of note 1 in = section=20 5.4 of PCELS ("pcimRuleValidityAssociation SHOULD be expected..."), = for=20 clarity, I suggest changing it to:=20 </SPAN></FONT></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></FONT><FONT=20 color=3D#008000><SPAN class=3D745254702-26042004><SPAN=20 class=3D879044212-27042004><SPAN class=3D365492107-06052004><FONT = face=3DArial><SPAN=20 class=3D034421723-10052004><SPAN = class=3D568004315-22052004><FONT><SPAN=20 = class=3D704483922-27052004>"</SPAN></FONT></SPAN></SPAN></FONT></SPAN></S= PAN></SPAN><SPAN=20 class=3D745254702-26042004><SPAN class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004><SPAN=20 class=3D568004315-22052004><FONT><SPAN class=3D704483922-27052004>If = DIT structure=20 rules and name forms are written for a PCELS implementation (as=20 suggested in section 5.5 of [PCLS]), they would require that an = instance=20 of the pcimRuleValidityAssociation class have as its superior an = instance=20 of the pcelsRule class or, if applicable, an instance of the pcimRule = class.=20 Any structure rules and name forms that require an = instance of=20 the pcimRuleValidityAssociation class to have as its superior only an = instance=20 of the pcimRule class, are in conflict and MUST be=20 removed."</SPAN></FONT></SPAN></SPAN></FONT></SPAN></SPAN></SPAN><SPAN = class=3D745254702-26042004><SPAN class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004><SPAN=20 class=3D568004315-22052004><FONT><SPAN=20 = class=3D704483922-27052004></mircea4></SPAN></FONT></SPAN></SPAN></= FONT></SPAN></SPAN></SPAN></FONT></P></SPAN></FONT></SPAN></SPAN></SPAN> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff = 2px solid; MARGIN-RIGHT: 0px"> <P><FONT face=3DArial><SPAN=20 class=3D879044212-27042004> [...]</SPAN></FONT></P> <P> <P><SPAN class=3D879044212-27042004></SPAN></P><FONT = face=3DArial><SPAN=20 class=3D879044212-27042004> </SPAN></FONT> - Page 11 - = the reader=20 will wonder why ReusablePolicy and <BR> =20 PolicyRoleCollectionInSystem are only implementable via DIT=20 <BR> containment, when every other association = has an=20 association defined <BR> (independent of whether = DIT=20 containment could be used). <BR><mircea>I fail to see the = issue.=20 <BR></mircea> <SPAN class=3D745254702-26042004><FONT=20 face=3D"Courier = New"> </FONT></SPAN></P></BLOCKQUOTE></BLOCKQUOTE> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff = 2px solid; MARGIN-RIGHT: 0px"> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier = New"><js> Good=20 schemata are consistent. Why are these two = associations only=20 implementable via DIT containment? </js></FONT> <SPAN=20 class=3D879044212-27042004><FONT = face=3DArial> </FONT></SPAN></SPAN></P> <P><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><FONT=20 face=3DArial><mircea2></FONT></SPAN></SPAN><SPAN=20 class=3D745254702-26042004><SPAN class=3D879044212-27042004><FONT=20 face=3DArial>For ReusablePolicy, DIT containment has the best = scalability (btw, PCLS does the same = thing).</FONT></SPAN></SPAN></P> <P><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><FONT=20 face=3DArial>PolicyRoleCollectionInSystem, is still open for=20 suggestions ;-) </FONT></SPAN></SPAN><SPAN=20 class=3D745254702-26042004><SPAN class=3D879044212-27042004><FONT=20 face=3DArial></mircea2></FONT> </SPAN></SPAN></P> <P><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><js2> But, my = issue of=20 consistency still holds. You are preventing the developer from = having a=20 choice here. I would suggest defining both and then stating, = editorially,=20 that DIT containment is preferred here. </js2><SPAN=20 = class=3D034421723-10052004> </SPAN></FONT></SPAN></SPAN></SPAN></P> <P><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN=20 class=3D034421723-10052004><mircea3>I have reviewed the = PCIMe=20 definitions for these two associations and I think = that mapping them=20 to LDAP classes/attributes is unnecessary (or = even wrong).=20 A <SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><FONT=20 face=3DArial>PolicyRoleCollection if it exists, it only exists in = the=20 context of a System, therefore the obvious = LDAP implementation=20 for <SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><FONT=20 face=3DArial>PolicyRoleCollectionInSystem </FONT></SPAN></SPAN>is = DIT=20 containment. ReusablePolicy places a policy element in a = *container*. Once=20 again, the obvious choice is DIT containment. In addition, one = could also=20 argue that mapping ReusablePolicy only to DIT containment=20 is consistent with PCLS (see Policy*InPolicyRepository = association=20 mappings in=20 = PCLS).</FONT></SPAN></SPAN></mircea3> </SPAN></FONT></SPAN></S= PAN></SPAN></P></BLOCKQUOTE></BLOCKQUOTE><SPAN=20 class=3D745254702-26042004><SPAN class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004> <P dir=3Dltr><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004><SPAN=20 class=3D568004315-22052004><FONT color=3D#ff0000><FONT=20 face=3D"Courier New"><js3> You're on dangerous ground = here...I=20 thought it was obvious that a User shouldn't be subclassed from a = Computer,=20 but more than one software company has disagreed with this. ;-) = Once=20 again, this is a DATA MODEL. I (amd my programmers) = don't think=20 that ANYTHING shoudl be left to guesswork - and it isn't hard to add = another=20 line or two specifying this. If you believe so strongly that DIT = containment=20 is the ONLY CORRECT mechanism for implementers, say so and prove it. = (And yes,=20 the above argument didn't convince me, though I **want** to agree = with=20 you.) </js></FONT> </FONT><FONT color=3D#0000ff><SPAN=20 = class=3D704483922-27052004> </SPAN></FONT></SPAN></SPAN></FONT></SPA= N></SPAN></SPAN></P> <P dir=3Dltr><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004><SPAN=20 class=3D568004315-22052004><FONT color=3D#0000ff><SPAN=20 class=3D704483922-27052004> <SPAN = class=3D745254702-26042004><SPAN=20 class=3D879044212-27042004><SPAN class=3D365492107-06052004><FONT = face=3DArial><SPAN=20 class=3D034421723-10052004><SPAN class=3D568004315-22052004><FONT=20 color=3D#008000><SPAN=20 class=3D704483922-27052004><mircea4>PolicyRoleCollectionInSystem = is a weak=20 association and weak associations map well to DIT = containment ("DMTF LDAP=20 Schema for the CIM v2.5 Core Information Model", section 2.8.2.4). It = is true=20 that DIT containment is not the only way to map a weak = association but=20 you have to agree that in the absence of additional constraints this = (DIT=20 containment) is the obvious choice. On the other hand I think that the = spec.=20 should not offer unnecessary choices. Redundant options make = the=20 spec. ambiguous and hard to implement. So, please consider one=20 of the following two options:=20 = (</SPAN></FONT></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SPAN></FONT></= SPAN></SPAN></FONT></SPAN></SPAN></SPAN><SPAN=20 class=3D745254702-26042004><SPAN class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004><SPAN=20 class=3D568004315-22052004><FONT color=3D#0000ff><SPAN=20 class=3D704483922-27052004><SPAN class=3D745254702-26042004><SPAN=20 class=3D879044212-27042004><SPAN class=3D365492107-06052004><FONT = face=3DArial><SPAN=20 class=3D034421723-10052004><SPAN class=3D568004315-22052004><FONT=20 color=3D#008000><SPAN class=3D704483922-27052004>1, preferred) add a = note to=20 indicate that DIT containment was chosen as the optimal mapping = for=20 the PolicyRoleCollectionInSystem weak association=20 = -or- (2)</SPAN></FONT></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></SP= AN></FONT></SPAN></SPAN></FONT></SPAN></SPAN></SPAN><SPAN=20 class=3D745254702-26042004><SPAN class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004><SPAN=20 class=3D568004315-22052004><FONT color=3D#0000ff><SPAN=20 class=3D704483922-27052004><SPAN class=3D745254702-26042004><SPAN=20 class=3D879044212-27042004><SPAN class=3D365492107-06052004><FONT = face=3DArial><SPAN=20 class=3D034421723-10052004><SPAN class=3D568004315-22052004><FONT=20 color=3D#008000><SPAN class=3D704483922-27052004> define a=20 additional single-value DN attribute to be used in = pcelsRoleCollection instances for representing=20 = the PolicyRoleCollectionInSystem.</SPAN></FONT></SPAN></SPAN></FONT>= </SPAN></SPAN></SPAN></SPAN></FONT></SPAN></SPAN></FONT></SPAN></SPAN></S= PAN></P> <P dir=3Dltr><SPAN class=3D745254702-26042004><SPAN = class=3D879044212-27042004><SPAN=20 class=3D365492107-06052004><FONT face=3DArial><SPAN = class=3D034421723-10052004><SPAN=20 class=3D568004315-22052004><FONT color=3D#0000ff><SPAN=20 class=3D704483922-27052004><SPAN class=3D745254702-26042004><SPAN=20 class=3D879044212-27042004><SPAN class=3D365492107-06052004><FONT = face=3DArial><SPAN=20 class=3D034421723-10052004><SPAN class=3D568004315-22052004><FONT=20 color=3D#008000><SPAN class=3D704483922-27052004>ReusablePolicy: I do = not see=20 the need to prove or justify the choice: whatever reasons = the=20 authors of PCLS had for choosing DIT containment are valid for PCELS = too.=20 However, as you suggest, it doesn't hurt to add a note so I propose to = say=20 that DIT containment was chosen here for scalability reasons = and for=20 consistency with=20 = PCLS.</mircea4></SPAN></FONT></SPAN></SPAN></FONT></SPAN></SPAN></S= PAN></SPAN></FONT></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></P></SPAN></= FONT></SPAN></SPAN></SPAN> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff = 2px solid; MARGIN-RIGHT: 0px"> <P> = </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C444BE.40B052B4-- --===============0770111807== 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 --===============0770111807==--