Policy Core Information Model -- Version 1 Specification

DNF (Disjunctive Normal Form) and CNF (Conjunctive Normal Form) were chosen as the mechanisms for combining policy conditions because they strike a balance between expressiveness and tractability, deliberately avoiding full predicate calculus which would render consistency checking and PDP algorithms intractable.

PolicyTimePeriodCondition is restricted to local time and UTC time, deliberately placing the mapping from human time representations (e.g., US Eastern Time) into the Policy Management Tool rather than into PDPs and PEPs, so the expensive conversion is done once rather than repeatedly in every enforcement point.

Roles are defined as selectors that identify which subset of policies apply to a resource, enabling a policy administrator to update policy for a role once and have the Policy Framework propagate configuration changes to all resources playing that role, rather than configuring each resource individually.

The distinction between rule-specific and reusable policy conditions/actions is semantic rather than structural: reusable conditions reside in a policy repository with independently expressible access permissions and existence criteria, while rule-specific conditions share their lifecycle and permissions with their single owning rule.

The Policy Core Information Model adopts a declarative rather than procedural approach, defining modular building blocks and relationships without prescribing algorithms or execution sequences. This keeps the model machine-friendly and avoids constraining implementers, while still allowing action ordering to be optionally expressed.

security, privacy

CIM and LDAP class specifications differ in several ways relevant to PCIM: CIM has only abstract/instantiable types (no auxiliary), uses property (not attribute) terminology, identifies classes and properties by name rather than OID, and scopes properties within their defining class rather than globally.

ldap

CIM strings are stored as UCS-2 (2 octets per character), while LDAP DirectoryString attributes use UTF-8. Implementations moving string values between CIM and LDAP environments must convert between these encodings per RFC 2279.

ldap

PCIM cardinalities documented globally on associations do not capture the full constraints that differ between rule-specific and reusable conditions/actions. Implementations must apply additional semantic constraints textually described in Section 5.1, as no formal mechanism for complex multi-association constraints exists in CIM.

Documents that define subclasses of the Policy Core Information Model classes SHOULD define additional keywords to characterize instances of those subclasses. By convention, keywords defined alongside class definitions are uppercase; installation-defined keywords may be any case.

In any implementation of PolicyGroup, PolicyRule, PolicyCondition, or PolicyAction, various key/identification properties MUST be defined. For native CIM implementations these keys are defined in Appendix A; for LDAP they will be defined in the LDAP mapping document.

Loops are not allowed in PolicyGroup nesting, including the degenerate case of a PolicyGroup that directly contains itself. This constraint applies to all implementations of the PolicyGroupInPolicyGroup aggregation.

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

The individual role names within a role combination string MUST appear in alphabetical order according to the UCS-2 collating sequence, to ensure correct string matching when PDPs look up applicable policies.

PolicyCondition is an abstract class with no properties of its own, serving as a superclass for domain-specific condition subclasses. Each condition evaluates to TRUE or FALSE; conditions are combined via ConditionListType and the GroupNumber/ConditionNegated properties of the PolicyConditionInPolicyRule aggregation.

PolicyGroup is a directly instantiable aggregation container derived from Policy that holds either PolicyRules or other PolicyGroups, supporting arbitrary nesting depth. Loops (including self-containment) are explicitly prohibited.

PolicyRepository is a class derived from AdminDomain that stores reusable policy conditions and actions. It supports recursive containment via the PolicyRepositoryInPolicyRepository association and is linked to conditions and actions via PolicyConditionInPolicyRepository and PolicyActionInPolicyRepository.

PolicyRule is the central class implementing 'If Condition then Action' semantics. Its key properties are Enabled (enabled/disabled/enabledForDebug), ConditionListType (DNF/CNF), Priority (uint16, higher value = higher priority), Mandatory (boolean), SequencedActions (mandatory/recommended/dontCare), and PolicyRoles (multi-valued string).

PolicyTimePeriodCondition provides time-based validity for policy rules through up to five properties: TimePeriod, MonthOfYearMask, DayOfMonthMask, DayOfWeekMask, TimeOfDayMask, and LocalOrUtcTime (which specifies whether all time values in the instance are local or UTC).

The abstract class Policy is the root of the policy class hierarchy, providing CommonName (CN), PolicyKeywords (multi-valued), Caption, and Description properties. It defines standard keyword values: UNKNOWN, CONFIGURATION, USAGE, SECURITY, SERVICE, MOTIVATIONAL, INSTALLATION, EVENT, and POLICY.

The Enabled property on PolicyRule supports an 'enabledForDebug' value (=3) that causes conditions to be evaluated but actions to be suppressed even when conditions are TRUE, enabling non-disruptive policy testing in production environments.

The PolicyActionInPolicyRule aggregation includes an ActionOrder property (uint16) that specifies the sequence in which actions are to be executed, interpreted per the SequencedActions property of the owning PolicyRule (mandatory, recommended, or dontCare).

The PolicyConditionInPolicyRule aggregation carries two critical properties beyond the references: GroupNumber (uint16) partitions conditions into AND-groups (for DNF) or OR-groups (for CNF), and ConditionNegated (boolean) allows individual conditions to be logically negated.

The PolicyRoles property on PolicyRule is a multi-valued string array where each value represents one role combination in the format '<RoleName>[&&<RoleName>]*'. Multiple values are logically ORed, allowing a rule to match any of several role combinations.

VendorPolicyCondition and VendorPolicyAction provide a standard vendor extension mechanism. VendorPolicyCondition carries a multi-valued Constraint property and a ConstraintEncoding OID; VendorPolicyAction carries ActionData and ActionEncoding, allowing opaque vendor-specific policy data.

Security policies are an explicitly recognized category in the PCIM, covering authentication, authorization, access control, and auditing. The PolicyKeywords property includes 'SECURITY' as a standard keyword to identify policy objects that serve security functions.

security