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

"John Strassner" <[email protected]> Sun, 20 Jun 2004 10:08:33 -0600
Newsgroups	gmane.ietf.policy
Message-ID	<[email protected]>
Please reread my reasoning. If you have questions, reply to me offline, =
as I'm sure the rest of the readership is tired of this circular debate

regards,
John
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]=20
> Sent: Thursday, June 10, 2004 10:14 AM
> To: [email protected]
> Subject: RE: [Policy] RE: response to comments on PCELS-05/May 06
>=20
>=20
> Hi,
>=20
> We thing that creating a pcimRuleValidityAssociation subclass=20
> we can extend its capabilities in order to associate=20
> pcelsRule and pcimTPCAuxClass. If the=20
> pcelsRuleConditionAssociation and pcelsRuleActionAssociation=20
> subclasses are accepted as they are defined, then the=20
> pcimRuleValidityAssociation should be correctly=20
> defined as well because the changes that were made to the=20
> these classes are the same that now have been proposed to define=20
> pcelsRuleActionAssociation.
>=20
> Technically there is no problem creating the PCELS model in a=20
> LDAP using a pcelsRuleActionAssociation as a=20
> pcimRuleValidityAssociation
> subclass:
>=20
> 		=09
> 	DN reference	+---------------------+
>            +------------|  pcelsRule Subclass |
> 	   |		+---------------------+
> 	   |      		  |
> 	   |		+---------+ DIT Containment
> 	   v    	|
> 	+-------------------------------+
> 	|  pcelsRuleValidityAssociation |
> 	+-------------------------------+
> 	=09
> At Technical University of Catalonia, we have implemented the=20
> last draft version (PCELS-05) (+ the last proposed change) in=20
> a distributed=20
> openLDAP server and the storaged policies are retrieved, and=20
> prodessed by the PDP with no problems.
>=20
> As an alternative, the pcelsRuleValidityAssociation could be defined=20
> on the same level than pcimRuleValidityAssociation and=20
> reusing its atributes:
>=20
>    ( OID NAME 'pcelsRuleValidityAssociation'
>            DESC 'This defines the scheduled activation or deactivation
>                  of a policy rule.'
>            SUP pcimPolicy
>            STRUCTURAL
>            MAY ( pcimValidityConditionName $=20
> pcimTimePeriodConditionDN )
>     )
>=20
> Opinions?
>=20
> Best regards,
>=20
> David Mor=F3n
> Antoni Barba
> Technical University of Catalonia
>=20
>=20
> ----------------------------------------------------------------------
> Fine. Since it is technically incorrect, please be advised=20
> that I will object in any Last Call.
>=20
> regards,
> John Strassner
> TeleManagement Forum Advisory Director
>=20
>=20
> 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
>=20
>=20
> >> -----Original Message-----
> >> From: Pana, Mircea [mailto:[email protected]]
> >> 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
> >> to convince me that your suggestion would be a better option.=20
> >> We have to agree that we disagree=20
> >>=20
> >> Joel, Unless somebody produces arguments to prove the
> >> 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
> > =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,=20
> >>> > I've
> >>> > 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
> >>> > clearer.
> >>> >=20
> >>> >=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
> >>   =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];=20
> [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=20
> >>>> > > 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=20
> subclass this one=20
> >>>> > > as well."
> >>>> > >=20
> >>>> > > Besides, PCELS defines the pcelsConditionAssociation and=20
> >>>> > > pcelsActionAssociation classes by subclassing PCLS=20
> classes for=20
> >>>> > > the purpose of extending their semantics. Neither=20
> you nor any=20
> >>>> > > other reviewer of the I-D has expressed any issue with those=20
> >>>> > > definitions.
> >>>> > >=20
> >>>> > > The latest proposal *does* accommodate your original request=20
> >>>> > > 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
> >>>> > > other) specification that would be violated. I am not
> >>>     =20
> >>>
> >> aware of any.
> > =20
> >
> >>>> > >=20
> >>>> > > Thank you,
> >>>> > > Mircea.
> >>>> > >=20
> >>>> > >=20
> >>>     =20
> >>>
> >>>>> > > > -----Original Message-----
> >>>>> > > > From: John Strassner=20
> [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=20
> >>>>> > > > pcelsRule (pcelsRule is a sibling of pcimRule. Thus, I=20
> >>>>> > > > believe that you need a new class.
> >>>>> > > >=20
> >>>>> > > > Second, rather than pcelsValidityAssociation, could I=20
> >>>>> > > > suggest pcelsRuleValidityAssociation?
> >>>>> > > >=20
> >>>>> > > > regards,
> >>>>> > > > John Strassner
> >>>>> > > > TeleManagement Forum Advisory Director
> >>>>> > > >=20
> >>>>> > > >=20
> >>>>> > > > John Strassner
> >>>>> > > > Chief Strategy Officer
> >>>>> > > > Intelliden Inc.
> >>>>> > > > 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
> >>>>       =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=20
> >>>>>> > > > > the
> >>>>>> > > > > proposal below. Please review it and let me=20
> know as soon as=20
> >>>>>> > > > > possible whether you like or not.
> >>>>>> > > > >=20
> >>>>>> > > > > Instead of re-using pcimRuleValidityAssociation, PCELS=20
> >>>>>> > > > > would
> >>>>>> > > > > introduce a new class: pcelsValidityAssociation. This=20
> >>>>>         =20
> >>>>>
> >> new class
> > =20
> >
> >>>>>> > > > > would be a subclass of pcimRuleValidityAssociation
> >>>>>         =20
> >>>>>
> >> and it would
> > =20
> >
> >>>>>> > > > > not introduce any new attributes. Its=20
> instances would be
> >>>>>> > > > > subordinated to pcelsRule instances. (Much like=20
> >>>>>> > > > > pcelsConditionAssociation etc.) The pcelsRule class,=20
> >>>>>         =20
> >>>>>
> >> instead of
> > =20
> >
> >>>>>> > > > > reusing the pcimRuleValidityPeriodList=20
> attribute, would=20
> >>>>>> > > > > use a
> >>>>>> > > > > new attribute (pcelsValidityPeriodList) as=20
> 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=20
> understand=20
> >>>>>> > > > > the
> >>>>>         =20
> >>>>>
> >>>>> > > > question.
> >>>>       =20
> >>>>
> >>>>>> > > > >=20
> >>>>>> > > > > From an object mapping and class definition=20
> perspective,=20
> >>>>>> > > > > it
> >>>>>> > > > > appears to me that extending the definition of=20
> >>>>>> > > > > pcimRuleValidityAssociation to point to a pcelsRule=20
> >>>>>         =20
> >>>>>
> >> is probably
> > =20
> >
> >>>>>> > > > > not appropriate.
> >>>>>> > > > >=20
> >>>>>> > > > > It seems to me thinking about this that adding a=20
> >>>>>> > > > > different
> >>>>>> > > > > association class for the pcelsRule - time-period=20
> >>>>>         =20
> >>>>>
> >> relationship
> > =20
> >
> >>>>>> > > > > will not adversely affect either existim PCLS=20
> >>>>>> > > > > implementors or
> >>>>>> > > > > future PCELS implementors.  Ruding churn in an=20
> I-D before=20
> >>>>>> > > > > publication is not a good reason to avoid making a=20
> >>>>>         =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=20
> who have an
> >>>>>> > > > > opinion on the complexity of either the current=20
> >>>>>         =20
> >>>>>
> >> "extension" or
> > =20
> >
> >>>>>> > > > > the proposed additional class, please speak=20
> up. If there=20
> >>>>>> > > > > are
> >>>>>> > > > > LDAP folks (other than John, who has been very=20
> >>>>>         =20
> >>>>>
> >> helpful) who can
> > =20
> >
> >>>>>> > > > > shed light or opinions on this, I would love to hear
> >>>>>         =20
> >>>>>
> >> from them.
> > =20
> >
> >>>>>> > > > >=20
> >>>>>> > > > > Given how many times we have been around the block on=20
> >>>>>> > > > > this, I
> >>>>>> > > > > would like to ask folks to respond within one week. =20
> >>>>>         =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
> >>>>>         =20
> >>>>>
> >>>> > > publication.
> >>>     =20
> >>>
> >>>>>> > > > >=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=20
> happy to let=20
> >>>>>> > > > > Joel
> >>>>>> > > > > rule one way or the other.
> >>>>>> > > > > =20
> >>>>>> > > > > Regarding changing the note in section 5.4, I=20
> agree with
> >>>>>         =20
> >>>>>
> >>>> > > the change.
> >>>     =20
> >>>
> >>>>>> > > > > =20
> >>>>>> > > > > Regarding the DIT containment issue, I'm happy=20
> with your
> >>>>>         =20
> >>>>>
> >>>> > > suggestion.
> >>>     =20
> >>>
> >>>>>> > > > > =20
> >>>>>> > > > >=20
> >>>>>> > > > > regards,
> >>>>>> > > > > John Strassner
> >>>>>> > > > > -----Original Message-----
> >>>>>> > > > > From: Pana, Mircea [mailto:[email protected]]
> >>>>>> > > > > Sent: Friday, May 28, 2004 8:16 AM=20
> >>>>>> > > > > To: John Strassner=20
> >>>>>> > > > > Cc: [email protected]; [email protected];=20
> >>>>>         =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
> >>>     =20
> >>>
> >>> >=20
> >>> > _______________________________________________
> >>> > Policy mailing list
> >>> > [email protected] https://www1.ietf.org/mailman/listinfo/policy
> >>> >=20
> >>   =20
> >>
> >>=20
> > =20
> >
>=20
> _______________________________________________
> Policy mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/policy
>=20
>=20
> _______________________________________________
> Policy mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/policy
>=20