headers
Pana, Mircea | 5 Sep 2003 00:09

PCLS classes deprecated in PCELS

PCELS deprecates some of the PCLS classes and attributes for various reasons. In some cases, deprecation could have been avoided but in other cases this was dictated by PCIMe. (details discussed below) I agree that deprecation might create backward compatibility problems where PCELS and PCLS implementations attempt to cooperate. BTW, does anybody out there have such requirements? Given that PCIMe deprecates a significant number of concepts from PCIM, is such cooperation even possible?

The classes deprecated by PCELS are discussed below:

1. The class pcimGroupContainmentAuxClass defined by PCLS provides a single, multi-valued attribute that references a set of pcimGroups. This unordered aggregation mechanism can not be reused in implementations of PCIMe because the model (PCIMe) requires PolicySetComponent associations to be prioritized:

"  5.5. Priorities and Decision Strategies
   [...] Unlike the earlier definition,
   PolicySetComponent.Priority MUST have a unique value when compared
   with others defined for the same aggregating PolicySet.  Thus, the
   evaluation of rules within a set is deterministically specified. "
If PCELS allowed pcimGroupContainmentAuxClass, then it would be conflicting with PCIMe.

2. The class pcimRuleContainmentAuxClass defined in PCLS is deprecated by PCELS for the same reasons.

3. The pcimRule* classes defined by PCLS are deprecated and redefined as pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority property is deprecated. Therefore PCELS redefines the PolicyRule class mainly for removing the Priority attribute. An other option would have been to leave pcimRule* as they are and then PCELS would have had to specify that the pcimRulePriority attribute MUST NOT be used - a less formal solution that does not prevent accidental use of the deprecated attribute.

An other reason for replacing the pcimRule* classes is the renaming of the attributes that serve in the Rule-Condition and Rule-Action associations. pcimRuleConditionList is replaced by pcimConditionList and pcimRuleActionList is replaced by pcimActionList. Thus, the new attributes along with the new association classes (discussed below) offer a generic mechanism for aggregating Conditions or Actions. The use the same Condition/Action aggregation mechanism for both Policy Rules and Compound Conditions/Action is an optimization in line with the Policy*Structure concepts defined by PCIMe.

The deprecation of the pcimRule* classes is certainly not the only option but based on our experience implementing PCIMe this one seemed an acceptable compromise. However, any opinions or suggestions from the WG based on their experience would be greatly appreciated.

4. The class pcimRuleConditionAssociation defined by PCLS has probably less reasons to be deprecated. It was done simply to keep the Condition aggregation (into rules or compound conditions) limited to a single association class. Now, looking from this different prospective, I think that it is a good idea to retain it.

So, I suggest the modification of the pcimRuleConditionAssociation to become a subclass of the pcimConditionAssociation already defined in PCELS. The attributes of the pcimRuleConditionAssociation, all inherited from its superclass, would end up being the same ones as previously defined by PCLS. Thus, for aggregating Conditions into a Policy Rule, one would have the choice of using pcimConditionAssociation or pcimRuleConditionAssociation while Condition aggregation into a Compound Condition would be realized only through the pcimConditionAssociation class.

Opinions?

5. pcimRuleActionAssociation - same suggestion as for the pcimRuleConditionAssociation class

6. The pcimRepository class defined by PCLS is deprecated by PCELS for reasons described in PCIMe:
"   Because of the potential for confusion with the Policy Framework
   component Policy Repository (from the four-box picture: Policy
   Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is
   a bad name for the PCIM class representing a container of reusable
   policy elements.  Thus the class PolicyRepository is being replaced
   with the class ReusablePolicyContainer."


Best Regards,
Mircea.



> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
> Sent: Friday, August 29, 2003 11:15 AM
> To: policy <at> ietf.org
> Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
>
>
> What an underwhelming interest in this document.
>
> When I start reading it, I see in the abstract:
>    This document defines a number of changes and extensions to the
>    Policy Core LDAP Schema [PCLS] based on the specifications of the
>    Policy Core Information Model Extensions [PCIM_EXT]. The changes
>    include additional object classes previously not covered,
> deprecation
>    of some object classes and changes to the object class hierarchy
>    defined in [PCLS].
>
> And so I immediately wonder... is it really OK that this document
> deprecates some object classes ??
>
> Possibly so... but I'd like to hear some of the PCIM, PCIM-EXT and
> PCLS authors/ediotrs to explicitly say so. PLEASE!
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
> > Sent: vrijdag 15 augustus 2003 11:45
> > To: policy <at> ietf.org
> > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> >
> >
> > Joel asked from the WG:
> > > -----Original Message-----
> > > From: Joel M. Halpern [mailto:joel <at> stevecrocker.com]
> > > Sent: woensdag 6 augustus 2003 17:33
> > > To: policy <at> ietf.org
> > > Subject: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> > >
> > >
> > > The revised Internet draft is now available in the I-D repository:
> > > http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ex
> > > t-schema-03.txt
> > >
> > > I believe it is appropriate for this document to go forward as an
> > > individual contribution that has been reviewed by a (our)
> > working group.
> > > As such, I will give folks one more chance to comment
> > before indicating
> > > that the author's can (and should) contact the AD for this.
> > > Please respond by August 20 (preferably sooner) with any
> comments,
> > > concerns, issues, etc.  It would even be helpful if folks
> > would merely
> > > indicate that they had read and liked the document.
> > >
> >
> > So did anyone actually READ (or even BROWSE) the document???
> >
> > PLEASE be active and participate!
> >
> > Bert
> > > Thank you,
> > > Joel M. Halpern
> >
> > _______________________________________________
> > 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
>

Permalink | Reply | 1 comment |
headers
Wijnen, Bert (Bert | 5 Sep 2003 00:58
Picon
Favicon

RE: PCLS classes deprecated in PCELS

Mircea, thanks for your extensive response.
 
What bothers me a bit is that it seems as if we are having this discussion between
a very very small set of people (and I do not consider myself an expert in this space).
So I would like to see comments from the WG, from people who have implemented PCLS
and how they react to this deprecation. From the original PCLS authors, what their
viewpoints are on this...
Thanks,
Bert
-----Original Message-----
From: Pana, Mircea [mailto:mpana <at> metasolv.com]
Sent: vrijdag 5 september 2003 0:10
To: 'bwijnen <at> lucent.com'; 'policy <at> ietf.org'
Subject: PCLS classes deprecated in PCELS

PCELS deprecates some of the PCLS classes and attributes for various reasons. In some cases, deprecation could have been avoided but in other cases this was dictated by PCIMe. (details discussed below) I agree that deprecation might create backward compatibility problems where PCELS and PCLS implementations attempt to cooperate. BTW, does anybody out there have such requirements? Given that PCIMe deprecates a significant number of concepts from PCIM, is such cooperation even possible?

The classes deprecated by PCELS are discussed below:

1. The class pcimGroupContainmentAuxClass defined by PCLS provides a single, multi-valued attribute that references a set of pcimGroups. This unordered aggregation mechanism can not be reused in implementations of PCIMe because the model (PCIMe) requires PolicySetComponent associations to be prioritized:

"  5.5. Priorities and Decision Strategies
   [...] Unlike the earlier definition,
   PolicySetComponent.Priority MUST have a unique value when compared
   with others defined for the same aggregating PolicySet.  Thus, the
   evaluation of rules within a set is deterministically specified. "
If PCELS allowed pcimGroupContainmentAuxClass, then it would be conflicting with PCIMe.

2. The class pcimRuleContainmentAuxClass defined in PCLS is deprecated by PCELS for the same reasons.

3. The pcimRule* classes defined by PCLS are deprecated and redefined as pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority property is deprecated. Therefore PCELS redefines the PolicyRule class mainly for removing the Priority attribute. An other option would have been to leave pcimRule* as they are and then PCELS would have had to specify that the pcimRulePriority attribute MUST NOT be used - a less formal solution that does not prevent accidental use of the deprecated attribute.

An other reason for replacing the pcimRule* classes is the renaming of the attributes that serve in the Rule-Condition and Rule-Action associations. pcimRuleConditionList is replaced by pcimConditionList and pcimRuleActionList is replaced by pcimActionList. Thus, the new attributes along with the new association classes (discussed below) offer a generic mechanism for aggregating Conditions or Actions. The use the same Condition/Action aggregation mechanism for both Policy Rules and Compound Conditions/Action is an optimization in line with the Policy*Structure concepts defined by PCIMe.

The deprecation of the pcimRule* classes is certainly not the only option but based on our experience implementing PCIMe this one seemed an acceptable compromise. However, any opinions or suggestions from the WG based on their experience would be greatly appreciated.

4. The class pcimRuleConditionAssociation defined by PCLS has probably less reasons to be deprecated. It was done simply to keep the Condition aggregation (into rules or compound conditions) limited to a single association class. Now, looking from this different prospective, I think that it is a good idea to retain it.

So, I suggest the modification of the pcimRuleConditionAssociation to become a subclass of the pcimConditionAssociation already defined in PCELS. The attributes of the pcimRuleConditionAssociation, all inherited from its superclass, would end up being the same ones as previously defined by PCLS. Thus, for aggregating Conditions into a Policy Rule, one would have the choice of using pcimConditionAssociation or pcimRuleConditionAssociation while Condition aggregation into a Compound Condition would be realized only through the pcimConditionAssociation class.

Opinions?

5. pcimRuleActionAssociation - same suggestion as for the pcimRuleConditionAssociation class

6. The pcimRepository class defined by PCLS is deprecated by PCELS for reasons described in PCIMe:
"   Because of the potential for confusion with the Policy Framework
   component Policy Repository (from the four-box picture: Policy
   Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is
   a bad name for the PCIM class representing a container of reusable
   policy elements.  Thus the class PolicyRepository is being replaced
   with the class ReusablePolicyContainer."


Best Regards,
Mircea.



> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
> Sent: Friday, August 29, 2003 11:15 AM
> To: policy <at> ietf.org
> Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
>
>
> What an underwhelming interest in this document.
>
> When I start reading it, I see in the abstract:
>    This document defines a number of changes and extensions to the
>    Policy Core LDAP Schema [PCLS] based on the specifications of the
>    Policy Core Information Model Extensions [PCIM_EXT]. The changes
>    include additional object classes previously not covered,
> deprecation
>    of some object classes and changes to the object class hierarchy
>    defined in [PCLS].
>
> And so I immediately wonder... is it really OK that this document
> deprecates some object classes ??
>
> Possibly so... but I'd like to hear some of the PCIM, PCIM-EXT and
> PCLS authors/ediotrs to explicitly say so. PLEASE!
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
> > Sent: vrijdag 15 augustus 2003 11:45
> > To: policy <at> ietf.org
> > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> >
> >
> > Joel asked from the WG:
> > > -----Original Message-----
> > > From: Joel M. Halpern [mailto:joel <at> stevecrocker.com]
> > > Sent: woensdag 6 augustus 2003 17:33
> > > To: policy <at> ietf.org
> > > Subject: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> > >
> > >
> > > The revised Internet draft is now available in the I-D repository:
> > > http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ex
> > > t-schema-03.txt
> > >
> > > I believe it is appropriate for this document to go forward as an
> > > individual contribution that has been reviewed by a (our)
> > working group.
> > > As such, I will give folks one more chance to comment
> > before indicating
> > > that the author's can (and should) contact the AD for this.
> > > Please respond by August 20 (preferably sooner) with any
> comments,
> > > concerns, issues, etc.  It would even be helpful if folks
> > would merely
> > > indicate that they had read and liked the document.
> > >
> >
> > So did anyone actually READ (or even BROWSE) the document???
> >
> > PLEASE be active and participate!
> >
> > Bert
> > > Thank you,
> > > Joel M. Halpern
> >
> > _______________________________________________
> > 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
>

Permalink | Reply | 0 comments |
headers
Pana, Mircea | 5 Sep 2003 15:19

RE: PCLS classes deprecated in PCELS

Bert,
 
Since we have heard opinions on this issue from two people so far (Larry and Ryan, I'd like to thank you for taking the time to do that) I felt that it would be helpful to give a detailed presentation of the reasons. I would love to hear more opinions from the authors of the other documents produced by this group. Are they still around?
Does anybody have running code based on PCIM, PCLS, PCIMe? Does anybody else have an opinion?
 
Thanks,
Mircea.
 
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
Sent: Thursday, September 04, 2003 6:59 PM
To: 'Pana, Mircea'; Wijnen, Bert (Bert); 'policy <at> ietf.org'
Subject: RE: PCLS classes deprecated in PCELS

Mircea, thanks for your extensive response.
 
What bothers me a bit is that it seems as if we are having this discussion between
a very very small set of people (and I do not consider myself an expert in this space).
So I would like to see comments from the WG, from people who have implemented PCLS
and how they react to this deprecation. From the original PCLS authors, what their
viewpoints are on this...
Thanks,
Bert
-----Original Message-----
From: Pana, Mircea [mailto:mpana <at> metasolv.com]
Sent: vrijdag 5 september 2003 0:10
To: 'bwijnen <at> lucent.com'; 'policy <at> ietf.org'
Subject: PCLS classes deprecated in PCELS

PCELS deprecates some of the PCLS classes and attributes for various reasons. In some cases, deprecation could have been avoided but in other cases this was dictated by PCIMe. (details discussed below) I agree that deprecation might create backward compatibility problems where PCELS and PCLS implementations attempt to cooperate. BTW, does anybody out there have such requirements? Given that PCIMe deprecates a significant number of concepts from PCIM, is such cooperation even possible?

The classes deprecated by PCELS are discussed below:

1. The class pcimGroupContainmentAuxClass defined by PCLS provides a single, multi-valued attribute that references a set of pcimGroups. This unordered aggregation mechanism can not be reused in implementations of PCIMe because the model (PCIMe) requires PolicySetComponent associations to be prioritized:

"  5.5. Priorities and Decision Strategies
   [...] Unlike the earlier definition,
   PolicySetComponent.Priority MUST have a unique value when compared
   with others defined for the same aggregating PolicySet.  Thus, the
   evaluation of rules within a set is deterministically specified. "
If PCELS allowed pcimGroupContainmentAuxClass, then it would be conflicting with PCIMe.

2. The class pcimRuleContainmentAuxClass defined in PCLS is deprecated by PCELS for the same reasons.

3. The pcimRule* classes defined by PCLS are deprecated and redefined as pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority property is deprecated. Therefore PCELS redefines the PolicyRule class mainly for removing the Priority attribute. An other option would have been to leave pcimRule* as they are and then PCELS would have had to specify that the pcimRulePriority attribute MUST NOT be used - a less formal solution that does not prevent accidental use of the deprecated attribute.

An other reason for replacing the pcimRule* classes is the renaming of the attributes that serve in the Rule-Condition and Rule-Action associations. pcimRuleConditionList is replaced by pcimConditionList and pcimRuleActionList is replaced by pcimActionList. Thus, the new attributes along with the new association classes (discussed below) offer a generic mechanism for aggregating Conditions or Actions. The use the same Condition/Action aggregation mechanism for both Policy Rules and Compound Conditions/Action is an optimization in line with the Policy*Structure concepts defined by PCIMe.

The deprecation of the pcimRule* classes is certainly not the only option but based on our experience implementing PCIMe this one seemed an acceptable compromise. However, any opinions or suggestions from the WG based on their experience would be greatly appreciated.

4. The class pcimRuleConditionAssociation defined by PCLS has probably less reasons to be deprecated. It was done simply to keep the Condition aggregation (into rules or compound conditions) limited to a single association class. Now, looking from this different prospective, I think that it is a good idea to retain it.

So, I suggest the modification of the pcimRuleConditionAssociation to become a subclass of the pcimConditionAssociation already defined in PCELS. The attributes of the pcimRuleConditionAssociation, all inherited from its superclass, would end up being the same ones as previously defined by PCLS. Thus, for aggregating Conditions into a Policy Rule, one would have the choice of using pcimConditionAssociation or pcimRuleConditionAssociation while Condition aggregation into a Compound Condition would be realized only through the pcimConditionAssociation class.

Opinions?

5. pcimRuleActionAssociation - same suggestion as for the pcimRuleConditionAssociation class

6. The pcimRepository class defined by PCLS is deprecated by PCELS for reasons described in PCIMe:
"   Because of the potential for confusion with the Policy Framework
   component Policy Repository (from the four-box picture: Policy
   Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is
   a bad name for the PCIM class representing a container of reusable
   policy elements.  Thus the class PolicyRepository is being replaced
   with the class ReusablePolicyContainer."


Best Regards,
Mircea.



> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
> Sent: Friday, August 29, 2003 11:15 AM
> To: policy <at> ietf.org
> Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
>
>
> What an underwhelming interest in this document.
>
> When I start reading it, I see in the abstract:
>    This document defines a number of changes and extensions to the
>    Policy Core LDAP Schema [PCLS] based on the specifications of the
>    Policy Core Information Model Extensions [PCIM_EXT]. The changes
>    include additional object classes previously not covered,
> deprecation
>    of some object classes and changes to the object class hierarchy
>    defined in [PCLS].
>
> And so I immediately wonder... is it really OK that this document
> deprecates some object classes ??
>
> Possibly so... but I'd like to hear some of the PCIM, PCIM-EXT and
> PCLS authors/ediotrs to explicitly say so. PLEASE!
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
> > Sent: vrijdag 15 augustus 2003 11:45
> > To: policy <at> ietf.org
> > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> >
> >
> > Joel asked from the WG:
> > > -----Original Message-----
> > > From: Joel M. Halpern [mailto:joel <at> stevecrocker.com]
> > > Sent: woensdag 6 augustus 2003 17:33
> > > To: policy <at> ietf.org
> > > Subject: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> > >
> > >
> > > The revised Internet draft is now available in the I-D repository:
> > > http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ex
> > > t-schema-03.txt
> > >
> > > I believe it is appropriate for this document to go forward as an
> > > individual contribution that has been reviewed by a (our)
> > working group.
> > > As such, I will give folks one more chance to comment
> > before indicating
> > > that the author's can (and should) contact the AD for this.
> > > Please respond by August 20 (preferably sooner) with any
> comments,
> > > concerns, issues, etc.  It would even be helpful if folks
> > would merely
> > > indicate that they had read and liked the document.
> > >
> >
> > So did anyone actually READ (or even BROWSE) the document???
> >
> > PLEASE be active and participate!
> >
> > Bert
> > > Thank you,
> > > Joel M. Halpern
> >
> > _______________________________________________
> > 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
>

Permalink | Reply | 7 comments |
headers
Ryan Moats | 9 Sep 2003 16:26

Re: PCLS classes deprecated in PCELS

On Thu, Sep 04, 2003 at 05:09:46PM -0500, Pana, Mircea wrote:
| PCELS deprecates some of the PCLS classes and attributes for various
| reasons. In some cases, deprecation could have been avoided but in other
| cases this was dictated by PCIMe. (details discussed below) I agree that
| deprecation might create backward compatibility problems where PCELS and
| PCLS implementations attempt to cooperate. BTW, does anybody out there have
| such requirements? Given that PCIMe deprecates a significant number of
| concepts from PCIM, is such cooperation even possible?
| 
| The classes deprecated by PCELS are discussed below:
| 
| 1. The class pcimGroupContainmentAuxClass defined by PCLS provides a single,
| multi-valued attribute that references a set of pcimGroups. This unordered
| aggregation mechanism can not be reused in implementations of PCIMe because
| the model (PCIMe) requires PolicySetComponent associations to be
| prioritized:
| "  5.5. Priorities and Decision Strategies
|    [...] Unlike the earlier definition,
|    PolicySetComponent.Priority MUST have a unique value when compared
|    with others defined for the same aggregating PolicySet.  Thus, the
|    evaluation of rules within a set is deterministically specified. "
| If PCELS allowed pcimGroupContainmentAuxClass, then it would be conflicting
| with PCIMe.
|
| 2. The class pcimRuleContainmentAuxClass defined in PCLS is deprecated by
| PCELS for the same reasons.

Those are not reason to deprecate classes in the more general model.  That's
a reason to say "in this space, this other class should be used".

| 3. The pcimRule* classes defined by PCLS are deprecated and redefined as
| pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority
| property is deprecated. Therefore PCELS redefines the PolicyRule class
| mainly for removing the Priority attribute. An other option would have been
| to leave pcimRule* as they are and then PCELS would have had to specify that
| the pcimRulePriority attribute MUST NOT be used - a less formal solution
| that does not prevent accidental use of the deprecated attribute.
|
| An other reason for replacing the pcimRule* classes is the renaming of the
| attributes that serve in the Rule-Condition and Rule-Action associations.
| pcimRuleConditionList is replaced by pcimConditionList and
| pcimRuleActionList is replaced by pcimActionList. Thus, the new attributes
| along with the new association classes (discussed below) offer a generic
| mechanism for aggregating Conditions or Actions. The use the same
| Condition/Action aggregation mechanism for both Policy Rules and Compound
| Conditions/Action is an optimization in line with the Policy*Structure
| concepts defined by PCIMe.

Since you are rethinking subclass/deprication below, I'd argue rethink it
here.

| The deprecation of the pcimRule* classes is certainly not the only option
| but based on our experience implementing PCIMe this one seemed an acceptable
| compromise. However, any opinions or suggestions from the WG based on their
| experience would be greatly appreciated.
|
| 4. The class pcimRuleConditionAssociation defined by PCLS has probably less
| reasons to be deprecated. It was done simply to keep the Condition
| aggregation (into rules or compound conditions) limited to a single
| association class. Now, looking from this different prospective, I think
| that it is a good idea to retain it.
| 
| So, I suggest the modification of the pcimRuleConditionAssociation to become
| a subclass of the pcimConditionAssociation already defined in PCELS. The
| attributes of the pcimRuleConditionAssociation, all inherited from its
| superclass, would end up being the same ones as previously defined by PCLS.
| Thus, for aggregating Conditions into a Policy Rule, one would have the
| choice of using pcimConditionAssociation or pcimRuleConditionAssociation
| while Condition aggregation into a Compound Condition would be realized only
| through the pcimConditionAssociation class.
| 
| 5. pcimRuleActionAssociation - same suggestion as for the
| pcimRuleConditionAssociation class

This is a much better solution...

| 6. The pcimRepository class defined by PCLS is deprecated by PCELS for
| reasons described in PCIMe:
| "   Because of the potential for confusion with the Policy Framework
|    component Policy Repository (from the four-box picture: Policy
|    Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is
|    a bad name for the PCIM class representing a container of reusable
|    policy elements.  Thus the class PolicyRepository is being replaced
|    with the class ReusablePolicyContainer."

This could also be handled with a subclass.

Ryan
Permalink | Reply | 0 comments |
headers
Ryan Moats | 9 Sep 2003 16:37

Re: RE: PCLS classes deprecated in PCELS

On Fri, Sep 05, 2003 at 08:19:55AM -0500, Pana, Mircea wrote:
| Bert,
|  
| Since we have heard opinions on this issue from two people so far (Larry and
| Ryan, I'd like to thank you for taking the time to do that) I felt that it
| would be helpful to give a detailed presentation of the reasons. I would
| love to hear more opinions from the authors of the other documents produced
| by this group. Are they still around?
| Does anybody have running code based on PCIM, PCLS, PCIMe? Does anybody else
| have an opinion?

I have running code that uses PolicyRule and PolicyRule.Priority quite
happily through subclasses, so I really don't see the need to deprecate it.

Ryan
Permalink | Reply | 0 comments |
headers
David McTavish | 9 Sep 2003 16:44
Favicon

RE: RE: PCLS classes deprecated in PCELS

I would like to second this approach.  We have implemented a hardware-based
solution using the existing PCIM schema, and with our goal to be following
this standard as much as possible.  Our experience with deprecating schema,
especially within the scope of LDAP, is that it is not a "good thing". While
we would like to strive to adopt PCIMe and PCLS for some of the extensions
that it brings, we would be hard-pressed to adopt such a sweeping change as
currently submitted.  I believe, that with Ryan's suggestions, the ability
to extend an existing implementation from PCIM would be more approachable
than in its current form.

rgds,
d.

-----Original Message-----
From: Ryan Moats [mailto:rmoats <at> lemurnetworks.net]
Sent: Tuesday, September 09, 2003 10:38 AM
To: Pana, Mircea
Cc: 'policy <at> ietf.org'
Subject: Re: [Policy] RE: PCLS classes deprecated in PCELS

On Fri, Sep 05, 2003 at 08:19:55AM -0500, Pana, Mircea wrote:
| Bert,
|  
| Since we have heard opinions on this issue from two people so far (Larry
and
| Ryan, I'd like to thank you for taking the time to do that) I felt that it
| would be helpful to give a detailed presentation of the reasons. I would
| love to hear more opinions from the authors of the other documents
produced
| by this group. Are they still around?
| Does anybody have running code based on PCIM, PCLS, PCIMe? Does anybody
else
| have an opinion?

I have running code that uses PolicyRule and PolicyRule.Priority quite
happily through subclasses, so I really don't see the need to deprecate it.

Ryan

_______________________________________________
Policy mailing list
Policy <at> ietf.org
https://www1.ietf.org/mailman/listinfo/policy
Permalink | Reply | 0 comments |
headers
Pana, Mircea | 12 Sep 2003 00:21

RE: PCLS classes deprecated in PCELS

IMO the usage of schema items corresponding to deprecated concepts would be in conflict with the model (in this case PCIMe). However, a "peaceful co-existence" would be a very good reason for compromise. The following proposal gets PCELS out of the "policing business" and where compliance with PCIMe requires PCLS classes or attributes not to be used, this is noted with the specific indication "for compliance with PCIMe implementations shall/shall not use ..." (or rather SHALL / SHALL NOT). I hope you will find the following acceptable:

1. Replace the pcimGroupContainmentAuxClass class deprecation with a paragraph to indicate that "for compliance with PCIMe, implementations shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a subordinated pcimPolicySetAssociation entry instead of an attached pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy Group, Rule or System".

2. Replace the pcimRuleContainmentAuxClass class deprecation with a paragraph to indicate that "for compliance with PCIMe,  implementations shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a subordinated pcimPolicySetAssociation entry instead of an attached pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy Group, Rule or System".

3. The pcimRule* classes would not be deprecated. Instead, the abstract class pcimRule would be modified to become a subclass of the abstract class pcimPolicyRule defined in PCELS. A note would be added to indicate that "for compliance with PCIMe, implementations shall not use the pcimRule.pcimRulePriority attribute". See also Note_1 below.

4. The class pcimRuleConditionAssociation would be modified to become subclass of the pcimConditionAssociation class.

5. The class pcimRuleActionAssociation would be modified to become subclass of the pcimActionAssociation class.

6. The pcimRepository* classes would not be deprecated. Instead the abstract class pcimRepository would be modified to become subclass of the abstract class pcimReusableContainer defined in PCELS. PCELS would indicate that "for compliance with PCIMe, the pcimReusableContainer* classes shall be used instead of the pcimRepository* classes".


Note_1:
Without other changes, the pcimRule would end up having redundant functionality:
- pcimRuleConditionList and pcimConditionList for aggregating conditions
- pcimRuleActionList and pcimActionList for aggregating actions
etc.

A. One option would be to do nothing about it but this may lead to ambiguous situations :-(

B. A second option would be to use the pcimRuleConditionAssociation and the pcimRuleActionAssociation attributes and the association classes defined by PCLS in the definition of the pcimPolicyRule. In this case the pcimPolicyRule* and pcimCompound*AuxClass would not use the same attributes and association classes to aggregate Conditions and Actions :-(

C. A third option would be to change the pcimPolicyRule definition to:
   ( [...] SUP pcimPolicySet
     ABSTRACT
     MAY ( pcimRuleName
         $ pcimRuleEnabled
         $ pcimRuleValidityPeriodList
         $ pcimRuleUsage
         $ pcimRuleMandatory )
   )
(Condition and Action aggregation attributes removed from the Rule class)
In this case, PCELS would recommend the use of attached pcimCompound*AuxClass instances as means to aggregate multiple Actions/Conditions to a Rule.

D. A mix of the previous two: Option B with a note that implementations MAY choose to support only C.

Comments and suggestions would be greatly appreciated? Also, I would greatly appreciate the PCIMe author's opinion wrt. the [non]deprecation.

Thanks,
Mircea.



 
> -----Original Message-----
> From: Ryan Moats [mailto:rmoats <at> lemurnetworks.net]
> Sent: Tuesday, September 09, 2003 10:26 AM
> To: Pana, Mircea
> Cc: 'bwijnen <at> lucent.com'; 'policy <at> ietf.org'
> Subject: Re: [Policy] PCLS classes deprecated in PCELS
>
>
> On Thu, Sep 04, 2003 at 05:09:46PM -0500, Pana, Mircea wrote:
> | PCELS deprecates some of the PCLS classes and attributes for various
> | reasons. In some cases, deprecation could have been avoided
> but in other
> | cases this was dictated by PCIMe. (details discussed below)
> I agree that
> | deprecation might create backward compatibility problems
> where PCELS and
> | PCLS implementations attempt to cooperate. BTW, does
> anybody out there have
> | such requirements? Given that PCIMe deprecates a
> significant number of
> | concepts from PCIM, is such cooperation even possible?
> |
> | The classes deprecated by PCELS are discussed below:
> |
> | 1. The class pcimGroupContainmentAuxClass defined by PCLS
> provides a single,
> | multi-valued attribute that references a set of pcimGroups.
> This unordered
> | aggregation mechanism can not be reused in implementations
> of PCIMe because
> | the model (PCIMe) requires PolicySetComponent associations to be
> | prioritized:
> | "  5.5. Priorities and Decision Strategies
> |    [...] Unlike the earlier definition,
> |    PolicySetComponent.Priority MUST have a unique value
> when compared
> |    with others defined for the same aggregating PolicySet. 
> Thus, the
> |    evaluation of rules within a set is deterministically
> specified. "
> | If PCELS allowed pcimGroupContainmentAuxClass, then it
> would be conflicting
> | with PCIMe.
> |
> | 2. The class pcimRuleContainmentAuxClass defined in PCLS is
> deprecated by
> | PCELS for the same reasons.
>
> Those are not reason to deprecate classes in the more general
> model.  That's
> a reason to say "in this space, this other class should be used".
>
> | 3. The pcimRule* classes defined by PCLS are deprecated and
> redefined as
> | pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority
> | property is deprecated. Therefore PCELS redefines the
> PolicyRule class
> | mainly for removing the Priority attribute. An other option
> would have been
> | to leave pcimRule* as they are and then PCELS would have
> had to specify that
> | the pcimRulePriority attribute MUST NOT be used - a less
> formal solution
> | that does not prevent accidental use of the deprecated attribute.
> |
> | An other reason for replacing the pcimRule* classes is the
> renaming of the
> | attributes that serve in the Rule-Condition and Rule-Action
> associations.
> | pcimRuleConditionList is replaced by pcimConditionList and
> | pcimRuleActionList is replaced by pcimActionList. Thus, the
> new attributes
> | along with the new association classes (discussed below)
> offer a generic
> | mechanism for aggregating Conditions or Actions. The use the same
> | Condition/Action aggregation mechanism for both Policy
> Rules and Compound
> | Conditions/Action is an optimization in line with the
> Policy*Structure
> | concepts defined by PCIMe.
>
> Since you are rethinking subclass/deprication below, I'd
> argue rethink it
> here.
>
> | The deprecation of the pcimRule* classes is certainly not
> the only option
> | but based on our experience implementing PCIMe this one
> seemed an acceptable
> | compromise. However, any opinions or suggestions from the
> WG based on their
> | experience would be greatly appreciated.
> |
> | 4. The class pcimRuleConditionAssociation defined by PCLS
> has probably less
> | reasons to be deprecated. It was done simply to keep the Condition
> | aggregation (into rules or compound conditions) limited to a single
> | association class. Now, looking from this different
> prospective, I think
> | that it is a good idea to retain it.
> |
> | So, I suggest the modification of the
> pcimRuleConditionAssociation to become
> | a subclass of the pcimConditionAssociation already defined
> in PCELS. The
> | attributes of the pcimRuleConditionAssociation, all
> inherited from its
> | superclass, would end up being the same ones as previously
> defined by PCLS.
> | Thus, for aggregating Conditions into a Policy Rule, one
> would have the
> | choice of using pcimConditionAssociation or
> pcimRuleConditionAssociation
> | while Condition aggregation into a Compound Condition would
> be realized only
> | through the pcimConditionAssociation class.
> |
> | 5. pcimRuleActionAssociation - same suggestion as for the
> | pcimRuleConditionAssociation class
>
> This is a much better solution...
>
> | 6. The pcimRepository class defined by PCLS is deprecated
> by PCELS for
> | reasons described in PCIMe:
> | "   Because of the potential for confusion with the Policy Framework
> |    component Policy Repository (from the four-box picture: Policy
> |    Management Tool, Policy Repository, PDP, PEP),
> "PolicyRepository" is
> |    a bad name for the PCIM class representing a container
> of reusable
> |    policy elements.  Thus the class PolicyRepository is
> being replaced
> |    with the class ReusablePolicyContainer."
>
> This could also be handled with a subclass.
>
> Ryan
>
> _______________________________________________
> Policy mailing list
> Policy <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

Permalink | Reply | 1 comment |
headers
Ryan Moats | 12 Sep 2003 01:07

Re: PCLS classes deprecated in PCELS

On Thu, Sep 11, 2003 at 05:21:42PM -0500, Pana, Mircea wrote:
| IMO the usage of schema items corresponding to deprecated concepts would be
| in conflict with the model (in this case PCIMe). However, a "peaceful
| co-existence" would be a very good reason for compromise. The following
| proposal gets PCELS out of the "policing business" and where compliance with
| PCIMe requires PCLS classes or attributes not to be used, this is noted with
| the specific indication "for compliance with PCIMe implementations
| shall/shall not use ..." (or rather SHALL / SHALL NOT). I hope you will find
| the following acceptable:
| 
| 1. Replace the pcimGroupContainmentAuxClass class deprecation with a
| paragraph to indicate that "for compliance with PCIMe, implementations shall
| use the pcimPolicySet.pcimPolicySetComponentList attribute and a
| subordinated pcimPolicySetAssociation entry instead of an attached
| pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy Group,
| Rule or System". 
| 
| 2. Replace the pcimRuleContainmentAuxClass class deprecation with a
| paragraph to indicate that "for compliance with PCIMe,  implementations
| shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a
| subordinated pcimPolicySetAssociation entry instead of an attached
| pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy Group,
| Rule or System". 

I can live with these two...

| 3. The pcimRule* classes would not be deprecated. Instead, the abstract
| class pcimRule would be modified to become a subclass of the abstract class
| pcimPolicyRule defined in PCELS. A note would be added to indicate that "for
| compliance with PCIMe, implementations shall not use the
| pcimRule.pcimRulePriority attribute". See also Note_1 below.
|
| 4. The class pcimRuleConditionAssociation would be modified to become
| subclass of the pcimConditionAssociation class.
| 
| 5. The class pcimRuleActionAssociation would be modified to become subclass
| of the pcimActionAssociation class.

I can't live with these three: they would require me to change my working
implementation and change the PCLS schema. 

If you are going to do a subclass here and not break PCLS or existing
implementations, you have to go the other way:
pcimPolicyRule is a subclass of pcimRule, pcimConditionAssociation as a
subclass of pcimRuleConditionAssociation, etc.  This changes Note #1 to
what are the issues for pcimPolicyRule...

| 6. The pcimRepository* classes would not be deprecated. Instead the abstract
| class pcimRepository would be modified to become subclass of the abstract
| class pcimReusableContainer defined in PCELS. PCELS would indicate that "for
| compliance with PCIMe, the pcimReusableContainer* classes shall be used
| instead of the pcimRepository* classes".

Again, I can live with #6.

Ryan
Permalink | Reply | 0 comments |
headers
David McTavish | 12 Sep 2003 01:36
Favicon

RE: PCLS classes deprecated in PCELS

I agree with Ryan for all points except point 6, although, I believe that
this change would be easier to manage than in the initial proposal.

d.

-----Original Message-----
From: Ryan Moats [mailto:rmoats <at> lemurnetworks.net]
Sent: Thursday, September 11, 2003 7:07 PM
To: Pana, Mircea
Cc: 'policy <at> ietf.org'; 'bwijnen <at> lucent.com'
Subject: Re: [Policy] PCLS classes deprecated in PCELS

On Thu, Sep 11, 2003 at 05:21:42PM -0500, Pana, Mircea wrote:
| IMO the usage of schema items corresponding to deprecated concepts would
be
| in conflict with the model (in this case PCIMe). However, a "peaceful
| co-existence" would be a very good reason for compromise. The following
| proposal gets PCELS out of the "policing business" and where compliance
with
| PCIMe requires PCLS classes or attributes not to be used, this is noted
with
| the specific indication "for compliance with PCIMe implementations
| shall/shall not use ..." (or rather SHALL / SHALL NOT). I hope you will
find
| the following acceptable:
| 
| 1. Replace the pcimGroupContainmentAuxClass class deprecation with a
| paragraph to indicate that "for compliance with PCIMe, implementations
shall
| use the pcimPolicySet.pcimPolicySetComponentList attribute and a
| subordinated pcimPolicySetAssociation entry instead of an attached
| pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy Group,
| Rule or System". 
| 
| 2. Replace the pcimRuleContainmentAuxClass class deprecation with a
| paragraph to indicate that "for compliance with PCIMe,  implementations
| shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a
| subordinated pcimPolicySetAssociation entry instead of an attached
| pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy Group,
| Rule or System". 

I can live with these two...

| 3. The pcimRule* classes would not be deprecated. Instead, the abstract
| class pcimRule would be modified to become a subclass of the abstract
class
| pcimPolicyRule defined in PCELS. A note would be added to indicate that
"for
| compliance with PCIMe, implementations shall not use the
| pcimRule.pcimRulePriority attribute". See also Note_1 below.
|
| 4. The class pcimRuleConditionAssociation would be modified to become
| subclass of the pcimConditionAssociation class.
| 
| 5. The class pcimRuleActionAssociation would be modified to become
subclass
| of the pcimActionAssociation class.

I can't live with these three: they would require me to change my working
implementation and change the PCLS schema. 

If you are going to do a subclass here and not break PCLS or existing
implementations, you have to go the other way:
pcimPolicyRule is a subclass of pcimRule, pcimConditionAssociation as a
subclass of pcimRuleConditionAssociation, etc.  This changes Note #1 to
what are the issues for pcimPolicyRule...

| 6. The pcimRepository* classes would not be deprecated. Instead the
abstract
| class pcimRepository would be modified to become subclass of the abstract
| class pcimReusableContainer defined in PCELS. PCELS would indicate that
"for
| compliance with PCIMe, the pcimReusableContainer* classes shall be used
| instead of the pcimRepository* classes".

Again, I can live with #6.

Ryan

_______________________________________________
Policy mailing list
Policy <at> ietf.org
https://www1.ietf.org/mailman/listinfo/policy
Permalink | Reply | 1 comment |
headers
Ryan Moats | 12 Sep 2003 02:21

Re: PCLS classes deprecated in PCELS

On Thu, Sep 11, 2003 at 07:36:05PM -0400, David McTavish wrote:
| I agree with Ryan for all points except point 6, although, I believe that
| this change would be easier to manage than in the initial proposal.
| 
| d.

David is right, I misread #6.  That has the same problem as #3-5.

Ryan

| -----Original Message-----
| From: Ryan Moats [mailto:rmoats <at> lemurnetworks.net]
| Sent: Thursday, September 11, 2003 7:07 PM
| To: Pana, Mircea
| Cc: 'policy <at> ietf.org'; 'bwijnen <at> lucent.com'
| Subject: Re: [Policy] PCLS classes deprecated in PCELS
| 
| 
| On Thu, Sep 11, 2003 at 05:21:42PM -0500, Pana, Mircea wrote:
| | IMO the usage of schema items corresponding to deprecated concepts would
| be
| | in conflict with the model (in this case PCIMe). However, a "peaceful
| | co-existence" would be a very good reason for compromise. The following
| | proposal gets PCELS out of the "policing business" and where compliance
| with
| | PCIMe requires PCLS classes or attributes not to be used, this is noted
| with
| | the specific indication "for compliance with PCIMe implementations
| | shall/shall not use ..." (or rather SHALL / SHALL NOT). I hope you will
| find
| | the following acceptable:
| | 
| | 1. Replace the pcimGroupContainmentAuxClass class deprecation with a
| | paragraph to indicate that "for compliance with PCIMe, implementations
| shall
| | use the pcimPolicySet.pcimPolicySetComponentList attribute and a
| | subordinated pcimPolicySetAssociation entry instead of an attached
| | pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy Group,
| | Rule or System". 
| | 
| | 2. Replace the pcimRuleContainmentAuxClass class deprecation with a
| | paragraph to indicate that "for compliance with PCIMe,  implementations
| | shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a
| | subordinated pcimPolicySetAssociation entry instead of an attached
| | pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy Group,
| | Rule or System". 
| 
| I can live with these two...
| 
| | 3. The pcimRule* classes would not be deprecated. Instead, the abstract
| | class pcimRule would be modified to become a subclass of the abstract
| class
| | pcimPolicyRule defined in PCELS. A note would be added to indicate that
| "for
| | compliance with PCIMe, implementations shall not use the
| | pcimRule.pcimRulePriority attribute". See also Note_1 below.
| |
| | 4. The class pcimRuleConditionAssociation would be modified to become
| | subclass of the pcimConditionAssociation class.
| | 
| | 5. The class pcimRuleActionAssociation would be modified to become
| subclass
| | of the pcimActionAssociation class.
| 
| I can't live with these three: they would require me to change my working
| implementation and change the PCLS schema. 
| 
| If you are going to do a subclass here and not break PCLS or existing
| implementations, you have to go the other way:
| pcimPolicyRule is a subclass of pcimRule, pcimConditionAssociation as a
| subclass of pcimRuleConditionAssociation, etc.  This changes Note #1 to
| what are the issues for pcimPolicyRule...
| 
| | 6. The pcimRepository* classes would not be deprecated. Instead the
| abstract
| | class pcimRepository would be modified to become subclass of the abstract
| | class pcimReusableContainer defined in PCELS. PCELS would indicate that
| "for
| | compliance with PCIMe, the pcimReusableContainer* classes shall be used
| | instead of the pcimRepository* classes".
| 
| Again, I can live with #6.
| 
| Ryan
| 
| _______________________________________________
| 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
Permalink | Reply | 0 comments |

Gmane