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

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

John,

You have started this thread by asking: "why is there no pcelsRuleValidityAssociation subclass?" In a subsequent message, you have further detailed the issue by saying: "Looking at your class structure, since you subclassed other associations, I was surprised that you didn't subclass this one as well."

Besides, PCELS defines the pcelsConditionAssociation and pcelsActionAssociation classes by subclassing PCLS classes for the purpose of extending their semantics. Neither you nor any other reviewer of the I-D has expressed any issue with those definitions.

The latest proposal *does* accommodate your original request but I see you bringing up a different issue now. So, if you think that it is wrong to subclass the PCLS association class(es), please help me out by pointing to the LDAP (or other) specification that would be violated. I am not aware of any.

Thank you,
Mircea.


> -----Original Message-----
> From: John Strassner [mailto:John.Strassner at intelliden.com]
> Sent: Friday, June 04, 2004 5:45 PM
> To: Pana, Mircea; policy at ietf.org
> Cc: bwijnen at lucent.com; joel at stevecrocker.com
> Subject: RE: response to comments on PCELS-05/May 06
> 
> 
> Hmm.
> 
> First, I don't think subclassing helps, because the root 
> problem is that
> pcimRuleValidityAssociation doesn't apply to a pcelsRule 
> (pcelsRule is a
> sibling of pcimRule. Thus, I believe that you need a new class.
> 
> Second, rather than pcelsValidityAssociation, could I suggest
> pcelsRuleValidityAssociation?
> 
> 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: Pana, Mircea [mailto:mpana at metasolv.com] 
> > Sent: Friday, June 04, 2004 2:48 PM
> > To: policy at ietf.org; John Strassner
> > Cc: bwijnen at lucent.com; joel at stevecrocker.com
> > Subject: 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: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. 
> 

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