Subject: [I2nsf] Post 2a: Background Information on PCIMe (Overview)

From: John Strassner <[email-masked]>
Date: Fri, 11 Dec 2015 13:55:13 -0800

The I2NSF framework draft mentions PCIM (RFC3060) and PCIMe (RFC3460) as
possible candidates for guiding the policy structure that can be mapped to
the Capability Layer's "Subject-Object-Action-Function" paradigm. This note
provides a brief analysis of the suitability of PCIMe for this task.

Attributes in PCIM and PCIMe do not obey standard coding conventions of
nonCapThenCap, they are CapThenCap. Please note that I name attributes in
the traditional nonCapThenCap manner in the following discussion.

Finally, sorry for the length of this note, but RFC3460 is a 93-page
document, and even more complex than PCIM. Therefore, I have tried to keep
this as brief as possible by splitting it into two, called Post 2a and Post
2b. This post (2a) gives a high-level overview, and is intended for
non-modelers. Post 2b adds detail to post 2a, and is intended for modelers.

If you need more explanation on anything, please do not hesitate to ask!

1.  Focus of PCIMe

PCIMe was built to accomplish two things:

   1) EXTEND PCIM into areas that were being worked on at the time
       (e.g., header filtering), and
   2) DEPRECATE parts of PCIM based on early experience

1.1.  EXTENSION

In general, extensions should not cause a problem, but there are exceptions
- the most important is PolicySet (parent of PolicyGroup and PolicyRule).
Please read Post 2b, section 1.1, for more detail on this.

1.2.  DEPRECATION

Deprecation is sometimes unavoidable. In general, such changes are not
backwards-compatible. Note that PCIMe does not include in its class
definitions annotations as to why a particular element was deprecated.

2.  SUMMARY: main drawbacks of using PCIMe

Note that the current CIM Policy Model (2.44.1) is significantly different
than either PCIM or PCIMe. PCIM is based on CIM 2.4; PCIMe is based on CIM
2.5. PCIMe is NOT backwards compatible with PCIM in all areas. Note also
that many of the deprecated items in 2.4 and 2.5 still exist in 2.44.1,
though some have been removed.
Given the large amount of problems, I recommend that we do not consider
PCIMe further for I2NSF work.

2.1.  Critical Problems

These are in addition to those pointed out in Post 1.

2.1.1.  Policy Rule Problems

  - There is no way to properly aggregate PolicyRules into
    PolicyGroups. PolicySetComponent is recursive, so it can be used
    to aggregate homogeneous, but not heterogeneous, objects
  - Nested policy rules (also called sub-rules) are no different than
    making a method call to another PolicyAction; this would greatly
    simplify implementation and understanding (see Post 2b)
  - There is no mechanism to make use of the executionStrategy
    attribute, since neither errors nor events are defined
  - There is no mechanism that can prevent side effects caused by
    the evaluation of conditions
  - There is no mechanism that can prevent side effects caused by
    the execution of actions

2.1.2.  Role Problems

  - Using attributes (i.e., policyRoles) to associate a PolicyRule
    to a resource is broken. This is what associations,
    aggregations, and compositions are for
  - Worse, the mechanism for aggregating roles is **backwards** in
    PCIMe. Roles describe object responsibilities, and there should
    be the object that is aggregated by an entity (see Post 2b)
  - Worse yet, there is no mechanism for ensuring that the resource
    object and the PolicyRoleCollection objects are scoped by the
    same System
  - Finally, there is no mechanism for role inheritance and role
    engineering to be performed (see Post 2b)

2.1.3.  Conditions and Actions

  - There is no reason to define the SimplePolicyCondition and
    CompoundPolicyCondition classes
  - There is no reason to define the SimplePolicyAction and
    CompoundPolicyAction classes

2.1.4.  Variables

  - There is no reason to have both a PolicyImplicitVariable and
    a PolicyExplicitVariable class (see Post 2b); they are
    performing the same semantic function

2.1.5.  Additional Problems

These are so important that they are repeated from Post 1:

  - There is no way to uniquely identify instances of the
    same object
  - There is no concept of error or exception handling
  - There is no concept of the subject or the target of a policy
  - Adding a new type of policy (e.g., declarative or functional)
    will cause a major rewrite of the entire model
  - There is no approach to detecting and solving policy conflicts

2.2.  Major Problems

2.2.1.  Abstraction Problems

  - The "levels of abstraction" (domain- and device-level policies)
    have no mechanisms defined in the model to support them
  - The PolicyComponent aggregation, defined on Policy, means that
    ANY SUBCLASS can aggregate itself, which is incorrect.
  - Scoping has no mechanisms to ensure that the PolicyRule and the
    resource to which it applies are in the same namespace.
    - First, weak relationships (a relational algebra construct),
      should not be used in information models.
    - Second, this requires two relationships (one for PolicyGroup
      and a different one for PolicyRule) to be used.
    - Third, the PCIMe implementation uses overriding of keys (!)
      to implement these aggregations.

2.2.2.  PolicyRule Problems

  - The "first-match" decision strategy can be ambiguous (see Post 2b)
  - The decisionStrategy attribute can be ambiguous (see Post 2b)
  - There is no mechanism to ensure that priority attribute values
    are unique within a PolicySet (or PolicySetInSystem); this
    leads to non-deterministic behavior
  - Different classes are required to associate each condition with
    a PolicyRule
  - Different classes are required to associate each action with
    a PolicyRule

2.2.3.  Condition and Action Problems

  - The MATCH operator is overloaded and ambiguous (see Post 2b)
  - CompoundPolicyConditions are very expensive (see Post 2b)
  - This also applies to CompoundPolicyActions
  - Building a Boolean condition clause is complex and requires too
    many aggregations (see Post 2b)
  - The above is more complex when PolicyConditions are nested, as
    well as when CompoundPolicyConditions are used (see Post 2b)
  - The above two points apply equally to PolicyActions

2.2.4. Miscellaneous Problems

  - The associations PolicyInSystem, PolicyGroupInSystem,
    and PolicyRuleInSystem are superfluous (see Post 2b)
  - Filters are too difficult to construct (see Post 2b)

2.3.  Minor Problems

  - PolicyRule has an attribute named "mandatory" whose semantics are
    ambiguous depending on the values of other attributes
  - The class CompoundFilterCondition defines one additional attribute;
    this is insufficient to standardize how filtering conditions
    should be structured
  - Copying the attributes sequencedActions and executionStrategy in
    both PolicyRule and CompoundPolicyAction does not make sense
  - All ImplicitPolicyVariable subclasses have no mechanism to
    enforce their allowed value types (see Post 2b)
  - The ReusablePolicyContainer class does not define any useful
    attributes for policy-based management

3. PCIMe Class Hierarchy

The PCIMe Class Hierarchy is still a CA (condition-action) model, as shown
below (changes are briefly noted in parentheses):

ManagedElement (abstract)
  |
  +---Policy (abstract)
  |     |
  |     +---PolicySet (abstract, new)
  |     |     |
  |     |     +---PolicyGroup (MOVED to here)
  |     |     |
  |     |     +---PolicyRule (MOVED to here)
  |     |
  |     +---PolicyCondition (abstract)
  |     |     |
  |     |     +---PolicyTimePeriodCondition
  |     |     |
  |     |     +---VendorPolicyCondition
  |     |     |
  |     |     +---SimplePolicyCondition (NEW)
  |     |     |
  |     |     +---CompoundPolicyCondition (NEW)
  |     |          |
  |     |          +---PolicyFilterCondition (NEW)
  |     |
  |     +---PolicyAction (abstract)
  |     |     |
  |     |     +---VendorPolicyAction
  |     |     |
  |     |     +---SimplePolicyAction (NEW)
  |     |     |
  |     |     +---CompoundPolicyAction (NEW)
  |     |     |
  |     +---PolicyVariable (abstract, NEW)
  |     |     |
  |     |     +---PolicyExplicitVariable (NEW)
  |     |     |
  |     |     +---PolicyImplicitVariable (abstract, NEW)
  |     |          |
  |     |          +---(NEW SUBCLASSES)
  |     |
  |     +---PolicyValue (abstract, NEW)
  |     |     |
  |     |     +---(NEW SUBCLASSES)
  |     |
  |     +---Collection (Abstract, NEW*)
  |     |     |
  |     |     +---PolicyRoleCollection (NEW)
  |     |
  |     +---ManagedSystemElement (abstract, NEW*)
  |     |     |
  |     |     +---LogicalElement (abstract, NEW*)
  |     |     |     |
  |     |     |     +---System (abstract, NEW*)
  |     |     |     |     |
  |     |     |     |    ... (deprecated PolicyRepository with
ReusablePolicyContainer, NEW*)
  |     |     |     |
  |     |     |     +---FilterEntryBase (abstract, NEW*)
  |     |     |     |     |
  |     |     |     |     +---IpHeadersFilter (NEW)*
  |     |     |     |     |
  |     |     |     |     +---8021Filter (NEW*)
  |     |     |     |     |
  |     |     |     +---FilterList (NEW*)

Note that RFC3460 says that the classes marked by NEW* are not new, as they
are defined in the CIM. However, they ARE new to PCIMe, so I have marked
them as NEW*. See additional notes in Post 2b if desired.

regards,
John