RFC 3060
Policy Core Information Model -- Version 1 Specification
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.
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.
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.
+---------------------------------------------------+ | 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].
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
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].
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:
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
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:
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
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
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
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
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"
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.
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.)
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.
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
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 string6.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
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.
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[ ] ActionEncoding6.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.
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)
