RE: 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=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]



> -----Original Message-----
> From: Pana, Mircea [mailto:[email protected]]=20
> Sent: Wednesday, June 09, 2004 6:13 PM
> To: John Strassner; [email protected]
> Cc: [email protected]; [email protected]
> Subject: RE: [Policy] RE: response to comments on PCELS-05/May 06
>=20
>=20
> John, Although very interesting, your arguments have failed=20
> to convince me that your suggestion would be a better option.=20
> We have to agree that we disagree ;-)
>=20
> Joel, Unless somebody produces arguments to prove the=20
> contrary, I would like to ask you to accept the version=20
> currently included in the I-D (i.e. reuse of=20
> pcimRuleValidityAssociation for pcelsRule) with the revised=20
> Note 1 in section 5.4 on the premise that: 1. it accurately=20
> maps the PCIMe model 2. it does not violate current LDAP=20
> recommendations 3. it is a practical approach (simplifies=20
> implementations)
>=20
> Thank you,
> Mircea.
>=20
>=20
> > -----Original Message-----
> > From: John Strassner [mailto:[email protected]]
> > Sent: Tuesday, June 08, 2004 5:05 PM
> > To: Pana, Mircea
> > Cc: [email protected]; [email protected]; [email protected]
> > Subject: [Policy] RE: response to comments on PCELS-05/May 06
> >=20
> >=20
> > I don't think we're making progress anymore. Regardless of=20
> what I may=20
> > have said, or what you think I may have said in the beginning, I've=20
> > given you very clear rationale as to what should be done.
> >=20
> > One last time: you can't subclass the existing association=20
> because it=20
> > was defined between classes that do not include pcelsRule.
> >=20
> > I have nothing else to say, as I don't know how to make this any=20
> > clearer.
> >=20
> >=20
> > regards,
> > John Strassner
> > TeleManagement Forum Advisory Director
> >=20
> >=20
> > John Strassner
> > 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
> >=20
> >=20
> > > -----Original Message-----
> > > From: Pana, Mircea [mailto:[email protected]]
> > > Sent: Monday, June 07, 2004 1:02 PM
> > > To: John Strassner
> > > Cc: [email protected]; [email protected]; [email protected]
> > > Subject: RE: response to comments on PCELS-05/May 06
> > >=20
> > >=20
> > > John,
> > >=20
> > > You have started this thread by asking: "why is there no
> > > pcelsRuleValidityAssociation subclass?" In a subsequent=20
> > > message, you have further detailed the issue by saying:=20
> > > "Looking at your class structure, since you subclassed other=20
> > > associations, I was surprised that you didn't subclass this=20
> > > one as well."
> > >=20
> > > Besides, PCELS defines the pcelsConditionAssociation and
> > > pcelsActionAssociation classes by subclassing PCLS classes=20
> > > for the purpose of extending their semantics. Neither you nor=20
> > > any other reviewer of the I-D has expressed any issue with=20
> > > those definitions.
> > >=20
> > > The latest proposal *does* accommodate your original request
> > > but I see you bringing up a different issue now. So, if you=20
> > > think that it is wrong to subclass the PCLS association=20
> > > class(es), please help me out by pointing to the LDAP (or=20
> > > other) specification that would be violated. I am not=20
> aware of any.
> > >=20
> > > Thank you,
> > > Mircea.
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: John Strassner [mailto:[email protected]]
> > > > Sent: Friday, June 04, 2004 5:45 PM
> > > > To: Pana, Mircea; [email protected]
> > > > Cc: [email protected]; [email protected]
> > > > Subject: RE: response to comments on PCELS-05/May 06
> > > >=20
> > > >=20
> > > > Hmm.
> > > >=20
> > > > First, I don't think subclassing helps, because the=20
> root problem=20
> > > > is that pcimRuleValidityAssociation doesn't apply to a pcelsRule
> > > > (pcelsRule is a
> > > > sibling of pcimRule. Thus, I believe that you need a new class.
> > > >=20
> > > > Second, rather than pcelsValidityAssociation, could I suggest
> > > > pcelsRuleValidityAssociation?
> > > >=20
> > > > regards,
> > > > John Strassner
> > > > TeleManagement Forum Advisory Director
> > > >=20
> > > >=20
> > > > John Strassner
> > > > Chief Strategy Officer
> > > > 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
> > > >=20
> > > >=20
> > > > > -----Original Message-----
> > > > > From: Pana, Mircea [mailto:[email protected]]
> > > > > Sent: Friday, June 04, 2004 2:48 PM
> > > > > To: [email protected]; John Strassner
> > > > > Cc: [email protected]; [email protected]
> > > > > Subject: RE: response to comments on PCELS-05/May 06
> > > > >=20
> > > > >=20
> > > > > To accomodate the change requested by Joel, I'm making the=20
> > > > > proposal below. Please review it and let me know as soon as=20
> > > > > possible whether you like or not.
> > > > >=20
> > > > > Instead of re-using pcimRuleValidityAssociation, PCELS would=20
> > > > > introduce a new class: pcelsValidityAssociation. This=20
> new class=20
> > > > > would be a subclass of pcimRuleValidityAssociation=20
> and it would=20
> > > > > not introduce any new attributes. Its instances would be=20
> > > > > subordinated to pcelsRule instances. (Much like=20
> > > > > pcelsConditionAssociation etc.) The pcelsRule class,=20
> instead of=20
> > > > > reusing the pcimRuleValidityPeriodList attribute, would use a=20
> > > > > new attribute (pcelsValidityPeriodList) as reference to its=20
> > > > > pcelsValidityAssociation instances.
> > > > >=20
> > > > > In addition, Note 1 in section 5.4 would be removed.
> > > > >=20
> > > > > Regards,
> > > > > Mircea.
> > > > >=20
> > > > >=20
> > > > > -----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
> > > > >=20
> > > > >=20
> > > > > I have looked this over again, and I think I understand the
> > > > question.
> > > > >=20
> > > > > From an object mapping and class definition perspective, it=20
> > > > > appears to me that extending the definition of=20
> > > > > pcimRuleValidityAssociation to point to a pcelsRule=20
> is probably=20
> > > > > not appropriate.
> > > > >=20
> > > > > It seems to me thinking about this that adding a different=20
> > > > > association class for the pcelsRule - time-period=20
> relationship=20
> > > > > will not adversely affect either existim PCLS implementors or=20
> > > > > future PCELS implementors.  Ruding churn in an I-D before=20
> > > > > publication is not a good reason to avoid making a=20
> technically=20
> > > > > correct change.
> > > > >=20
> > > > > However, I could easily have missed multiple aspects=20
> of this. If=20
> > > > > there are folks looking at implementing PCELS who have an=20
> > > > > opinion on the complexity of either the current=20
> "extension" or=20
> > > > > the proposed additional class, please speak up. If there are=20
> > > > > LDAP folks (other than John, who has been very=20
> helpful) who can=20
> > > > > shed light or opinions on this, I would love to hear=20
> from them.
> > > > >=20
> > > > > Given how many times we have been around the block on this, I=20
> > > > > would like to ask folks to respond within one week. =20
> If we hear=20
> > > > > nothing, I will ask Mircea and company if they can=20
> make this one=20
> > > > > last change, and hand the document to Bert for
> > > publication.
> > > > >=20
> > > > > And then we will officially close the working group!
> > > > >=20
> > > > > Yours,
> > > > > Joel M. Halpern
> > > > >=20
> > > > > At 07:55 PM 6/3/2004 -0600, John Strassner wrote:
> > > > >=20
> > > > > Subject: RE: response to comments on PCELS-05/May 06
> > > > > To: "Pana, Mircea" <[email protected]>
> > > > > Cc: <[email protected]>,
> > > > >         <[email protected]>,
> > > > >         <[email protected]>
> > > > >=20
> > > > > Hi Mircea,
> > > > > =20
> > > > > thanks for your thoughtful response.
> > > > > =20
> > > > > Regarding the first issue, I still disagree. The=20
> definition of=20
> > > > > the class doesn't allow this, even though the=20
> semantics remain=20
> > > > > unchanged. Since we are at an impasse, I'm happy to let Joel=20
> > > > > 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
> > > > >=20
> > > > > regards,
> > > > > John Strassner
> > > > > -----Original Message-----
> > > > > 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];=20
> [email protected]=20
> > > > > Subject: RE: response to comments on PCELS-05/May 06
> > > > >=20
> > > > >=20
> > > > > Look for my responses in <mircea4></mircea4>. Sorry,=20
> I'm slow to=20
> > > > > respond as well. Regards,
> > > > > Mircea.=20
> > > >=20
> > >=20
> >=20
> > _______________________________________________
> > Policy mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/policy
> >=20
>=20