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

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:[email protected]]
Sent: Friday, June 04, 2004 9:37 AM
To: [email protected]
Cc: [email protected]; 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" <[email protected]>
Cc: <[email protected]>,
        <[email protected]>,
        <[email protected]>

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

regards,
John Strassner=20
-----Original Message-----=20
From: Pana, Mircea [mailto:[email protected]]=20
Sent: Friday, May 28, 2004 8:16 AM=20
To: John Strassner=20
Cc: [email protected]; [email protected]; [email protected]=20
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.=20
Regards,=20
Mircea.=20
=20
-----Original Message-----=20
From: John Strassner [mailto:[email protected]]=20
Sent: Saturday, May 22, 2004 5:49 PM=20
To: [email protected]; John Strassner=20
Cc: [email protected]; [email protected]; [email protected]=20
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,=20
John Strassner=20
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]=20
-----Original Message-----=20
From: [email protected] [mailto:[email protected]]=20
Sent: Wednesday, May 12, 2004 5:02 PM=20
To: John Strassner=20
Cc: [email protected]; [email protected]; [email protected]=20
Subject: response to comments on PCELS-05/May 06


John, See my comments tagged <mircea3></mircea3>.=20
=20
Thank You,=20
Mircea=20
-----Original Message-----=20
From: John Strassner [mailto:[email protected]]=20
Sent: Thursday, May 06, 2004 3:44 AM=20
To: [email protected]; John Strassner=20
Cc: [email protected]; [email protected]=20
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
[...]=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>