Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 3060

Policy Core Information Model -- Version 1 Specification

Pages: 100
Proposed Standard
Updated by:  3460
Part 2 of 5 – Pages 10 to 25
First   Prev   Next

Top   ToC   RFC3060 - Page 10   prevText

3. Overview of the Policy Core Information Model

The following diagram provides an overview of the five central classes comprising the Policy Core Information Model, their associations to each other, and their associations to other classes in the overall CIM model. Note that the abstract class Policy and the two extension classes VendorPolicyCondition and VendorPolicyAction are not shown. NOTE: For cardinalities, "*" is an abbreviation for "0..n".
Top   ToC   RFC3060 - Page 11
                               |  System   |
            .....              +--^-----^--+       .....
            .   .                1.    1.          .   .
           *.(a).*                .(b)  .(c)      *.(d).*
         +--v---v---------+       .     .        +-v---v------------+
         |  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
Top   ToC   RFC3060 - Page 12
   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.
Top   ToC   RFC3060 - Page 13
   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
Top   ToC   RFC3060 - Page 14
   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:

       +---PolicyComponent (abstract)
       |   |
       |   +---PolicyGroupInPolicyGroup
       |   |
       |   +---PolicyRuleInPolicyGroup
       |   |
       |   +---PolicyConditionInPolicyRule
       |   |
       |   +---PolicyRuleValidityPeriod
       |   |
       |   +---PolicyActionInPolicyRule
       +---Dependency (abstract)
       |   |
       |   +---PolicyInSystem (abstract)
       |       |
       |       +---PolicyGroupInSystem
       |       |
       |       +---PolicyRuleInSystem
       |       |
       |       +---PolicyConditionInPolicyRepository
       |       |
       |       +---PolicyActionInPolicyRepository
       +---Component (abstract)

   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
Top   ToC   RFC3060 - Page 15

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".
Top   ToC   RFC3060 - Page 16
   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
   to make the access permissions for a rule-specific condition or
   action identical to those for the rule itself.  It's also natural for
   a rule-specific condition or action to be removed from the policy
   repository at the same time the rule is.  With reusable conditions
   and actions, on the other hand, access permissions and existence
   criteria must be expressible without reference to a policy rule.

   The preceding paragraph does not contain an exhaustive list of the
   ways in which reusable and rule-specific conditions should be treated
   differently.  Its purpose is merely to justify making a semantic
   distinction between rule-specific and reusable, and then reflecting
   this distinction in the policy model itself.

   An issue is highlighted by reusable and rule-specific policy
   conditions and policy actions:  the lack of a programmatic capability
   for expressing complex constraints involving multiple associations.
   Taking PolicyCondition as an example, there are two aggregations to
   look at.  PolicyConditionInPolicyRule has the cardinality * at both
   ends, and PolicyConditionInPolicyRepository has the cardinality * at
   the PolicyCondition end, and [0..1] at the PolicyRepository end.

   Globally, these cardinalities are correct.  However, there's more to
   the story, which only becomes clear if we examine the cardinalities
   separately for the two cases of a rule-specific PolicyCondition and a
   reusable one.

   For a rule-specific PolicyCondition, the cardinality of
   PolicyConditionInPolicyRule at the PolicyRule end is [1..1], rather
   than [0..n] (recall that * is an abbreviation for [0..n]), since the
   condition is unique to one policy rule.  And the cardinality of
   PolicyConditionInPolicyRepository at the PolicyRepository end is
   [0..0], since the condition is not in the "re-usable" repository.
   This is OK, since these are both subsets of the specified
Top   ToC   RFC3060 - Page 17
   For a reusable PolicyCondition, however, the cardinality of
   PolicyConditionInPolicyRepository at the PolicyRepository end is
   [1..1], since the condition must be in the repository.  And, the
   cardinality of PolicyConditionInPolicyRule at the PolicyRule end is
   [0..n].  This last point is important:  a reusable PolicyCondition
   may be associated with 0, 1, or more than 1 PolicyRules, via exactly
   the same association PolicyConditionInPolicyRule that binds a rule-
   specific condition to its PolicyRule.

   Currently the only way to document constraints of this type is
   textually.  More formal methods for documenting complex constraints
   are needed.

5.2. Roles

5.2.1. Roles and Role Combinations

The concept of role is central to the design of the entire Policy Framework. The idea behind roles is a simple one. Rather than configuring, and then later having to update the configuration of, hundreds or thousands (or more) of resources in a network, a policy administrator assigns each resource to one or more roles, and then specifies the policies for each of these roles. The Policy Framework is then responsible for configuring each of the resources associated with a role in such a way that it behaves according to the policies specified for that role. When network behavior must be changed, the policy administrator can perform a single update to the policy for a role, and the Policy Framework will ensure that the necessary configuration updates are performed on all the resources playing that role. A more formal definition of a role is as follows: A role is a type of attribute that is used to select one or more policies for a set of entities and/or components from among a much larger set of available policies. Roles can be combined together. Here is a formal definition of a "role- combination": A role-combination is a set of attributes that are used to select one or more policies for a set of entities and/or components from among a much larger set of available policies. As the examples below illustrate, the selection process for a role combination chooses policies associated with the combination itself, policies associated with each of its sub-combinations, and policies associated with each of the individual roles in the role- combination.
Top   ToC   RFC3060 - Page 18
   It is important to note that a role is more than an attribute.  A
   role defines a particular function of an entity or component that can
   be used to identify particular behavior associated with that entity
   or component.  This difference is critical, and is most easily
   understood by thinking of a role as a selector.  When used in this
   manner, one role (or role-combination) selects a different set of
   policies than a different role (or role-combination) does.

   Roles and role-combinations are especially useful in selecting which
   policies are applicable to a particular set of entities or components
   when the policy repository can store thousands or hundreds of
   thousands of policies.  This use emphasizes the ability of the role
   (or role- combination) to select the small subset of policies that
   are applicable from a huge set of policies that are available.

   An example will illustrate how role-combinations actually work.
   Suppose an installation has three roles defined for interfaces:
   "Ethernet", "Campus", and "WAN".  In the Policy Repository, some
   policy rules could be associated with the role "Ethernet"; these
   rules would apply to all Ethernet interfaces, regardless of whether
   they were on the campus side or the WAN side.  Other rules could be
   associated with the role-combination "Campus"+"Ethernet"; these rules
   would apply to the campus-side Ethernet interfaces, but not to those
   on the WAN side.  Finally, a third set of rules could be associated
   with the role-combination "Ethernet"+"WAN"; these rules would apply
   to the WAN-side Ethernet interfaces, but not to those on the campus
   side.  (The roles in a role-combination appear in alphabetical order
   in these examples, because that is how they appear in the information

   If we have a specific interface A that's associated with the role-
   combination "Ethernet"+"WAN", we see that it should have three
   categories of policy rules applied to it:  those for the "Ethernet"
   role, those for the "WAN" role, and those for the role-combination
   "Ethernet"+"WAN".  Going one step further, if interface B is
   associated with the role- combination "branch-
   office"+"Ethernet"+"WAN", then B should have seven categories of
   policy rules applied to it - those associated with the following

      o "branch-office"
      o "Ethernet"
      o "WAN"
      o "branch-office"+"Ethernet"
      o "branch-office"+"WAN"
      o "Ethernet"+"WAN"
      o "branch-office"+"Ethernet"+"WAN".
Top   ToC   RFC3060 - Page 19
   In order to get all of the right policy rules for a resource like
   interface B, a PDP must expand the single role-combination it
   receives for B into this list of seven role-combinations, and then
   retrieve from the Policy Repository the corresponding seven sets of
   policy rules.  Of course this example is unusually complicated:  the
   normal case will involve expanding a two-role combination into three
   values identifying three sets of policy rules.

   Role-combinations also help to simplify somewhat the problem of
   identifying conflicts between policy rules.  With role-combinations,
   it is possible for a policy administrator to specify one set of
   policy rules for campus-side Ethernet interfaces, and a second set of
   policy rules for WAN-side Ethernet interfaces, without having to
   worry about conflicts between the two sets of rules.  The policy
   administrator simply "turns off" conflict detection for these two
   sets of rules, by telling the policy management system that the roles
   "Campus" and "WAN" are incompatible with each other.  This indicates
   that the role combination will never occur, and therefore conflicts
   will never occur.  In some cases the technology itself might identify
   incompatible roles:  "Ethernet" and "FrameRelay", for example.  But
   for less precise terms like "Campus" and "WAN", the policy
   administrator must say whether they identify incompatible roles.

   When the policy administrator does this, there are three effects:

   1. If an interface has assigned to it a role-combination involving
      both "Campus" and "WAN", then the policy management system can
      flag it as an error.

   2. If a policy rule is associated with a role-combination involving
      both "Campus" and "WAN", then the policy management system can
      flag it as an error.

   3. If the policy management system sees two policy rules, where one
      is tied to the role "Campus" (or to a role-combination that
      includes the role "Campus") and the other is tied to the role
      "WAN" (or to a role- combination that includes the role "WAN"),
      then the system does not need to look for conflicts between the
      two policy rules:  because of the incompatible roles, the two
      rules cannot possibly conflict.
Top   ToC   RFC3060 - Page 20
                        | Policy Repository |
                                  V retrieval of policy
                             | PDP/PEP |
                                  v application of policy
                          | Network Entity |

             Figure 4.    Retrieval and Application of a Policy

      Figure 4, which is introduced only as an example of how the Policy
      Framework might be implemented by a collection of network
      components, illustrates how roles operate within the Policy
      Framework.  Because the distinction between them is not important
      to this discussion, the PDP and the PEP are combined in one box.
      The points illustrated here apply equally well, though, to an
      environment where the PDP and the PEP are implemented separately.

      A role represents a functional characteristic or capability of a
      resource to which policies are applied.  Examples of roles include
      Backbone interface, Frame Relay interface, BGP-capable router, web
      server, firewall, etc.  The multiple roles assigned to a single
      resource are combined to form that resource's role combination.
      Role combinations are represented in the PCIM by values of the
      PolicyRoles property in the PolicyRule class.  A PDP uses policy
      roles as follows to identify the policies it needs to be aware of:

      1. The PDP learns in some way the list of roles that its PEPs
         play.  This information might be configured at the PDP, the
         PEPs might supply it to the PDP, or the PDP might retrieve it
         from a repository.

      2. Using repository-specific means, the PDP determines where to
         look for policy rules that might apply to it.

      3. Using the roles and role-combinations it received from its PEPs
         as indicated in the examples above, the PDP is able to locate
         and retrieve the policy rules that are relevant to it.
Top   ToC   RFC3060 - Page 21

5.2.2. The PolicyRoles Property

As indicated earlier, PolicyRoles is a property associated with a policy rule. It is an array holding "role combinations" for the policy rule, and correlates with the roles defined for a network resource. Using the PolicyRoles property, it is possible to mark a policy rule as applying, for example, to a Frame Relay interface or to a backbone ATM interface. The PolicyRoles property take strings of the form: <RoleName>[&&<RoleName>]* Each value of this property represents a role combination, including the special case of a "combination" containing only one role. As the format indicates, the role names in a role combination are ANDed together to form a single selector. The multiple values of the PolicyRoles property are logically ORed, to make it possible for a policy rule to have multiple selectors. The individual role names in a role combination must appear in alphabetical order (according to the collating sequence for UCS-2 characters), to make the string matches work correctly. The role names used in an environment are specified by the policy administrator.

5.3. Local Time and UTC Time in PolicyTimePeriodConditions

An instance of PolicyTimePeriodCondition has up to five properties that represent times: TimePeriod, MonthOfYearMask, DayOfMonthMask, DayOfWeekMask, and TimeOfDayMask. All of the time-related properties in an instance of PolicyTimePeriodCondition represent one of two types of times: local time at the place where a policy rule is applied, or UTC time. The property LocalOrUtcTime indicates which time representation applies to an instance of PolicyTimePeriodCondition. Since the PCIM provides only for local time and UTC time, a Policy Management Tool that provides for other time representations (for example, a fixed time at a particular location) will need to map from these other representations to either local time or UTC time. An example will illustrate the nature of this mapping. Suppose a policy rule is tied to the hours of operation for a Help Desk: 0800 to 2000 Monday through Friday [US] Eastern Time. In order to express these times in PolicyTimePeriodCondition, a management tool must convert them to UTC times. (They are not local times, because they refer to a single time interval worldwide, not to intervals tied to the local clocks at the locations where the
Top   ToC   RFC3060 - Page 22
   PolicyRule is being applied.)  As reference [10] points out, mapping
   from [US] Eastern Time to UTC time is not simply a matter of applying
   an offset:  the offset between [US] Eastern Time and UTC time
   switches between -0500 and -0400 depending on whether Daylight
   Savings Time is in effect in the US.

   Suppose the policy administrator's goal is to have a policy rule be
   valid from 0800 until 1200 [US] Eastern Time on every Monday, within
   the overall time period from the beginning of 2000 until the end of
   2001.  The Policy Management Tool could either be configured with the
   definition of what [US] Eastern Time means, or it could be configured
   with knowledge of where to go to get this information.  Reference
   [10] contains further discussion of time zone definitions and where
   they might reside.

   Armed with knowledge about [US] Eastern Time, the Policy Management
   Tool would create however many instances of PolicyTimePeriodCondition
   it needed to represent the desired intervals.  Note that while there
   is an increased number of PolicyTimePeriodCondition instances, there
   is still just one PolicyRule, which is tied to all the
   PolicyTimePeriodCondition instances via the aggregation
   PolicyRuleValidityPeriod.  Here are the first two of these instances:

         1. TimePeriod:  20000101T050000/20000402T070000
            DayOfWeekMask:  { Monday }
            TimeOfDayMask:  T130000/T170000
            LocalOrUtcTime:  UTC

         2. TimePeriod:  20000402T070000/20001029T070000
            DayOfWeekMask:  { Monday }
            TimeOfDayMask:  T120000/T160000
            LocalOrUtcTime:  UTC

   There would be three more similar instances, for winter 2000-2001,
   summer 2001, and winter 2001 up through December 31.

   Had the example been chosen differently, there could have been even
   more instances of PolicyTimePeriodCondition.  If, for example, the

   time interval had been from 0800 - 2200 [US] Eastern Time on Mondays,
   instance 1 above would have split into two instances:  one with a UTC
   time interval of T130000/T240000 on Mondays, and another with a UTC
   time interval of T000000/T030000 on Tuesdays.  So the end result
   would have been ten instances of PolicyTimePeriodCondition, not five.

   By restricting PolicyTimePeriodCondition to local time and UTC time,
   the PCIM places the difficult and expensive task of mapping from
   "human" time representations to machine-friendly ones in the Policy
Top   ToC   RFC3060 - Page 23
   Management Tool.  Another approach would have been to place in
   PolicyTimePeriodCondition a means of representing a named time zone,
   such as [US] Eastern Time.  This, however, would have passed the
   difficult mapping responsibility down to the PDPs and PEPs.  It is
   better to have a mapping such as the one described above done once in
   a Policy Management Tool, rather than having it done over and over in
   each of the PDPs (and possibly PEPs) that need to apply a PolicyRule.

5.4. CIM Data Types

Since PCIM extends the CIM Schema, a correspondence between data types used in both CIM and PCIM is needed. The following CIM data types are used in the class definitions that follow in Sections 6 and 7: o uint8 unsigned 8-bit integer o uint16 unsigned 16-bit integer o boolean Boolean o string UCS-2 string. Strings in CIM are stored as UCS-2 characters, where each character is encoded in two octets. Thus string values may need to be converted when moving between a CIM environment and one that uses a different string encoding. For example, in an LDAP-accessible directory, attributes of type DirectoryString are stored in UTF-8 format. RFC 2279 [7] explains how to convert between these two formats. When it is applied to a CIM string, a MaxLen value refers to the maximum number of characters in the string, rather than to the maximum number of octets. In addition to the CIM data types listed above, the association classes in Section 7 use the following type: o <classname> ref strongly typed reference. There is one obvious omission from this list of CIM data types: octet strings. This is because CIM treats octet strings as a derived data type. There are two forms of octet strings in CIM - an ordered uint8 array for single-valued strings, and a string array for multi- valued properties. Both are described by adding an "OctetString" qualifier (meta-data) to the property. This qualifier functions exactly like an SMIv2 (SNMP) Textual Convention, refining the syntax and semantics of the existing CIM data type.
Top   ToC   RFC3060 - Page 24
   The first four numeric elements of both of the "OctetString"
   representations are a length field.  (The reason that the "numeric"
   adjective is added to the previous sentence is that the string
   property also includes '0' and 'x', as its first characters.)  In
   both cases, these 4 numeric elements (octets) are included in
   calculating the length.  For example, a single-valued octet string
   property having the value X'7C' would be represented by the uint8
   array, X'00 00 00 05 7C'.

   The strings representing the individual values of a multi-valued
   property qualified with the "OctetString" qualifier are constructed

   1. Take a value to be encoded as an octet string (we'll use X'7C' as
      above), and prepend to it a four-octet length.  The result is the
      same, X'00 00 00 05 7C'.

   2. Convert this to a character string by introducing '0' and 'x' at
      the front, and removing all white space.  Thus we have the 12-
      character string "0x000000057C".  This string is the value of one
      of the array elements in the CIM string array.  Since CIM uses the
      UCS-2 character set, it will require 24 octets to encode this 12-
      character string.

   Mappings of the PCIM to particular data models are not required to
   follow this CIM technique of representing multi-valued octet strings
   as length- prefixed character strings.  In an LDAP mapping, for
   example, it would be much more natural to simply use the Octet String
   syntax, and omit the prepended length octets.

5.5. Comparison between CIM and LDAP Class Specifications

There are a number of differences between CIM and LDAP class specifications. The ones that are relevant to the abbreviated class specifications in this document are listed below. These items are included here to help introduce the IETF community, which is already familiar with LDAP, to CIM modeling, and by extension, to information modeling in general. o Instead of LDAP's three class types (abstract, auxiliary, structural), CIM has only two: abstract and instantiable. The type of a CIM class is indicated by the Boolean qualifier ABSTRACT. o CIM uses the term "property" for what LDAP terms an "attribute".
Top   ToC   RFC3060 - Page 25
   o  CIM uses the array notation "[ ]" to indicate that a property is
      multi-valued.  CIM defines three types of arrays: bags (contents
      are unordered, duplicates allowed), ordered bags (contents are
      ordered but duplicates are allowed) and indexed arrays (contents
      are ordered and no duplicates are allowed).

   o  CIM classes and properties are identified by name, not by OID.

   o  CIM classes use a different naming scheme for native
      implementations, than LDAP.  The CIM naming scheme is documented
      in Appendix A since it is not critical to understanding the
      information model, and only applies when communicating with a
      native CIM implementation.

   o  In LDAP, attribute definitions are global, and the same attribute
      may appear in multiple classes.  In CIM, a property is defined
      within the scope of a single class definition.  The property may
      be inherited into subclasses of the class in which it is defined,
      but otherwise it cannot appear in other classes.  One side effect
      of this difference is that CIM property names tend to be much
      shorter than LDAP attribute names, since they are implicitly
      scoped by the name of the class in which they are defined.

   There is also a notational convention that this document follows, to
   improve readability.  In CIM, all class and property names are
   prefixed with the characters "CIM_".  These prefixes have been
   omitted throughout this document, with one exception regarding
   naming, documented in Appendix A.

   For the complete definition of the CIM specification language, see
   reference [2].

(page 25 continued on part 3)

Next Section