tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 3060


Policy Core Information Model -- Version 1 Specification

Part 2 of 5, p. 10 to 25
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 10 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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)

   Figure 2.    Inheritance Hierarchy for the Core Policy Classes

Top      Up      ToC       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      Up      ToC       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

   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      Up      ToC       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      Up      ToC       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

   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-

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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:


   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

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

   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      Up      ToC       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      Up      ToC       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

   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

   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      Up      ToC       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

   o  CIM uses the term "property" for what LDAP terms an "attribute".

Top      Up      ToC       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 RFC Part