RE: PCLS classes deprecated in PCELS

 
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.