The central class used for representing the \'If Condition then Action\' semantics of a policy rule. 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 PolicyRule are modeled, respectively, with subclasses of PolicyCondition and PolicyAction. These condition and action objects are tied to instances of PolicyRule by the PolicyConditionInPolicyRule and PolicyActionInPolicyRule aggregations.
A PolicyRule 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 PolicySetValidityPeriod aggregation that provides this linkage.
The PolicyRule class uses the property ConditionListType, to indicate whether the conditions for the rule are in DNF (disjunctive normal form), CNF (conjunctive normal form) or, in the case of a rule with no conditions, as an UnconditionalRule. 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 PolicyConditions 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 PolicyConditions 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 PolicyActions associated with the PolicyRule.
PolicyRule instances may also be used to aggregate other PolicyRules and/or PolicyGroups. When used in this way to implement nested rules, the conditions of the aggregating rule apply to the subordinate rules as well. However, any side effects of condition evaluation or the execution of actions MUST NOT affect the result of the evaluation of other conditions evaluated by the rule engine in the same evaluation pass. That is, an implementation of a rule engine MAY evaluate all conditions in any order before applying the priority and determining which actions are to be executed.
CIM_PolicyRule - child subclasses in ROOT\StandardCimv2\MS_409
'Indicates whether the list of PolicyConditions associated with this PolicyRule is in disjunctive normal form (DNF), conjunctive normal form (CNF), or has no conditions (i.e., is an UnconditionalRule) and is automatically evaluated to "True." The default value is 1 ("DNF").'
'CreationClassName indicates the name of the class or the subclass used in the creation of an instance. When used with the other key properties of this class, this property allows all instances of this class and its subclasses to be uniquely identified.'
'ExecutionStrategy defines the strategy to be used in executing the sequenced actions aggregated by this PolicyRule. There are three execution strategies:
Do Until Success - execute actions according to predefined order, until successful execution of a single action. Do All - execute ALL actions which are part of the modeled set, according to their predefined order. Continue doing this, even if one or more of the actions fails. Do Until Failure - execute actions according to predefined order, until the first failure in execution of an action instance.'
Values
['Do Until Success', 'Do All', 'Do Until Failure']
'A flag indicating that the evaluation of the Policy Conditions and execution of PolicyActions (if the Conditions evaluate to TRUE) is required. The evaluation of a PolicyRule MUST be attempted if the Mandatory property value is TRUE. If the Mandatory property is FALSE, then the evaluation of the Rule is \'best effort\' and MAY be ignored.'
'PolicyRule.Priority is deprecated and replaced by providing the priority for a rule (and a group) in the context of the aggregating PolicySet instead of the priority being used for all aggregating PolicySet instances. Thus, the assignment of priority values is much simpler.
A non-negative integer for prioritizing this Policy Rule relative to other Rules. A larger value indicates a higher priority. The default value is 0.'
'This property gives a policy administrator a way of specifying how the ordering of the PolicyActions 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. The default value is 3 ("DontCare").'
'A user-friendly name for the object. This property allows each instance to define a user-friendly name in addition to its key properties, identity data, and description information. Note that the Name property of ManagedSystemElement is also defined as a user-friendly name. But, it is often subclassed to be a Key. It is not reasonable that the same property can convey both identity and a user-friendly name, without inconsistencies. Where Name exists and is not a Key (such as for instances of LogicalDevice), the same information can be present in both the Name and ElementName properties. Note that if there is an associated instance of CIM_EnabledLogicalElementCapabilities, restrictions on this properties may exist as defined in ElementNameMask and MaxElementNameLen properties defined in that class.'
'Indicates whether this PolicySet is administratively enabled, administratively disabled, or enabled for debug. The "EnabledForDebug" property value is deprecated and, when it or any value not understood by the receiver is specified, the receiving enforcement point treats the PolicySet as "Disabled". To determine if a PolicySet is "Enabled", the containment hierarchy specified by the PolicySetComponent aggregation is examined and the Enabled property values of the hierarchy are ANDed together. Thus, for example, everything aggregated by a PolicyGroup may be disabled by setting the Enabled property in the PolicyGroup instance to "Disabled" without changing the Enabled property values of any of the aggregated instances. The default value is 1 ("Enabled").'
'InstanceID is an optional property that may be used to opaquely and uniquely identify an instance of this class within the scope of the instantiating Namespace. Various subclasses of this class may override this property to make it required, or a key. Such subclasses may also modify the preferred algorithms for ensuring uniqueness that are defined below. To ensure uniqueness within the NameSpace, the value of InstanceID should be constructed using the following "preferred" algorithm: : Where and are separated by a colon (:), and where must include a copyrighted, trademarked, or otherwise unique name that is owned by the business entity that is creating or defining the InstanceID or that is a registered ID assigned to the business entity by a recognized global authority. (This requirement is similar to the _ structure of Schema class names.) In addition, to ensure uniqueness, must not contain a colon (:). When using this algorithm, the first colon to appear in InstanceID must appear between and . is chosen by the business entity and should not be reused to identify different underlying (real-world) elements. If not null and the above "preferred" algorithm is not used, the defining entity must assure that the resulting InstanceID is not reused across any InstanceIDs produced by this or other providers for the NameSpace of this instance. If not set to null for DMTF-defined instances, the "preferred" algorithm must be used with the set to CIM.'
'PolicyDecisionStrategy defines the evaluation method used for policies contained in the PolicySet. There are two values currently defined: - \'First Matching\' (1) executes the actions of the first rule whose conditions evaluate to TRUE. The concept of \'first\' is determined by examining the priority of the rule within the policy set (i.e., by examining the property, PolicySetComponent.Priority). Note that this ordering property MUST be maintained when processing the PolicyDecisionStrategy. - \'All\' (2) executes the actions of ALL rules whose conditions evaluate to TRUE, in the set. As noted above, the order of processing of the rules is defined by the property, PolicySetComponent.Priority (and within a rule, the ordering of the actions is defined by the property, PolicyActionStructure.ActionOrder). Note that when this strategy is defined, processing MUST be completed of ALL rules whose conditions evaluate to TRUE, regardless of errors in the execution of the rule actions.'
'An array of keywords for characterizing / categorizing policy objects. Keywords are of one of two types: - Keywords defined in this and other MOFs, or in DMTF white papers. These keywords provide a vendor- independent, installation-independent way of characterizing policy objects. - Installation-dependent keywords for characterizing policy objects. Examples include \'Engineering\', \'Billing\', and \'Review in December 2000\'. This MOF defines the following keywords: \'UNKNOWN\', \'CONFIGURATION\', \'USAGE\', \'SECURITY\', \'SERVICE\', \'MOTIVATIONAL\', \'INSTALLATION\', and \'EVENT\'. These concepts are self-explanatory and are further discussed in the SLA/Policy White Paper. One additional keyword is defined: \'POLICY\'. The role of this keyword is to identify policy-related instances that may not be otherwise identifiable, in some implementations. The keyword \'POLICY\' is NOT mutually exclusive of the other keywords specified above.'
'The PolicyRoles property represents the roles associated with a PolicySet. All contained PolicySet instances inherit the values of the PolicyRoles of the aggregating PolicySet but the values are not copied. A contained PolicySet instance may, however, add additional PolicyRoles to those it inherits from its aggregating PolicySet(s). Each value in PolicyRoles multi-valued property represents a role for which the PolicySet applies, i.e., the PolicySet should be used by any enforcement point that assumes any of the listed PolicyRoles values.
Although not officially designated as \'role combinations\', multiple roles may be specified using the form: [&&]* where the individual role names appear in alphabetical order (according to the collating sequence for UCS-2). Implementations may treat PolicyRoles values that are specified as \'role combinations\' as simple strings.
This property is deprecated in lieu of the use of an association, CIM_PolicySetInRoleCollection. The latter is a more explicit and less error-prone approach to modeling that a PolicySet has one or more PolicyRoles.'
'The central class used for representing the \'If Condition then Action\' semantics of a policy rule. 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 PolicyRule are modeled, respectively, with subclasses of PolicyCondition and PolicyAction. These condition and action objects are tied to instances of PolicyRule by the PolicyConditionInPolicyRule and PolicyActionInPolicyRule aggregations.
A PolicyRule 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 PolicySetValidityPeriod aggregation that provides this linkage.
The PolicyRule class uses the property ConditionListType, to indicate whether the conditions for the rule are in DNF (disjunctive normal form), CNF (conjunctive normal form) or, in the case of a rule with no conditions, as an UnconditionalRule. 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 PolicyConditions 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 PolicyConditions 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 PolicyActions associated with the PolicyRule.
PolicyRule instances may also be used to aggregate other PolicyRules and/or PolicyGroups. When used in this way to implement nested rules, the conditions of the aggregating rule apply to the subordinate rules as well. However, any side effects of condition evaluation or the execution of actions MUST NOT affect the result of the evaluation of other conditions evaluated by the rule engine in the same evaluation pass. That is, an implementation of a rule engine MAY evaluate all conditions in any order before applying the priority and determining which actions are to be executed.'