RE: PCLS classes deprecated in PCELS

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
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     +1.719.785.0644
email:    [email protected]


> -----Original Message-----
> From: Ryan Moats [mailto:[email protected]]
> Sent: Tuesday, September 09, 2003 8:26 AM
> To: Pana, Mircea
> Cc: '[email protected]'; '[email protected]'
> 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?

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

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

<js> I agree with Ryan </js> 

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

<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
> | experience would be greatly appreciated.

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

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

> | 5. pcimRuleActionAssociation - same suggestion as for the
> | pcimRuleConditionAssociation class
> 
> 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
> | 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.

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

> Ryan
> 
> _______________________________________________
> Policy mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/policy