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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 5 Sep 2003 00:58:54 +0200

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:[email-masked]]
Sent: vrijdag 5 september 2003 0:10
To: [email-masked]'; [email-masked]'
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:[email-masked] <mailto:[email-masked]> ] 
> Sent: Friday, August 29, 2003 11:15 AM 
> To: [email-masked] 
> 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:[email-masked] <mailto:[email-masked]> ] 
> > Sent: vrijdag 15 augustus 2003 11:45 
> > To: [email-masked] 
> > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt 
> > 
> > 
> > Joel asked from the WG: 
> > > -----Original Message----- 
> > > From: Joel M. Halpern [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > Sent: woensdag 6 augustus 2003 17:33 
> > > To: [email-masked] 
> > > 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 <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 
> > [email-masked] 
> > https://www1.ietf.org/mailman/listinfo/policy <https://www1.ietf.org/mailman/listinfo/policy>  
> > 
> 
> _______________________________________________ 
> Policy mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/policy <https://www1.ietf.org/mailman/listinfo/policy>  
>

---

From: David McTavish <[email-masked]>
Date: Tue, 9 Sep 2003 10:44:12 -0400

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:[email-masked]]
Sent: Tuesday, September 09, 2003 10:38 AM
To: Pana, Mircea
Cc: [email-masked]'
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/policy

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

---

From: John Strassner <[email-masked]>
Date: Mon, 15 Sep 2003 07:14:42 -0600

Please see comments inline.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     +1.719.785.0644
email:    [email-masked]

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Thursday, September 11, 2003 4:22 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [Policy] 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).

<js> Au contraire, it is inappropriate to deprecate LDAP schema.

You have a tough choice - try and design a true update of PCLS, or say "Gee,
since PCIMe changed the playing rules, so can we. Unfortunately, what you've
done is try to do both - build a new design under the guise of an "update",
and it doesn't work. You need to choose one approach or the other. And if
you choose update, then you need to be compatible with PCLS. Currently,
you're not. </js>

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:

<js> But you STILL need to choose one approach or the other, see below </js>

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". 

<js> Upper case SHALL, or just a plain "shall"? </js>

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".

<js> These are exactly backwards. A PolicyRule is-a special type of Rule.
Same problem with 4 and 5 - for example, in the old QPIM work, we had
defined the concept of a condition in a condition. Thus, there is (or at
least could be) a marked difference between a condition and a ruleCondition.

Regarding pcimRepository, it shares two things with the other classes in 3-5
- in the LDAP sense, it is exactly backwards, and your proposal ensures
incompatibility. </js>

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. 

<js> This assumes that the semantics of aggregating a condition in a rule
are the same as aggregating a condition in other types of objects. I, for
one, disagree with that assumption. </js>

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.

<js> Your choice depends on whether you believe that we're done, or that
their may be future implementations that want to further refine the
semantics that PCIMe has defined. Your choice must also consider
compatibility with previous PCLS implementations. Since I'm working on one
of those "future" implementations, I would rather see a generic condition
aggregation defined, with the particular case of a policyCondition
aggregated by a policyRule treated as a specialization of that generic
aggregation. </js>

Thanks, 
Mircea. 

> Sent: Tuesday, September 09, 2003 10:26 AM 
> To: Pana, Mircea 
> Cc: [email-masked]'; [email-masked]' 
> 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 
>

---

From: John Strassner <[email-masked]>
Date: Mon, 15 Sep 2003 07:14:37 -0600

I have to agree with Ryan, Larry and David. I find the notion of deprecation
in PCELS unfortunate and technically NOT a good idea. I agree with Ryan's
points on this email, and could add even more, but see that as beating a
dead horse.

With respect to the two questions asked:

  1) PCLS should, in my opinion, be completed as a standards
     track document
  2) An extension document, by definition, further refines the
     original document. It does not fold, spindle, and mutilate
     the original document. IF there are fundamental reasons
     why the original document cannot be extended, then the 
     problem should be corrected in the original document, NOT
     by building an incompatible new document.
  3) Thus, I agree with Ryan: when PCELS starts deprecating 
     PCLS classes or changing the PCLS objectclass tree, then
     it is changing PCLS and it is impossible to then say that
     PCELS is an **extension** of PCLS.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue

> Sent: Friday, September 12, 2003 10:02 AM
> To: Joel M. Halpern
> Cc: Larry S. Bartz; Pana, Mircea; [email-masked]'
> On Fri, Sep 12, 2003 at 11:56:51AM -0400, Joel M. Halpern wrote:
> | I think that there really are two separate questions.
> | 1) Should PCLS be completed as a standards track RFC?  As far as
> I know,
> | everyone agrees that the answer to that is yes.
> 
> I certainly hope so...
> 
> | 2) How should PCIMe be mapped to LDAP?  My concern is taht you
> and others
> | are holding that mapping up to a standard of PCLS compatibility
> that PCIMe
> | itself does not meet.  I may be mistaken, but I believe that the
> | differences between PCIMe and PCIM are such that it is at best
> extremely
> | difficult (and quite possibly impossible) to accurately map PCIMe
> to LDAP
> | in a fashion compatible with PCLS.  My feeling is that concerns
> about PCELS
> | should be in the context of support for PCIMe, not in the context
> of
> | support for PCIM without PCIMe.
> 
> When PCELS starts deprecating PCLS classes or changing the
> objectclass tree of
> PCLS objects then its changing PCLS. That's why I've been asking
> for textual
> words and having PCELS classes inherit from PCLS classes (rather
> than the
> other was around), so that PCELS could be discussed in terms of
> PCIMe and
> not PCIM as PCLS is left intact.
> 
> Ryan
>

---

From: John Strassner <[email-masked]>
Date: Mon, 15 Sep 2003 07:14:45 -0600

With respect to your first point, PCELS does NOT already do this everywhere
- for example, there are cases where you've changed the name of the PCLS
class but kept the names of its attributes. That's very bad and will result
in some NASTY errors.

With respect to the second point, that's much better. I will provide
comments on the schema itself next week.

With respect to naming, I don't understand the problem. You have build a new
design, not an update of an existing design. Thus, new concepts should be
assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas
existing concepts should be assigned the pcim prefix. Thus, it is not a
"everything or nothing" decision but instead a judicious application of new
(pcels) vs old (pcim) concepts.

regards,
John

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Friday, September 12, 2003 3:11 PM
To: 'Joel M. Halpern'; Larry S. Bartz; [email-masked]'
Cc: [email-masked]; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

So, if I understand correctly, everything would be "OK" if PCELS did: 

1. Define only subclasses of PCLS classes and, where not possible, redefine
PCLS concepts as new classes (use different names and oid.s). This is
already the case in the currently published ID with the exception of
pcimGroup* that would need to be redefined with a different name.  

2. Use "for compliance with PCIMe implementations SHALL use <list schema
items> instead of <list of schema items> for the realization of <concepts>"
instead of deprecating PCLS classes. This would be added to a new revision
of the ID.

I'm fine with both. (I hope I did not miss anything) 

Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as
there are no naming conflicts, I would prefer to avoid it if possible. Could
you live with that? However if we have to do it for one item we should do it
for all.

Thanks, 
Mircea. 

> From: Joel M. Halpern [mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Friday, September 12, 2003 1:50 PM 
> To: Larry S. Bartz; [email-masked]' 
> Cc: [email-masked]; David McTavish; Pana, Mircea 
> 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 
> 
> At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote: 
> >Ryan Moats wrote, On 09/12/03 11:27: 
> >[snip} 
> >>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. 
> > 
> >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 
> >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 
> ::::::::::| 
> 
> 
> 
<https://www1.ietf.org/mailman/listinfo/policy>

---

From: John Strassner <[email-masked]>
Date: Mon, 15 Sep 2003 07:14:42 -0600

Hmm. Clearly, PCELS classes that are not compatible with PCLS should use
their own prefix, a simple and time-honored way to separate class
hierarchies. However, I still worry about the rigidity and lack of
extensibility if we simply say "Here lies PCLS, and here lies PCELS. May
their paths never cross". The example given in my previous note regarding a
more generic (AND ABSTRACT) policyConditionAssociation, from which a more
specific policyConditionInPolicyRule, as well as a more specific
policyConditionInPolicyCondition are subclasses, seems infinitely better.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue

> Sent: Friday, September 12, 2003 10:28 AM
> To: Pana, Mircea
> Cc: David McTavish; [email-masked]'
> 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: John Strassner <[email-masked]>
Date: Mon, 15 Sep 2003 07:14:43 -0600

Hear hear! Nicely stated, I absolutely agree.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue

> From: Larry S. Bartz [mailto:[email-masked]]
> Sent: Friday, September 12, 2003 11:39 AM
> To: [email-masked]'
> Cc: [email-masked]; David McTavish; Joel M. Halpern;
> Pana, Mircea
> 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
> 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
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::|
> # Larry Bartz
> #
> #  voice (317) 226-7060
> #  FAX   (317) 226-6378
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::|
> 
>

---

From: John Strassner <[email-masked]>
Date: Mon, 15 Sep 2003 07:14:41 -0600

Comments inline; please look for <js>..</js>. In general, I think that the
prefix "pcim" is misused in PCELS - this implies that PCELS is truly an
update and is using the same schema, whereas in reality PCELS is a new
design and is building a different schema that in its proposal is
incompatible is some important, fundamental ways. So why not use a new
prefix - pcime or pcels - to indicate this for the new classes proposed?

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue

> Sent: Tuesday, September 09, 2003 8:26 AM
> To: Pana, Mircea
> | 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

<js> While it is true that PCIMe did deprecate concepts in PCIM, this was
done with interoperability in mind. PCELS seems to have considered the
design as a clean slate, as opposed to maximizing interoperability. Also,
note that there is a huge difference between RFC3460, which is an
information model, and PCELS, which is a data model. </js>

> | multi-valued attribute that references a set of pcimGroups. This
> unordered
> | aggregation mechanism can not be reused in implementations of
> PCIMe because
> |    PolicySetComponent.Priority MUST have a unique value when
> compared
> |    with others defined for the same aggregating PolicySet.  Thus,
> the
> | If PCELS allowed pcimGroupContainmentAuxClass, then it would be
> conflicting
> | with PCIMe.
> |

<js> I agree with Ryan </js> 

> | 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
> | pcimRuleActionList is replaced by pcimActionList. Thus, the new
> attributes
> | along with the new association classes (discussed below) offer a
> generic
> | Condition/Action aggregation mechanism for both Policy Rules and
> Compound
> Since you are rethinking subclass/deprication below, I'd argue
> rethink it
> here.

<js> I agree with Ryan. This isn't an update as much as it is a redesign.
</js>

> | 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

<js> I'd like to know why you think deprecating an existing class and
introducing incompatibility with existing implementations is better? </js>

> | 4. The class pcimRuleConditionAssociation defined by PCLS has
> probably less
> | association class. Now, looking from this different prospective,
> I think
> | a subclass of the pcimConditionAssociation already defined in
> PCELS. The
> | attributes of the pcimRuleConditionAssociation, all inherited
> from its
> | Thus, for aggregating Conditions into a Policy Rule, one would
> have the
> | while Condition aggregation into a Compound Condition would be
> realized only

<js> This is confusing. You've changed the name of the LDAP class but kept
the name of its attributes! You've therefore broken the LDAP class, as its
OID is related to its class name, and further confused things by trying to
move already assigned OIDs of attributes in the original definition of the
class to a new class. This needs to be fixed. In addition, you're assuming
that the semantics of aggregating a condition inside a condition are the
same as the semantics of aggregating a condition inside a rule. Even if that
is correct (which I'm not sure it is) this is a dangerous assumption,
because in subsequent implementations if this does change, you can't
accommodate these changes. </js>

> This is a much better solution...

<js> I disagree with Ryan here - see above </js>

> | 6. The pcimRepository class defined by PCLS is deprecated by
> PCELS for
> |    a bad name for the PCIM class representing a container of
> reusable
> |    policy elements.  Thus the class PolicyRepository is being
> replaced

<js> To be honest, I've never agreed with that reasoning, since the four-box
picture represents an unrealistic, simplistic architecture. But if you are
going to do this, handling this with a subclass as Ryan suggests would be
acceptable. </js>

---

From: John Strassner <[email-masked]>
Date: Mon, 15 Sep 2003 09:24:21 -0600

I very much agree with Larry about naming.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue

> Sent: Monday, September 15, 2003 7:41 AM
> To: Pana, Mircea
> Cc: 'Joel M. Halpern'; [email-masked]'; [email-masked];
> David McTavish; John Strassner
> Pana, Mircea wrote, On 09/12/03 16:10:
> > 1. Define only subclasses of PCLS classes and, where not
> possible,
> > redefine PCLS concepts as new classes (use different names and
> oid.s).
> > This is already the case in the currently published ID with the
> > exception of pcimGroup* that would need to be redefined with a
> different
> > name.
> >
> > items> instead of <list of schema items> for the realization of
> > <concepts>" instead of deprecating PCLS classes. This would be
> added to
> > a new revision of the ID.
> >
> Excellent!
> > Wrt. naming PCELS classes and attributes pcime* instead of pcim*,
> as
> > long as there are no naming conflicts, I would prefer to avoid it
> if
> > possible. Could you live with that? However if we have to do it
> for one
> > item we should do it for all.
> 
> 
> The distinction between PCIM/PCLS (the "core") and PCIMe/PCELS (the
> "extension") is significant; significant enough to distinguish the
> work of you and your co-authors by assigning a set of distinctive
> names
> to all new and different PCELS attributetypes and objectclasses. If
> PCELS does not do this, implementers will naturally expect that
> information components with similar prefixes belong to the same
> information model. The logical differences between PCIM/PCLS and
> PCIMe/PCELS preclude this kind of mix and match. PCELS should
> facilitate implementation by providing its own set of names.
> 
> One more thing. I agree with John Strassner, who writes:
>  > ..this document changes PCLS in several fundamental ways. I do
> NOT
>  > think that the word "update" should be used anywhere in this
> document. </js>
> 
> Thanks,
> 
> --
> --

---

From: "Pana, Mircea" <[email-masked]>
Date: Mon, 15 Sep 2003 17:20:54 -0500

John,

Thanks for the detailed comments and suggestions. This is greatly
appreciated. As already noted, there will be a PCELS revision shortly. This
revision will take into account the suggestions that you and the other
participants made on the list.

There are a few clarifications that I'd like to ask for. See below in
<mircea>..</mircea>.

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Monday, September 15, 2003 9:15 AM
To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; [email-masked]'
Cc: [email-masked]; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

<mircea>
Can you please give an example from the current PCELS? I don't understand
what you mean by "changed the name of the PCLS class". Except for pcimGroup*
and the PCLS classes marked as deprecated (that will be changed as noted)
there are concepts that have been redefined (i.e. new classes introduced by
PCELS with new OIDs). Some use attributes defined by PCLS. Do you see
anything wrong with that?</mircea>

<mircea>
I have heard valid arguments for using a different naming prefix in PCELS
than the one used by PCLS. These arguments are based on the view that
PCIM/PCLS is the "core" while PCIMe/PCELS is an "extension". This is one
point of view. Mine is that PCIM/PCLS alone is incomplete and that only
*together* with PCIMe/PCELS it provides THE Framework for the development of
domain specific submodels. Both produced by the same WG btw. (I'm not going
to argue that though - it seems to be a sore spot!) For me, the naming
prefix is a minor issue and I can live with a different prefix if people are
so strongly against reuse.

Thanks,
Mircea.
</mircea>

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Friday, September 12, 2003 3:11 PM
To: 'Joel M. Halpern'; Larry S. Bartz; [email-masked]'
Cc: [email-masked]; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

> From: Joel M. Halpern [mailto:[email-masked]]

---

From: John Strassner <[email-masked]>
Date: Tue, 16 Sep 2003 21:21:56 -0600

Hi there...

regards,
John

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Monday, September 15, 2003 4:21 PM
To: 'John Strassner'; 'Joel M. Halpern'; Larry S. Bartz; [email-masked]'
Cc: [email-masked]; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

John, 

-----Original Message----- 
From: John Strassner [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, September 15, 2003 9:15 AM 
To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; [email-masked]' 
Cc: [email-masked]; David McTavish 
Subject: RE: [Policy] PCLS classes deprecated in PCELS 

<mircea> 

<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines
pcimPolicyRule with a set of 10 optional attributes. Of these, five of the
PCELS attributes have the same name as the corresponding PCLS attributes,
yet you have deprecated pcimRule. How is that possible?
</js>

<mircea> 

<js>
I disagree with your statement that PCIM/PCLS is incomplete. You have
already heard that many people have built implementations. I think that the
goal has to be interoperability and peaceful coexistence between PCLS and
PCELS implementations.
</js>

Thanks, 
Mircea. 
</mircea> 

regards, 
John 

John C. Strassner 
Chief Strategy Officer 
Intelliden Inc. 
90 South Cascade Avenue 

-----Original Message----- 
From: Pana, Mircea [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, September 12, 2003 3:11 PM 
To: 'Joel M. Halpern'; Larry S. Bartz; [email-masked]' 
Cc: [email-masked]; David McTavish 
Subject: RE: [Policy] PCLS classes deprecated in PCELS 

Thanks, 
Mircea.

---

From: "Pana, Mircea" <[email-masked]>
Date: Wed, 17 Sep 2003 11:03:09 -0500

John,
 
see <mircea2>..</mircea2>
Thanks,
Mircea.

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, September 16, 2003 11:22 PM
To: 'Pana, Mircea'; John Strassner; 'Joel M. Halpern'; 'Larry S. Bartz';
[email-masked]'
Cc: [email-masked]'; 'David McTavish'
Subject: RE: [Policy] PCLS classes deprecated in PCELS

Hi there...

regards,
John

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Monday, September 15, 2003 4:21 PM
To: 'John Strassner'; 'Joel M. Halpern'; Larry S. Bartz; [email-masked]'
Cc: [email-masked]; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

John, 

-----Original Message----- 
From: John Strassner [ mailto:[email-masked]

<mircea> 

<js>

<mircea2>The five attributes with the same name are the ones defined by
PCLS. They are NOT redefined by PCELS, they are reused in their original
form and with their original semantics. PCELS provides replacement for the
pcimRule class and 5 of its 11 attributes. (The currently published revision
of PCELS explicitly deprecates the class and five of its 11 attributes and
the next revision will replace that with a note explicitly listing the
replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in
PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2> 

<mircea> 

<js>
I disagree with your statement that PCIM/PCLS is incomplete. You have
already heard that many people have built implementations.   I think that
the goal has to be interoperability and peaceful coexistence between PCLS
and PCELS implementations.
</js> 

<mircea2>Peace! I totally agree that, to the extent posible,
interoperability with the original schema and a peaceful coexistence should
be (and will be) the goals of PCELS ;-)</mircea2>   

Thanks, 
Mircea. 
</mircea> 

regards, 
John 

John C. Strassner 
Chief Strategy Officer 
Intelliden Inc. 
90 South Cascade Avenue 

-----Original Message----- 
From: Pana, Mircea [ mailto:[email-masked] <mailto:[email-masked]> ]

Thanks, 
Mircea.

---

From: David McTavish <[email-masked]>
Date: Wed, 17 Sep 2003 16:48:48 -0400

I'm getting the feeling that we are drifting from the original objective
that the schema MUST NOT be deprecated in PCELS, but rather, extended. It
would be nice if we could outline that a requirement of the PCELS is that no
prior schema from PCIM is deprecated. I can't stress enough that deprecating
schema in LDAP is on parallel to a cardinal sin, it should nearly be never
done. I'm not trying to critique anybody's experience, but am only adding my
extensive experience gained from working with LDAP hands-on, and with PCIM
in particular.
From practice, and having an LDAP-implemented PCIM solution in the field for
almost a year now, it has come to our conclusion that if schema is designed
incorrectly in the past, it is left as-is, and new schema is created to make
up for the deficiency (unless we're adding new attributes to an object
class).  My interest in PCELS is solely from the perspective to protect our
existing investment in PCIM and PCLS. Not to say that I don't appreciate
what is occurring here, as I do, but there needs to be some level of
formality going forward that appreciates the effort of the initial
implementation (PCIM and PCLS), and parties using it. If PCIMe/PCELS is
allowed to hijack the previous effort, then the point of having a "standard"
is moot. There will be no standard, only a series of forked implementations.
If the changes in PCIMe ARE necessary (I will argue that not all of them are
later), then I suggest that we deprecate the current RFC dedicated to PCIM
and PCLS and re-submit the standard as version 2.0.
 
After debating these changes, my curiosity was piqued further to try to have
a firmer understanding of why these changes need to come about in
PCIMe/PCELS.  Reviewing the Feb-2004 draft, I'm of the opinion that 50% of
the document is duplicating existing PCIM implementation by renaming
classes, and the other half is providing new functionality. I believe that
changing class names for the sole sake of renaming the class is bad from a
design standpoint, and worse from the perspective of existing
implementations. (ie: all pcimRuleConditionList -> pcimConditionList changes
should be outright dismissed and removed from the document).
 
So that I can understand better, I've listed all of the new functionality
proposed by PCIMe/PCELS. Please feel free to supplement with what I may have
overlooked:
 - groups behave more like rules and inherit the following properties
(priority, pcimRoles)
 - rules and groups have new properties (pcimDecisionStrategy)
 - rules have new property (pcimExecutionStrategy)
 - new pcimSimpleConditionAuxClass enables reusable variables and values
 - new pcimCompoundConditionAuxClass enables reusable collection of
conditions 
 - new pcimCompoundFilterAuxClass enables ???
 - new pcimSimpleActionAuxClass enables reusable variables and values
 - new pcimCompoundActionAuxClass enables resuable collection of actions
 - new pcimVariable class
 - new pcimExplicitVariableAuxClass
 * as far as I can tell, an effort was made to make a somewhat exhaustive
collection of AuxClass and pcimType objects to be included with Condition
and Action instances.  I appreciate the effort put into this, but wonder if
the AuxClass instances are a little overboard? In most cases, people who are
extending PCIM and PCIMe, will most likely want to have their own
*ConditionAuxClass that extends from the VendorAuxClass in PCIM and add
their appropriate fields as desired. ie: SandvineFilterConditionAuxClass
extends VendorAuxClass and MAY { labelledURI, ipHostNumber }. Seeming as you
can only inherit from one object class, I think preference should be left
with the original PCIM implementation to extend from Vendor, instead of
adding a large number of AuxClasses to a condition to provide the desired
attribute types. We have to remember that this is only the core model of
which implementations are going to be based, not the final product of
implementation. That is for other standards like QoS to push forth and
outline the exact format for conditions and actions to be implemented.
 
Also, it would be nice to see some effort go into re-using existing IETF
standardized LDAP "attributes", like labelledURI and ipServicePort (defined
in RFC2307). I believe that interdependence on existing standards only
solidifies the reason for existence of both standards.
 
From what I believe is a duplicate of effort:
 - pcimPolicySet ~= pcimGroup
 - pcimPolicySetList = pcimRulesAuxContainedSet + pcimGroupsAuxContainedSet
 - pcimPolicySetAssociation ~= pcimGroupInstance +
pcimRuleContainmentAuxClass + pcimGroupContainmentAuxClass
 - pcimReusableContainer == pcimRepository
 - pcimReusableContainerAuxClass == pcimRepositoryAuxClass
 - pcimReusableContainerInstace == pcimRepositoryInstance

Things I disagree with:
5.6 pcimPolicyRule "If a pcimPolicyRule instance has a pcimConditionAuxClass
attached to it then the attribute pcimConditionList SHOULD NOT be present in
the same entry for the purpose of associating other conditions to the rule.
However, when such situations occur the referenced conditions MUST NOT be
considered as associated to the rule."
 - this means that re-usable conditions are not easily used in conjuction
with customized conditions. ie: we use PCIM to specify rules for
policy-based filtering. For instance, we may have a pre-defined condition
that is linked through the pcimConditionList, but the individual user may
update their policy so that the rule contains a TimePeriodCondition that
specifies it only is valid between the hours of 9-5. With the above
language, this sort of amalgamation of conditions is not valid. I believe
the configuration SHOULD be correct, and the evaluation of the conditions
are done on a priority-based level.

Regards,
d.

---

From: "Pana, Mircea" <[email-masked]>
Date: Wed, 24 Sep 2003 08:15:13 -0500

David,
 
PCLS recommends:
 "A policy rule may have its conditions attached to itself and its actions 
attached to other entries, or it may have its actions attached to itself 
and its conditions attached to other entries. However, it SHALL NOT have 
either its conditions or its actions attached both to itself and to 
other entries, with one exception:  a policy rule may reference its 
validity periods with the pcimRuleValidityPeriodList attribute, but have 
its other conditions attached to itself."
 
Which implies that if a pcimTPCAuxClass is attached to a pcimRule (because
pcimTPCAuxClass is a subclass of pcimConditionAuxClass) then no other
conditions shall be aggregated (referenced) by that rule except for other
validity periods aggregated through pcimRuleValidityPeriodList references. I
am not sure about the reasons behind this limitation introduced by PCLS but
in PCELS we have simply re-phrased it to make it clear for implementers.

Regards,
Mircea.

Things I disagree with:

Regards,
d.