[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Fine. Since it is technically incorrect, please be advised that I will
object in any Last Call.

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: Wednesday, June 09, 2004 6:13 PM
> To: John Strassner; joel at stevecrocker.com
> Cc: bwijnen at lucent.com; policy at ietf.org
> Subject: RE: [Policy] RE: response to comments on PCELS-05/May 06
> 
> 
> John, Although very interesting, your arguments have failed 
> to convince me that your suggestion would be a better option. 
> We have to agree that we disagree ;-)
> 
> Joel, Unless somebody produces arguments to prove the 
> contrary, I would like to ask you to accept the version 
> currently included in the I-D (i.e. reuse of 
> pcimRuleValidityAssociation for pcelsRule) with the revised 
> Note 1 in section 5.4 on the premise that: 1. it accurately 
> maps the PCIMe model 2. it does not violate current LDAP 
> recommendations 3. it is a practical approach (simplifies 
> implementations)
> 
> Thank you,
> Mircea.
> 
> 
> > -----Original Message-----
> > From: John Strassner [mailto:John.Strassner at intelliden.com]
> > Sent: Tuesday, June 08, 2004 5:05 PM
> > To: Pana, Mircea
> > Cc: joel at stevecrocker.com; bwijnen at lucent.com; policy at ietf.org
> > Subject: [Policy] RE: response to comments on PCELS-05/May 06
> > 
> > 
> > I don't think we're making progress anymore. Regardless of 
> what I may 
> > have said, or what you think I may have said in the beginning, I've 
> > given you very clear rationale as to what should be done.
> > 
> > One last time: you can't subclass the existing association 
> because it 
> > was defined between classes that do not include pcelsRule.
> > 
> > I have nothing else to say, as I don't know how to make this any 
> > clearer.
> > 
> > 
> > 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: Monday, June 07, 2004 1:02 PM
> > > To: John Strassner
> > > Cc: policy at ietf.org; bwijnen at lucent.com; joel at stevecrocker.com
> > > Subject: RE: response to comments on PCELS-05/May 06
> > > 
> > > 
> > > 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
> > 
> 

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