Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3060

Policy Core Information Model -- Version 1 Specification

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

Top   ToC   RFC3060 - Page 25   prevText

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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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   ToC   RFC3060 - 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 Section