time interval of T000000/T030000 on Tuesdays. So the end result
would have been ten instances of PolicyTimePeriodCondition, not five.
By restricting PolicyTimePeriodCondition to local time and UTC time,
the PCIM places the difficult and expensive task of mapping from
"human" time representations to machine-friendly ones in the Policy
Management Tool. Another approach would have been to place in
PolicyTimePeriodCondition a means of representing a named time zone,
such as [US] Eastern Time. This, however, would have passed the
difficult mapping responsibility down to the PDPs and PEPs. It is
better to have a mapping such as the one described above done once in
a Policy Management Tool, rather than having it done over and over in
each of the PDPs (and possibly PEPs) that need to apply a PolicyRule.
5.4. CIM Data Types
Since PCIM extends the CIM Schema, a correspondence between data
types used in both CIM and PCIM is needed. The following CIM data
types are used in the class definitions that follow in Sections 6 and
7:
o uint8 unsigned 8-bit integer
o uint16 unsigned 16-bit integer
o boolean Boolean
o string UCS-2 string.
Strings in CIM are stored as UCS-2 characters, where each character
is encoded in two octets. Thus string values may need to be
converted when moving between a CIM environment and one that uses a
different string encoding. For example, in an LDAP-accessible
directory, attributes of type DirectoryString are stored in UTF-8
format. RFC2279 [7] explains how to convert between these two
formats.
When it is applied to a CIM string, a MaxLen value refers to the
maximum number of characters in the string, rather than to the
maximum number of octets.
In addition to the CIM data types listed above, the association
classes in Section 7 use the following type:
o <classname> ref strongly typed reference.
There is one obvious omission from this list of CIM data types:
octet strings. This is because CIM treats octet strings as a derived
data type. There are two forms of octet strings in CIM - an ordered
uint8 array for single-valued strings, and a string array for multi-
valued properties. Both are described by adding an "OctetString"
qualifier (meta-data) to the property. This qualifier functions
exactly like an SMIv2 (SNMP) Textual Convention, refining the syntax
and semantics of the existing CIM data type.
The first four numeric elements of both of the "OctetString"
representations are a length field. (The reason that the "numeric"
adjective is added to the previous sentence is that the string
property also includes '0' and 'x', as its first characters.) In
both cases, these 4 numeric elements (octets) are included in
calculating the length. For example, a single-valued octet string
property having the value X'7C' would be represented by the uint8
array, X'00 00 00 05 7C'.
The strings representing the individual values of a multi-valued
property qualified with the "OctetString" qualifier are constructed
similarly:
1. Take a value to be encoded as an octet string (we'll use X'7C' as
above), and prepend to it a four-octet length. The result is the
same, X'00 00 00 05 7C'.
2. Convert this to a character string by introducing '0' and 'x' at
the front, and removing all white space. Thus we have the 12-
character string "0x000000057C". This string is the value of one
of the array elements in the CIM string array. Since CIM uses the
UCS-2 character set, it will require 24 octets to encode this 12-
character string.
Mappings of the PCIM to particular data models are not required to
follow this CIM technique of representing multi-valued octet strings
as length- prefixed character strings. In an LDAP mapping, for
example, it would be much more natural to simply use the Octet String
syntax, and omit the prepended length octets.
5.5. Comparison between CIM and LDAP Class Specifications
There are a number of differences between CIM and LDAP class
specifications. The ones that are relevant to the abbreviated class
specifications in this document are listed below. These items are
included here to help introduce the IETF community, which is already
familiar with LDAP, to CIM modeling, and by extension, to information
modeling in general.
o Instead of LDAP's three class types (abstract, auxiliary,
structural), CIM has only two: abstract and instantiable. The
type of a CIM class is indicated by the Boolean qualifier
ABSTRACT.
o CIM uses the term "property" for what LDAP terms an "attribute".
o CIM uses the array notation "[ ]" to indicate that a property is
multi-valued. CIM defines three types of arrays: bags (contents
are unordered, duplicates allowed), ordered bags (contents are
ordered but duplicates are allowed) and indexed arrays (contents
are ordered and no duplicates are allowed).
o CIM classes and properties are identified by name, not by OID.
o CIM classes use a different naming scheme for native
implementations, than LDAP. The CIM naming scheme is documented
in Appendix A since it is not critical to understanding the
information model, and only applies when communicating with a
native CIM implementation.
o In LDAP, attribute definitions are global, and the same attribute
may appear in multiple classes. In CIM, a property is defined
within the scope of a single class definition. The property may
be inherited into subclasses of the class in which it is defined,
but otherwise it cannot appear in other classes. One side effect
of this difference is that CIM property names tend to be much
shorter than LDAP attribute names, since they are implicitly
scoped by the name of the class in which they are defined.
There is also a notational convention that this document follows, to
improve readability. In CIM, all class and property names are
prefixed with the characters "CIM_". These prefixes have been
omitted throughout this document, with one exception regarding
naming, documented in Appendix A.
For the complete definition of the CIM specification language, see
reference [2].
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 RFC2445 (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 RFC2445.
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 RFC2445 does not use these two strings in connection with
explicit time periods. Thus the PCIM is combining two elements from
RFC2445 that are not combined in the RFCitself.
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 RFC2445 [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 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
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[ ]
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.
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
7. Association and Aggregation Definitions
The first two subsections of this section introduce associations and
aggregations as they are used in CIM. The remaining subsections
present the class definitions for the associations and aggregations
that are part of the Policy Core Information Model.
7.1. Associations
An association is a CIM construct representing a relationship between
two (or theoretically more) objects. It is modeled as a class
containing typically two object references. Associations can be