Subject: Policy Core Information Model -- Naming Issues (long note)

From: [email-masked]
Date: Thu, 19 Aug 1999 16:21:44 -0400

NOTE:  The following text makes use of some concepts from the
DMTF's CIM object model.  Some readers of the IETF Policy
mailing list may find the online DMTF CIM tutorial useful.
Here is its URL:  http://www.dmtf.org/educ/tutorials/cim/

Those of you following the discussions on the IETF mailing list
will know that a consensus seems to be emerging on where to place
policy rules, policy conditions, and policy actions in the DIT.
There are two approaches allowed:

1. Non-reusable conditions and actions:
                                     __________________________
                                     | Legend:                |
                                     |                        |
               policyRule            |    |                   |
               |        |            |    |    DIT containment|
               |...     |...         |    |                   |
               |        |            |                        |
   pConditionAssoc     pActionAssoc  |  ++++   AUX attachment |
         +++                +++      |                        |
   policyCondition     policyAction  |  ***>   DN pointer     |
                                     |________________________|

2. Reusable conditions and actions:

               policyRule                    policyRepository
               |        |                      |          |
               |...     |...                   |          |
               |        |                      |          |
   pConditionAssoc     pActionAssoc            |          |
    DNpointer*          DNpointer*             |          |
             *                   *             |          |
             *                   *             |          |
             *                   *********************>pInstance
             *                                 |          +++
             *                                 |     policyAction
             *****************************>pInstance
                                              +++
                                        policyCondition

This direction has several advantages:

  - It takes a clear position on what the units of reusability
    are:  conditions and actions, but not entire policy rules.
  - It makes use of LDAP's subtree retrieval capabilities to
    reduce the number of LDAP requests needed to retrieve
    policy.
  - It constrains DIT structure down near the leaves, but it
    doesn't introduce any constraints higher up in the tree.
  - It gives the policy administrator a choice of how much
    reusability to use, although an implementation such as a
    Policy Management Tool might take this choice away from
    the administrator.

From the point of view of naming, the implications of the new
direction are very straightforward:  A policy condition or
policy action is always named (i.e., DIT-contained) in one of
two places:  either directly under a policy rule, or directly
under a policy repository.

Turning now to CIM naming, we note first that it is not
hierarchical in the way that LDAP (really, X.500) naming is.
In CIM an instance is identified by a unique combination of
keys, but this identification takes place within a single,
global namespace.

CIM simulates hierarchical naming to some extent via its weak
associations.  If a class A is weak to a class B, then an
instance of A is identified in the global CIM namespace by the
combination of its own keys and those of the instance of B
to which it bears the weak association.  This is not all that
different from X.500 naming, with the instance of A DIT-contained
under the instance of B.

If we try to map back into CIM the direction we discussed above
for placing policy conditions and policy actions into the DIT, we
run into an immediate problem:  in CIM a class is only allowed
to be weak to a single other class.  So how can we map the idea
that a policy condition or action may be named either under a
policy rule or under a policy repository?

Since weak associations are inherited, one possible approach
would be to insert (in the class inheritance hierarchy) a class
PolicyRuleOrPolicyRepository between the abstract class Policy and
the classes PolicyRule and PolicyRepository, so that PolicyCondition
and PolicyAction could be weak to it.  Besides being extremely
ugly, this approach runs into the problem that CIM already has
a class AdminDomain (a subclass of System, *not* of Policy) that
looks suspiciously like a policy repository.  So I've taken a
different approach:  simulating weak associations by manually adding
the keys that would have been propagated if the associations really
had been weak.  More on this below.

Another aspect of the CIM naming puzzle is how to name policy rules.
Naming a policy rule directly under the CIM global namespace seems
wrong.  The natural place to name a policy rule in CIM is "under"
the System to which it applies.  (System is a very general abstract
class in CIM -- it embraces computers, subnets, networks, etc.
AdminDomain is also a subclass of System in CIM.)  Since so many
subclasses are derived from System in CIM, there's no problem
saying that a policy rule must always be named in the context of the
System to which it applies.  Thus I have introduced a *weak*
association PolicyRuleInSystem between these two classes.

Returning to policy conditions and actions, each of these classes
has four key properties:

  - SystemCreationClassName and SystemName:  These properties
    simulate the key propagation that comes with a weak
    association.  For rule-specific conditions and actions, these
    properties contain the key values for the instance of
    System to which the policy rule "containing" them is
    associated via the weak association PolicyRuleInSystem.
    Since PolicyRuleInSystem is weak, these keys values are also
    used in identifying the policy rule itself.  For a
    reusable condition or action, these are the key values
    that identify the AdminDomain (i.e., Policy Repository)
    to which it belongs.
  - PolicyRuleName:  For a rule-specific condition or action,
    this property contains the key value that (together with
    the two key values propagated from System) identifies the
    instance of PolicyRule to which the condition or action
    "belongs".  For a reusable condition or action, this
    property returns a null value.  (I'm still investigating
    exactly what a "null" value is in CIM.  I'm guessing it's
    the zero-length string in this case, but I'm not sure.)
  - PolicyConditionName or PolicyActionName:  This is the
    key value that identifies a specific condition or action,
    given a set of values for the other key properties.

This naming scheme introduces a cross-associational
constraint that cannot be expressed in the Visio:  a policy
condition or policy action must be associated either with one
policy rule, with an AdminDomain, or with both one *or more*
policy rules and an AdminDomain.  The point to focus on is the
ConditionInAdminDomain (or ActionInAdminDomain) association.
If a condition or action participates in this association, then
(by definition) it is reusable.  This means (1) that the
condition or action is named with its repository's key values,
and (2) that it may be associated (basically, used by) zero,
one, or more than one policy rule.

On the other hand, if a condition or action does not participate
in the ConditionInAdminDomain (or ActionInAdminDomain)
association, then it is *not* reusable.  Consequently, it must
be associated with *exactly* one policy rule, and this rule
both uses the condition or action and gives to it its identity
(because the condition or action is named using the policy
rule's key values).

This set of constraints will have to be documented in the DMTF
White Paper that will accompany the Policy Visio and MOF.
It will also be included in the next update of the Policy Core
Informational Model I-D.

For IETFers, here's the URL for the PDF version of the Visio file,
on our AIW ftp server.  (Sorry, but there's "some assembly
required on all of these URLs.)

ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/
   Visio-CIM_Policy_1999_08_18a.pdf

For members of the DMTF SLA Policy WG, here's the URL for
the Visio file itself:

http://www.dmtf.org/members/tdc/wg-service/
   CIM_Policy_1999_08_18a.vsd

Ed also put the PDF file out on the DMTF server:

http://www.dmtf.org/members/tdc/wg-service/
   Visio-CIM_Policy_1999_08_18a.pdf

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]