[Policy] RE: response to comments on PCELS-05/May 06

["Pana, Mircea" <mpana at metasolv.com>]

To accomodate the change requested by Joel, I'm making the proposal below. Please review it and let me know as soon as possible whether you like or not.

Instead of re-using pcimRuleValidityAssociation, PCELS would introduce a new class: pcelsValidityAssociation. This new class would be a subclass of pcimRuleValidityAssociation and it would not introduce any new attributes. Its instances would be subordinated to pcelsRule instances. (Much like pcelsConditionAssociation etc.) The pcelsRule class, instead of reusing the pcimRuleValidityPeriodList attribute, would use a new attribute (pcelsValidityPeriodList) as reference to its pcelsValidityAssociation instances.

In addition, Note 1 in section 5.4 would be removed.

Regards,
Mircea.


-----Original Message-----
From: Joel M. Halpern [mailto:joel at stevecrocker.com]
Sent: Friday, June 04, 2004 9:37 AM
To: policy at ietf.org
Cc: bwijnen at lucent.com; John Strassner; Pana, Mircea
Subject: RE: response to comments on PCELS-05/May 06


I have looked this over again, and I think I understand the question.

>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.

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.

However, I could easily have missed multiple aspects of this.
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.
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.

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.

And then we will officially close the working group!

Yours,
Joel M. Halpern

At 07:55 PM 6/3/2004 -0600, John Strassner wrote:

Subject: RE: response to comments on PCELS-05/May 06
To: "Pana, Mircea" <mpana at metasolv.com>
Cc: <joel at stevecrocker.com>,
        <bwijnen at lucent.com>,
        <policy at ietf.org>

Hi Mircea,
 
thanks for your thoughtful response.
 
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.
 
Regarding changing the note in section 5.4, I agree with the change.
 
Regarding the DIT containment issue, I'm happy with your suggestion.
 

regards,
John Strassner 
-----Original Message----- 
From: Pana, Mircea [mailto:mpana at metasolv.com] 
Sent: Friday, May 28, 2004 8:16 AM 
To: John Strassner 
Cc: joel at stevecrocker.com; bwijnen at lucent.com; policy at ietf.org 
Subject: RE: response to comments on PCELS-05/May 06


Look for my responses in <mircea4></mircea4>. Sorry, I'm slow to respond as well. 
Regards, 
Mircea. 
 
-----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 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 
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 06


John, 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 26


I've just pulled up the remaining problems to make it easier to deal with. I'm copying Joel and Bert so that they know that I am responding, albeit slowly...look for <js2/> 
 
[...] 
 
Sixth, why is there no pcelsRuleValidityAssociation subclass? At this point, <mircea>I do not understand the issue. PCELS reuses pcimRuleValidityAssociation that is defined in PCLS


</mircea>  


<js> True, this is addressed in Note 1 in page 27 of the draft. Looking at your class structure, since you subclassed other associations, I was surprised that you didn't subclass this one as well. This is because pcelsRule and  pcimRule are siblings, and pcimRuleValidityPeriod (in PCIM) is defined to exist between pcimRule and policyConditionTimePeriod only. So, how do pcelsRule instances use a policyConditionTimePeriod? </js> 
<mircea2>PCELS adopts pcimRuleValidityAssociation extending its applicability to pcelsRule. I.e. PCELS recommends the use of pcimRuleValidityAssociation instances subordinated to pcelsRule entries for associating pcimTPCAuxClass instances to a Rule. Note that PCELS also recommends that: "As result, the class pcimRuleValidityAssociation SHOULD be expected (and allowed) to have instances of pcelsRule as superior entries."


This isn't a change of semantics for the pcimRuleValidityAssociation class. In a PCELS implementation, this class continues to represent the PolicyRuleValidityPeriod aggregation. Other association classes defined in PCIM are subclassed in PCELS for the purpose of extending their semantics (and for changing their names ;-)</mircea2>


<js2> The above logic is incorrect. Look at how pcimRuleValidityPeriod is defined in RFC3060. It is NOT a representation of a PolicyRuleValidityPeriod, it is a representation of the *association* between a PolicyRuleValidityPeriod and a PolicyRule. So, the problem is that you have defined a pcelsPolicySet to be a sibling of pcimRule (to which pcimRuleValidityPeriod applies). Therefore, pcimRuleValidityPeriod does NOT apply to pcelsPolicySet (and thus not to pcelsRule). Therefore, you have to either redefine this association, or create a new one. You did neither. </js2> 


<mircea3>I must be missing something... You say that pcimRuleValidityPeriod is defined in RFC3060 but in PCIM I can not find any reference to pcimRuleValidityPeriod. PCLS (RFC3703) does not define such class either. You also mention the association between a PolicyRuleValidityPeriod and a PolicyRule but I can not find anything in either PCIM or PCLS that implements such association. 
<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>

_______________________________________________
Policy mailing list
Policy at ietf.org
https://www1.ietf.org/mailman/listinfo/policy