[I2nsf] Service Layer Policies - Post 1: Background Information on PCIM

[John Strassner <[e-mail]>]

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 PCIM and PCIMe for this
task. I have tried to avoid model-theoretic essays as much as possible.

Sorry for the length of this note, but RFC3060 is a 100-page document, and
this is a complex subject. Therefore, I have tried to keep this as brief as
possible. If you need more explanation on the conclusions in section 3,
please do not hesitate to ask!

1.  Terminology

   An information model is a representation of concepts of interest
   to an environment in a form that is independent of data repository,
   data definition language, query language, implementation language,
   and protocol.

   A data model is a representation of concepts of interest to an
   environment in a form that is dependent on data repository, data
   definition language, query language, implementation language, and
   protocol (typically, but not necessarily, all three).


2.  Brief description of PCIM

The PCIM Class Hierarchy is very simple, as this is a CA (condition-action)
model. Events are NOT represented. PCIM defines a PolicyRule, a PolicyGroup
(group of PolicyRules), PolicyCondition, and PolicyAction. These are all
siblings; their common superclass is called Policy, as shown below:

ManagedElement (abstract)
  |
  +---Policy (abstract)
  |     |
  |     +---PolicyGroup
  |     |
  |     +---PolicyRule
  |     |
  |     +---PolicyCondition (abstract)
  |     |      |
  |     |      +---PolicyTimePeriodCondition
  |     |      |
  |     |      +---VendorPolicyCondition
  |     |
  |     +---PolicyAction (abstract)
  |            |
  |            +---VendorPolicyAction

Note: PCIM does have a simple notion of Roles, but implements them as
attributes, instead of objects. This is not scalable, and does not fully
realize the power of using roles. This will be discussed more in Post 3.

Note: It is possible to define limited constraints in PCIM as conditions.
For example, the VendorPolicyCondition class has two attributes, Constraint
and ConstraintEncoding, that do this. This will be discussed more in Post 4.

Note: Context is NOT defined in the PCIM.


3.  Summary: main drawbacks of using PCIM

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.

Critical Problems:

   - There is no unique ID that can be used to distinguish different
   instances of the same PolicyRule, PolicyGroup, PolicyCondition,
   or PolicyAction.
   - Relationships are implemented by defining an abstract class
   with keys, and then overriding the keys in the subclasses of the
   relationship. This is broken. Would you override keys in an RDBMS?
   - Most of the classes that are used to implement the relationships
   do NOT have attributes, so it is impossible to restrict which
   classes are related to which other classes (e.g., by context).
   Put another way, the same relationship must always be used
   between two types, even if the semantics varies. (The two
   exceptions are PolicyConditionInPolicyRule and
   PolicyActionInPolicyRule).
   - The "ignore this unless you need this" philosophy does not
   work. How do you know if other implementations that you are
   supposed to interoperate with are using them?
   - 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;
   this is due to the simplistic notion of just using a PDP and a
   PEP for applying policies.

Major Problems:

   - The notion of "rule-specific" or "reusable" does not make sense.
   ANY object should be reusable. Worse, this affects the naming
   of the CIM classes.
   - PolicyGroup does not prevent defining loops of PolicyRules.
   - PolicyGroup uses a recursive aggregation for nesting; this
   causes unexpected behavior the further the nesting goes
   - The PolicyGroup recursive aggregation also does not support
   the aggregation of PolicyRules AND PolicyGroups; it is an
   either-or aggregation
   - Different classes are required to associate each condition with
   a PolicyRule
   - Different classes are required to associate each action with
   a PolicyRule
   - PolicyRule has a priority attribute; this can NOT be used to
   resolve priorities across nested PolicyRules and PolicyGroups
   - The aggregation PolicyActionInPolicyRule has an actionOrder
   attribute, which has 2 problems:
      1) this can NOT be used to define the order of actions
          across nested PolicyRules and PolicyGroups
      2) this is a very fragile mechanism for establishing the
          order of actions within a PolicyRule (e.g., no mechanisms
          are defined for verifying the order of actions is correct)
   - PolicyRule defines roles as a set of strings; this is NOT
   optimal, as will be explained in my next post (#3)
   - The associations PolicyInSystem, PolicyGroupInSystem,
   and PolicyRuleInSystem are superfluous; modern software
   techniques like introspection or reflection do the same
   things in more powerful ways.

Minor Problems

   - Policy inherits at least 5 recursive relationships that are not
   useful for Policy-based Management.
   - Policy inherits at least 3 attributes that are not useful for
   Policy-based Management
   - PolicyGroup has no useful attributes defined
   - PolicyCondition is an abstract class with no attributes defined
   - PolicyTimePeriodCondition lacks full time capabilities (e.g., local
   time, lunar calendar, etc.)
   - PolicyAction is an abstract class with no attributes defined


4. Recommendations

Given the large amount of problems, I recommend that we not consider PCIM
further.


5. Origin of PCIM/PCIMe

This is a **theory** section; please skip unless you want to understand the
model in more detail.

The PCIM is based on the DMTF CIM, which is actually a **data model**
(despite its name) because it uses relational technologies (e.g., keys and
weak references) to create its model. PCIM is based on an early version of
the CIM (2.4); the current version of the CIM is 2.44.1 as of this writing.
Since this is tied to the CIM, this means that:

   1) Policy is subclassed from a more generic class (ManagedElement)
   2) ALL relationships (associations, aggregations, and compositions)
       are realized as **classes**
   3) As a result of 2), relationships are subclassed
   4) Both attributes and associations are **inherited**
   5) The same design approach (as much as possible) was used in
        PCIM/PCIMe as was in CIM. Specifically, it was thought better
        to define a generic, but optional, relationship instead of not
        defining the relationship.
   6) The CIM does NOT have a single rooted hierarchy; this makes
        code generation more complex
   7) The CIM uses a proprietary language and is not strictly UML
        compliant, even though it looks like UML (unfortunately, this
        language is also called MOF)

Depending on the complexity of the implementation, the above have been
shown to produce problems in large environments. For example, the spirit of
"let's define an attribute or association in case it is useful, and make it
optional so you don't have to worry about it" not only violates some
well-known software architectural guidelines (e.g., Single Responsibility
Principle and the Liskov Substitution Principle), but it makes things
difficult to interoperate with (since you never really know if an attribute
or relationship should be instantiated or not).


regards,
John