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

From: "Pana, Mircea" <[email-masked]>
Date: Fri, 5 Sep 2003 08:19:55 -0500

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:[email-masked]]
Sent: Thursday, September 04, 2003 6:59 PM
To: 'Pana, Mircea'; Wijnen, Bert (Bert); [email-masked]'
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:[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: Ryan Moats <[email-masked]>
Date: Tue, 9 Sep 2003 09:37:34 -0500

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

---

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

Pana, Mircea wrote, On 09/05/03 08:19:
[snip]
> Does anybody have running code based on PCIM, PCLS, PCIMe?
[snip]

Yes. We have running code which is dependent upon PCIM and PCLS. The
code implements applications which are in production. They are used
every day to support real work.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Sep 2003 10:43:04 -0400

Given the discussion about the relationship between PCLS and the proposed 
PCELS, allow me to ask a naive question please.

There were some significant structural changes introduced between PCIM and 
PCIMe.  They were introduced to address problems with the PCIM structuring 
when other folks tried to use that as a basis for work.
Folks seem (as I read the exchanges) to be objecting to the corresponding 
changes in the LDAP schema.
Are the folks who implemented PCLS and are concerned about the changes 
expecting to support PCIMe?
If you are expecting to support PCIMe, how would you expect to deal with 
the fact that there are structural changes in the underlying model?

Yours,
Joel M. Halpern                 speaking as an interested participant

---

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

On Fri, Sep 12, 2003 at 10:43:04AM -0400, Joel M. Halpern wrote:
| Given the discussion about the relationship between PCLS and the proposed 
| PCELS, allow me to ask a naive question please.
| 
| There were some significant structural changes introduced between PCIM and 
| PCIMe.  They were introduced to address problems with the PCIM structuring 
| when other folks tried to use that as a basis for work.
| Folks seem (as I read the exchanges) to be objecting to the corresponding 
| changes in the LDAP schema.

| Are the folks who implemented PCLS and are concerned about the changes 
| expecting to support PCIMe?
| If you are expecting to support PCIMe, how would you expect to deal with 
| the fact that there are structural changes in the underlying model?

I am not expecting to support PCIMe.  

Ryan

---

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

Joel M. Halpern wrote, On 09/12/03 09:43:
> Given the discussion about the relationship between PCLS and the 
> proposed PCELS, allow me to ask a naive question please.
> 
> There were some significant structural changes introduced between PCIM 
> and PCIMe.  They were introduced to address problems with the PCIM 
> structuring when other folks tried to use that as a basis for work.
> Folks seem (as I read the exchanges) to be objecting to the 
> corresponding changes in the LDAP schema.

I disagreed (in this forum) with some of the strategies of PCIMe.
My concerns were not accomodated in the discussion or the design.
Ultimately, I made a personal choice not to pursue my points further,
as I recognize that intelligent, experienced, and reasonable people
may disagree without causing harm.

As far as I was concerned, PCIM and PCLS were already accomplished
work, work with which I agreed, and work upon which I could (and did)
build further. I have not experienced "problems with the PCIM
structuring", quite the opposite. I have found PCIM and PCLS to be
elegant, thorough, and highly serviceable designs. My work does not
require the restructuring and additional complexity of PCIMe. Neither
does my work require the QoS-specific components of PCIMe and PCELS.

I don't have a requirement for PCIMe. I don't anticipate modifying
my work to accomodate PCIMe.

I see PCIMe as a departure from PCIM's simplicity and elegance. I
see PCIMe as one of many possible elaborations upon PCIM's model.
Even with that unfortunate "Update" word in RFC 3460, I still consider
PCIM (RFC 3060) to be an authoritative document which describes a
viable model.

In the same spirit, I really want to see PCLS become an RFC. And
I especially don't want PCELS to clobber it or impinge upon it
in any way.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Sep 2003 11:56:51 -0400

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

I can understand that you (and possibly others) disagreed with the rough 
consensus on PCIMe.  But it is unfair to the PCELS authors to base 
objections to their mapping on objections to the differences and 
incompatibilities between PCIM and PCIMe.

Yours,
Joel M. Halpern

PS: In contrast to my concern above, if one can accurately map PCIMe to 
LDAP in a way that is compatible with PCLS, then that would clearly seem 
desirable.

---

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

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