diff options
Diffstat (limited to 'doc/rfc/rfc3703.txt')
| -rw-r--r-- | doc/rfc/rfc3703.txt | 3419 |
1 files changed, 3419 insertions, 0 deletions
diff --git a/doc/rfc/rfc3703.txt b/doc/rfc/rfc3703.txt new file mode 100644 index 0000000..48f6376 --- /dev/null +++ b/doc/rfc/rfc3703.txt @@ -0,0 +1,3419 @@ + + + + + + +Network Working Group J. Strassner +Request for Comments: 3703 Intelliden Corporation +Category: Standards Track B. Moore + IBM Corporation + R. Moats + Lemur Networks, Inc. + E. Ellesson + February 2004 + + + Policy Core Lightweight Directory Access Protocol (LDAP) Schema + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document defines a mapping of the Policy Core Information Model + to a form that can be implemented in a directory that uses + Lightweight Directory Access Protocol (LDAP) as its access protocol. + This model defines two hierarchies of object classes: structural + classes representing information for representing and controlling + policy data as specified in RFC 3060, and relationship classes that + indicate how instances of the structural classes are related to each + other. Classes are also added to the LDAP schema to improve the + performance of a client's interactions with an LDAP server when the + client is retrieving large amounts of policy-related information. + These classes exist only to optimize LDAP retrievals: there are no + classes in the information model that correspond to them. + +Table of Contents + + 1. Introduction ................................................. 2 + 2. The Policy Core Information Model ............................ 4 + 3. Inheritance Hierarchy for the PCLS ........................... 5 + 4. General Discussion of Mapping the Information Model to LDAP .. 6 + 4.1. Summary of Class and Association Mappings .............. 7 + 4.2. Usage of DIT Content and Structure Rules and Name Forms. 9 + 4.3. Naming Attributes in the PCLS .......................... 10 + + + +Strassner, et al. Standards Track [Page 1] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + 4.4. Rule-Specific and Reusable Conditions and Actions ...... 11 + 4.5. Location and Retrieval of Policy Objects in the + Directory .............................................. 16 + 4.5.1. Aliases and Other DIT-Optimization Techniques .. 19 + 5. Class Definitions ............................................ 19 + 5.1. The Abstract Class "pcimPolicy" ........................ 21 + 5.2. The Three Policy Group Classes ......................... 22 + 5.3. The Three Policy Rule Classes .......................... 23 + 5.4. The Class pcimRuleConditionAssociation ................. 30 + 5.5. The Class pcimRuleValidityAssociation .................. 32 + 5.6. The Class pcimRuleActionAssociation .................... 34 + 5.7. The Auxiliary Class pcimConditionAuxClass .............. 36 + 5.8. The Auxiliary Class pcimTPCAuxClass .................... 36 + 5.9. The Auxiliary Class pcimConditionVendorAuxClass ........ 40 + 5.10. The Auxiliary Class pcimActionAuxClass ................. 41 + 5.11. The Auxiliary Class pcimActionVendorAuxClass ........... 42 + 5.12. The Class pcimPolicyInstance ........................... 43 + 5.13. The Auxiliary Class pcimElementAuxClass ................ 44 + 5.14. The Three Policy Repository Classes .................... 45 + 5.15. The Auxiliary Class pcimSubtreesPtrAuxClass ............ 46 + 5.16. The Auxiliary Class pcimGroupContainmentAuxClass ....... 48 + 5.17. The Auxiliary Class pcimRuleContainmentAuxClass ........ 49 + 6. Extending the Classes Defined in This Document ............... 50 + 6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 50 + 6.2. Using the Vendor Policy Attributes ..................... 50 + 6.3. Using Time Validity Periods ............................ 51 + 7. Security Considerations ...................................... 51 + 8. IANA Considerations .......................................... 53 + 8.1. Object Identifiers ..................................... 53 + 8.2. Object Identifier Descriptors .......................... 53 + 9. Acknowledgments .............................................. 56 + 10. Appendix: Constructing the Value of orderedCIMKeys .......... 57 + 11. References ................................................... 58 + 11.1. Normative References ................................... 58 + 11.2. Informative References ................................. 59 + 12. Authors' Addresses ........................................... 60 + 13. Full Copyright Statement ..................................... 61 + +1. Introduction + + This document takes as its starting point the object-oriented + information model for representing information for representing and + controlling policy data as specified in [1]. Lightweight Directory + Access Protocol (LDAP) [2] implementers, please note that the use of + the term "policy" in this document does not refer to the use of the + term "policy" as defined in X.501 [4]. Rather, the use of the term + "policy" throughout this document is defined as follows: + + + + +Strassner, et al. Standards Track [Page 2] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + Policy is defined as a set of rules to administer, manage, and + control access to network resources. + + This work is currently under joint development in the IETF's Policy + Framework working group and in the Policy working group of the + Distributed Management Task Force (DMTF). This model defines two + hierarchies of object classes: structural classes representing policy + information and control of policies, and relationship classes that + indicate how instances of the structural classes are related to each + other. In general, both of these class hierarchies will need to be + mapped to a particular data store. + + This document defines the mapping of these information model classes + to a directory that uses LDAP as its access protocol. Two types of + mappings are involved: + + - For the structural classes in the information model, the + mapping is basically one-for-one: information model classes map + to LDAP classes, information model properties map to LDAP + attributes. + + - For the relationship classes in the information model, + different mappings are possible. In this document, the Policy + Core Information Model's (PCIM's) relationship classes and + their properties are mapped in three ways: to LDAP auxiliary + classes, to attributes representing distinguished name (DN) + references, and to superior-subordinate relationships in the + Directory Information Tree (DIT). + + Implementations that use an LDAP directory as their policy repository + and want to implement policy information according to RFC 3060 [1] + SHALL use the LDAP schema defined in this document, or a schema that + subclasses from the schema defined in this document. The use of the + information model defined in reference [1] as the starting point + enables the inheritance and the relationship class hierarchies to be + extensible, such that other types of policy repositories, such as + relational databases, can also use this information. + + This document fits into the overall framework for representing, + deploying, and managing policies being developed by the Policy + Framework Working Group. + + The LDAP schema described in this document uses the prefix "pcim" to + identify its classes and attributes. It consists of ten very general + classes: pcimPolicy (an abstract class), three policy group classes + (pcimGroup, pcimGroupAuxClass, and pcimGroupInstance), three policy + rule classes (pcimRule, pcimRuleAuxClass, and pcimRuleInstance), and + three special auxiliary classes (pcimConditionAuxClass, + + + +Strassner, et al. Standards Track [Page 3] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + pcimTPCAuxClass, and pcimActionAuxClass). (Note that the + PolicyTimePeriodCondition auxiliary class defined in [1] would + normally have been named pcimTimePeriodConditionAuxClass, but this + name is too long for some directories. Therefore, we have + abbreviated this name to be pcimTPCAuxClass). + + The mapping for the PCIM classes pcimGroup and pcimRule is designed + to be as flexible as possible. Three classes are defined for these + two PCIM classes. First, an abstract superclass is defined that + contains all required properties of each PCIM class. Then, both an + auxiliary class as well as a structural class are derived from the + abstract superclass. This provides maximum flexibility for the + developer. + + The schema also contains two less general classes: + pcimConditionVendorAuxClass and pcimActionVendorAuxClass. To achieve + the mapping of the information model's relationships, the schema also + contains two auxiliary classes: pcimGroupContainmentAuxClass and + pcimRuleContainmentAuxClass. Capturing the distinction between + rule-specific and reusable policy conditions and policy actions + introduces seven other classes: pcimRuleConditionAssociation, + pcimRuleValidityAssociation, pcimRuleActionAssociation, + pcimPolicyInstance, and three policy repository classes + (pcimRepository, pcimRepositoryAuxClass, and pcimRepositoryInstance). + Finally, the schema includes two classes (pcimSubtreesPtrAuxClass and + pcimElementAuxClass) for optimizing LDAP retrievals. In all, the + schema contains 23 classes. + + Within the context of this document, the term "PCLS" (Policy Core + LDAP Schema) is used to refer to the LDAP class definitions that this + document contains. The term "PCIM" refers to classes defined in [1]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [10]. + +2. The Policy Core Information Model + + This document contains an LDAP schema representing the classes + defined in the companion document "Policy Core Information + Model -- Version 1 Specification" [1]. Other documents may + subsequently be produced, with mappings of this same PCIM to other + storage technologies. Since the detailed semantics of the PCIM + classes appear only in [1], that document is a prerequisite for + reading and understanding this document. + + + + + + +Strassner, et al. Standards Track [Page 4] + +RFC 3703 Policy Core LDAP Schema February 2004 + + +3. Inheritance Hierarchy for the PCLS + + The following diagram illustrates the class hierarchy for the LDAP + Classes defined in this document: + + top + | + +--dlm1ManagedElement (abstract) + | | + | +--pcimPolicy (abstract) + | | | + | | +--pcimGroup (abstract) + | | | | + | | | +--pcimGroupAuxClass (auxiliary) + | | | | + | | | +--pcimGroupInstance (structural) + | | | + | | +--pcimRule (abstract) + | | | | + | | | +--pcimRuleAuxClass (auxiliary) + | | | | + | | | +--pcimRuleInstance (structural) + | | | + | | +--pcimRuleConditionAssociation (structural) + | | | + | | +--pcimRuleValidityAssociation (structural) + | | | + | | +--pcimRuleActionAssociation (structural) + | | | + | | +--pcimPolicyInstance (structural) + | | | + | | +--pcimElementAuxClass (auxiliary) + | | + | +--dlm1ManagedSystemElement (abstract) + | | + | +--dlm1LogicalElement (abstract) + | | + | +--dlm1System (abstract) + | | + | +--dlm1AdminDomain (abstract) + | | + | +--pcimRepository (abstract) + | | + | +--pcimRepositoryAuxClass (auxiliary) + + + + + + + +Strassner, et al. Standards Track [Page 5] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + top + | | + | +--pcimRepositoryInstance + | (structural) + | + +--pcimConditionAuxClass (auxiliary) + | | + | +---pcimTPCAuxClass (auxiliary) + | | + | +---pcimConditionVendorAuxClass (auxiliary) + | + +--pcimActionAuxClass (auxiliary) + | | + | +---pcimActionVendorAuxClass (auxiliary) + | + +--pcimSubtreesPtrAuxClass (auxiliary) + | + +--pcimGroupContainmentAuxClass (auxiliary) + | + +--pcimRuleContainmentAuxClass (auxiliary) + + Figure 1. LDAP Class Inheritance Hierarchy for the PCLS + +4. General Discussion of Mapping the Information Model to LDAP + + The classes described in Section 5 below contain certain + optimizations for a directory that uses LDAP as its access protocol. + One example of this is the use of auxiliary classes to represent some + of the associations defined in the information model. Other data + stores might need to implement these associations differently. A + second example is the introduction of classes specifically designed + to optimize retrieval of large amounts of policy-related data from a + directory. This section discusses some general topics related to the + mapping from the information model to LDAP. + + The remainder of this section will discuss the following topics. + Section 4.1 will discuss the strategy used in mapping the classes and + associations defined in [1] to a form that can be represented in a + directory that uses LDAP as its access protocol. Section 4.2 + discusses DIT content and structure rules, as well as name forms. + Section 4.3 describes the strategy used in defining naming attributes + for the schema described in Section 5 of this document. Section 4.4 + defines the strategy recommended for locating and retrieving + PCIM-derived objects in the directory. + + + + + + + +Strassner, et al. Standards Track [Page 6] + +RFC 3703 Policy Core LDAP Schema February 2004 + + +4.1. Summary of Class and Association Mappings + + Fifteen of the classes in the PCLS come directly from the nine + corresponding classes in the information model. Note that names of + classes begin with an upper case character in the information model + (although for CIM in particular, case is not significant in class and + property names), but with a lower case character in LDAP. This is + because although LDAP doesn't care, X.500 doesn't allow class names + to begin with an uppercase character. Note also that the prefix + "pcim" is used to identify these LDAP classes. + + +---------------------------+-------------------------------+ + | Information Model | LDAP Class(es) | + +---------------------------+-------------------------------+ + +---------------------------+-------------------------------+ + | Policy | pcimPolicy | + +---------------------------+-------------------------------+ + | PolicyGroup | pcimGroup | + | | pcimGroupAuxClass | + | | pcimGroupInstance | + +---------------------------+-------------------------------+ + | PolicyRule | pcimRule | + | | pcimRuleAuxClass | + | | pcimRuleInstance | + +---------------------------+-------------------------------+ + | PolicyCondition | pcimConditionAuxClass | + +---------------------------+-------------------------------+ + | PolicyAction | pcimActionAuxClass | + +---------------------------+-------------------------------+ + | VendorPolicyCondition | pcimConditionVendorAuxClass | + +---------------------------+-------------------------------+ + | VendorPolicyAction | pcimActionVendorAuxClass | + +---------------------------+-------------------------------+ + | PolicyTimePeriodCondition | pcimTPCAuxClass | + +---------------------------+-------------------------------+ + | PolicyRepository | pcimRepository | + | | pcimRepositoryAuxClass | + | | pcimRepositoryInstance | + +---------------------------+-------------------------------+ + + Figure 2. Mapping of Information Model Classes to LDAP + + The associations in the information model map to attributes that + reference DNs (Distinguished Names) or to Directory Information Tree + (DIT) containment (i.e., superior-subordinate relationships) in LDAP. + Two of the attributes that reference DNs appear in auxiliary classes, + which allow each of them to represent several relationships from the + information model. + + + +Strassner, et al. Standards Track [Page 7] + +RFC 3703 Policy Core LDAP Schema February 2004 + + ++----------------------------------+----------------------------------+ +| Information Model Association | LDAP Attribute / Class | ++-----------------------------------+---------------------------------+ ++-----------------------------------+---------------------------------+ +| PolicyGroupInPolicyGroup | pcimGroupsAuxContainedSet in | +| | pcimGroupContainmentAuxClass | ++-----------------------------------+---------------------------------+ +| PolicyRuleInPolicyGroup | pcimRulesAuxContainedSet in | +| | pcimRuleContainmentAuxClass | ++-----------------------------------+---------------------------------+ +| PolicyConditionInPolicyRule | DIT containment or | +| | pcimRuleConditionList in | +| | pcimRule or | +| | pcimConditionDN in | +| | pcimRuleConditionAssociation | ++-----------------------------------+---------------------------------+ +| PolicyActionInPolicyRule | DIT containment or | +| | pcimRuleActionList in | +| | pcimRule or | +| | pcimActionDN in | +| | pcimRuleActionAssociation | ++-----------------------------------+---------------------------------+ +| PolicyRuleValidityPeriod | pcimRuleValidityPeriodList | +| | in pcimRule or (if reusable) | +| | referenced through the | +| | pcimTimePeriodConditionDN in | +| | pcimRuleValidityAssociation | ++-----------------------------------+---------------------------------+ +| PolicyConditionInPolicyRepository | DIT containment | ++-----------------------------------+---------------------------------+ +| PolicyActionInPolicyRepository | DIT containment | ++-----------------------------------+---------------------------------+ +| PolicyRepositoryInPolicyRepository| DIT containment | ++-----------------------------------+---------------------------------+ + + Figure 3. Mapping of Information Model Associations to LDAP + + Of the remaining classes in the PCLS, two (pcimElementAuxClass and + pcimSubtreesPtrAuxClass) are included to make navigation through the + DIT and retrieval of the entries found there more efficient. This + topic is discussed below in Section 4.5. + + The remaining four classes in the PCLS, pcimRuleConditionAssociation, + pcimRuleValidityAssociation, pcimRuleActionAssociation, and + pcimPolicyInstance, are all involved with the representation of + policy conditions and policy actions in an LDAP directory. This + topic is discussed below in Section 4.4. + + + + +Strassner, et al. Standards Track [Page 8] + +RFC 3703 Policy Core LDAP Schema February 2004 + + +4.2. Usage of DIT Content and Structure Rules and Name Forms + + There are three powerful tools that can be used to help define + schemata. The first, DIT content rules, is a way of defining the + content of an entry for a structural object class. It can be used to + specify the following characteristics of the entry: + + - additional mandatory attributes that the entries are required + to contain + - additional optional attributes the entries are allowed to + contain + - the set of additional auxiliary object classes that these + entries are allowed to be members of + - any optional attributes from the structural and auxiliary + object class definitions that the entries are required to + preclude + + DIT content rules are NOT mandatory for any structural object class. + + A DIT structure rule, together with a name form, controls the + placement and naming of an entry within the scope of a subschema. + Name forms define which attribute type(s) are required and are + allowed to be used in forming the Relative Distinguished Names (RDNs) + of entries. DIT structure rules specify which entries are allowed to + be superior to other entries, and hence control the way that RDNs are + added together to make DNs. + + A name form specifies the following: + + - the structural object class of the entries named by this name + form + - attributes that are required to be used in forming the RDNs of + these entries + - attributes that are allowed to be used in forming the RDNs of + these entries + - an object identifier to uniquely identify this name form + + Note that name forms can only be specified for structural object + classes. However, every entry in the DIT must have a name form + controlling it. + + Unfortunately, current LDAP servers vary quite a lot in their support + of these features. There are also three crucial implementation + points that must be followed. First, X.500 use of structure rules + requires that a structural object class with no superior structure + rule be a subschema administrative point. This is exactly NOT what + we want for policy information. Second, when an auxiliary class is + subclassed, if a content rule exists for the structural class that + + + +Strassner, et al. Standards Track [Page 9] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + the auxiliary class refers to, then that content rule needs to be + augmented. Finally, most LDAP servers unfortunately do not support + inheritance of structure and content rules. + + Given these concerns, DIT structure and content rules have been + removed from the PCLS. This is because, if included, they would be + normative references and would require OIDs. However, we don't want + to lose the insight gained in building the structure and content + rules of the previous version of the schema. Therefore, we describe + where such rules could be used in this schema, what they would + control, and what their effect would be. + +4.3. Naming Attributes in the PCLS + + Instances in a directory are identified by distinguished names (DNs), + which provide the same type of hierarchical organization that a file + system provides in a computer system. A distinguished name is a + sequence of RDNs. An RDN provides a unique identifier for an + instance within the context of its immediate superior, in the same + way that a filename provides a unique identifier for a file within + the context of the folder in which it resides. + + To preserve maximum naming flexibility for policy administrators, + three optional (i.e., "MAY") naming attributes have been defined. + They are: + + - Each of the structural classes defined in this schema has its + own unique ("MAY") naming attribute. Since the naming + attributes are different, a policy administrator can, by using + these attributes, guarantee that there will be no name + collisions between instances of different classes, even if the + same value is assigned to the instances' respective naming + attributes. + + - The LDAP attribute cn (corresponding to X.500's commonName) is + included as a MAY attribute in the abstract class pcimPolicy, + and thus by inheritance in all of its subclasses. In X.500, + commonName typically functions as an RDN attribute, for naming + instances of many classes (e.g., X.500's person class). + + - A special attribute is provided for implementations that expect + to map between native CIM and LDAP representations of policy + information. This attribute, called orderedCimKeys, is defined + in the class dlm1ManagedElement [6]. The value of this + attribute is derived algorithmically from values that are + already present in a CIM policy instance. The normative + reference for this algorithm is contained in [6]. See the + appendix of this document for a description of the algorithm. + + + +Strassner, et al. Standards Track [Page 10] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + Since any of these naming attributes MAY be used for naming an + instance of a PCLS class, implementations MUST be able to accommodate + instances named in any of these ways. + + Note that it is recommended that two or more of these attributes + SHOULD NOT be used together to form a multi-part RDN, since support + for multi-part RDNs is limited among existing directory + implementations. + +4.4. Rule-Specific and Reusable Conditions and Actions + + The PCIM [1] distinguishes between two types of policy conditions and + policy actions: those associated with a single policy rule, and + those that are reusable, in the sense that they may be associated + with more than one policy rule. While there is no inherent + functional difference between a rule-specific condition or action and + a reusable one, there is both a usage, as well as, an implementation + difference between them. + + Defining a condition or action as reusable vs. rule-specific reflects + a conscious decision on the part of the administrator in defining how + they are used. In addition, there are variations that reflect + implementing rule-specific vs. reusable policy conditions and actions + and how they are treated in a policy repository. The major + implementation differences between a rule-specific and a reusable + condition or action are delineated below: + + 1. It is natural for a rule-specific condition or action to be + removed from the policy repository at the same time the rule is. + It is just the opposite for reusable conditions and actions. + This is because the condition or action is conceptually attached + to the rule in the rule-specific case, whereas it is referenced + (e.g., pointed at) in the reusable case. The persistence of a + pcimRepository instance is independent of the persistence of a + pcimRule instance. + 2. Access permissions for a rule-specific condition or action are + usually identical to those for the rule itself. On the other + hand, access permissions of reusable conditions and actions must + be expressible without reference to a policy rule. + 3. Rule-specific conditions and actions require fewer accesses, + because the conditions and actions are "attached" to the rule. + In contrast, reusable conditions and actions require more + accesses, because each condition or action that is reusable + requires a separate access. + 4. Rule-specific conditions and actions are designed for use by a + single rule. As the number of rules that use the same + rule-specific condition increase, subtle problems are created + (the most obvious being how to keep the rule-specific conditions + + + +Strassner, et al. Standards Track [Page 11] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + and actions updated to reflect the same value). Reusable + conditions and actions lend themselves for use by multiple + independent rules. + 5. Reusable conditions and actions offer an optimization when + multiple rules are using the same condition or action. This is + because the reusable condition or action only needs be updated + once, and by virtue of DN reference, the policy rules will be + automatically updated. + + The preceding paragraph does not contain an exhaustive list of the + ways in which reusable and rule-specific conditions should be treated + differently. Its purpose is merely to justify making a semantic + distinction between rule-specific and reusable, and then reflecting + this distinction in the policy repository itself. + + When the policy repository is realized in an LDAP-accessible + directory, the distinction between rule-specific and reusable + conditions and actions is realized via placement of auxiliary classes + and via DIT containment. Figure 4 illustrates a policy rule Rule1 + with one rule-specific condition CA and one rule-specific action AB. + + +-----+ + |Rule1| + | | + +-----|- -|-----+ + | +-----+ | + | * * | + | * * | + | **** **** | + | * * | + v * * v + +--------+ +--------+ + | CA+ca | | AB+ab | + +--------+ +--------+ + + + +------------------------------+ + |LEGEND: | + | ***** DIT containment | + | + auxiliary attachment | + | ----> DN reference | + +------------------------------+ + + Figure 4 Rule-Specific Policy Conditions and Actions + + + + + + + +Strassner, et al. Standards Track [Page 12] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + Because the condition and action are specific to Rule1, the auxiliary + classes ca and ab that represent them are attached, respectively, to + the structural classes CA and AB. These structural classes represent + not the condition ca and action ab themselves, but rather the + associations between Rule1 and ca, and between Rule1 and ab. + + As Figure 4 illustrates, Rule1 contains DN references to the + structural classes CA and AB that appear below it in the DIT. At + first glance it might appear that these DN references are + unnecessary, since a subtree search below Rule1 would find all of the + structural classes representing the associations between Rule1 and + its conditions and actions. Relying only on a subtree search, + though, runs the risk of missing conditions or actions that should + have appeared in the subtree, but for some reason did not, or of + finding conditions or actions that were inadvertently placed in the + subtree, or that should have been removed from the subtree, but for + some reason were not. Implementation experience has suggested that + many (but not all) of these risks are eliminated. + + However, it must be noted that this comes at a price. The use of DN + references, as shown in Figure 4 above, thwarts inheritance of access + control information as well as existence dependency information. It + also is subject to referential integrity considerations. Therefore, + it is being included as an option for the designer. + + Figure 5 illustrates a second way of representing rule-specific + conditions and actions in an LDAP-accessible directory: attachment of + the auxiliary classes directly to the instance representing the + policy rule. When all of the conditions and actions are attached to + a policy rule in this way, the rule is termed a "simple" policy rule. + When conditions and actions are not attached directly to a policy + rule, the rule is termed a "complex" policy rule. + + +-----------+ + |Rule1+ca+ab| + | | + +-----------+ + + +------------------------------+ + |LEGEND: | + | + auxiliary attachment | + +------------------------------+ + + Figure 5. A Simple Policy Rule + + + + + + + +Strassner, et al. Standards Track [Page 13] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The simple/complex distinction for a policy rule is not all or + nothing. A policy rule may have its conditions attached to itself + and its actions attached to other entries, or it may have its actions + attached to itself and its conditions attached to other entries. + However, it SHALL NOT have either its conditions or its actions + attached both to itself and to other entries, with one exception: a + policy rule may reference its validity periods with the + pcimRuleValidityPeriodList attribute, but have its other conditions + attached to itself. + + The tradeoffs between simple and complex policy rules are between the + efficiency of simple rules and the flexibility and greater potential + for reuse of complex rules. With a simple policy rule, the semantic + options are limited: + + - All conditions are ANDed together. This combination can be + represented in two ways in the Disjunctive Normal Form (DNF)/ + Conjunctive Normal Form (CNF) (please see [1] for definitions of + these terms) expressions characteristic of policy conditions: as + a DNF expression with a single AND group, or as a CNF expression + with multiple single-condition OR groups. The first of these is + arbitrarily chosen as the representation for the ANDed conditions + in a simple policy rule. + + - If multiple actions are included, no order can be specified for + them. + + If a policy administrator needs to combine conditions in some other + way, or if there is a set of actions that must be ordered, then the + only option is to use a complex policy rule. + + Finally, Figure 6 illustrates the same policy rule Rule1, but this + time its condition and action are reusable. The association classes + CA and AB are still present, and they are still DIT contained under + Rule1. But rather than having the auxiliary classes ca and ab + attached directly to the association classes CA and AB, each now + contains DN references to other entries to which these auxiliary + classes are attached. These other entries, CIA and AIB, are DIT + contained under RepositoryX, which is an instance of the class + pcimRepository. Because they are named under an instance of + pcimRepository, ca and ab are clearly identified as reusable. + + + + + + + + + + +Strassner, et al. Standards Track [Page 14] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + +-----+ +-------------+ + |Rule1| | RepositoryX | + +-|- -|--+ | | + | +-----+ | +-------------+ + | * * | * * + | * * | * * + | *** **** | * * + | * * v * * + | * +---+ * * + | * |AB | +------+ * + v * | -|-------->|AIB+ab| * + +---+ +---+ +------+ * + |CA | +------+ + | -|------------------------>|CIA+ca| + +---+ +------+ + + +------------------------------+ + |LEGEND: | + | ***** DIT containment | + | + auxiliary attachment | + | ----> DN reference | + +------------------------------+ + + Figure 6. Reusable Policy Conditions and Actions + + The classes pcimConditionAuxClass and pcimActionAuxClass do not + themselves represent actual conditions and actions: these are + introduced in their subclasses. What pcimConditionAuxClass and + pcimActionAuxClass do introduce are the semantics of being a policy + condition or a policy action. These are the semantics that all the + subclasses of pcimConditionAuxClass and pcimActionAuxClass inherit. + Among these semantics are those of representing either a + rule-specific or a reusable policy condition or policy action. + + In order to preserve the ability to represent a rule-specific or a + reusable condition or action, as well as a simple policy rule, all + the subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST + also be auxiliary classes. + + + + + + + + + + + + + +Strassner, et al. Standards Track [Page 15] + +RFC 3703 Policy Core LDAP Schema February 2004 + + +4.5. Location and Retrieval of Policy Objects in the Directory + + When a Policy Decision Point (PDP) goes to an LDAP directory to + retrieve the policy object instances relevant to the Policy + Enforcement Points (PEPs) it serves, it is faced with two related + problems: + + - How does it locate and retrieve the directory entries that apply + to its PEPs? These entries may include instances of the PCLS + classes, instances of domain-specific subclasses of these + classes, and instances of other classes modeling such resources + as user groups, interfaces, and address ranges. + + - How does it retrieve the directory entries it needs in an + efficient manner, so that retrieval of policy information from + the directory does not become a roadblock to scalability? There + are two facets to this efficiency: retrieving only the relevant + directory entries, and retrieving these entries using as few LDAP + calls as possible. + + The placement of objects in the Directory Information Tree (DIT) + involves considerations other than how the policy-related objects + will be retrieved by a PDP. Consequently, all that the PCLS can do + is to provide a "toolkit" of classes to assist the policy + administrator as the DIT is being designed and built. A PDP SHOULD + be able to take advantage of any tools that the policy administrator + is able to build into the DIT, but it MUST be able to use a less + efficient means of retrieval if that is all it has available to it. + + The basic idea behind the LDAP optimization classes is a simple one: + make it possible for a PDP to retrieve all the policy-related objects + it needs, and only those objects, using as few LDAP calls as + possible. An important assumption underlying this approach is that + the policy administrator has sufficient control over the underlying + DIT structure to define subtrees for storing policy information. If + the policy administrator does not have this level of control over DIT + structure, a PDP can still retrieve the policy-related objects it + needs individually. But it will require more LDAP access operations + to do the retrieval in this way. Figure 7 illustrates how LDAP + optimization is accomplished. + + + + + + + + + + + +Strassner, et al. Standards Track [Page 16] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + +-----+ + ---------------->| A | + DN reference to | | DN references to subtrees +---+ + starting object +-----+ +-------------------------->| C | + | o--+----+ +---+ +---+ + | o--+------------->| B | / \ + +-----+ +---+ / \ + / \ / \ / ... \ + / \ / \ + / \ / ... \ + + Figure 7. Using the pcimSubtreesPtrAuxClass to Locate Policies + + The PDP is configured initially with a DN reference to some entry in + the DIT. The structural class of this entry is not important; the + PDP is interested only in the pcimSubtreesPtrAuxClass attached to it. + This auxiliary class contains a multi-valued attribute with DN + references to objects that anchor subtrees containing policy-related + objects of interest to the PDP. Since pcimSubtreesPtrAuxClass is an + auxiliary class, it can be attached to an entry that the PDP would + need to access anyway - perhaps an entry containing initial + configuration settings for the PDP, or for a PEP that uses the PDP. + + Once it has retrieved the DN references, the PDP will direct to each + of the objects identified by them an LDAP request that all entries in + its subtree be evaluated against the selection criteria specified in + the request. The LDAP-enabled directory then returns all entries in + that subtree that satisfy the specified criteria. + + The selection criteria always specify that object class="pcimPolicy". + Since all classes representing policy rules, policy conditions, and + policy actions, both in the PCLS and in any domain-specific schema + derived from it, are subclasses of the abstract class policy, this + criterion evaluates to TRUE for all instances of these classes. To + accommodate special cases where a PDP needs to retrieve objects that + are not inherently policy-related (for example, an IP address range + object referenced by a subclass of pcimActionAuxClass representing + the DHCP action "assign from this address range"), the auxiliary + class pcimElementAuxClass can be used to "tag" an entry, so that it + will be found by the selection criterion "object class=pcimPolicy". + + The approach described in the preceding paragraph will not work for + certain directory implementations, because these implementations do + not support matching of auxiliary classes in the objectClass + attribute. For environments where these implementations are expected + to be present, the "tagging" of entries as relevant to policy can be + + + + + +Strassner, et al. Standards Track [Page 17] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + accomplished by inserting the special value "POLICY" into the list of + values contained in the pcimKeywords attribute (provided by the + pcimPolicy class). + + If a PDP needs only a subset of the policy-related objects in the + indicated subtrees, then it can be configured with additional + selection criteria based on the pcimKeywords attribute defined in the + pcimPolicy class. This attribute supports both standardized and + administrator- defined values. For example, a PDP could be + configured to request only those policy-related objects containing + the keywords "DHCP" and "Eastern US". + + To optimize what is expected to be a typical case, the initial + request from the client includes not only the object to which its + "seed" DN references, but also the subtree contained under this + object. The filter for searching this subtree is whatever the client + is going to use later to search the other subtrees: object + class="pcimPolicy" or the presence of the keyword "POLICY", and/or + presence of a more specific value of pcimKeywords (e.g., "QoS Edge + Policy"). + + Returning to the example in Figure 7, we see that in the best case, a + PDP can get all the policy-related objects it needs, and only those + objects, with exactly three LDAP requests: one to its starting + object A to get the references to B and C, as well as the + policy-related objects it needs from the subtree under A, and then + one each to B and C to get all the policy-related objects that pass + the selection criteria with which it was configured. Once it has + retrieved all of these objects, the PDP can then traverse their + various DN references locally to understand the semantic + relationships among them. The PDP should also be prepared to find a + reference to another subtree attached to any of the objects it + retrieves, and to follow this reference first, before it follows any + of the semantically significant references it has received. This + recursion permits a structured approach to identifying related + policies. In Figure 7, for example, if the subtree under B includes + departmental policies and the one under C includes divisional + policies, then there might be a reference from the subtree under C to + an object D that roots the subtree of corporate-level policies. + + A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be + capable of retrieving and processing the entries in the subtrees it + references, and SHOULD be capable of doing all of this recursively. + The same requirements apply to any other entity needing to retrieve + policy information from the directory. Thus, a Policy Management + Tool that retrieves policy entries from the directory in order to + perform validation and conflict detection SHOULD also understand and + be capable of using the pcimSubtreesPtrAuxClass. All of these + + + +Strassner, et al. Standards Track [Page 18] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + requirements are "SHOULD"s rather than "MUST"s because an LDAP client + that doesn't implement them can still access and retrieve the + directory entries it needs. The process of doing so will just be + less efficient than it would have been if the client had implemented + these optimizations. + + When it is serving as a tool for creating policy entries in the + directory, a Policy Management Tool SHOULD support creation of + pcimSubtreesPtrAuxClass entries and their references to object + instances. + +4.5.1. Aliases and Other DIT-Optimization Techniques + + Additional flexibility in DIT structure is available to the policy + administrator via LDAP aliasing and other techniques. Previous + versions of this document have used aliases. However, because + aliases are experimental, the use of aliases has been removed from + this version of this document. This is because the IETF has yet to + produce a specification on how aliases are represented in the + directory or how server implementations are to process aliases. + +5. Class Definitions + + The semantics for the policy information classes that are to be + mapped directly from the information model to an LDAP representation + are detailed in [1]. Consequently, all that this document presents + for these classes is the specification for how to do the mapping from + the information model (which is independent of repository type and + access protocol) to a form that can be accessed using LDAP. Remember + that some new classes needed to be created (that were not part of + [1]) to implement the LDAP mapping. These new LDAP-only classes are + fully documented in this document. + + The formal language for specifying the classes, attributes, and DIT + structure and content rules is that defined in reference [3]. If + your implementation does not support auxiliary class inheritance, you + will have to list auxiliary classes in content rules explicitly or + define them in another (implementation-specific) way. + + The following notes apply to this section in its entirety. + + Note 1: in the following definitions, the class and attribute + definitions follow RFC 2252 [3] but they are line-wrapped to enhance + human readability. + + Note 2: where applicable, the possibilities for specifying DIT + structure and content rules are noted. However, care must be taken + in specifying DIT structure rules. This is because X.501 [4] states + + + +Strassner, et al. Standards Track [Page 19] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + that an entry may only exist in the DIT as a subordinate to another + superior entry (the superior) if a DIT structure rule exists in the + governing subschema which: + + 1) indicates a name form for the structural object class of the + subordinate entry, and + 2) either includes the entry's superior structure rule as a possible + superior structure rule, or + 3) does not specify a superior structure rule. + + If this last case (3) applies, then the entry is defined to be a + subschema administrative point. This is not what is desired. + Therefore, care must be taken in defining structure rules, and in + particular, they must be locally augmented. + + Note 3: Wherever possible, both an equality and a substring matching + rule are defined for a particular attribute (as well as an ordering + match rule to enable sorting of matching results). This provides two + different choices for the developer for maximum flexibility. + + For example, consider the pcimRoles attribute (section 5.3). Suppose + that a PEP has reported that it is interested in pcimRules for three + roles R1, R2, and R3. If the goal is to minimize queries, then the + PDP can supply three substring filters containing the three role + names. + + These queries will return all of the pcimRules that apply to the PEP, + but they may also get some that do not apply (e.g., ones that contain + one of the roles R1, R2, or R3 and one or more other roles present in + a role-combination [1]). + + Another strategy would be for the PDP to use only equality filters. + This approach eliminates the extraneous replies, but it requires the + PDP to explicitly build the desired role-combinations itself. It + also requires extra queries. Note that this approach is practical + only because the role names in a role combination are required to + appear in alphabetical order. + + Note 4: in the following definitions, note that all LDAP matching + rules are defined in [3] and in [9]. The corresponding X.500 + matching rules are defined in [8]. + + Note 5: some of the following attribute definitions specify + additional constraints on various data types (e.g., this integer has + values that are valid from 1..10). Text has been added to instruct + servers and applications what to do if a value outside of this range + + + + + +Strassner, et al. Standards Track [Page 20] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + is encountered. In all cases, if a constraint is violated, then the + policy rule SHOULD be treated as being disabled, meaning that + execution of the policy rule SHOULD be stopped. + +5.1. The Abstract Class pcimPolicy + + The abstract class pcimPolicy is a direct mapping of the abstract + class Policy from the PCIM. The class value "pcimPolicy" is also + used as the mechanism for identifying policy-related instances in the + Directory Information Tree. An instance of any class may be "tagged" + with this class value by attaching to it the auxiliary class + pcimElementAuxClass. Since pcimPolicy is derived from the class + dlm1ManagedElement defined in reference [6], this specification has a + normative dependency on that element of reference [6]. + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.1 NAME 'pcimPolicy' + DESC 'An abstract class that is the base class for all classes + that describe policy-related instances.' + SUP dlm1ManagedElement + ABSTRACT + MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $ + pcimKeywords ) + ) + + The attribute cn is defined in RFC 2256 [7]. The dlmCaption, + dlmDescription, and orderedCimKeys attributes are defined in [6]. + + The pcimKeywords attribute is a multi-valued attribute that contains + a set of keywords to assist directory clients in locating the policy + objects identified by these keywords. It is defined as follows: + + ( 1.3.6.1.1.6.2.3 NAME 'pcimKeywords' + DESC 'A set of keywords to assist directory clients in + locating the policy objects applicable to them.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + ) + + + + + + + + + + +Strassner, et al. Standards Track [Page 21] + +RFC 3703 Policy Core LDAP Schema February 2004 + + +5.2. The Three Policy Group Classes + + PCIM [1] defines the PolicyGroup class to serve as a generalized + aggregation mechanism, enabling PolicyRules and/or PolicyGroups to be + aggregated together. PCLS maps this class into three LDAP classes, + called pcimGroup, pcimGroupAuxClass, and pcimGroupInstance. This is + done in order to provide maximum flexibility for the DIT designer. + + The class definitions for the three policy group classes are listed + below. These class definitions do not include attributes to realize + the PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations + from the PCIM. This is because a pcimGroup object refers to + instances of pcimGroup and pcimRule via, respectively, the attribute + pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object + class and the attribute pcimRulesAuxContainedSet in the + pcimRuleContainmentAuxClass object class. + + To maximize flexibility, the pcimGroup class is defined as abstract. + The subclass pcimGroupAuxClass provides for auxiliary attachment to + another entry, while the structural subclass pcimGroupInstance is + available to represent a policy group as a standalone entry. + + The class definitions are as follows. First, the definition of the + abstract class pcimGroup: + + ( 1.3.6.1.1.6.1.2 NAME 'pcimGroup' + DESC 'A container for a set of related pcimRules and/or + a set of related pcimGroups.' + SUP pcimPolicy + ABSTRACT + MAY ( pcimGroupName ) + ) + + The one attribute of pcimGroup is pcimGroupName. This attribute is + used to define a user-friendly name of this policy group, and may be + used as a naming attribute if desired. It is defined as follows: + + ( 1.3.6.1.1.6.2.4 NAME 'pcimGroupName' + DESC 'The user-friendly name of this policy group.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + ) + + + + + + +Strassner, et al. Standards Track [Page 22] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The two subclasses of pcimGroup are defined as follows. The class + pcimGroupAuxClass is an auxiliary class that can be used to collect a + set of related pcimRule and/or pcimGroup classes. It is defined as + follows: + + ( 1.3.6.1.1.6.1.3 NAME 'pcimGroupAuxClass' + DESC 'An auxiliary class that collects a set of related + pcimRule and/or pcimGroup entries.' + SUP pcimGroup + AUXILIARY + ) + + The class pcimGroupInstance is a structural class that can be used to + collect a set of related pcimRule and/or pcimGroup classes. It is + defined as follows: + + ( 1.3.6.1.1.6.1.4 NAME 'pcimGroupInstance' + DESC 'A structural class that collects a set of related + pcimRule and/or pcimGroup entries.' + SUP pcimGroup + STRUCTURAL + ) + + A DIT content rule could be written to enable an instance of + pcimGroupInstance to have attached to it either references to one or + more policy groups (using pcimGroupContainmentAuxClass) or references + to one or more policy rules (using pcimRuleContainmentAuxClass). + This would be used to formalize the semantics of the PolicyGroup + class [1]. Since these semantics do not include specifying any + properties of the PolicyGroup class, the content rule would not need + to specify any attributes. + + Similarly, three separate DIT structure rules could be written, each + of which would refer to a specific name form that identified one of + the three possible naming attributes (i.e., pcimGroupName, cn, and + orderedCIMKeys) for the pcimGroup object class. This structure rule + SHOULD include a superiorStructureRule (see Note 2 at the beginning + of section 5). The three name forms referenced by the three + structure rules would each define one of the three naming attributes. + +5.3. The Three Policy Rule Classes + + The information model defines a PolicyRule class to represent the "If + Condition then Action" semantics associated with processing policy + information. For maximum flexibility, the PCLS maps this class into + three LDAP classes. + + + + + +Strassner, et al. Standards Track [Page 23] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + To maximize flexibility, the pcimRule class is defined as abstract. + The subclass pcimRuleAuxClass provides for auxiliary attachment to + another entry, while the structural subclass pcimRuleInstance is + available to represent a policy rule as a standalone entry. + + The conditions and actions associated with a policy rule are modeled, + respectively, with auxiliary subclasses of the auxiliary classes + pcimConditionAuxClass and pcimActionAuxClass. Each of these + auxiliary subclasses is attached to an instance of one of three + structural classes. A subclass of pcimConditionAuxClass is attached + to an instance of pcimRuleInstance, to an instance of + pcimRuleConditionAssociation, or to an instance of + pcimPolicyInstance. Similarly, a subclass of pcimActionAuxClass is + attached to an instance of pcimRuleInstance, to an instance of + pcimRuleActionAssociation, or to an instance of pcimPolicyInstance. + + The pcimRuleValidityPeriodList attribute (defined below) realizes the + PolicyRuleValidityPeriod association defined in the PCIM. Since this + association has no additional properties besides those that tie the + association to its associated objects, this association can be + realized by simply using an attribute. Thus, the + pcimRuleValidityPeriodList attribute is simply a multi-valued + attribute that provides an unordered set of DN references to one or + more instances of the pcimTPCAuxClass, indicating when the policy + rule is scheduled to be active and when it is scheduled to be + inactive. A policy rule is scheduled to be active if it is active + according to AT LEAST ONE of the pcimTPCAuxClass instances referenced + by this attribute. + + The PolicyConditionInPolicyRule and PolicyActionInPolicyRule + associations, however, do have additional attributes. The + association PolicyActionInPolicyRule defines an integer attribute to + sequence the actions, and the association PolicyConditionInPolicyRule + has both an integer attribute to group the condition terms as well as + a Boolean property to specify whether a condition is to be negated. + + In the PCLS, these additional association attributes are represented + as attributes of two classes introduced specifically to model these + associations. These classes are the pcimRuleConditionAssociation + class and the pcimRuleActionAssociation class, which are defined in + Sections 5.4 and 5.5, respectively. Thus, they do not appear as + attributes of the class pcimRule. Instead, the pcimRuleConditionList + and pcimRuleActionList attributes can be used to reference these + classes. + + + + + + + +Strassner, et al. Standards Track [Page 24] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The class definitions for the three pcimRule classes are as follows. + + The abstract class pcimRule is a base class for representing the "If + Condition then Action" semantics associated with a policy rule. It + is defined as follows: + + ( 1.3.6.1.1.6.1.5 NAME 'pcimRule' + DESC 'The base class for representing the "If Condition + then Action" semantics associated with a policy rule.' + SUP pcimPolicy + ABSTRACT + MAY ( pcimRuleName $ pcimRuleEnabled $ + pcimRuleConditionListType $ pcimRuleConditionList $ + pcimRuleActionList $ pcimRuleValidityPeriodList $ + pcimRuleUsage $ pcimRulePriority $ + pcimRuleMandatory $ pcimRuleSequencedActions $ + pcimRoles ) + ) + + The PCIM [1] defines seven properties for the PolicyRule class. The + PCLS defines eleven attributes for the pcimRule class, which is the + LDAP equivalent of the PolicyRule class. Of these eleven attributes, + seven are mapped directly from corresponding properties in PCIM's + PolicyRule class. The remaining four attributes are a class-specific + optional naming attribute, and three attributes used to realize the + three associations that the pcimRule class participates in. + + The pcimRuleName attribute is used as a user-friendly name of this + policy rule, and can also serve as the class-specific optional naming + attribute. It is defined as follows: + + ( 1.3.6.1.1.6.2.5 NAME 'pcimRuleName' + DESC 'The user-friendly name of this policy rule.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + ) + + The pcimRuleEnabled attribute is an integer enumeration indicating + whether a policy rule is administratively enabled (value=1), + administratively disabled (value=2), or enabled for debug (value=3). + It is defined as follows: + + ( 1.3.6.1.1.6.2.6 NAME 'pcimRuleEnabled' + DESC 'An integer indicating whether a policy rule is + administratively enabled (value=1), disabled + + + +Strassner, et al. Standards Track [Page 25] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + (value=2), or enabled for debug (value=3).' + EQUALITY integerMatch + ORDERING integerOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE + ) + + Note: All other values for the pcimRuleEnabled attribute are + considered errors, and the administrator SHOULD treat this rule as + being disabled if an invalid value is found. + + The pcimRuleConditionListType attribute is used to indicate whether + the list of policy conditions associated with this policy rule is in + disjunctive normal form (DNF, value=1) or conjunctive normal form + (CNF, value=2). It is defined as follows: + + ( 1.3.6.1.1.6.2.7 NAME 'pcimRuleConditionListType' + DESC 'A value of 1 means that this policy rule is in + disjunctive normal form; a value of 2 means that this + policy rule is in conjunctive normal form.' + EQUALITY integerMatch + ORDERING integerOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE + ) + + Note: any value other than 1 or 2 for the pcimRuleConditionListType + attribute is considered an error. Administrators SHOULD treat this + rule as being disabled if an invalid value is found, since it is + unclear how to structure the condition list. + + The pcimRuleConditionList attribute is a multi-valued attribute that + is used to realize the policyRuleInPolicyCondition association + defined in [1]. It contains a set of DNs of + pcimRuleConditionAssociation entries representing associations + between this policy rule and its conditions. No order is implied. + It is defined as follows: + + ( 1.3.6.1.1.6.2.8 NAME 'pcimRuleConditionList' + DESC 'Unordered set of DNs of pcimRuleConditionAssociation + entries representing associations between this policy + rule and its conditions.' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + ) + + + + + + +Strassner, et al. Standards Track [Page 26] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The pcimRuleActionList attribute is a multi-valued attribute that is + used to realize the policyRuleInPolicyAction association defined in + [1]. It contains a set of DNs of pcimRuleActionAssociation entries + representing associations between this policy rule and its actions. + No order is implied. It is defined as follows: + + ( 1.3.6.1.1.6.2.9 NAME 'pcimRuleActionList' + DESC 'Unordered set of DNs of pcimRuleActionAssociation + entries representing associations between this policy + rule and its actions.' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + ) + + The pcimRuleValidityPeriodList attribute is a multi-valued attribute + that is used to realize the pcimRuleValidityPeriod association that + is defined in [1]. It contains a set of DNs of + pcimRuleValidityAssociation entries that determine when the pcimRule + is scheduled to be active or inactive. No order is implied. It is + defined as follows: + + ( 1.3.6.1.1.6.2.10 NAME 'pcimRuleValidityPeriodList' + DESC 'Unordered set of DNs of pcimRuleValidityAssociation + entries that determine when the pcimRule is scheduled + to be active or inactive.' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + ) + + The pcimRuleUsage attribute is a free-form string providing + guidelines on how this policy should be used. It is defined as + follows: + + ( 1.3.6.1.1.6.2.11 NAME 'pcimRuleUsage' + DESC 'This attribute is a free-form sting providing + guidelines on how this policy should be used.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + ) + + + + + + + + + +Strassner, et al. Standards Track [Page 27] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The pcimRulePriority attribute is a non-negative integer that is used + to prioritize this pcimRule relative to other pcimRules. A larger + value indicates a higher priority. It is defined as follows: + + ( 1.3.6.1.1.6.2.12 NAME 'pcimRulePriority' + DESC 'A non-negative integer for prioritizing this + pcimRule relative to other pcimRules. A larger + value indicates a higher priority.' + EQUALITY integerMatch + ORDERING integerOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE + ) + + Note: if the value of the pcimRulePriority field is 0, then it SHOULD + be treated as "don't care". On the other hand, if the value is + negative, then it SHOULD be treated as an error and Administrators + SHOULD treat this rule as being disabled. + + The pcimRuleMandatory attribute is a Boolean attribute that, if TRUE, + indicates that for this policy rule, the evaluation of its conditions + and execution of its actions (if the condition is satisfied) is + required. If it is FALSE, then the evaluation of its conditions and + execution of its actions (if the condition is satisfied) is not + required. This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.13 NAME 'pcimRuleMandatory' + DESC 'If TRUE, indicates that for this policy rule, the + evaluation of its conditions and execution of its + actions (if the condition is satisfied) is required.' + EQUALITY booleanMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 + SINGLE-VALUE + ) + + The pcimRuleSequencedActions attribute is an integer enumeration that + is used to indicate that the ordering of actions defined by the + pcimActionOrder attribute is either mandatory(value=1), + recommended(value=2), or dontCare(value=3). It is defined as + follows: + + ( 1.3.6.1.1.6.2.14 NAME 'pcimRuleSequencedActions' + DESC 'An integer enumeration indicating that the ordering of + actions defined by the pcimActionOrder attribute is + mandatory(1), recommended(2), or dontCare(3).' + EQUALITY integerMatch + ORDERING integerOrderingMatch + + + + +Strassner, et al. Standards Track [Page 28] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE + ) + + Note: if the value of pcimRulesSequencedActions field is not one of + these three values, then Administrators SHOULD treat this rule as + being disabled. + + The pcimRoles attribute represents the policyRoles property of [1]. + Each value of this attribute represents a role-combination, which 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. + This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.15 NAME 'pcimRoles' + DESC 'Each value of this attribute represents a role- + combination.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + ) + + Note: if the value of the pcimRoles attribute does not conform to the + format "<RoleName>[&&<RoleName>]*" (see Section 6.3.7 of [1]), then + this attribute is malformed and its policy rule SHOULD be treated as + being disabled. + + The two subclasses of the pcimRule class are defined as follows. + First, the pcimRuleAuxClass is an auxiliary class for representing + the "If Condition then Action" semantics associated with a policy + rule. Its class definition is as follows: + + ( 1.3.6.1.1.6.1.6 NAME 'pcimRuleAuxClass' + DESC 'An auxiliary class for representing the "If Condition + then Action" semantics associated with a policy rule.' + SUP pcimRule + AUXILIARY + ) + + The pcimRuleInstance is a structural class for representing the "If + Condition then Action" semantics associated with a policy rule. Its + class definition is as follows: + + ( 1.3.6.1.1.6.1.7 NAME 'pcimRuleInstance' + DESC 'A structural class for representing the "If Condition + then Action" semantics associated with a policy rule.' + + + +Strassner, et al. Standards Track [Page 29] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + SUP pcimRule + STRUCTURAL + ) + + A DIT content rule could be written to enable an instance of + pcimRuleInstance to have attached to it either references to one or + more policy conditions (using pcimConditionAuxClass) or references to + one or more policy actions (using pcimActionAuxClass). This would be + used to formalize the semantics of the PolicyRule class [1]. Since + these semantics do not include specifying any properties of the + PolicyRule class, the content rule would not need to specify any + attributes. + + Similarly, three separate DIT structure rules could be written, each + of which would refer to a specific name form that identified one of + its three possible naming attributes (i.e., pcimRuleName, cn, and + orderedCIMKeys). This structure rule SHOULD include a + superiorStructureRule (see Note 2 at the beginning of section 5). + The three name forms referenced by the three structure rules would + each define one of the three naming attributes. + +5.4. The Class pcimRuleConditionAssociation + + This class contains attributes to represent the properties of the + PCIM's PolicyConditionInPolicyRule association. Instances of this + class are related to an instance of pcimRule via DIT containment. + The policy conditions themselves are represented by auxiliary + subclasses of the auxiliary class pcimConditionAuxClass. These + auxiliary classes are attached directly to instances of + pcimRuleConditionAssociation for rule-specific policy conditions. + For a reusable policy condition, the policyCondition auxiliary + subclass is attached to an instance of the class pcimPolicyInstance + (which is presumably associated with a pcimRepository by DIT + containment), and the policyConditionDN attribute (of this class) is + used to reference the reusable policyCondition instance. + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.8 NAME 'pcimRuleConditionAssociation' + DESC 'This class contains attributes characterizing the + relationship between a policy rule and one of its + policy conditions.' + SUP pcimPolicy + MUST ( pcimConditionGroupNumber $ pcimConditionNegated ) + MAY ( pcimConditionName $ pcimConditionDN ) + ) + + + + + +Strassner, et al. Standards Track [Page 30] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The attributes of this class are defined as follows. + + The pcimConditionGroupNumber attribute is a non-negative integer. It + is used to identify the group to which the condition referenced by + this association is assigned. This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.16 + NAME 'pcimConditionGroupNumber' + DESC 'The number of the group to which a policy condition + belongs. This is used to form the DNF or CNF + expression associated with a policy rule.' + EQUALITY integerMatch + ORDERING integerOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE + ) + + Note that this number is non-negative. A negative value for this + attribute is invalid, and any policy rule that refers to an invalid + entry SHOULD be treated as being disabled. + + The pcimConditionNegated attribute is a Boolean attribute that + indicates whether this policy condition is to be negated or not. If + it is TRUE (FALSE), it indicates that a policy condition IS (IS NOT) + negated in the DNF or CNF expression associated with a policy rule. + This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.17 + NAME 'pcimConditionNegated' + DESC 'If TRUE (FALSE), it indicates that a policy condition + IS (IS NOT) negated in the DNF or CNF expression + associated with a policy rule.' + EQUALITY booleanMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 + SINGLE-VALUE + ) + + The pcimConditionName is a user-friendly name for identifying this + policy condition, and may be used as a naming attribute if desired. + This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.18 + NAME 'pcimConditionName' + DESC 'A user-friendly name for a policy condition.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + + + + +Strassner, et al. Standards Track [Page 31] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + ) + + The pcimConditionDN attribute is a DN that references an instance of + a reusable policy condition. This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.19 + NAME 'pcimConditionDN' + DESC 'A DN that references an instance of a reusable policy + condition.' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE + ) + + A DIT content rule could be written to enable an instance of + pcimRuleConditionAssociation to have attached to it an instance of + the auxiliary class pcimConditionAuxClass, or one of its subclasses. + This would be used to formalize the semantics of the + PolicyConditionInPolicyRule association. Specifically, this would be + used to represent a rule-specific policy condition [1]. + Similarly, three separate DIT structure rules could be written. Each + of these DIT structure rules would refer to a specific name form that + defined two important semantics. First, each name form would + identify one of the three possible naming attributes (i.e., + pcimConditionName, cn, and orderedCIMKeys) for the + pcimRuleConditionAssociation object class. Second, each name form + would require that an instance of the pcimRuleConditionAssociation + class have as its superior an instance of the pcimRule class. This + structure rule SHOULD also include a superiorStructureRule (see Note + 2 at the beginning of section 5). + +5.5. The Class pcimRuleValidityAssociation + + The policyRuleValidityPeriod aggregation is mapped to the PCLS + pcimRuleValidityAssociation class. This class represents the + scheduled activation and deactivation of a policy rule by binding the + definition of times that the policy is active to the policy rule + itself. The "scheduled" times are either identified through an + attached auxiliary class pcimTPCAuxClass, or are referenced through + its pcimTimePeriodConditionDN attribute. + + This class is defined as follows: + + ( 1.3.6.1.1.6.1.9 NAME 'pcimRuleValidityAssociation' + DESC 'This defines the scheduled activation or deactivation + of a policy rule.' + + + +Strassner, et al. Standards Track [Page 32] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + SUP pcimPolicy + STRUCTURAL + MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN ) + ) + + The attributes of this class are defined as follows: + + The pcimValidityConditionName attribute is used to define a + user-friendly name of this condition, and may be used as a naming + attribute if desired. This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.20 + NAME 'pcimValidityConditionName' + DESC 'A user-friendly name for identifying an instance of + a pcimRuleValidityAssociation entry.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + ) + + The pcimTimePeriodConditionDN attribute is a DN that references a + reusable time period condition. It is defined as follows: + + ( 1.3.6.1.1.6.2.21 + NAME 'pcimTimePeriodConditionDN' + DESC 'A reference to a reusable policy time period + condition.' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE + ) + + A DIT content rule could be written to enable an instance of + pcimRuleValidityAssociation to have attached to it an instance of the + auxiliary class pcimTPCAuxClass, or one of its subclasses. This + would be used to formalize the semantics of the + PolicyRuleValidityPeriod aggregation [1]. + + Similarly, three separate DIT structure rules could be written. Each + of these DIT structure rules would refer to a specific name form that + defined two important semantics. First, each name form would + identify one of the three possible naming attributes (i.e., + pcimValidityConditionName, cn, and orderedCIMKeys) for the + pcimRuleValidityAssociation object class. Second, each name form + would require that an instance of the pcimRuleValidityAssociation + class have as its superior an instance of the pcimRule class. This + + + +Strassner, et al. Standards Track [Page 33] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + structure rule SHOULD also include a superiorStructureRule (see Note + 2 at the beginning of section 5). + +5.6. The Class pcimRuleActionAssociation + + This class contains an attribute to represent the one property of the + PCIM PolicyActionInPolicyRule association, ActionOrder. This + property is used to specify an order for executing the actions + associated with a policy rule. Instances of this class are related + to an instance of pcimRule via DIT containment. The actions + themselves are represented by auxiliary subclasses of the auxiliary + class pcimActionAuxClass. + + These auxiliary classes are attached directly to instances of + pcimRuleActionAssociation for rule-specific policy actions. For a + reusable policy action, the pcimAction auxiliary subclass is attached + to an instance of the class pcimPolicyInstance (which is presumably + associated with a pcimRepository by DIT containment), and the + pcimActionDN attribute (of this class) is used to reference the + reusable pcimCondition instance. + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.10 NAME 'pcimRuleActionAssociation' + DESC 'This class contains attributes characterizing the + relationship between a policy rule and one of its + policy actions.' + SUP pcimPolicy + MUST ( pcimActionOrder ) + MAY ( pcimActionName $ pcimActionDN ) + ) + + The pcimActionName attribute is used to define a user-friendly name + of this action, and may be used as a naming attribute if desired. + This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.22 + NAME 'pcimActionName' + DESC 'A user-friendly name for a policy action.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + ) + + + + + + +Strassner, et al. Standards Track [Page 34] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The pcimActionOrder attribute is an unsigned integer that is used to + indicate the relative position of an action in a sequence of actions + that are associated with a given policy rule. When this number is + positive, it indicates a place in the sequence of actions to be + performed, with smaller values indicating earlier positions in the + sequence. If the value is zero, then this indicates that the order + is irrelevant. Note that if two or more actions have the same + non-zero value, they may be performed in any order as long as they + are each performed in the correct place in the overall sequence of + actions. This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.23 + NAME 'pcimActionOrder' + DESC 'An integer indicating the relative order of an action + in the context of a policy rule.' + EQUALITY integerMatch + ORDERING integerOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE + ) + + Note: if the value of the pcimActionOrder field is negative, then it + SHOULD be treated as an error and any policy rule that refers to such + an entry SHOULD be treated as being disabled. + + The pcimActionDN attribute is a DN that references a reusable policy + action. It is defined as follows: + + ( 1.3.6.1.1.6.2.24 + NAME 'pcimActionDN' + DESC 'A DN that references a reusable policy action.' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + SINGLE-VALUE + ) + + A DIT content rule could be written to enable an instance of + pcimRuleActionAssociation to have attached to it an instance of the + auxiliary class pcimActionAuxClass, or one of its subclasses. This + would be used to formalize the semantics of the + PolicyActionInPolicyRule association. Specifically, this would be + used to represent a rule-specific policy action [1]. + + Similarly, three separate DIT structure rules could be written. Each + of these DIT structure rules would refer to a specific name form that + defined two important semantics. First, each name form would + identify one of the three possible naming attributes (i.e., + pcimActionName, cn, and orderedCIMKeys) for the + + + +Strassner, et al. Standards Track [Page 35] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + pcimRuleActionAssociation object class. Second, each name form would + require that an instance of the pcimRuleActionAssociation class have + as its superior an instance of the pcimRule class. This structure + rule should also include a superiorStructureRule (see Note 2 at the + beginning of section 5). + +5.7. The Auxiliary Class pcimConditionAuxClass + + The purpose of a policy condition is to determine whether or not the + set of actions (contained in the pcimRule that the condition applies + to) should be executed or not. This class defines the basic + organizational semantics of a policy condition, as specified in [1]. + Subclasses of this auxiliary class can be attached to instances of + three other classes in the PCLS. When a subclass of this class is + attached to an instance of pcimRuleConditionAssociation, or to an + instance of pcimRule, it represents a rule-specific policy condition. + When a subclass of this class is attached to an instance of + pcimPolicyInstance, it represents a reusable policy condition. + + Since all of the classes to which subclasses of this auxiliary class + may be attached are derived from the pcimPolicy class, the attributes + of pcimPolicy will already be defined for the entries to which these + subclasses attach. Thus, this class is derived directly from "top". + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.11 NAME 'pcimConditionAuxClass' + DESC 'A class representing a condition to be evaluated in + conjunction with a policy rule.' + SUP top + AUXILIARY + ) + +5.8. The Auxiliary Class pcimTPCAuxClass + + The PCIM defines a time period class, PolicyTimePeriodCondition, to + provide a means of representing the time periods during which a + policy rule is valid, i.e., active. It also defines an aggregation, + PolicyRuleValidityPeriod, so that time periods can be associated with + a PolicyRule. The LDAP mapping also provides two classes, one for + the time condition itself, and one for the aggregation. + + In the PCIM, the time period class is named + PolicyTimePeriodCondition. However, the resulting name of the + auxiliary class in this mapping (pcimTimePeriodConditionAuxClass) + exceeds the length of a name that some directories can store. + Therefore, the name has been shortened to pcimTPCAuxClass. + + + + +Strassner, et al. Standards Track [Page 36] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.12 NAME 'pcimTPCAuxClass' + DESC 'This provides the capability of enabling or disabling + a policy rule according to a predetermined schedule.' + SUP pcimConditionAuxClass + AUXILIARY + MAY ( pcimTPCTime $ pcimTPCMonthOfYearMask $ + pcimTPCDayOfMonthMask $ pcimTPCDayOfWeekMask $ + pcimTPCTimeOfDayMask $ pcimTPCLocalOrUtcTime ) + ) + + The attributes of the pcimTPCAuxClass are defined as follows. + + The pcimTPCTime attribute represents the time period that a policy + rule is enabled for. This attribute is defined as a string in [1] + with a special format which defines a time period with a starting + date and an ending date separated by a forward slash ("/"), as + follows: + + yyyymmddThhmmss/yyyymmddThhmmss + + where the first date and time may be replaced with the string + "THISANDPRIOR" or the second date and time may be replaced with the + string "THISANDFUTURE". This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.25 + NAME 'pcimTPCTime' + DESC 'The start and end times on which a policy rule is + valid.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 + SINGLE-VALUE + ) + + The value of this attribute SHOULD be checked against its defined + format ("yyyymmddThhmmss/yyyymmddThhmmss", where the first and second + date strings may be replaced with the strings "THISANDPRIOR" and + "THISANDFUTURE"). If the value of this attribute does not conform to + this syntax, then this SHOULD be considered an error and the policy + rule SHOULD be treated as being disabled. + + The next four attributes (pcimTPCMonthOfYearMask, + pcimTPCDayOfMonthMask, pcimTPCDayOfWeekMask, and + pcimTPCTimeOfDayMask) are all defined as octet strings in [1]. + However, the semantics of each of these attributes are contained in + + + +Strassner, et al. Standards Track [Page 37] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + bit strings of various fixed lengths. Therefore, the PCLS uses a + syntax of Bit String to represent each of them. The definition of + these four attributes are as follows. + + The pcimTPCMonthOfYearMask attribute defines a 12-bit mask + identifying the months of the year in which a policy rule is valid. + The format is a bit string of length 12, representing the months of + the year from January through December. The definition of this + attribute is as follows: + + ( 1.3.6.1.1.6.2.26 + NAME 'pcimTPCMonthOfYearMask' + DESC 'This identifies the valid months of the year for a + policy rule using a 12-bit string that represents the + months of the year from January through December.' + EQUALITY bitStringMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 + SINGLE-VALUE + ) + + The value of this attribute SHOULD be checked against its defined + format. If the value of this attribute does not conform to this + syntax, then this SHOULD be considered an error and the policy rule + SHOULD be treated as being disabled. + + The pcimTPCMonthOfDayMask attribute defines a mask identifying the + days of the month on which a policy rule is valid. The format is a + bit string of length 62. The first 31 positions represent the days + of the month in ascending order, from day 1 to day 31. The next 31 + positions represent the days of the month in descending order, from + the last day to the day 31 days from the end. The definition of this + attribute is as follows: + + ( 1.3.6.1.1.6.2.27 + NAME 'pcimTPCDayOfMonthMask' + DESC 'This identifies the valid days of the month for a + policy rule using a 62-bit string. The first 31 + positions represent the days of the month in ascending + order, and the next 31 positions represent the days of + the month in descending order.' + EQUALITY bitStringMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 + SINGLE-VALUE + ) + + + + + + + +Strassner, et al. Standards Track [Page 38] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The value of this attribute SHOULD be checked against its defined + format. If the value of this attribute does not conform to this + syntax, then this SHOULD be considered an error and the policy rule + SHOULD be treated as being disabled. + + The pcimTPCDayOfWeekMask attribute defines a mask identifying the + days of the week on which a policy rule is valid. The format is a + bit string of length 7, representing the days of the week from Sunday + through Saturday. The definition of this attribute is as follows: + + ( 1.3.6.1.1.6.2.28 + NAME 'pcimTPCDayOfWeekMask' + DESC 'This identifies the valid days of the week for a + policy rule using a 7-bit string. This represents + the days of the week from Sunday through Saturday.' + EQUALITY bitStringMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 + SINGLE-VALUE + ) + + The value of this attribute SHOULD be checked against its defined + format. If the value of this attribute does not conform to this + syntax, then this SHOULD be considered an error and the policy rule + SHOULD be treated as being disabled. + + The pcimTPCTimeOfDayMask attribute defines 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. The format of the string is + Thhmmss/Thhmmss. The definition of this attribute is as follows: + + ( 1.3.6.1.1.6.2.29 + NAME 'pcimTPCTimeOfDayMask' + DESC 'This identifies the valid range of times for a policy + using the format Thhmmss/Thhmmss.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 + SINGLE-VALUE + ) + + The value of this attribute SHOULD be checked against its defined + format. If the value of this attribute does not conform to this + syntax, then this SHOULD be considered an error and the policy rule + SHOULD be treated as being disabled. + + + + + + +Strassner, et al. Standards Track [Page 39] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + Finally, the pcimTPCLocalOrUtcTime attribute is used to choose + between local or UTC time representation. This is mapped as a simple + integer syntax, with the value of 1 representing local time and the + value of 2 representing UTC time. The definition of this attribute + is as follows: + + ( 1.3.6.1.1.6.2.30 + NAME 'pcimTPCLocalOrUtcTime' + DESC 'This defines whether the times in this instance + represent local (value=1) times or UTC (value=2) + times.' + EQUALITY integerMatch + ORDERING integerOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 + SINGLE-VALUE + ) + + Note: if the value of the pcimTPCLocalOrUtcTime is not 1 or 2, then + this SHOULD be considered an error and the policy rule SHOULD be + disabled. If the attribute is not present at all, then all times are + interpreted as if it were present with the value 2, that is, UTC + time. + +5.9. The Auxiliary Class pcimConditionVendorAuxClass + + This class provides a general extension mechanism for representing + policy conditions that have not been modeled with specific + properties. Instead, its two properties are used to define the + content and format of the condition, as explained below. This class + is intended for vendor-specific extensions that are not amenable to + using pcimCondition; standardized extensions SHOULD NOT use this + class. + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.13 NAME 'pcimConditionVendorAuxClass' + DESC 'A class that defines a registered means to describe a + policy condition.' + SUP pcimConditionAuxClass + AUXILIARY + MAY ( pcimVendorConstraintData $ + pcimVendorConstraintEncoding ) + ) + + The pcimVendorConstraintData attribute is a multi-valued attribute. + It provides a general mechanism for representing policy conditions + that have not been modeled as specific attributes. This information + is encoded in a set of octet strings. The format of the octet + + + +Strassner, et al. Standards Track [Page 40] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + strings is identified by the OID stored in the + pcimVendorConstraintEncoding attribute. This attribute is defined as + follows: + + ( 1.3.6.1.1.6.2.31 + NAME 'pcimVendorConstraintData' + DESC 'Mechanism for representing constraints that have not + been modeled as specific attributes. Their format is + identified by the OID stored in the attribute + pcimVendorConstraintEncoding.' + EQUALITY octetStringMatch + ORDERING octetStringOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 + ) + + The pcimVendorConstraintEncoding attribute is used to identify the + format and semantics for the pcimVendorConstraintData attribute. + This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.32 + NAME 'pcimVendorConstraintEncoding' + DESC 'An OID identifying the format and semantics for the + pcimVendorConstraintData for this instance.' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + SINGLE-VALUE + ) + +5.10. The Auxiliary Class pcimActionAuxClass + + 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 policy state. This class is used to + represent an action to be performed as a result of a policy rule + whose condition clause was satisfied. + + Subclasses of this auxiliary class can be attached to instances of + three other classes in the PCLS. When a subclass of this class is + attached to an instance of pcimRuleActionAssociation, or to an + instance of pcimRule, it represents a rule-specific policy action. + When a subclass of this class is attached to an instance of + pcimPolicyInstance, it represents a reusable policy action. + + Since all of the classes to which subclasses of this auxiliary class + may be attached are derived from the pcimPolicy class, the attributes + of the pcimPolicy class will already be defined for the entries to + which these subclasses attach. Thus, this class is derived directly + from "top". + + + +Strassner, et al. Standards Track [Page 41] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.14 NAME 'pcimActionAuxClass' + DESC 'A class representing an action to be performed as a + result of a policy rule.' + SUP top + AUXILIARY + ) + +5.11. The Auxiliary Class pcimActionVendorAuxClass + + 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, its two properties 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 that are not amenable to using the standard pcimAction + class. Standardized extensions SHOULD NOT use this class. + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.15 NAME 'pcimActionVendorAuxClass' + DESC 'A class that defines a registered means to describe a + policy action.' + SUP pcimActionAuxClass + AUXILIARY + MAY ( pcimVendorActionData $ pcimVendorActionEncoding ) + ) + + The pcimVendorActionData attribute is a multi-valued attribute. It + provides a general mechanism for representing policy actions that + have not been modeled as specific attributes. This information is + encoded in a set of octet strings. The format of the octet strings + is identified by the OID stored in the pcimVendorActionEncoding + attribute. This attribute is defined as follows: + + ( 1.3.6.1.1.6.2.33 + NAME 'pcimVendorActionData' + DESC ' Mechanism for representing policy actions that have + not been modeled as specific attributes. Their + format is identified by the OID stored in the + attribute pcimVendorActionEncoding.' + EQUALITY octetStringMatch + ORDERING octetStringOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 + ) + + + + +Strassner, et al. Standards Track [Page 42] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The pcimVendorActionEncoding attribute is used to identify the format + and semantics for the pcimVendorActionData attribute. This attribute + is defined as follows: + + ( 1.3.6.1.1.6.2.34 + NAME 'pcimVendorActionEncoding' + DESC 'An OID identifying the format and semantics for the + pcimVendorActionData attribute of this instance.' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + SINGLE-VALUE + ) + +5.12. The Class pcimPolicyInstance + + This class is not defined in the PCIM. Its role is to serve as a + structural class to which auxiliary classes representing policy + information are attached when the information is reusable. For + auxiliary classes representing policy conditions and policy actions, + there are alternative structural classes that may be used. See + Section 4.4 for a complete discussion of reusable policy conditions + and actions, and of the role that this class plays in how they are + represented. + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.16 NAME 'pcimPolicyInstance' + DESC 'A structural class to which aux classes containing + reusable policy information can be attached.' + SUP pcimPolicy + MAY ( pcimPolicyInstanceName ) + ) + + The pcimPolicyInstanceName attribute is used to define a + user-friendly name of this class, and may be used as a naming + attribute if desired. It is defined as follows: + + ( 1.3.6.1.1.6.2.35 NAME 'pcimPolicyInstanceName' + DESC 'The user-friendly name of this policy instance.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + ) + + + + + + +Strassner, et al. Standards Track [Page 43] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + A DIT content rule could be written to enable an instance of + pcimPolicyInstance to have attached to it either instances of one or + more of the auxiliary object classes pcimConditionAuxClass and + pcimActionAuxClass. Since these semantics do not include specifying + any properties, the content rule would not need to specify any + attributes. Note that other content rules could be defined to enable + other policy-related auxiliary classes to be attached to + pcimPolicyInstance. + + Similarly, three separate DIT structure rules could be written. Each + of these DIT structure rules would refer to a specific name form that + defined two important semantics. First, each name form would + identify one of the three possible naming attributes (i.e., + pcimPolicyInstanceName, cn, and orderedCIMKeys) for this object + class. Second, each name form would require that an instance of the + pcimPolicyInstance class have as its superior an instance of the + pcimRepository class. This structure rule SHOULD also include a + superiorStructureRule (see Note 2 at the beginning of section 5). + +5.13. The Auxiliary Class pcimElementAuxClass + + This class introduces no additional attributes, beyond those defined + in the class pcimPolicy from which it is derived. Its role is to + "tag" an instance of a class defined outside the realm of policy + information as represented by PCIM as being nevertheless relevant to + a policy specification. This tagging can potentially take place at + two levels: + + - Every instance to which pcimElementAuxClass is attached becomes + an instance of the class pcimPolicy, since pcimElementAuxClass is + a subclass of pcimPolicy. Searching for object + class="pcimPolicy" will return the instance. (As noted earlier, + this approach does NOT work for some directory implementations. + To accommodate these implementations, policy-related entries + SHOULD be tagged with the pcimKeyword "POLICY".) + + - With the pcimKeywords attribute that it inherits from pcimPolicy, + an instance to which pcimElementAuxClass is attached can be + tagged as being relevant to a particular type or category of + policy information, using standard keywords, + administrator-defined keywords, or both. + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.17 NAME 'pcimElementAuxClass' + DESC 'An auxiliary class used to tag instances of classes + defined outside the realm of policy as relevant to a + particular policy specification.' + + + +Strassner, et al. Standards Track [Page 44] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + SUP pcimPolicy + AUXILIARY + ) + +5.14. The Three Policy Repository Classes + + These classes provide a container for reusable policy information, + such as reusable policy conditions and/or reusable policy actions. + This document is concerned with mapping just the properties that + appear in these classes. Conceptually, this may be thought of as a + special location in the DIT where policy information may reside. + Since pcimRepository is derived from the class dlm1AdminDomain + defined in reference [6], this specification has a normative + dependency on that element of reference [6] (as well as on its entire + derivation hierarchy, which also appears in reference [6]). To + maximize flexibility, the pcimRepository class is defined as + abstract. A subclass pcimRepositoryAuxClass provides for auxiliary + attachment to another entry, while a structural subclass + pcimRepositoryInstance is available to represent a policy repository + as a standalone entry. + + The definition for the pcimRepository class is as follows: + + ( 1.3.6.1.1.6.1.18 NAME 'pcimRepository' + DESC 'A container for reusable policy information.' + SUP dlm1AdminDomain + ABSTRACT + MAY ( pcimRepositoryName ) + ) + + The pcimRepositoryName attribute is used to define a user-friendly + name of this class, and may be used as a naming attribute if desired. + It is defined as follows: + + ( 1.3.6.1.1.6.2.36 NAME 'pcimRepositoryName' + DESC 'The user-friendly name of this policy repository.' + EQUALITY caseIgnoreMatch + ORDERING caseIgnoreOrderingMatch + SUBSTR caseIgnoreSubstringsMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 + SINGLE-VALUE + ) + + + + + + + + + +Strassner, et al. Standards Track [Page 45] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The two subclasses of pcimRepository are defined as follows. First, + the pcimRepositoryAuxClass is an auxiliary class that can be used to + aggregate reusable policy information. It is defined as follows: + + ( 1.3.6.1.1.6.1.19 NAME 'pcimRepositoryAuxClass' + DESC 'An auxiliary class that can be used to aggregate + reusable policy information.' + SUP pcimRepository + AUXILIARY + ) + + In cases where structural classes are needed instead of an auxiliary + class, the pcimRepositoryInstance class is a structural class that + can be used to aggregate reusable policy information. It is defined + as follows: + + ( 1.3.6.1.1.6.1.20 NAME 'pcimRepositoryInstance' + DESC 'A structural class that can be used to aggregate + reusable policy information.' + SUP pcimRepository + STRUCTURAL + ) + + Three separate DIT structure rules could be written for this class. + Each of these DIT structure rules would refer to a specific name form + that enabled an instance of the pcimRepository class to be named + under any superior using one of the three possible naming attributes + (i.e., pcimRepositoryName, cn, and orderedCIMKeys). This structure + rule SHOULD also include a superiorStructureRule (see Note 2 at the + beginning of section 5). + +5.15. The Auxiliary Class pcimSubtreesPtrAuxClass + + This auxiliary class provides a single, multi-valued attribute that + references a set of objects that are at the root of DIT subtrees + containing policy-related information. By attaching this attribute + to instances of various other classes, a policy administrator has a + flexible way of providing an entry point into the directory that + allows a client to locate and retrieve the policy information + relevant to it. + + It is intended that these entries are placed in the DIT such that + well-known DNs can be used to reference a well-known structural entry + that has the pcimSubtreesPtrAuxClass attached to it. In effect, this + defines a set of entry points. Each of these entry points can + contain and/or reference all related policy entries for + + + + + +Strassner, et al. Standards Track [Page 46] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + any well-known policy domains. The pcimSubtreesPtrAuxClass functions + as a tag to identify portions of the DIT that contain policy + information. + + This object does not provide the semantic linkages between individual + policy objects, such as those between a policy group and the policy + rules that belong to it. Its only role is to enable efficient bulk + retrieval of policy-related objects, as described in Section 4.5. + + Once the objects have been retrieved, a directory client can + determine the semantic linkages by following references contained in + multi-valued attributes, such as pcimRulesAuxContainedSet. + + Since policy-related objects will often be included in the DIT + subtree beneath an object to which this auxiliary class is attached, + a client SHOULD request the policy-related objects from the subtree + under the object with these references at the same time that it + requests the references themselves. + + Since clients are expected to behave in this way, the policy + administrator SHOULD make sure that this subtree does not contain so + many objects unrelated to policy that an initial search done in this + way results in a performance problem. The pcimSubtreesPtrAuxClass + SHOULD NOT be attached to the partition root for a large directory + partition containing a relatively few number of policy-related + objects along with a large number of objects unrelated to policy + (again, "policy" here refers to the PCIM, not the X.501, definition + and use of "policy"). A better approach would be to introduce a + container object immediately below the partition root, attach + pcimSubtreesPtrAuxClass to this container object, and then place all + of the policy-related objects in that subtree. + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.21 NAME 'pcimSubtreesPtrAuxClass' + DESC 'An auxiliary class providing DN references to roots of + DIT subtrees containing policy-related objects.' + SUP top + AUXILIARY + MAY ( pcimSubtreesAuxContainedSet ) + ) + + + + + + + + + + +Strassner, et al. Standards Track [Page 47] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The attribute pcimSubtreesAuxContainedSet provides an unordered set + of DN references to instances of one or more objects under which + policy-related information is present. The objects referenced may or + may not themselves contain policy-related information. The attribute + definition is as follows: + + ( 1.3.6.1.1.6.2.37 + NAME 'pcimSubtreesAuxContainedSet' + DESC 'DNs of objects that serve as roots for DIT subtrees + containing policy-related objects.' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + ) + + Note that the cn attribute does NOT need to be defined for this + class. This is because an auxiliary class is used as a means to + collect common attributes and treat them as properties of an object. + A good analogy is a #include file, except that since an auxiliary + class is a class, all the benefits of a class (e.g., inheritance) can + be applied to an auxiliary class. + +5.16. The Auxiliary Class pcimGroupContainmentAuxClass + + This auxiliary class provides a single, multi-valued attribute that + references a set of pcimGroups. By attaching this attribute to + instances of various other classes, a policy administrator has a + flexible way of providing an entry point into the directory that + allows a client to locate and retrieve the pcimGroups relevant to it. + + As is the case with pcimRules, a policy administrator might have + several different references to a pcimGroup in the overall directory + structure. The pcimGroupContainmentAuxClass is the mechanism that + makes it possible for the policy administrator to define all these + different references. + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.22 NAME 'pcimGroupContainmentAuxClass' + DESC 'An auxiliary class used to bind pcimGroups to an + appropriate container object.' + SUP top + AUXILIARY + MAY ( pcimGroupsAuxContainedSet ) + ) + + + + + + + +Strassner, et al. Standards Track [Page 48] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The attribute pcimGroupsAuxContainedSet provides an unordered set of + references to instances of one or more pcimGroups associated with the + instance of a structural class to which this attribute has been + appended. + + The attribute definition is as follows: + + ( 1.3.6.1.1.6.2.38 + NAME 'pcimGroupsAuxContainedSet' + DESC 'DNs of pcimGroups associated in some way with the + instance to which this attribute has been appended.' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + ) + + Note that the cn attribute does NOT have to be defined for this class + for the same reasons as those given for the pcimSubtreesPtrAuxClass + in section 5.15. + +5.17. The Auxiliary Class pcimRuleContainmentAuxClass + + This auxiliary class provides a single, multi-valued attribute that + references a set of pcimRules. By attaching this attribute to + instances of various other classes, a policy administrator has a + flexible way of providing an entry point into the directory that + allows a client to locate and retrieve the pcimRules relevant to it. + + A policy administrator might have several different references to a + pcimRule in the overall directory structure. For example, there + might be references to all pcimRules for traffic originating in a + particular subnet from a directory entry that represents that subnet. + At the same time, there might be references to all pcimRules related + to a particular DiffServ setting from an instance of a pcimGroup + explicitly introduced as a container for DiffServ-related pcimRules. + The pcimRuleContainmentAuxClass is the mechanism that makes it + possible for the policy administrator to define all these separate + references. + + The class definition is as follows: + + ( 1.3.6.1.1.6.1.23 NAME 'pcimRuleContainmentAuxClass' + DESC 'An auxiliary class used to bind pcimRules to an + appropriate container object.' + SUP top + AUXILIARY + MAY ( pcimRulesAuxContainedSet ) + ) + + + + +Strassner, et al. Standards Track [Page 49] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The attribute pcimRulesAuxContainedSet provides an unordered set of + references to one or more instances of pcimRules associated with the + instance of a structural class to which this attribute has been + appended. The attribute definition is as follows: + + ( 1.3.6.1.1.6.2.39 + NAME 'pcimRulesAuxContainedSet' + DESC 'DNs of pcimRules associated in some way with the + instance to which this attribute has been appended.' + EQUALITY distinguishedNameMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 + ) + + The cn attribute does NOT have to be defined for this class for the + same reasons as those given for the pcimSubtreesPtrAuxClass in + section 5.15. + +6. Extending the Classes Defined in This Document + + The following subsections provide general guidance on how to create a + domain-specific schema derived from this document, discuss how the + vendor classes in the PCLS should be used, and explain how + policyTimePeriodConditions are related to other policy conditions. + +6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass + + In Section 4.4, there is a discussion of how, by representing policy + conditions and policy actions as auxiliary classes in a schema, the + flexibility is retained to instantiate a particular condition or + action as either rule-specific or reusable. This flexibility is lost + if a condition or action class is defined as structural rather than + auxiliary. For standardized schemata, this document specifies that + domain-specific information MUST be expressed in auxiliary subclasses + of pcimConditionAuxClass and pcimActionAuxClass. It is RECOMMENDED + that non-standardized schemata follow this practice as well. + +6.2. Using the Vendor Policy Attributes + + As discussed Section 5.9, the attributes pcimVendorConstraintData and + pcimVendorConstraintEncoding are included in the + pcimConditionVendorAuxClass to provide a mechanism for representing + vendor-specific policy conditions that are not amenable to being + represented with the pcimCondition class (or its subclasses). The + attributes pcimVendorActionData and pcimVendorActionEncoding in the + pcimActionVendorAuxClass class play the same role with respect to + actions. This enables interoperability between different vendors who + could not otherwise interoperate. + + + + +Strassner, et al. Standards Track [Page 50] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + For example, imagine a network composed of access devices from vendor + A, edge and core devices from vendor B, and a policy server from + vendor C. It is desirable for this policy server to be able to + configure and manage all of the devices from vendors A and B. + Unfortunately, these devices will in general have little in common + (e.g., different mechanisms, different ways for controlling those + mechanisms, different operating systems, different commands, and so + forth). The extension conditions provide a way for vendor-specific + commands to be encoded as octet strings, so that a single policy + server can commonly manage devices from different vendors. + +6.3. Using Time Validity Periods + + Time validity periods are defined as an auxiliary subclass of + pcimConditionAuxClass, called pcimTPCAuxClass. This is to allow + their inclusion in the AND/OR condition definitions for a pcimRule. + Care should be taken not to subclass pcimTPCAuxClass to add + domain-specific condition properties. + + For example, it would be incorrect to add IPsec- or QoS-specific + condition properties to the pcimTPCAuxClass class, just because IPsec + or QoS includes time in its condition definition. The correct + subclassing would be to create IPsec or QoS-specific subclasses of + pcimConditionAuxClass and then combine instances of these + domain-specific condition classes with the appropriate validity + period criteria. This is accomplished using the AND/OR association + capabilities for policy conditions in pcimRules. + +7. Security Considerations + + The PCLS, presented in this document, provides a mapping of the + object-oriented model for describing policy information (PCIM) into a + data model that forms the basic framework for describing the + structure of policy data, in the case where the policy repository + takes the form of an LDAP-accessible directory. + + PCLS is not intended to represent any particular system design or + implementation. PCLS is not directly useable in a real world system, + without the discipline-specific mappings that are works in progress + in the Policy Framework Working Group of the IETF. + + These other derivative documents, which use PCIM and its + discipline-specific extensions as a base, will need to convey more + specific security considerations (refer to RFC 3060 for more + information.) + + + + + + +Strassner, et al. Standards Track [Page 51] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + The reason that PCLS, as defined here, is not representative of any + real-world system, is that its object classes were designed to be + independent of any specific discipline, or policy domain. For + example, DiffServ and IPsec represent two different policy domains. + Each document that extends PCIM to one of these domains will derive + subclasses from the classes and relationships defined in PCIM, in + order to represent extensions of a generic model to cover specific + technical domains. + + PCIM-derived documents will thus subclass the PCIM classes into + classes specific to each technical policy domain (QOS, IPsec, etc.), + which will, in turn, be mapped, to directory-specific schemata + consistent with the PCLS documented here. + + Even though discipline-specific security requirements are not + appropriate for PCLS, specific security requirements MUST be defined + for each operational real-world application of PCIM. Just as there + will be a wide range of operational, real-world systems using PCIM, + there will also be a wide range of security requirements for these + systems. Some operational, real-world systems that are deployed + using PCLS may have extensive security requirements that impact + nearly all object classes utilized by such a system, while other + systems' security requirements might have very little impact. + + The derivative documents, discussed above, will create the context + for applying operational, real-world, system-level security + requirements against the various models that derive from PCIM, + consistent with PCLS. + + In some real-world scenarios, the values associated with certain + properties, within certain instantiated object classes, may represent + information associated with scarce, and/or costly (and therefore + valuable) resources. It may be the case that these values must not + be disclosed to, or manipulated by, unauthorized parties. + + Since this document forms the basis for the representation of a + policy data model in a specific format (an LDAP-accessible + directory), it is herein appropriate to reference the data + model-specific tools and mechanisms that are available for achieving + the authentication and authorization implicit in a requirement that + restricts read and/or read- write access to these values stored in a + directory. + + + + + + + + + +Strassner, et al. Standards Track [Page 52] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + General LDAP security considerations apply, as documented in RFC 3377 + [2]. LDAP-specific authentication and authorization tools and + mechanisms are found in the following standards track documents, + which are appropriate for application to the management of security + applied to policy data models stored in an LDAP-accessible directory: + + - RFC 2829 (Authentication Methods for LDAP) + - RFC 2830 (Lightweight Directory Access Protocol (v3): Extension + for Transport Layer Security) + + Any identified security requirements that are not dealt with in the + appropriate discipline-specific information model documents, or in + this document, MUST be dealt with in the derivative data model + documents which are specific to each discipline. + +8. IANA Considerations + + Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access Protocol (LDAP)" + [16]. + +8.1. Object Identifiers + + The IANA has registered an LDAP Object Identifier for use in this + technical specification according to the following template: + + Subject: Request for LDAP OID Registration + Person & email address to contact for further information: + Bob Moore (remoore@us.ibm.com) + Specification: RFC 3703 + Author/Change Controller: IESG + Comments: + The assigned OID will be used as a base for identifying + a number of schema elements defined in this document. + + IANA has assigned an OID of 1.3.6.1.1.6 with the name of pcimSchema + to this registration as recorded in the following registry: + + http://www.iana.org/assignments/smi-numbers + +8.2. Object Identifier Descriptors + + The IANA has registered the LDAP Descriptors used in this technical + specification as detailed in the following template: + + Subject: Request for LDAP Descriptor Registration Update + Descriptor (short name): see comment + Object Identifier: see comment + + + +Strassner, et al. Standards Track [Page 53] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + Person & email address to contact for further information: + Bob Moore (remoore@us.ibm.com) + Usage: see comment + Specification: RFC 3703 + Author/Change Controller: IESG + Comments: + + The following descriptors have been added: + + NAME Type OID + -------------- ---- ------------ + pcimPolicy O 1.3.6.1.1.6.1.1 + pcimGroup O 1.3.6.1.1.6.1.2 + pcimGroupAuxClass O 1.3.6.1.1.6.1.3 + pcimGroupInstance O 1.3.6.1.1.6.1.4 + pcimRule O 1.3.6.1.1.6.1.5 + pcimRuleAuxClass O 1.3.6.1.1.6.1.6 + pcimRuleInstance O 1.3.6.1.1.6.1.7 + pcimRuleConditionAssociation O 1.3.6.1.1.6.1.8 + pcimRuleValidityAssociation O 1.3.6.1.1.6.1.9 + pcimRuleActionAssociation O 1.3.6.1.1.6.1.10 + pcimConditionAuxClass O 1.3.6.1.1.6.1.11 + pcimTPCAuxClass O 1.3.6.1.1.6.1.12 + pcimConditionVendorAuxClass O 1.3.6.1.1.6.1.13 + pcimActionAuxClass O 1.3.6.1.1.6.1.14 + pcimActionVendorAuxClass O 1.3.6.1.1.6.1.15 + pcimPolicyInstance O 1.3.6.1.1.6.1.16 + pcimElementAuxClass O 1.3.6.1.1.6.1.17 + pcimRepository O 1.3.6.1.1.6.1.18 + pcimRepositoryAuxClass O 1.3.6.1.1.6.1.19 + pcimRepositoryInstance O 1.3.6.1.1.6.1.20 + pcimSubtreesPtrAuxClass O 1.3.6.1.1.6.1.21 + pcimGroupContainmentAuxClass O 1.3.6.1.1.6.1.22 + pcimRuleContainmentAuxClass O 1.3.6.1.1.6.1.23 + pcimKeywords A 1.3.6.1.1.6.2.3 + pcimGroupName A 1.3.6.1.1.6.2.4 + pcimRuleName A 1.3.6.1.1.6.2.5 + pcimRuleEnabled A 1.3.6.1.1.6.2.6 + pcimRuleConditionListType A 1.3.6.1.1.6.2.7 + pcimRuleConditionList A 1.3.6.1.1.6.2.8 + pcimRuleActionList A 1.3.6.1.1.6.2.9 + pcimRuleValidityPeriodList A 1.3.6.1.1.6.2.10 + pcimRuleUsage A 1.3.6.1.1.6.2.11 + pcimRulePriority A 1.3.6.1.1.6.2.12 + pcimRuleMandatory A 1.3.6.1.1.6.2.13 + pcimRuleSequencedActions A 1.3.6.1.1.6.2.14 + pcimRoles A 1.3.6.1.1.6.2.15 + pcimConditionGroupNumber A 1.3.6.1.1.6.2.16 + + + +Strassner, et al. Standards Track [Page 54] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + NAME Type OID + -------------- ---- ------------ + pcimConditionNegated A 1.3.6.1.1.6.2.17 + pcimConditionName A 1.3.6.1.1.6.2.18 + pcimConditionDN A 1.3.6.1.1.6.2.19 + pcimValidityConditionName A 1.3.6.1.1.6.2.20 + pcimTimePeriodConditionDN A 1.3.6.1.1.6.2.21 + pcimActionName A 1.3.6.1.1.6.2.22 + pcimActionOrder A 1.3.6.1.1.6.2.23 + pcimActionDN A 1.3.6.1.1.6.2.24 + pcimTPCTime A 1.3.6.1.1.6.2.25 + pcimTPCMonthOfYearMask A 1.3.6.1.1.6.2.26 + pcimTPCDayOfMonthMask A 1.3.6.1.1.6.2.27 + pcimTPCDayOfWeekMask A 1.3.6.1.1.6.2.28 + pcimTPCTimeOfDayMask A 1.3.6.1.1.6.2.29 + pcimTPCLocalOrUtcTime A 1.3.6.1.1.6.2.30 + pcimVendorConstraintData A 1.3.6.1.1.6.2.31 + pcimVendorConstraintEncoding A 1.3.6.1.1.6.2.32 + pcimVendorActionData A 1.3.6.1.1.6.2.33 + pcimVendorActionEncoding A 1.3.6.1.1.6.2.34 + pcimPolicyInstanceName A 1.3.6.1.1.6.2.35 + pcimRepositoryName A 1.3.6.1.1.6.2.36 + pcimSubtreesAuxContainedSet A 1.3.6.1.1.6.2.37 + pcimGroupsAuxContainedSet A 1.3.6.1.1.6.2.38 + pcimRulesAuxContainedSet A 1.3.6.1.1.6.2.39 + + where Type A is Attribute, Type O is ObjectClass + + These assignments are recorded in the following registry: + + http://www.iana.org/assignments/ldap-parameters + + + + + + + + + + + + + + + + + + + + +Strassner, et al. Standards Track [Page 55] + +RFC 3703 Policy Core LDAP Schema February 2004 + + +9. Acknowledgments + + We would like to thank Kurt Zeilenga, Roland Hedburg, and Steven Legg + for doing a review of this document and making many helpful + suggestions and corrections. + + Several of the policy classes in this model first appeared in early + IETF drafts on IPsec policy and QoS policy. The authors of these + drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy + Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael + See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar. + + This document is closely aligned with the work being done in the + Distributed Management Task Force (DMTF) Policy and Networks working + groups. We would especially like to thank Lee Rafalow, Glenn Waters, + David Black, Michael Richardson, Mark Stevens, David Jones, Hugh + Mahon, Yoram Snir, and Yoram Ramberg for their helpful comments. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Strassner, et al. Standards Track [Page 56] + +RFC 3703 Policy Core LDAP Schema February 2004 + + +10. Appendix: Constructing the Value of orderedCIMKeys + + This appendix is non-normative, and is included in this document as a + guide to implementers that wish to exchange information between CIM + schemata and LDAP schemata. + + Within a CIM name space, the naming is basically flat; all instances + are identified by the values of their key properties, and each + combination of key values must be unique. A limited form of + hierarchical naming is available in CIM, however, by using weak + associations: since a weak association involves propagation of key + properties and their values from the superior object to the + subordinate one, the subordinate object can be thought of as being + named "under" the superior object. Once they have been propagated, + however, propagated key properties and their values function in + exactly the same way that native key properties and their values do + in identifying a CIM instance. + + The CIM mapping document [6] introduces a special attribute, + orderedCIMKeys, to help map from the CIM_ManagedElement class to the + LDAP class dlm1ManagedElement. This attribute SHOULD only be used in + an environment where it is necessary to map between an + LDAP-accessible directory and a CIM repository. For an LDAP + environment, other LDAP naming attributes are defined (i.e., cn and a + class-specific naming attribute) that SHOULD be used instead. + + The role of orderedCIMKeys is to represent the information necessary + to correlate an entry in an LDAP-accessible directory with an + instance in a CIM name space. Depending on how naming of CIM-related + entries is handled in an LDAP directory, the value of orderedCIMKeys + represents one of two things: + + - If the DIT hierarchy does not mirror the "weakness hierarchy" of + the CIM name space, then orderedCIMKeys represents all the + keys of the CIM instance, both native and propagated. + - If the DIT hierarchy does mirror the "weakness hierarchy" of the + CIM name space, then orderedCIMKeys may represent either all the + keys of the instance, or only the native keys. + + Regardless of which of these alternatives is taken, the syntax of + orderedCIMKeys is the same - a DirectoryString of the form + + <className>.<key>=<value>[,<key>=<value>]* + + where the <key>=<value> elements are ordered by the names of the key + properties, according to the collating sequence for US ASCII. The + only spaces allowed in the DirectoryString are those that fall within + a <value> element. As with alphabetizing the key properties, the + + + +Strassner, et al. Standards Track [Page 57] + +RFC 3703 Policy Core LDAP Schema February 2004 + + + goal of suppressing the spaces is once again to make the results of + string operations predictable. + + The values of the <value> elements are derived from the various CIM + syntaxes according to a grammar specified in [5]. + +11. References + +11.1. Normative References + + [1] Moore, B., Ellesson,E., Strassner, J. and A. Westerinen "Policy + Core Information Model -- Version 1 Specification", RFC 3060, + February 2001. + + [2] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, September + 2002. + + [3] Wahl, M., Coulbeck, A., Howes,T. and S. Kille, "Lightweight + Directory Access Protocol (v3): Attribute Syntax Definitions", + RFC 2252, December 1997. + + [4] The Directory: Models. ITU-T Recommendation X.501, 2001. + + [5] Distributed Management Task Force, Inc., "Common Information + Model (CIM) Specification", Version 2.2, June 14, 1999. This + document is available on the following DMTF web page: + http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf + + [6] Distributed Management Task Force, Inc., "DMTF LDAP Schema for + the CIM v2.5 Core Information Model", April 15, 2002. This + document is available on the following DMTF web page: + http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf + + [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with + LDAPv3", RFC 2256, December 1997. + + [8] The Directory: Selected Attribute Types. ITU-T Recommendation + X.520, 2001. + + [9] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Additional Matching Rules", RFC 3698, February 2004. + + [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + + +Strassner, et al. Standards Track [Page 58] + +RFC 3703 Policy Core LDAP Schema February 2004 + + +11.2. Informative References + + [11] Hovey, R. and S. Bradner, "The Organizations Involved in the + IETF Standards Process", BCP 11, RFC 2028, October 1996. + + [12] Strassner, J., policy architecture BOF presentation, 42nd IETF + Meeting, Chicago, Illinois, October 1998. Minutes of this BOF + are available at the following location: + http://www.ietf.org/proceedings/98aug/index.html. + + [13] Yavatkar, R., Guerin, R. and D. Pendarakis, "A Framework for + Policy-based Admission Control", RFC 2753, January 2000. + + [14] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, + "Authentication Methods for LDAP", RFC 2829, May 2000 + + [15] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory + Access Protocol (v3): Extension for Transport Layer Security", + RFC 2830, May 2000. + + [16] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access Protocol + (LDAP)", BCP 64, RFC 3383, September 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Strassner, et al. Standards Track [Page 59] + +RFC 3703 Policy Core LDAP Schema February 2004 + + +12. Authors' Addresses + + John Strassner + Intelliden Corporation + 90 South Cascade Avenue + Colorado Springs, CO 80903 + + Phone: +1.719.785.0648 + Fax: +1.719.785.0644 + EMail: john.strassner@intelliden.com + + + Bob Moore + IBM Corporation + P. O. Box 12195, BRQA/B501/G206 + 3039 Cornwallis Rd. + Research Triangle Park, NC 27709-2195 + + Phone: +1 919-254-4436 + Fax: +1 919-254-6243 + EMail: remoore@us.ibm.com + + + Ryan Moats + Lemur Networks, Inc. + 15621 Drexel Circle + Omaha, NE 68135 + + Phone: +1-402-894-9456 + EMail: rmoats@lemurnetworks.net + + + Ed Ellesson + 3026 Carriage Trail + Hillsborough, NC 27278 + + Phone: +1 919-644-3977 + EMail: ellesson@mindspring.com + + + + + + + + + + + + + +Strassner, et al. Standards Track [Page 60] + +RFC 3703 Policy Core LDAP Schema February 2004 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78 and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Strassner, et al. Standards Track [Page 61] + |