rfc3060.txt

最新的RFC

         |  PolicyGroup   <........     .        | PolicyRepository |
         |                | w *         .        |                  |
         +------^---------+             .        +-----^---------^--+
               *.                       .         0..1 .    0..1 .
                .(e)                    .              .(f)      .(g)
               *.                       .              .         .
         +------v------+ w *            .              .         .
         |             <.................              .         .
         | PolicyRule  |                               .         .
         |             |                               .         .
         |             |                               .         .
         |             <........................       .         .
         |             |*      (h)             .       .         .
         |             |                       .       .         .
         |             |                       .       .         .
         |             |                       .       .         .
         |             |                       .       .         .
         |             |                       .       .         .
         |             |                       .       .         .
         |             |                       .*      .*        .
         |             |             +---------v-------v--+      .
         |             |             |  PolicyCondition   |      .
         |             |            *+--------------------+      .
         |             |       (i)             ^                 .
         |             <..............         I                 .
         |             |*            .         I                 .
         |             |             .*        ^                 .
         |             |        +----v----------------------+    .
         |             |        | PolicyTimePeriodCondition |    .
         |             |        +---------------------------+    .
         |             |       (j)                               .
         |             <.........................                .
         |             |*                       .                .
         |             |                        .*               .
         |             |             +----------v---------+*     .
         |             |             | PolicyAction       <.......
         +-------------+             +--------------------+

   Figure 1.    Overview of the Core Policy Classes and Relationships






Moore, et al.               Standards Track                    [Page 11]

RFC 3060             Policy Core Information Model         February 2001


   In this figure the boxes represent the classes, and the dotted arrows
   represent the associations.  The following associations appear:

   (a)     PolicyGroupInPolicyGroup

   (b)     PolicyGroupInSystem

   (c)     PolicyRuleInSystem

   (d)     PolicyRepositoryInPolicyRepository

   (e)     PolicyRuleInPolicyGroup

   (f)     PolicyConditionInPolicyRepository

   (g)     PolicyActionInPolicyRepository

   (h)     PolicyConditionInPolicyRule

   (i)     PolicyRuleValidityPeriod

   (j)     PolicyActionInPolicyRule

   An association always connects two classes.  The "two" classes may,
   however, be the same class, as is the case with the
   PolicyGroupInPolicyGroup association, which represents the recursive
   containment of PolicyGroups in other PolicyGroups.  The
   PolicyRepositoryInPolicyRepository association is recursive in the
   same way.

   An association includes cardinalities for each of the related
   classes.  These cardinalities indicate how many instances of each
   class may be related to an instance of the other class.  For example,
   the PolicyRuleInPolicyGroup association has the cardinality range "*'
   (that is, "0..n") for both the PolicyGroup and PolicyRule classes.
   These ranges are interpreted as follows:

   o  The "*" written next to PolicyGroup indicates that a PolicyRule
      may be related to no PolicyGroups, to one PolicyGroup, or to more
      than one PolicyGroup via the PolicyRuleInPolicyGroup association.
      In other words, a PolicyRule may be contained in no PolicyGroups,
      in one PolicyGroups, or in more than one PolicyGroup.

   o  The "*" written next to PolicyRule indicates that a PolicyGroup
      may be related to no PolicyRules, to one PolicyRule, or to more
      than one PolicyRule via the PolicyRuleInPolicyGroup association.
      In other words, a PolicyGroup may contain no PolicyRules, one
      PolicyRule, or more than one PolicyRule.



Moore, et al.               Standards Track                    [Page 12]

RFC 3060             Policy Core Information Model         February 2001


   The "w" written next to the PolicyGroupInSystem and
   PolicyRuleInSystem indicates that these are what CIM terms
   "aggregations with weak references", or more briefly, "weak
   aggregations".  A weak aggregation is simply an indication of a
   naming scope.  Thus these two aggregations indicate that an instance
   of a PolicyGroup or PolicyRule is named within the scope of a System
   object.  A weak aggregation implicitly has the cardinality 1..1 at
   the end opposite the 'w'.

   The associations shown in Figure 1 are discussed in more detail in
   Section 7.

4. Inheritance Hierarchies for the Policy Core Information Model

   The following diagram illustrates the inheritance hierarchy for the
   core policy classes:

      ManagedElement (abstract)
       |
       +--Policy (abstract)
       |  |
       |  +---PolicyGroup
       |  |
       |  +---PolicyRule
       |  |
       |  +---PolicyCondition (abstract)
       |  |          |
       |  |          +---PolicyTimePeriodCondition
       |  |          |
       |  |          +---VendorPolicyCondition
       |  |
       |  +---PolicyAction (abstract)
       |             |
       |             +---VendorPolicyAction
       |
       +--ManagedSystemElement (abstract)
          |
          +--LogicalElement (abstract)
             |
             +--System (abstract)
                |
                +--AdminDomain (abstract)
                   |
                   +---PolicyRepository

   Figure 2.    Inheritance Hierarchy for the Core Policy Classes





Moore, et al.               Standards Track                    [Page 13]

RFC 3060             Policy Core Information Model         February 2001


   ManagedElement, ManagedSystemElement, LogicalElement, System, and
   AdminDomain are defined in the CIM schema [1].  These classes are not
   discussed in detail in this document.

   In CIM, associations are also modeled as classes.  For the Policy
   Core Information Model, the inheritance hierarchy for the
   associations is as follows:

      [unrooted]
       |
       +---PolicyComponent (abstract)
       |   |
       |   +---PolicyGroupInPolicyGroup
       |   |
       |   +---PolicyRuleInPolicyGroup
       |   |
       |   +---PolicyConditionInPolicyRule
       |   |
       |   +---PolicyRuleValidityPeriod
       |   |
       |   +---PolicyActionInPolicyRule
       |
       +---Dependency (abstract)
       |   |
       |   +---PolicyInSystem (abstract)
       |       |
       |       +---PolicyGroupInSystem
       |       |
       |       +---PolicyRuleInSystem
       |       |
       |       +---PolicyConditionInPolicyRepository
       |       |
       |       +---PolicyActionInPolicyRepository
       |
       +---Component (abstract)
           |
           +---SystemComponent
               |
               +---PolicyRepositoryInPolicyRepository

   Figure 3.    Inheritance Hierarchy for the Core Policy Associations

   The Dependency, Component, and SystemComponent associations are
   defined in the CIM schema [1], and are not discussed further in this
   document.






Moore, et al.               Standards Track                    [Page 14]

RFC 3060             Policy Core Information Model         February 2001


4.1. Implications of CIM Inheritance

   From the CIM schema, both properties and associations are inherited
   to the Policy classes.  For example, the class ManagedElement is
   referenced in the associations Dependency, Statistics and
   MemberOfCollection.  And, the Dependency association is in turn
   referenced in the DependencyContext association.  At this very
   abstract and high level in the inheritance hierarchy, the number of
   these associations is very small and their semantics are quite
   general.

   Many of these inherited associations convey additional semantics that
   are not needed in understanding the Policy Core Information Model.
   In fact, they are defined as OPTIONAL in the CIM Schema - since their
   cardinality is "0..n" on all references.  The PCIM document
   specifically discusses what is necessary to support and instantiate.
   For example, through subclassing of the Dependency association, the
   exact Dependency semantics in PCIM are described.

   So, one may wonder what to do with these other inherited
   associations.  The answer is "ignore them unless you need them".  You
   would need them to describe additional information and semantics for
   policy data.  For example, it may be necessary to capture statistical
   data for a PolicyRule (either for the rule in a repository or for
   when it is executing in a policy system).  Some examples of
   statistical data for a rule are the number of times it was
   downloaded, the number of times its conditions were evaluated, and
   the number of times its actions were executed.  (These types of data
   would be described in a subclass of CIM_StatisticalInformation.)  In
   these cases, the Statistics association inherited from ManagedElement
   to PolicyRule may be used to describe the tie between an instance of
   a PolicyRule and the set of statistics for it.

5. Details of the Model

   The following subsections discuss several specific issues related to
   the Policy Core Information Model.

5.1. Reusable versus Rule-Specific Conditions and Actions

   Policy conditions and policy actions can be partitioned into two
   groups:  ones associated with a single policy rule, and ones that are
   reusable, in the sense that they may be associated with more than one
   policy rule.  Conditions and actions in the first group are termed
   "rule-specific" conditions and actions; those in the second group are
   characterized as "reusable".





Moore, et al.               Standards Track                    [Page 15]

RFC 3060             Policy Core Information Model         February 2001


   It is important to understand that the difference between a rule-
   specific condition or action and a reusable one is based on the
   intent of the policy administrator for the condition or action,
   rather than on the current associations in which the condition or
   action participates.  Thus a reusable condition or action (that is,
   one that a policy administrator has created to be reusable) may at
   some point in time be associated with exactly one policy rule,
   without thereby becoming rule-specific.

   There is no inherent difference between a rule-specific condition or
   action and a reusable one.  There are, however, differences in how
   they are treated in a policy repository.  For example, it's natural