tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3060

 
 
 

Policy Core Information Model -- Version 1 Specification

Part 3 of 5, p. 25 to 46
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 25 
6. Class Definitions

   The following sections contain the definitions of the PCIM classes.

6.1. The Abstract Class "Policy"

   The abstract class Policy collects several properties that may be
   included in instances of any of the Core Policy classes (or their
   subclasses).  For convenience, the two properties that Policy
   inherits from ManagedElement in the CIM schema are shown here as
   well.

Top      Up      ToC       Page 26 
   The class definition is as follows:

      NAME             Policy
      DESCRIPTION      An abstract class with four properties for
                       describing a policy-related instance.
      DERIVED FROM     ManagedElement
      ABSTRACT         TRUE
      PROPERTIES       CommonName (CN)
                       PolicyKeywords[ ]
                              // Caption (inherited)
                              // Description (inherited)

6.1.1. The Property "CommonName (CN)"

   The CN, or CommonName, property corresponds to the X.500 attribute
   commonName (cn).  In X.500 this property specifies one or more user-
   friendly names (typically only one name) by which an object is
   commonly known, names that conform to the naming conventions of the
   country or culture with which the object is associated.  In the CIM
   model, however, the CommonName property is single-valued.

      NAME             CN
      DESCRIPTION      A user-friendly name of a policy-related object.
      SYNTAX           string

6.1.2. The Multi-valued Property "PolicyKeywords"

   This property provides a set of one or more keywords that a policy
   administrator may use to assist in characterizing or categorizing a
   policy object.  Keywords are of one of two types:

   o  Keywords defined in this document, or in documents that define
      subclasses of the classes defined in this document.  These
      keywords provide a vendor-independent, installation-independent
      way of characterizing policy objects.

   o  Installation-dependent keywords for characterizing policy objects.
      Examples include "Engineering", "Billing", and "Review in December
      2000".

   This document defines the following keywords:  "UNKNOWN",
   "CONFIGURATION", "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL",
   "INSTALLATION", and "EVENT".  These concepts were defined earlier in
   Section 2.

Top      Up      ToC       Page 27 
   One additional keyword is defined:  "POLICY".  The role of this
   keyword is to identify policy-related instances that would not
   otherwise be identifiable as being related to policy.  It may be
   needed in some repository implementations.

   Documents that define subclasses of the Policy Core Information Model
   classes SHOULD define additional keywords to characterize instances
   of these subclasses.  By convention, keywords defined in conjunction
   with class definitions are in uppercase.  Installation-defined
   keywords can be in any case.

   The property definition is as follows:

   NAME             PolicyKeywords
   DESCRIPTION      A set of keywords for characterizing /categorizing
                    policy objects.
   SYNTAX           string

6.1.3. The Property "Caption" (Inherited from ManagedElement)

   This property provides a one-line description of a policy-related
   object.

   NAME             Caption
   DESCRIPTION      A one-line description of this policy-related object.
   SYNTAX           string

6.1.4. The Property "Description" (Inherited from ManagedElement)

   This property provides a longer description than that provided by the
   caption property.

   NAME             Description
   DESCRIPTION      A long description of this policy-related object.
   SYNTAX           string

6.2. The Class "PolicyGroup"

   This class is a generalized aggregation container.  It enables either
   PolicyRules or PolicyGroups to be aggregated in a single container.
   Loops, including the degenerate case of a PolicyGroup that contains
   itself, are not allowed when PolicyGroups contain other PolicyGroups.

   PolicyGroups and their nesting capabilities are shown in Figure 5
   below.  Note that a PolicyGroup can nest other PolicyGroups, and
   there is no restriction on the depth of the nesting in sibling
   PolicyGroups.

Top      Up      ToC       Page 28 
         +---------------------------------------------------+
         |                    PolicyGroup                    |
         |                                                   |
         | +--------------------+       +-----------------+  |
         | |    PolicyGroup A   |       |  PolicyGroup X  |  |
         | |                    |       |                 |  |
         | | +----------------+ |  ooo  |                 |  |
         | | | PolicyGroup A1 | |       |                 |  |
         | | +----------------+ |       |                 |  |
         | +--------------------+       +-----------------+  |
         +---------------------------------------------------+

            Figure 5.    Overview of the PolicyGroup class

   As a simple example, think of the highest level PolicyGroup shown in
   Figure 5 above as a logon policy for US employees of a company.  This
   PolicyGroup may be called USEmployeeLogonPolicy, and may aggregate
   several PolicyGroups that provide specialized rules per location.
   Hence, PolicyGroup A in Figure 5 above may define logon rules for
   employees on the West Coast, while another PolicyGroup might define
   logon rules for the Midwest (e.g., PolicyGroup X), and so forth.

   Note also that the depth of each PolicyGroup does not need to be the
   same.  Thus, the WestCoast PolicyGroup might have several additional
   layers of PolicyGroups defined for any of several reasons (different
   locales, number of subnets, etc..).  The PolicyRules are therefore
   contained at n levels from the USEmployeeLogonPolicyGroup.  Compare
   this to the Midwest PolicyGroup (PolicyGroup X), which might directly
   contain PolicyRules.

   The class definition for PolicyGroup is as follows:

      NAME             PolicyGroup
      DESCRIPTION      A container for either a set of related
                       PolicyRules or a set of related PolicyGroups.
      DERIVED FROM     Policy
      ABSTRACT         FALSE
      PROPERTIES       NONE

   No properties are defined for this class since it inherits all its
   properties from Policy.  The class exists to aggregate PolicyRules or
   other PolicyGroups.  It is directly instantiable.  In an
   implementation, various key/identification properties MUST be
   defined.  The keys for a native CIM implementation are defined in
   Appendix A, Section 13.1.1.  Keys for an LDAP implementation will be
   defined in the LDAP mapping of this information model [11].

Top      Up      ToC       Page 29 
6.3. The Class "PolicyRule"

   This class represents the "If Condition then Action" semantics
   associated with a policy.  A PolicyRule condition, in the most
   general sense, is represented as either an ORed set of ANDed
   conditions (Disjunctive Normal Form, or DNF) or an ANDed set of ORed
   conditions (Conjunctive Normal Form, or CNF).  Individual conditions
   may either be negated (NOT C) or unnegated (C).  The actions
   specified by a PolicyRule are to be performed if and only if the
   PolicyRule condition (whether it is represented in DNF or CNF)
   evaluates to TRUE.

   The conditions and actions associated with a policy rule are modeled,
   respectively, with subclasses of the classes PolicyCondition and
   PolicyAction.  These condition and action objects are tied to
   instances of PolicyRule by the PolicyConditionInPolicyRule and
   PolicyActionInPolicyRule aggregations.

   As illustrated above in Section 3, a policy rule may also be
   associated with one or more policy time periods, indicating the
   schedule according to which the policy rule is active and inactive.
   In this case it is the PolicyRuleValidityPeriod aggregation that
   provides the linkage.

   A policy rule is illustrated conceptually in Figure 6. below.

            +------------------------------------------------+
            |                    PolicyRule                  |
            |                                                |
            | +--------------------+     +-----------------+ |
            | | PolicyCondition(s) |     | PolicyAction(s) | |
            | +--------------------+     +-----------------+ |
            |                                                |
            |        +------------------------------+        |
            |        | PolicyTimePeriodCondition(s) |        |
            |        +------------------------------+        |
            +------------------------------------------------+

              Figure 6.    Overview of the PolicyRule Class

   The PolicyRule class uses the property ConditionListType, to indicate
   whether the conditions for the rule are in DNF or CNF.  The
   PolicyConditionInPolicyRule aggregation contains two additional
   properties to complete the representation of the rule's conditional
   expression.  The first of these properties is an integer to partition
   the referenced conditions into one or more groups, and the second is
   a Boolean to indicate whether a referenced condition is negated.  An

Top      Up      ToC       Page 30 
   example shows how ConditionListType and these two additional
   properties provide a unique representation of a set of conditions in
   either DNF or CNF.

   Suppose we have a PolicyRule that aggregates five PolicyConditions C1
   through C5, with the following values in the properties of the five
   PolicyConditionInPolicyRule associations:

      C1:  GroupNumber = 1, ConditionNegated = FALSE
      C2:  GroupNumber = 1, ConditionNegated = TRUE
      C3:  GroupNumber = 1, ConditionNegated = FALSE
      C4:  GroupNumber = 2, ConditionNegated = FALSE
      C5:  GroupNumber = 2, ConditionNegated = FALSE

   If ConditionListType = DNF, then the overall condition for the
   PolicyRule is:

      (C1 AND (NOT C2) AND C3) OR (C4 AND C5)

   On the other hand, if ConditionListType = CNF, then the overall
   condition for the PolicyRule is:

      (C1 OR (NOT C2) OR C3) AND (C4 OR C5)

   In both cases, there is an unambiguous specification of the overall
   condition that is tested to determine whether to perform the actions
   associated with the PolicyRule.

   The class definition is as follows:

   NAME             PolicyRule
   DESCRIPTION      The central class for representing the "If Condition
                    then Action" semantics associated with a policy rule.
   DERIVED FROM     Policy
   ABSTRACT         FALSE
   PROPERTIES       Enabled
                    ConditionListType
                    RuleUsage
                    Priority
                    Mandatory
                    SequencedActions
                    PolicyRoles

   The PolicyRule class is directly instantiable.  In an implementation,
   various key/identification properties MUST be defined.  The keys for
   a native CIM implementation are defined in Appendix A, Section
   13.1.2.  Keys for an LDAP implementation will be defined in the LDAP
   mapping of this information model [11].

Top      Up      ToC       Page 31 
6.3.1. The Property "Enabled"

   This property indicates whether a policy rule is currently enabled,
   from an administrative point of view.  Its purpose is to allow a
   policy administrator to enable or disable a policy rule without
   having to add it to, or remove it from, the policy repository.

   The property also supports the value 'enabledForDebug'.  When the
   property has this value, the entity evaluating the policy
   condition(s) is being told to evaluate the conditions for the policy
   rule, but not to perform the actions if the conditions evaluate to
   TRUE.  This value serves as a debug vehicle when attempting to
   determine what policies would execute in a particular scenario,
   without taking any actions to change state during the debugging.

   The property definition is as follows:

   NAME             Enabled
   DESCRIPTION      An enumeration indicating whether a policy rule is
                    administratively enabled, administratively disabled,
                    or enabled for debug mode.
   SYNTAX           uint16
   VALUES           enabled(1), disabled(2), enabledForDebug(3)
   DEFAULT VALUE    enabled(1)

6.3.2. The Property "ConditionListType"

   This property is used to specify whether the list of policy
   conditions associated with this policy rule is in disjunctive normal
   form (DNF) or conjunctive normal form (CNF).  If this property is not
   present, the list type defaults to DNF.  The property definition is
   as follows:

   NAME             ConditionListType
   DESCRIPTION      Indicates whether the list of policy conditions
                    associated with this policy rule is in disjunctive
                    normal form (DNF) or conjunctive normal form (CNF).
   SYNTAX           uint16
   VALUES           DNF(1), CNF(2)
   DEFAULT VALUE    DNF(1)

6.3.3. The Property "RuleUsage"

   This property is a free-form string that recommends how this policy
   should be used.  The property definition is as follows:

Top      Up      ToC       Page 32 
      NAME             RuleUsage
      DESCRIPTION      This property is used to provide guidelines on
                       how this policy should be used.
      SYNTAX           string

6.3.4. The Property "Priority"

   This property provides a non-negative integer for prioritizing policy
   rules relative to each other.  Larger integer values indicate higher
   priority.  Since one purpose of this property is to allow specific,
   ad hoc policy rules to temporarily override established policy rules,
   an instance that has this property set has a higher priority than all
   instances that use or set the default value of zero.

   Prioritization among policy rules provides a basic mechanism for
   resolving policy conflicts.

   The property definition is as follows:

   NAME             Priority
   DESCRIPTION      A non-negative integer for prioritizing this
                    PolicyRule relative to other PolicyRules.  A larger
                    value indicates a higher priority.
   SYNTAX           uint16
   DEFAULT VALUE    0

6.3.5. The Property "Mandatory"

   This property indicates whether evaluation (and possibly action
   execution) of a PolicyRule is mandatory or not.  Its concept is
   similar to the ability to mark packets for delivery or possible
   discard, based on network traffic and device load.

   The evaluation of a PolicyRule MUST be attempted if the Mandatory
   property value is TRUE.  If the Mandatory property value of a
   PolicyRule is FALSE, then the evaluation of the rule is "best effort"
   and MAY be ignored.

   The property definition is as follows:

      NAME             Mandatory
      DESCRIPTION      A flag indicating that the evaluation of the
                       PolicyConditions and execution of PolicyActions
                       (if the condition list evaluates to TRUE) is
                       required.
      SYNTAX           boolean
      DEFAULT VALUE    TRUE

Top      Up      ToC       Page 33 
6.3.6. The Property "SequencedActions"

   This property gives a policy administrator a way of specifying how
   the ordering of the policy actions associated with this PolicyRule is
   to be interpreted.  Three values are supported:

   o  mandatory(1):   Do the actions in the indicated order, or don't do
      them at all.

   o  recommended(2): Do the actions in the indicated order if you can,
      but if you can't do them in this order, do them in another order
      if you can.

   o  dontCare(3):    Do them -- I don't care about the order.

   When error / event reporting is addressed for the Policy Framework,
   suitable codes will be defined for reporting that a set of actions
   could not be performed in an order specified as mandatory (and thus
   were not performed at all), that a set of actions could not be
   performed in a recommended order (and moreover could not be performed
   in any order), or that a set of actions could not be performed in a
   recommended order (but were performed in a different order).  The
   property definition is as follows:

      NAME             SequencedActions
      DESCRIPTION      An enumeration indicating how to interpret the
                       action ordering indicated via the
                       PolicyActionInPolicyRule aggregation.
      SYNTAX           uint16
      VALUES           mandatory(1), recommended(2), dontCare(3)
      DEFAULT VALUE    dontCare(3)

6.3.7. The Multi-valued Property "PolicyRoles"

   This property represents the roles and role combinations associated
   with a policy rule.  Each value represents one role combination.
   Since this is a multi-valued property, more than one role combination
   can be associated with a single policy rule.  Each value is a string
   of the form

      <RoleName>[&&<RoleName>]*

   where the individual role names appear in alphabetical order
   (according to the collating sequence for UCS-2).  The property
   definition is as follows:

Top      Up      ToC       Page 34 
      NAME             PolicyRoles
      DESCRIPTION      A set of strings representing the roles and role
                       combinations associated with a policy rule.  Each
                       value represents one role combination.
      SYNTAX           string

6.4. The Abstract Class "PolicyCondition"

   The purpose of a policy condition is to determine whether or not the
   set of actions (aggregated in the PolicyRule that the condition
   applies to) should be executed or not.  For the purposes of the
   Policy  Core Information Model, all that matters about an individual
   PolicyCondition is that it evaluates to TRUE or FALSE.  (The
   individual PolicyConditions associated with a PolicyRule are combined
   to form a compound expression in either DNF or CNF, but this is
   accomplished via the ConditionListType property, discussed above, and
   by the properties of the PolicyConditionInPolicyRule aggregation,
   introduced above and discussed further in Section 7.6 below.)  A
   logical structure within an individual PolicyCondition may also be
   introduced, but this would have to be done in a subclass of
   PolicyCondition.

   Because it is general, the PolicyCondition class does not itself
   contain any "real" conditions.  These will be represented by
   properties of the domain-specific subclasses of PolicyCondition.

      +---------------------------------------------------------------+
      |                    Policy Conditions in DNF                   |
      | +-------------------------+         +-----------------------+ |
      | |       AND list          |         |      AND list         | |
      | |  +-------------------+  |         |  +-----------------+  | |
      | |  |  PolicyCondition  |  |         |  | PolicyCondition |  | |
      | |  +-------------------+  |         |  +-----------------+  | |
      | |  +-------------------+  |         |  +-----------------+  | |
      | |  |  PolicyCondition  |  |   ...   |  | PolicyCondition |  | |
      | |  +-------------------+  |   ORed  |  +-----------------+  | |
      | |          ...            |         |         ...           | |
      | |         ANDed           |         |        ANDed          | |
      | |  +-------------------+  |         |  +-----------------+  | |
      | |  |  PolicyCondition  |  |         |  | PolicyCondition |  | |
      | |  +-------------------+  |         |  +-----------------+  | |
      | +-------------------------+         +-----------------------+ |
      +---------------------------------------------------------------+

             Figure 7.    Overview of Policy Conditions in DNF

Top      Up      ToC       Page 35 
   This figure illustrates that when policy conditions are in DNF, there
   are one or more sets of conditions that are ANDed together to form
   AND lists.  An AND list evaluates to TRUE if and only if all of its
   constituent conditions evaluate to TRUE.  The overall condition then
   evaluates to TRUE if and only if at least one of its constituent AND
   lists evaluates to TRUE.

      +---------------------------------------------------------------+
      |                    Policy Conditions in CNF                   |
      | +-------------------------+         +-----------------------+ |
      | |        OR list          |         |       OR list         | |
      | |  +-------------------+  |         |  +-----------------+  | |
      | |  |  PolicyCondition  |  |         |  | PolicyCondition |  | |
      | |  +-------------------+  |         |  +-----------------+  | |
      | |  +-------------------+  |         |  +-----------------+  | |
      | |  |  PolicyCondition  |  |   ...   |  | PolicyCondition |  | |
      | |  +-------------------+  |  ANDed  |  +-----------------+  | |
      | |          ...            |         |         ...           | |
      | |         ORed            |         |         ORed          | |
      | |  +-------------------+  |         |  +-----------------+  | |
      | |  |  PolicyCondition  |  |         |  | PolicyCondition |  | |
      | |  +-------------------+  |         |  +-----------------+  | |
      | +-------------------------+         +-----------------------+ |
      +---------------------------------------------------------------+

             Figure 8.    Overview of Policy Conditions in CNF

   In this figure, the policy conditions are in CNF.  Consequently,
   there are one or more OR lists, each of which evaluates to TRUE if
   and only if at least one of its constituent conditions evaluates to
   TRUE.  The overall condition then evaluates to TRUE if and only if
   ALL of its constituent OR lists evaluate to TRUE.

   The class definition of PolicyCondition is as follows:

      NAME             PolicyCondition
      DESCRIPTION      A class representing a rule-specific or reusable
                       policy condition to be evaluated in conjunction
                       with a policy rule.
      DERIVED FROM     Policy
      ABSTRACT         TRUE
      PROPERTIES       NONE

   No properties are defined for this class since it inherits all its
   properties from Policy.  The class exists as an abstract superclass
   for domain-specific policy conditions, defined in subclasses.  In an
   implementation, various key/identification properties MUST be defined
   for the class or its instantiable subclasses.  The keys for a native

Top      Up      ToC       Page 36 
   CIM implementation are defined in Appendix A, Section 13.2.  Keys for
   an LDAP implementation will be defined in the LDAP mapping of this
   information model [11].

   When identifying and using the PolicyCondition class, it is necessary
   to remember that a condition can be rule-specific or reusable.  This
   was discussed above in Section 5.1.  The distinction between the two
   types of policy conditions lies in the associations in which an
   instance can participate, and in how the different instances are
   named.  Conceptually, a reusable policy condition resides in a policy
   repository, and is named within the scope of that repository.  On the
   other hand, a rule-specific policy condition is, as the name
   suggests, named within the scope of the single policy rule to which
   it is related.

   The distinction between rule-specific and reusable PolicyConditions
   affects the CIM naming, defined in Appendix A, and the LDAP mapping
   [11].

6.5. The Class "PolicyTimePeriodCondition"

   This class provides a means of representing the time periods during
   which a policy rule is valid, i.e., active.  At all times that fall
   outside these time periods, the policy rule has no effect.  A policy
   rule is treated as valid at all times if it does not specify a
   PolicyTimePeriodCondition.

   In some cases a PDP may need to perform certain setup / cleanup
   actions when a policy rule becomes active / inactive.  For example,
   sessions that were established while a policy rule was active might
   need to be taken down when the rule becomes inactive.  In other
   cases, however, such sessions might be left up:  in this case, the
   effect of deactivating the policy rule would just be to prevent the
   establishment of new sessions.  Setup / cleanup behaviors on validity
   period transitions are not currently addressed by the PCIM, and must
   be specified in 'guideline' documents, or via subclasses of
   PolicyRule, PolicyTimePeriodCondition or other concrete subclasses of
   Policy.  If such behaviors need to be under the control of the policy
   administrator, then a mechanism to allow this control must also be
   specified in the subclass.

   PolicyTimePeriodCondition is defined as a subclass of
   PolicyCondition.  This is to allow the inclusion of time-based
   criteria in the AND/OR condition definitions for a PolicyRule.

   Instances of this class may have up to five properties identifying
   time periods at different levels.  The values of all the properties
   present in an instance are ANDed together to determine the validity

Top      Up      ToC       Page 37 
   period(s) for the instance.  For example, an instance with an overall
   validity range of January 1, 2000 through December 31, 2000; a month
   mask that selects March and April; a day-of-the-week mask that
   selects Fridays; and a time of day range of 0800 through 1600 would
   represent the following time periods:

      Friday, March  5, 2000, from 0800 through 1600;
      Friday, March 12, 2000, from 0800 through 1600;
      Friday, March 19, 2000, from 0800 through 1600;
      Friday, March 26, 2000, from 0800 through 1600;
      Friday, April  2, 2000, from 0800 through 1600;
      Friday, April  9, 2000, from 0800 through 1600;
      Friday, April 16, 2000, from 0800 through 1600;
      Friday, April 23, 2000, from 0800 through 1600;
      Friday, April 30, 2000, from 0800 through 1600.

   Properties not present in an instance of PolicyTimePeriodCondition
   are implicitly treated as having their value "always enabled".  Thus,
   in the example above, the day-of-the-month mask is not present, and
   so the validity period for the instance implicitly includes a day-
   of-the-month mask that selects all days of the month.  If we apply
   this "missing property" rule to its fullest, we see that there is a
   second way to indicate that a policy rule is always enabled: have it
   point to an instance of PolicyTimePeriodCondition whose only
   properties are its naming properties.

   The property LocalOrUtcTime indicates whether the times represented
   in the other five time-related properties of an instance of
   PolicyTimePeriodCondition are to be interpreted as local times for
   the location where a policy rule is being applied, or as UTC times.

   The class definition is as follows.

   NAME             PolicyTimePeriodCondition
   DESCRIPTION      A class that provides the capability of enabling /
                    disabling a policy rule according to a
                    pre-determined schedule.
   DERIVED FROM     PolicyCondition
   ABSTRACT         FALSE
   PROPERTIES       TimePeriod
                    MonthOfYearMask
                    DayOfMonthMask
                    DayOfWeekMask
                    TimeOfDayMask
                    LocalOrUtcTime

Top      Up      ToC       Page 38 
6.5.1. The Property "TimePeriod"

   This property identifies an overall range of calendar dates and times
   over which a policy rule is valid.  It reuses the format for an
   explicit time period defined in RFC 2445 (reference [10]): a string
   representing a starting date and time, in which the character 'T'
   indicates the beginning of the time portion, followed by the solidus
   character '/', followed by a similar string representing an end date
   and time.  The first date indicates the beginning of the range, while
   the second date indicates the end.  Thus, the second date and time
   must be later than the first.  Date/times are expressed as substrings
   of the form "yyyymmddThhmmss".  For example:

      20000101T080000/20000131T120000

         January 1, 2000, 0800 through January 31, 2000, noon

   There are also two special cases in which one of the date/time
   strings is replaced with a special string defined in RFC 2445.

   o  If the first date/time is replaced with the string "THISANDPRIOR",
      then the property indicates that a policy rule is valid [from now]
      until the date/time that appears after the '/'.

   o  If the second date/time is replaced with the string
      "THISANDFUTURE", then the property indicates that a policy rule
      becomes valid on the date/time that appears before the '/', and
      remains valid from that point on.

   Note that RFC 2445 does not use these two strings in connection with
   explicit time periods.  Thus the PCIM is combining two elements from
   RFC 2445 that are not combined in the RFC itself.

   The property definition is as follows:

      NAME             TimePeriod
      DESCRIPTION      The range of calendar dates on which a policy
                       rule is valid.
      SYNTAX           string
      FORMAT           yyyymmddThhmmss/yyyymmddThhmmss, where the first
                       date/time may be replaced with the string
                       "THISANDPRIOR" or the second date/time may be
                       replaced with the string "THISANDFUTURE"

Top      Up      ToC       Page 39 
6.5.2. The Property "MonthOfYearMask"

   The purpose of this property is to refine the definition of the valid
   time period that is defined by the TimePeriod property, by explicitly
   specifying the months when the policy is valid.  These properties
   work together, with the TimePeriod used to specify the overall time
   period during which the policy might be valid, and the
   MonthOfYearMask used to pick out the specific months within that time
   period when the policy is valid.

   This property is formatted as an octet string of size 2, consisting
   of 12 bits identifying the 12 months of the year, beginning with
   January and ending with December, followed by 4 bits that are always
   set to '0'.  For each month, the value '1' indicates that the policy
   is valid for that month, and the value '0' indicates that it is not
   valid.  The value X'08 30', for example, indicates that a policy rule
   is valid only in the months May, November, and December.

   See section 5.4 for details of how CIM represents a single-valued
   octet string property such as this one.  (Basically, CIM prepends a
   4-octet length to the octet string.)

   If this property is omitted, then the policy rule is treated as valid
   for all twelve months.  The property definition is as follows:

      NAME             MonthOfYearMask
      DESCRIPTION      A mask identifying the months of the year in
                       which a policy rule is valid.
      SYNTAX           octet string
      FORMAT           X'hh h0'

6.5.3. The Property "DayOfMonthMask"

   The purpose of this property is to refine the definition of the valid
   time period that is defined by the TimePeriod property, by explicitly
   specifying the days of the month when the policy is valid.  These
   properties work together, with the TimePeriod used to specify the
   overall time period during which the policy might be valid, and the
   DayOfMonthMask used to pick out the specific days of the month within
   that time period when the policy is valid.

   This property is formatted as an octet string of size 8, consisting
   of 31 bits identifying the days of the month counting from the
   beginning, followed by 31 more bits identifying the days of the month
   counting from the end, followed by 2 bits that are always set to '0'.
   For each day, the value '1' indicates that the policy is valid for
   that day, and the value '0' indicates that it is not valid.

Top      Up      ToC       Page 40 
   The value X'80 00 00 01 00 00 00 00', for example, indicates that a
   policy rule is valid on the first and last days of the month.

   For months with fewer than 31 days, the digits corresponding to days
   that the months do not have (counting in both directions) are
   ignored.

   The encoding of the 62 significant bits in the octet string matches
   that used for the schedDay object in the DISMAN-SCHEDULE-MIB.  See
   reference [8] for more details on this object.

   See section 5.4 for details of how CIM represents a single-valued
   octet string property such as this one.  (Basically, CIM prepends a
   4-octet length to the octet string.)

   The property definition is as follows:

      NAME             DayOfMonthMask
      DESCRIPTION      A mask identifying the days of the month on
                       which a policy rule is valid.
      SYNTAX           octet string
      FORMAT           X'hh hh hh hh hh hh hh hh'

6.5.4. The Property "DayOfWeekMask"

   The purpose of this property is to refine the definition of the valid
   time period that is defined by the TimePeriod property by explicitly
   specifying the days of the week when the policy is valid.  These
   properties work together, with the TimePeriod used to specify the
   overall time period when the policy might be valid, and the
   DayOfWeekMask used to pick out the specific days of the week in that
   time period when the policy is valid.

   This property is formatted as an octet string of size 1, consisting
   of 7 bits identifying the 7 days of the week, beginning with Sunday
   and ending with Saturday, followed by 1 bit that is always set to
   '0'.  For each day of the week, the value '1' indicates that the
   policy is valid for that day, and the value '0' indicates that it is
   not valid.

   The value X'7C', for example, indicates that a policy rule is valid
   Monday through Friday.

   See section 5.4 for details of how CIM represents a single-valued
   octet string property such as this one.  (Basically, CIM prepends a
   4-octet length to the octet string.)

Top      Up      ToC       Page 41 
   The property definition is as follows:

      NAME             DayOfWeekMask
      DESCRIPTION      A mask identifying the days of the week on which
                       a policy rule is valid.
      SYNTAX           octet string
      FORMAT           B'bbbb bbb0'

6.5.5. The Property "TimeOfDayMask"

   The purpose of this property is to refine the definition of the valid
   time period that is defined by the TimePeriod property by explicitly
   specifying a range of times in a day the policy is valid for.  These
   properties work together, with the TimePeriod used to specify the
   overall time period that the policy is valid for, and the
   TimeOfDayMask used to pick out which range of time periods in a given
   day of that time period the policy is valid for.

   This property is formatted in the style of RFC 2445 [10]:  a time
   string beginning with the character 'T', followed by the solidus
   character '/', followed by a second time string.  The first time
   indicates the beginning of the range, while the second time indicates
   the end.  Times are expressed as substrings of the form "Thhmmss".

   The second substring always identifies a later time than the first
   substring.  To allow for ranges that span midnight, however, the
   value of the second string may be smaller than the value of the first
   substring.  Thus, "T080000/T210000" identifies the range from 0800
   until 2100, while "T210000/T080000" identifies the range from 2100
   until 0800 of the following day.

   When a range spans midnight, it by definition includes parts of two
   successive days.  When one of these days is also selected by either
   the MonthOfYearMask, DayOfMonthMask, and/or DayOfWeekMask, but the
   other day is not, then the policy is active only during the portion
   of the range that falls on the selected day.  For example, if the
   range extends from 2100 until 0800, and the day of week mask selects
   Monday and Tuesday, then the policy is active during the following
   three intervals:

      From midnight Sunday until 0800 Monday;
      From 2100 Monday until 0800 Tuesday;
      From 2100 Tuesday until 23:59:59 Tuesday.

Top      Up      ToC       Page 42 
   The property definition is as follows:

      NAME             TimeOfDayMask
      DESCRIPTION      The range of times at which a policy rule is
                       valid.  If the second time is earlier than the
                       first, then the interval spans midnight.
      SYNTAX           string
      FORMAT           Thhmmss/Thhmmss

6.5.6. The Property "LocalOrUtcTime"

   This property indicates whether the times represented in the
   TimePeriod property and in the various Mask properties represent
   local times or UTC times.  There is no provision for mixing of local
   times and UTC times:  the value of this property applies to all of
   the other time-related properties.

   The property definition is as follows:

      NAME             LocalOrUtcTime
      DESCRIPTION      An indication of whether the other times in this
                       instance represent local times or UTC times.
      SYNTAX           uint16
      VALUES           localTime(1), utcTime(2)
      DEFAULT VALUE    utcTime(2)

6.6. The Class "VendorPolicyCondition"

   The purpose of this class is to provide a general extension mechanism
   for representing policy conditions that have not been modeled with
   specific properties.  Instead, the two properties Constraint and
   ConstraintEncoding are used to define the content and format of the
   condition, as explained below.

   As its name suggests, this class is intended for vendor-specific
   extensions to the Policy Core Information Model.  Standardized
   extensions are not expected to use this class.

   The class definition is as follows:

      NAME             VendorPolicyCondition
      DESCRIPTION      A class that defines a registered means to
                       describe a policy condition.
      DERIVED FROM     PolicyCondition
      ABSTRACT         FALSE
      PROPERTIES       Constraint[ ]
                       ConstraintEncoding

Top      Up      ToC       Page 43 
6.6.1. The Multi-valued Property "Constraint"

   This property provides a general extension mechanism for representing
   policy conditions that have not been modeled with specific
   properties.  The format of the octet strings in the array is left
   unspecified in this definition.  It is determined by the OID value
   stored in the property ConstraintEncoding.  Since ConstraintEncoding
   is single-valued, all the values of Constraint share the same format
   and semantics.

   See Section 5.4 for a description of how CIM encodes an array of
   octet strings like this one.

   A policy decision point can readily determine whether it supports the
   values stored in an instance of Constraint by checking the OID value
   from ConstraintEncoding against the set of OIDs it recognizes.  The
   action for the policy decision point to take in case it does not
   recognize the format of this data could itself be modeled as a policy
   rule, governing the behavior of the policy decision point.

   The property is defined as follows:

      NAME             Constraint
      DESCRIPTION      Extension mechanism for representing constraints
                       that have not been modeled as specific
                       properties.  The format of the values is
                       identified by the OID stored in the property
                       ConstraintEncoding.
      SYNTAX           octet string

6.6.2. The Property "ConstraintEncoding"

   This property identifies the encoding and semantics of the Constraint
   property values in this instance.  The value of this property is a
   single string, representing a single OID.

   The property is defined as follows:

      NAME             ConstraintEncoding
      DESCRIPTION      An OID encoded as a string, identifying the format
                       and semantics for this instance's Constraint
                       property.  The value is a dotted sequence of
                       decimal digits (for example, "1.2.100.200")
                       representing the arcs of the OID.  The characters
                       in the string are the UCS-2 characters
                       corresponding to the US ASCII encodings of the
                       numeric characters and the period.
      SYNTAX           string

Top      Up      ToC       Page 44 
6.7. The Abstract Class "PolicyAction"

   The purpose of a policy action is to execute one or more operations
   that will affect network traffic and/or systems, devices, etc., in
   order to achieve a desired state.  This (new) state provides one or
   more (new) behaviors.  A policy action ordinarily changes the
   configuration of one or more elements.

   A PolicyRule contains one or more policy actions.  A policy
   administrator can assign an order to the actions associated with a
   PolicyRule, complete with an indication of whether the indicated
   order is mandatory, recommended, or of no significance.  Ordering of
   the actions associated with a PolicyRule is accomplished via a
   property in the PolicyActionInPolicyRule aggregation.

   The actions associated with a PolicyRule are executed if and only if
   the overall condition(s) of the PolicyRule evaluates to TRUE.

   The class definition of PolicyAction is as follows:

      NAME             PolicyAction
      DESCRIPTION      A class representing a rule-specific or reusable
                       policy action to be performed if the condition for
                       a policy rule evaluates to TRUE.
      DERIVED FROM     Policy
      ABSTRACT         TRUE
      PROPERTIES       NONE

   No properties are defined for this class since it inherits all its
   properties from Policy.  The class exists as an abstract superclass
   for domain-specific policy actions, defined in subclasses.  In an
   implementation, various key/identification properties MUST be defined
   for the class or its instantiable subclasses.  The keys for a native
   CIM implementation are defined in Appendix A, Section 13.3.  Keys for
   an LDAP implementation will be defined in the LDAP mapping of this
   information model [11].

   When identifying and using the PolicyAction class, it is necessary to
   remember that an action can be rule-specific or reusable.  This was
   discussed above in Section 5.1.  The distinction between the two
   types of policy actions lies in the associations in which an instance
   can participate, and in how the different instances are named.
   Conceptually, a reusable policy action resides in a policy
   repository, and is named within the scope of that repository.  On the
   other hand, a rule-specific policy action is named within the scope
   of the single policy rule to which it is related.

Top      Up      ToC       Page 45 
   The distinction between rule-specific and reusable PolicyActions
   affects the CIM naming, defined in Appendix A, and the LDAP mapping
   [11].

6.8. The Class "VendorPolicyAction"

   The purpose of this class is to provide a general extension mechanism
   for representing policy actions that have not been modeled with
   specific properties.  Instead, the two properties ActionData and
   ActionEncoding are used to define the content and format of the
   action, as explained below.

   As its name suggests, this class is intended for vendor-specific
   extensions to the Policy Core Information Model.  Standardized
   extensions are not expected to use this class.

   The class definition is as follows:

      NAME             VendorPolicyAction
      DESCRIPTION      A class that defines a registered means to
                       describe a policy action.
      DERIVED FROM     PolicyAction
      ABSTRACT         FALSE
      PROPERTIES       ActionData[ ]
                       ActionEncoding

6.8.1. The Multi-valued Property "ActionData"

   This property provides a general extension mechanism for representing
   policy actions that have not been modeled with specific properties.
   The format of the octet strings in the array is left unspecified in
   this definition.  It is determined by the OID value stored in the
   property ActionEncoding.  Since ActionEncoding is single-valued, all
   the values of ActionData share the same format and semantics.  See
   Section 5.4 for a discussion of how CIM encodes an array of octet
   strings like this one.

   A policy decision point can readily determine whether it supports the
   values stored in an instance of ActionData by checking the OID value
   from ActionEncoding against the set of OIDs it recognizes.  The
   action for the policy decision point to take in case it does not
   recognize the format of this data could itself be modeled as a policy
   rule, governing the behavior of the policy decision point.

Top      Up      ToC       Page 46 
   The property is defined as follows:

      NAME             ActionData
      DESCRIPTION      Extension mechanism for representing actions that
                       have not been modeled as specific properties.  The
                       format of the values is identified by the OID
                       stored in the property ActionEncoding.
      SYNTAX           octet string

6.8.2. The Property "ActionEncoding"

   This property identifies the encoding and semantics of the ActionData
   property values in this instance.  The value of this property is a
   single string, representing a single OID.

   The property is defined as follows:

      NAME             ActionEncoding
      DESCRIPTION      An OID encoded as a string, identifying the format
                       and semantics for this instance's ActionData
                       property.  The value is a dotted sequence of
                       decimal digits (for example, "1.2.100.200")
                       representing the arcs of the OID.  The characters
                       in the string are the UCS-2 characters
                       corresponding to the US ASCII encodings of the
                       numeric characters and the period.
      SYNTAX           string

6.9. The Class "PolicyRepository"

   The class definition of PolicyRepository is as follows:

      NAME             PolicyRepository
      DESCRIPTION      A class representing an administratively defined
                       container for reusable policy-related
                       information.  This class does not introduce any
                       additional properties beyond those in its
                       superclass AdminDomain.  It does, however,
                       participate in a number of unique associations.
      DERIVED FROM     AdminDomain
      ABSTRACT         FALSE



(page 46 continued on part 4)

Next RFC Part