-----Original Message-----
From: John Strassner [mailto:John.Strassner at intelliden.com]
Sent: Saturday, May 22, 2004 5:49 PM
To: mpana at metasolv.com; John Strassner
Cc: joel at stevecrocker.com; bwijnen at lucent.com; policy at ietf.org
Subject: RE: response to comments on PCELS-05/May 06Please 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 DirectorJohn Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO 80906 USA
phone: +1.719.785.0648
fax: +1.719.785.0644
email: john.strassner at intelliden.com-----Original Message-----
From: mpana at metasolv.com [mailto:mpana at metasolv.com]
Sent: Wednesday, May 12, 2004 5:02 PM
To: John Strassner
Cc: joel at stevecrocker.com; bwijnen at lucent.com; policy at ietf.org
Subject: response to comments on PCELS-05/May 06John, See my comments tagged <mircea3></mircea3>.Thank You,Mircea-----Original Message-----
From: John Strassner [mailto:John.Strassner at intelliden.com]
Sent: Thursday, May 06, 2004 3:44 AM
To: mpana at metasolv.com; John Strassner
Cc: joel at stevecrocker.com; bwijnen at lucent.com
Subject: RE: your comments on PCELS-05 / April 26I'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.
<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>
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>
<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><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
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>
<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>
<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>
_______________________________________________ Policy mailing list Policy at ietf.org https://www1.ietf.org/mailman/listinfo/policy