Subject: Re: [Policy] PCLS classes deprecated in PCELS

From: Ryan Moats <[email-masked]>
Date: Fri, 12 Sep 2003 11:15:07 -0500

On Fri, Sep 12, 2003 at 11:01:33AM -0500, Pana, Mircea wrote:
| I would like to understand why you have a problem with PCELS inserting a new
| class in the inheritance chain of a PCLS defined class. 

Because you've broken the binding between an LDAP object class's OID and 
an that object class's name. Included in this binding is the superior
objectclass.  Therefore

( <oid> NAME "pcimRepository" SUP top )

and

( <oid> NAME "pcimRepository" SUP pcimRulesContainer )

are *NOT* the same from an LDAP point of view: they require different
OID and different names.

Ryan

_______________________________________________
Policy mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/policy

---

From: Ryan Moats <[email-masked]>
Date: Fri, 12 Sep 2003 11:27:48 -0500

On Fri, Sep 12, 2003 at 11:15:07AM -0500, Ryan Moats wrote:
| On Fri, Sep 12, 2003 at 11:01:33AM -0500, Pana, Mircea wrote:
| | I would like to understand why you have a problem with PCELS inserting a new
| | class in the inheritance chain of a PCLS defined class. 
| 
| Because you've broken the binding between an LDAP object class's OID and 
| an that object class's name. Included in this binding is the superior
| objectclass.  Therefore
| 
| ( <oid> NAME "pcimRepository" SUP top )
| 
| and
| 
| ( <oid> NAME "pcimRepository" SUP pcimRulesContainer )
| 
| are *NOT* the same from an LDAP point of view: they require different
| OID and different names.
| 
| Ryan

Actually, that is a solution for all of the subclass cases: in PCELS call 
tem pcime*, give them different OIDs from what's in PCLS and then everything
is ok.

Ryan

---

From: "Larry S. Bartz" <[email-masked]>
Date: Fri, 12 Sep 2003 12:39:22 -0500

Ryan Moats wrote, On 09/12/03 11:27:
[snip}
> tem pcime*, give them different OIDs from what's in PCLS and then everything

I'll go further and suggest that every component of PCIMe which is
not exactly as defined in PCLS should be prefixed "pcime". If PCELS
simply avoids deprecating, renaming, or redefining anything from
PCLS, there can be no conflict with PCLS. And if everything new
which is introduced by PCELS is prefixed "pcime", there can be no
confusion about which is "core" and which is "extension".

Such a strategy will ultimately satisfy Joel's concerns, when he wrote:
 > My feeling is that concerns about PCELS should be in the context of
 > support for PCIMe,
and
 > if one can accurately map PCIMe to LDAP in a way that is compatible
 > with PCLS, then that would clearly seem desirable

PCELS should map PCIMe to LDAP in a way which is not INcompatible with
PCLS, in a way which does not break PCLS. I agree that "concerns about
PCELS should be in the context of support for PCIMe". I augment that
by saying that PCELS should not be concerned with recasting PCLS in
any way.

PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any
impact on PCLS.

-- 
--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz
#
#  voice (317) 226-7060
#  FAX   (317) 226-6378
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Sep 2003 13:50:09 -0400

Ryan as just nicely explained this to me in a way that got it through my 
thick skull.  You both are correct.  We can not move existing classes.

Hence, one needs to create new classes, and include text that says "use 
this instead of the old thing".

Unfortunate, but really a common problem with class naming / inheritance 
(not specific to just LDAP).

As I said to Ryan, thanks for the patience explaining this.
Joel

---

From: "Pana, Mircea" <[email-masked]>
Date: Fri, 12 Sep 2003 11:01:33 -0500

I would like to understand why you have a problem with PCELS inserting a new
class in the inheritance chain of a PCLS defined class. 
 
Let's take #6 for example: PCELS defines a new class pcimReusableContainer
and makes the existing pcimRepository a subclass of the new one. Thus,
once/if the PCELS schema is (incrementally) applied to the Directory server:
A. a PCLS implementation continues to handle pcimRepository entries just
like it did before
B. because a pcimRepository is also a pcimReusableContainer, a PCELS
implementation can also handle such entry correctly (i.e. as a container of
reusable policy components)
C. for a PCELS implementation, the presence of the pcimRepository class in a
pcimReusableContainer entry can trigger additional safeguards to allow the
entry to continue to be compatible with PCLS
D. a PCELS implementation that intends to comply with PCIMe would create
pcimReusableContainer entries that are not pcimRepository.

IMO, if it was the other way around (pcimReusableContainer defined as
subclass of pcimRepository) then D. would never be possible because a
pcimReusableContainer would also be a pcimRepository therefore violating the
PCIMe recommendation.

What situation did you have in mind when you stated that such change would
break PCLS or existing implementations?

Thanks,
Mircea.

> -----Original Message-----
> From: Ryan Moats [mailto:[email-masked]]
> Sent: Thursday, September 11, 2003 8:21 PM
> To: David McTavish
> Cc: Pana, Mircea; [email-masked]'; [email-masked]'
> Subject: Re: [Policy] 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:[email-masked]]
> | Sent: Thursday, September 11, 2003 7:07 PM
> | To: Pana, Mircea
> | Cc: [email-masked]'; [email-masked]'
> | 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
> | [email-masked]
> | https://www1.ietf.org/mailman/listinfo/policy
> | 
> | _______________________________________________
> | Policy mailing list
> | [email-masked]
> | https://www1.ietf.org/mailman/listinfo/policy
>