RE: RE: response to comments on PCELS-05/May 06
David Moron <[email protected]> Fri, 11 Jun 2004 16:36:26 +0200
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
Hi,
We thing that creating a pcimRuleValidityAssociation subclass we can
extend its capabilities in order to associate pcelsRule and
pcimTPCAuxClass. If the pcelsRuleConditionAssociation and
pcelsRuleActionAssociation subclasses are accepted as they are
defined, then the pcimRuleValidityAssociation should be correctly=20
defined as well because the changes that were made to the these classes
are the same that now have been proposed to define=20
pcelsRuleActionAssociation.
Technically there is no problem creating the PCELS model in a LDAP
using a pcelsRuleActionAssociation as a pcimRuleValidityAssociation
subclass:
=09
DN reference +---------------------+
+------------| pcelsRule Subclass |
| +---------------------+
| |
| +---------+ DIT Containment
v |
+-------------------------------+
| pcelsRuleValidityAssociation |
+-------------------------------+
=09
At Technical University of Catalonia, we have implemented the last
draft version (PCELS-05) (+ the last proposed change) in a distributed=20
openLDAP server and the storaged policies are retrieved, and
prodessed by the PDP with no problems.
As an alternative, the pcelsRuleValidityAssociation could be defined=20
on the same level than pcimRuleValidityAssociation and reusing its atribu=
tes:
( OID NAME 'pcelsRuleValidityAssociation'
DESC 'This defines the scheduled activation or deactivation
of a policy rule.'
SUP pcimPolicy
STRUCTURAL
MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN )
)
Opinions?
David Mor=F3n
Antoni Barba
Technical University of Catalonia
>----------------------------------------------------------------------
>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
>>=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
> =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
>> =20
>>
>> what I may=20
> =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
>> =20
>>
>> because it=20
> =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
>> =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
>>> =20
>>>
>> aware of any.
> =20
>
>>>> > >=20
>>>> > > Thank you,
>>>> > > Mircea.
>>>> > >=20
>>>> > >=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
>>>> =20
>>>>
>> root problem=20
> =20
>
>>>>> > > > is that pcimRuleValidityAssociation doesn't apply to a pcelsR=
ule
>>>>> > > > (pcelsRule is a
>>>>> > > > sibling of pcimRule. Thus, I believe that you need a new clas=
s.
>>>>> > > >=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
>>>> =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 a=
s=20
>>>>>> > > > > possible whether you like or not.
>>>>>> > > > >=20
>>>>>> > > > > Instead of re-using pcimRuleValidityAssociation, PCELS wou=
ld=20
>>>>>> > > > > introduce a new class: pcelsValidityAssociation. This=20
>>>>> =20
>>>>>
>> new class=20
> =20
>
>>>>>> > > > > would be a subclass of pcimRuleValidityAssociation=20
>>>>> =20
>>>>>
>> and it would=20
> =20
>
>>>>>> > > > > not introduce any new attributes. Its instances would be=20
>>>>>> > > > > subordinated to pcelsRule instances. (Much like=20
>>>>>> > > > > pcelsConditionAssociation etc.) The pcelsRule class,=20
>>>>> =20
>>>>>
>> instead of=20
> =20
>
>>>>>> > > > > reusing the pcimRuleValidityPeriodList attribute, would us=
e a=20
>>>>>> > > > > new attribute (pcelsValidityPeriodList) as reference to it=
s=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 th=
e
>>>>> =20
>>>>>
>>>>> > > > question.
>>>> =20
>>>>
>>>>>> > > > >=20
>>>>>> > > > > From an object mapping and class definition perspective, i=
t=20
>>>>>> > > > > appears to me that extending the definition of=20
>>>>>> > > > > pcimRuleValidityAssociation to point to a pcelsRule=20
>>>>> =20
>>>>>
>> is probably=20
> =20
>
>>>>>> > > > > not appropriate.
>>>>>> > > > >=20
>>>>>> > > > > It seems to me thinking about this that adding a different=
=20
>>>>>> > > > > association class for the pcelsRule - time-period=20
>>>>> =20
>>>>>
>> relationship=20
> =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
>>>>> =20
>>>>>
>> technically=20
> =20
>
>>>>>> > > > > correct change.
>>>>>> > > > >=20
>>>>>> > > > > However, I could easily have missed multiple aspects=20
>>>>> =20
>>>>>
>> of this. If=20
> =20
>
>>>>>> > > > > there are folks looking at implementing PCELS who have an=20
>>>>>> > > > > opinion on the complexity of either the current=20
>>>>> =20
>>>>>
>> "extension" or=20
> =20
>
>>>>>> > > > > the proposed additional class, please speak up. If there a=
re=20
>>>>>> > > > > LDAP folks (other than John, who has been very=20
>>>>> =20
>>>>>
>> helpful) who can=20
> =20
>
>>>>>> > > > > shed light or opinions on this, I would love to hear=20
>>>>> =20
>>>>>
>> from them.
> =20
>
>>>>>> > > > >=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
>>>>> =20
>>>>>
>> If we hear=20
> =20
>
>>>>>> > > > > nothing, I will ask Mircea and company if they can=20
>>>>> =20
>>>>>
>> make this one=20
> =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
>>>>> =20
>>>>>
>> definition of=20
> =20
>
>>>>>> > > > > the class doesn't allow this, even though the=20
>>>>> =20
>>>>>
>> semantics remain=20
> =20
>
>>>>>> > > > > unchanged. Since we are at an impasse, I'm happy to let Jo=
el=20
>>>>>> > > > > rule one way or the other.
>>>>>> > > > > =20
>>>>>> > > > > Regarding changing the note in section 5.4, I agree with
>>>>> =20
>>>>>
>>>> > > the change.
>>> =20
>>>
>>>>>> > > > > =20
>>>>>> > > > > Regarding the DIT containment issue, I'm happy with your
>>>>> =20
>>>>>
>>>> > > suggestion.
>>> =20
>>>
>>>>>> > > > > =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
>>>>> =20
>>>>>
>> [email protected]=20
> =20
>
>>>>>> > > > > Subject: RE: response to comments on PCELS-05/May 06
>>>>>> > > > >=20
>>>>>> > > > >=20
>>>>>> > > > > Look for my responses in <mircea4></mircea4>. Sorry,=20
>>>>> =20
>>>>>
>> I'm slow to=20
> =20
>
>>>>>> > > > > respond as well. Regards,
>>>>>> > > > > Mircea.=20
>>>>> =20
>>>>>
>>>>> > > >=20
>>>> =20
>>>>
>>>> > >=20
>>> =20
>>>
>>> >=20
>>> > _______________________________________________
>>> > Policy mailing list
>>> > [email protected]
>>> > https://www1.ietf.org/mailman/listinfo/policy
>>> >=20
>> =20
>>
>>=20
> =20
>
_______________________________________________
Policy mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/policy
--=20
David Mor=F3n Ruano
Coordinador de Proyectos
=20
Grupo OpenWired, S.L.
Cardenal Reig, 26, entr. 3? - 08028 - Barcelona (Spain)
Tel (+34) 93/440 99 90 - Fax (+34) 93/448 41 44
www.openwired.net, www.tecnologialinux.com