Policy Framework Working Group J. Strassner Internet-draft Cisco Systems Category: Standards Track E. Ellesson LongBoard, Inc. B. Moore IBM Corporation R. Moats Coreon, Inc. March 2001 Policy Core LDAP Schema draft-ietf-policy-core-schema-09.txt March 01, 2001 14:21 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document takes as its starting point the object-oriented information model for representing policy information currently under joint development in the Service Level Agreements (SLA) Policy working group of the Distributed Management Task Force (DMTF) and in the IETF's Policy Framework working group. The IETF document defining this information model is the "Policy Core Information Model -- Version 1 Specification" [1]. 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 draft defines the mapping of these information model classes to a directory that uses LDAPv3 as its access protocol. When mapping to an Strassner, et al. Expires: September 2001 [Page 1] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 LDAP schema, the structural classes can be mapped more or less directly. The relationship hierarchy, however, must be mapped to a form suitable for directory implementation. Since this mapping of the relationship classes could be done in a number of different ways, there is the risk of non-interoperable implementations. To avoid this possibility, this document provides a single mapping that all implementations using an LDAP directory as their policy repository SHALL use. 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. The LDAP schema described in this document consists of six very general classes: policy (an abstract class), policyGroup, policyRule, policyConditionAuxClass, policyTimePeriodConditionAuxClass, and policyActionAuxClass. The schema also contains two less general classes: vendorPolicyConditionAuxClass and vendorPolicyActionAuxClass. To achieve the mapping of the information model's relationships, the schema contains two auxiliary classes: policyGroupContainmentAuxClass and policyRuleContainmentAuxClass. Capturing the distinction between rule-specific and reusable policy conditions and policy actions introduces six other classes: policyRuleConditionAssociation, policyRuleActionAssociation, policyInstance, policyConditionInstance, policyActionInstance, and policyRepository. Finally, the schema includes two classes policySubtreesPtrAuxClass and policyElementAuxClass for optimizing LDAP retrievals. In all, therefore, the schema contains 18 classes. Within the context of this document, the term "Core [Policy] Schema" is used to refer to the LDAP class definitions it contains. Strassner, et al. Expires: September 2001 [Page 2] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 Table of Contents 1. Introduction......................................................3 2. The Policy Core Information Model.................................4 3. Inheritance Hierarchy for the LDAP Core Policy Schema.............5 4. General Discussion of Mapping the Information Model to LDAP.......7 4.1. Summary of Class and Association Mappings....................7 4.2. Naming Attributes in the Core Schema.........................9 4.3. Rule-Specific and Reusable Conditions and Actions...........10 4.4. Location and Retrieval of Policy Objects in the Directory...14 4.4.1. Aliases and Other DIT-Optimization Techniques.............17 5. Class Definitions................................................18 5.1. The Abstract Class "policy".................................18 5.2. The Three policyGroup Classes...............................19 5.3. The Three policyRule Classes................................21 5.4. The Class policyRuleConditionAssociation....................27 5.5. The Class policyRuleActionAssociation.......................29 5.6. The Auxiliary Class policyConditionAuxClass.................31 5.7. The Auxiliary Class policyTimePeriodConditionAuxClass.......32 5.8. The Auxiliary Class vendorPolicyConditionAuxClass...........34 5.9. The Auxiliary Class policyActionAuxClass....................34 5.10. The Auxiliary Class vendorPolicyActionAuxClass.............35 5.11. The Class policyInstance...................................36 5.12. The Class policyConditionInstance..........................37 5.13. The Class policyActionInstance.............................39 5.14. The Auxiliary Class policyElementAuxClass..................40 5.15. The Three policyRepository Classes.........................41 5.16. The Auxiliary Class policySubtreesPtrAuxClass..............43 5.16.1. The Attribute policySubtreesAuxContainedSet..............44 5.17. The Auxiliary Class policyGroupContainmentAuxClass.........44 5.17.1. The Attribute policyGroupsAuxContainedSet................45 5.18. The Auxiliary Class policyRuleContainmentAuxClass..........45 5.18.1. The Attribute policyRulesAuxContainedSet.................46 6. Extending the Core Schema........................................46 6.1. Subclassing policyConditionAuxClass and policyActionAuxClass46 6.2. Using the Vendor Policy Encoding Attributes.................47 6.3. Using Time Validity Periods.................................47 7. Security Considerations..........................................47 8. Intellectual Property............................................49 9. Acknowledgments..................................................49 10. References......................................................50 11. Authors' Addresses..............................................50 12. Full Copyright Statement........................................51 13. Appendix: Constructing the Value of orderedCimKeys.............52 1. Introduction This document takes as its starting point the object-oriented information model for representing policy information currently under joint development in the Service Level Agreements working group of the Distributed Management Task Force (DMTF) and in the IETF's Policy Strassner, et al. Expires: September 2001 [Page 3] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 Framework working group. The IETF document defining this information model is the "Policy Core Information Model -- Version 1 Specification" [1]. 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 draft defines the mapping of these information model classes to a directory that uses LDAPv3 as its access protocol. Two types of mappings are involved: o 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. o For the relationship classes in the information model, different mappings are possible. In this document the information model's relationship classes and their properties are mapped in three ways: to LDAP auxiliary classes, to attributes representing DN pointers, and to containment in the Directory Information Tree (DIT). Implementations that use an LDAP directory as their policy repository SHALL use the LDAP policy schema defined in this document. The use of the information model defined in reference [1] as the starting point enables the schema and the relationship class hierarchy 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. It traces its origins to work that was originally done for the Directory-enabled Networks (DEN) specification, reference [5]. Work on the DEN specification by the DEN Ad-Hoc Working Group itself has been completed. Further work to standardize the models contained in it will be the responsibility of selected working groups of the Common Information Model (CIM) effort in the Distributed Management Task Force (DMTF). DMTF standardization of the core policy model is the responsibility of the SLA Policy working group in the DMTF. 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, reference [3]. 2. The Policy Core Information Model This document contains an LDAP schema representing the Policy Core Information Model (abbreviated "PCIM"), which is defined in the Strassner, et al. Expires: September 2001 [Page 4] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 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 Core Policy classes appear only in reference [1], that document is a prerequisite for reading and understanding this document. 3. Inheritance Hierarchy for the LDAP Core Policy Schema The following diagram illustrates the class hierarchy for the LDAP Core Policy Schema classes: Strassner, et al. Expires: September 2001 [Page 5] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 top | +--dlm1ManagedElement (abstract) | | | +--policy (abstract) | | | | | +--policyGroup (abstract) | | | | | | | +--policyGroupAuxClass (auxiliary) | | | | | | | +--policyGroupInstance (structural) | | | | | +--policyRule (abstract) | | | | | | | +--policyRuleAuxClass (auxiliary) | | | | | | | +--policyRuleInstance (structural) | | | | | +--policyRuleConditionAssociation (structural) | | | | | +--policyRuleActionAssociation (structural) | | | | | +--policyInstance (structural) | | | | | | | +--policyConditionInstance (structural) | | | | | | | +--policyActionInstance (structural) | | | | | +--policyElementAuxClass (auxiliary) | | | +--dlm1ManagedSystemElement (abstract) | | | +--dlm1LogicalElement (abstract) | | | +--dlm1System (abstract) | | | +--dlm1AdminDomain (abstract) | | | +--policyRepository (abstract) | | | +--policyRepositoryAuxClass (auxiliary) | | | +--policyRepositoryInstance (structural) (continued on following page) Strassner, et al. Expires: September 2001 [Page 6] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 (continued from previous page) top | +--policyConditionAuxClass (auxiliary) | | | +---policyTimePeriodConditionAuxClass (auxiliary) | | | +---vendorPolicyConditionAuxClass (auxiliary) | +--policyActionAuxClass (auxiliary) | | | +---vendorPolicyActionAuxClass (auxiliary) | +--policySubtreesPtrAuxClass (auxiliary) | +--policyGroupContainmentAuxClass (auxiliary) | +--policyRuleContainmentAuxClass (auxiliary) Figure 1. LDAP Class Inheritance Hierarchy for the Core Policy Schema 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. 4.1. Summary of Class and Association Mappings Nine of the classes in the LDAP Core Policy Schema come directly from 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. Strassner, et al. Expires: September 2001 [Page 7] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 +---------------------------+-----------------------------------+ | Information Model | LDAP Class | +---------------------------+-----------------------------------+ +---------------------------+-----------------------------------+ | Policy | policy | +---------------------------+-----------------------------------+ | PolicyGroup | policyGroup | +---------------------------+-----------------------------------+ | PolicyRule | policyRule | +---------------------------+-----------------------------------+ | PolicyCondition | policyConditionAuxClass | +---------------------------+-----------------------------------+ | PolicyAction | policyActionAuxClass | +---------------------------+-----------------------------------+ | VendorPolicyCondition | vendorPolicyConditionAuxClass | +---------------------------+-----------------------------------+ | VendorPolicyAction | vendorPolicyActionAuxClass | +---------------------------+-----------------------------------+ | PolicyTimePeriodCondition | policyTimePeriodConditionAuxClass | +---------------------------+-----------------------------------+ | PolicyRepository | policyRepository | +---------------------------+-----------------------------------+ Figure 2. Mapping of Information Model Classes to LDAP The associations in the information model map to DN-pointer attributes or to Directory Information Tree (DIT) containment in LDAP. Two of the DN-pointer attributes appear in auxiliary classes, which allow each of them to represent several relationships from the information model. Strassner, et al. Expires: September 2001 [Page 8] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 +-----------------------------------+--------------------------------+ | Information Model Association | LDAP Attribute / Class | +-----------------------------------+--------------------------------+ +-----------------------------------+--------------------------------+ | PolicyGroupInPolicyGroup | policyGroupsAuxContainedSet in | | | policyGroupContainmentAuxClass| +-----------------------------------+--------------------------------+ | PolicyRuleInPolicyGroup | policyRulesAuxContainedSet in | | | policyRuleContainmentAuxClass | +-----------------------------------+--------------------------------+ | PolicyConditionInPolicyRule | DIT containment + | | | policyRuleConditionList in | | | policyRule + | | | policyConditionDN in | | | policyRuleConditionAssociation| +-----------------------------------+--------------------------------+ | PolicyActionInPolicyRule | DIT containment + | | | policyRuleActionList in | | | policyRule + | | | policyActionDN in | | | policyRuleActionAssociation | +-----------------------------------+--------------------------------+ | PolicyRuleValidityPeriod | policyRuleValidityPeriodList in| | | policyRule | +-----------------------------------+--------------------------------+ | PolicyConditionInPolicyRepository | DIT containment | +-----------------------------------+--------------------------------+ | PolicyActionInPolicyRepository | DIT containment | +-----------------------------------+--------------------------------+ | PolicyRepositoryInPolicyRepository| DIT containment | +-----------------------------------+--------------------------------+ Figure 3. Mapping of Information Model Associations to LDAP Of the remaining classes in the LDAP Core Schema, two (policyElementAuxClass and policySubtreesPtrAuxClass) are included to make navigation through the DIT and retrieval of the entries found there more efficient. This topic is discussed in Section 4.4 below. The remaining five classes in the LDAP Core Schema, policyRuleConditionAssociation, policyRuleActionAssociation, policyInstance, policyConditionInstance, and policyActionInstance are all involved with the representation of policy conditions and policy actions in an LDAP directory. This topic is discussed in Section 4.3 below. 4.2. Naming Attributes in the Core Schema 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 relative distinguished names (RDNs), where an RDN provides a unique identifier for an instance within the context of its Strassner, et al. Expires: September 2001 [Page 9] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 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, each of the structural classes defined in this schema has its own naming attribute. (The naming attribute policyConditionName is used in two structural class: policyRuleConditionAssociation and policyConditionInstance. As discussed below in Section 4.3, these are two of the structural classes to which the auxiliary class policyConditionAuxClass may be attached. The naming attribute policyActionName is similarly associated with two structural classes.) 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 X.500 attribute commonName (cn) is included as a MAY attribute in the abstract class policy, and thus by inheritance in all of its subclasses. In X.500, commonName typically functions as an RDN attribute, for naming instances of such classes as X.500's person. Finally, for implementations that expect to map between native CIM and LDAP representations of policy information, a second MAY attribute, orderedCimKeys, is inherited from the class dlm1ManagedElement, defined in reference [10], into the abstract class "policy". The value of this attribute is derived algorithmically from values that are already present in a CIM policy instance. See the appendix of this document for a complete description of the algorithm. Each of the Core Schema classes thus has three attributes suitable for naming: cn, its own class-specific attribute, and orderedCimKeys. Any of these attributes MAY be used for naming an instance of a Core Schema class. Consequently, implementations MUST be able to accommodate instances named in any of these ways. Note that since they are required ("MUST") attributes, the class- specific naming attributes are always present in instances of their respective classes, even if they are not being used for naming the instances. In these cases the class-specific naming attributes may be used for other purposes. Note also that "cn", the class-specific naming attribute, and orderedCimKeys SHOULD NOT be used together to form a multi-part RDN, since support for multi-part RDNs is limited among existing directory implementations. 4.3. Rule-Specific and Reusable Conditions and Actions The PCIM [1] distinguishes between two types of policy conditions and policy actions: ones associated with a single policy rule, and ones that are reusable, in the sense that they may be associated with more than one policy rule. There is no inherent difference between a rule- specific condition or action and a reusable one. There are, however, Strassner, et al. Expires: September 2001 [Page 10] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 differences in how they are treated in a policy repository. For example, it's natural to make the access permissions for a rule- specific condition or action identical to those for the rule itself. It's also natural for a rule-specific condition or action to be removed from the policy repository at the same time the rule is. With reusable conditions and actions, on the other hand, access permissions and existence criteria must be expressible without reference to a policy rule. 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. 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 pointers to the structural classes CA and AB that appear below it in the DIT. At first glance it might appear that these DN pointers 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. With the use of DN pointers, many (but not all) of these risks are eliminated. Note that the existence dependency of a rule-specific condition or action on its policy rule follows in this case from the semantics of DNs. Note also that for directory implementations supporting subtree- based access permissions, it's easy to indicate that parties with access to Rule1 also have access to its condition and action. Strassner, et al. Expires: September 2001 [Page 11] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 +-----+ |Rule1| | | +-----|- -|-----+ | +-----+ | | * * | | * * | | **** **** | | * * | v * * v +--------+ +--------+ | CA+ca | | AB+ab | +--------+ +--------+ +------------------------------+ |LEGEND: | | ***** DIT containment | | + auxiliary attachment | | ----> DN pointer | +------------------------------+ Figure 4. Rule-Specific Policy Conditions and Actions 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 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 "complex". 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 point to its validity periods with the policyRuleValidityPeriodList 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: o All conditions are ANDed together. This combination can be represented in two ways in the DNF / CNF 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 Strassner, et al. Expires: September 2001 [Page 12] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 the representation for the ANDed conditions in a simple policy rule. o 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. +-----------+ |Rule1+ca+ab| | | +-----------+ +------------------------------+ |LEGEND: | | + auxiliary attachment | +------------------------------+ Figure 5. A Simple 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 to themselves, CA and AB now contain DN pointers 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 policyRepository. Because they are named under an instance of policyRepository, ca and ab are clearly identified as reusable. The structural classes CIA and AIB in Figure 6 may either be instances of the generic class policyInstance (defined in Section 5.11), or, respectively, instances of the classes policyConditionInstance (Section 5.12) and policyActionInstance (Section 5.13). Strassner, et al. Expires: September 2001 [Page 13] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 +-----+ +-------------+ |Rule1| | RepositoryX | +-|- -|--+ | | | +-----+ | +-------------+ | * * | * * | * * | * * | *** **** | * * | * * v * * | * +---+ * * | * |AB | +------+ * v * | -|-------->|AIB+ab| * +---+ +---+ +------+ * |CA | +------+ | -|------------------------>|CIA+ca| +---+ +------+ +------------------------------+ |LEGEND: | | ***** DIT containment | | + auxiliary attachment | | ----> DN pointer | +------------------------------+ Figure 6. Reusable Policy Conditions and Actions The classes policyConditionAuxClass and policyActionAuxClass do not themselves represent actual conditions and actions: these are introduced in their subclasses. What policyConditionAuxClass and policyActionAuxClass do introduce are the semantics of being a policy condition or a policy action. These are the semantics that all the subclasses of policyConditionAuxClass and policyActionAuxClass 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 policyConditionAuxClass and policyActionAuxClass MUST also be auxiliary classes. 4.4. Location and Retrieval of Policy Objects in the Directory When a PDP goes to an LDAP directory to retrieve the policy object instances relevant to the PEPs it serves, it is faced with two related problems: o How does it locate and retrieve the directory entries that apply to its PEPs? These entries may include instances of the Core Schema classes, instances of domain-specific subclasses of these classes, and instances of other classes modeling such resources as user groups, interfaces, and address ranges. Strassner, et al. Expires: September 2001 [Page 14] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 o 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 Core Schema 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. +-----+ ---------------->| A | DN pointer to | | DN pointers to subtrees +---+ starting object +-----+ +------------------------->| C | | o--+----+ +---+ +---+ | o--+------------->| B | / \ +-----+ +---+ / \ / \ / \ / ... \ / \ / \ / \ / ... \ Figure 7. Using policySubtreesPtrAuxClass to Locate Policies The PDP is configured initially with a DN pointer to some entry in the DIT. The structural class of this entry is not important; the PDP is interested only in the policySubtreesPtrAuxClass attached to it. This auxiliary class contains a multi-valued attribute with DN pointers to objects that anchor subtrees containing policy-related objects of interest to the PDP. Since policySubtreesPtrAuxClass 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. Strassner, et al. Expires: September 2001 [Page 15] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 Once it has retrieved the DN pointers, 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 = "policy". Since all classes representing policy rules, policy conditions, and policy actions, both in the Core Schema 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 pointed to by a subclass of policyActionAuxClass representing the DHCP action "assign from this address range), the auxiliary class policyElementAuxClass can be used to "tag" an entry, so that it will be found by the selection criterion "object class = policy". 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 accomplished by inserting the special value "POLICY" into the list of values contained in the policyKeywords attribute. 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 policyKeywords attribute defined in the policy class. This attribute supports both standardized and administrator-defined values. Thus 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 pointer points, 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 = policy", presence of the keyword "POLICY", or presence of a more specific policyKeyword. 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 these objects, with exactly three LDAP requests: one to its starting object A to get the pointers 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 pointers locally to understand the semantic relationships among them. The PDP Strassner, et al. Expires: September 2001 [Page 16] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 should also be prepared to find a pointer to another subtree attached to any of the objects it retrieves, and to follow this pointer first, before it follows any of the semantically significant pointers 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 pointer from the subtree under C to an object D that roots the subtree of corporate-level policies. Since a PDP has no guarantee that the entity that populates the directory won't use the policySubtreesPtrAuxClass, a PDP SHOULD understand this class, SHOULD be capable of retrieving and processing the entries in the subtrees it points to, 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 policySubtreesPtrAuxClass. All of these 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 policySubtreesPtrAuxClass entries and their DN pointers. 4.4.1. Aliases and Other DIT-Optimization Techniques Additional flexibility in DIT structure is available to the policy administrator via LDAP aliasing. Figure 8 illustrates this flexibility. +-----+ ---------------->| A | DN pointer to | | DN pointers to subtrees +---+ starting object +-----+ +------------------------->| C | | o--+----+ +---+ +---+ | o--+------------->| B | / \ +-----+ +---+ / \ / \ / \ / ... \ / \ / \ / \ / \ +---+ / +------+ \ | X |<***************************|aliasX| +---+ +------+ Figure 8. Addition of an Alias Object Even if it is necessary to store a policy entry X in a directory location separate from the other policy entries, batch retrieval using Strassner, et al. Expires: September 2001 [Page 17] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 policy subtrees can still be done. The administrator simply inserts into one of the subtrees of policy entries an alias entry aliasX pointing to the outlying entry X. When the PDP requests all entries in the subtree under B, a response will be returned for entry X, just as responses are returned for all the (non-alias) entries that actually are in the subtree. Since resolution of an alias to its true entry is handled entirely by the LDAP directory, and is invisible to directory clients, PDPs need not do anything extra to support aliases. A Policy Management Tool MAY make available to a policy administrator the ability to create alias entries like the one in Figure 7. In addition to aliases, there are several other techniques for managing the placement of entries in the DIT and their retrieval by directory clients. Among these other techniques are referrals, LDAP URLs, and attributes like seeAlso. Discussion of how these other techniques might be applied to policy-related entries in a directory is outside the scope of this document. 5. Class Definitions The semantics for the LDAP classes mapped directly from the information model are detailed in reference [1]. Consequently, all that this document presents for these classes is a bare specification of the LDAP classes and attributes. More details are provided for the attributes listed above in Figure 3, which realize in LDAP the relationships defined in the information model. Finally, the classes that exist only in the LDAP Core Schema are documented fully in this document. The formal language for specifying the classes, attributes, and DIT structure and content rules is that defined in reference [2]. Note: all attribute, object class, and name form OIDs, and all structure rule integers, are place holders, and syntax OIDs in definitions have been replaced by names for clarity. 5.1. The Abstract Class "policy" The abstract class "policy" is a direct mapping of the abstract class Policy from the Core Information Model. The five properties in Policy, three of which are inherited from the class dlm1ManagedElement, map directly to attributes in the class "policy". See reference [10] for the definition of the LDAP class dlm1ManagedElement. The class value "policy" 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 policyElementAuxClass. Strassner, et al. Expires: September 2001 [Page 18] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 The class definition is as follows: ( NAME 'policy' DESC 'An abstract class with five attributes for describing a policy-related instance. The attributes dlmCaption, dlmDescription, and orderedCimKeys are inherited from dlm1ManagedElement.' SUP dlm1ManagedElement ABSTRACT MAY ( cn $ policyKeywords ) ) The three attributes dlmCaption, dlmDescription, and orderedCimKeys are defined in reference [10]. The attribute "cn" is defined in X.520. The remaining attribute, policyKeywords, is defined as follows: ( NAME 'policyKeywords' DESC 'A set of keywords to assist directory clients in locating the policy objects applicable to them. Each value of the multi-valued attribute contains a single keyword. Standard keyword values are listed in the Policy Core Information Model document. This value is a Directory String.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 5.2. The Three policyGroup Classes The class definitions for the three policyGroup classes are as follows. Note that these class definitions do not include attributes to realize the PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from the object model, since a policyGroup object points to instances of policyGroup and policyRule via, respectively, the pointer in policyGroupContainmentAuxClass and the pointer in policyRuleContainmentAuxClass. To maximize flexibility, the policyGroup class is defined as abstract. A subclass policyGroupAuxClass provides for auxiliary attachment to another entry, while a structural subclass policyGroupInstance is available to represent a policy group as a standalone entry. ( NAME 'policyGroup' DESC 'A container for either a set of related policyRules or a set of related policyGroups. A policyGroup may also contain a mixture of policyRules and other policyGroups.' SUP policy ABSTRACT Strassner, et al. Expires: September 2001 [Page 19] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 MUST ( policyGroupName ) ) ( NAME 'policyGroupAuxClass' DESC 'A container for either a set of related policyRules or a set of related policyGroups. A policyGroup may also contain a mixture of policyRules and other policyGroups.' SUP policyGroup AUXILIARY ) ( NAME 'policyGroupInstance' DESC 'A container for either a set of related policyRules or a set of related policyGroups. A policyGroup may also contain a mixture of policyRules and other policyGroups.' SUP policyGroup STRUCTURAL ) The following DIT content rule indicates that an instance of policyGroupInstance may have attached to it either DN pointers to one or more other policyGroups, or DN pointers to one or more policyRules. ( NAME 'policyGroupContentRule' DESC 'shows what auxiliary classes go with this object' AUX ( policyGroupContainmentAuxClass $ policyRuleContainmentAuxClass ) ) The following DIT structure rules indicate that an instance of policyGroupInstance may be named under any superior, using any of its three naming attributes. NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule are named within the scope of ("are weak to" in the CIM jargon) an instance of the CIM class System, or one of its subclasses. The most natural way to map a weak relationship of this type is to map it to DIT structure rules specifying that an instance of policyGroupInstance or policyRuleInstance is subordinate to an object representing a CIM System. Since, however, the mapping of CIM's System class to an LDAP class falls outside the scope of this document, the DIT structure rules that follow do not constrain the superiors under which an instance of policyGroupInstance may be named. ( NAME 'policyGroupNameForm1' OC policyGroupInstance MUST ( cn ) ) Strassner, et al. Expires: September 2001 [Page 20] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 ( NAME 'policyGroupStructuralRule1' FORM policyGroupNameForm1 ) ( NAME 'policyGroupNameForm2' OC policyGroupInstance MUST ( policyGroupName ) ) ( NAME 'policyGroupStructuralRule2' FORM policyGroupNameForm2 ) ( NAME 'policyGroupNameForm3' OC policyGroupInstance MUST ( orderedCimKeys ) ) ( NAME 'policyGroupStructuralRule3' FORM policyGroupNameForm3 ) The one attribute of policyGroup is defined as: ( NAME 'policyGroupName' DESC 'The user-friendly name of this policy group. This value is a Directory String.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) 5.3. The Three policyRule Classes This class represents the "If Condition then Action" semantics associated with a policy. The conditions and actions associated with a policy rule are modeled, respectively, with auxiliary subclasses of the auxiliary classes policyConditionAuxClass and policyActionAuxClass. Each of these auxiliary subclasses is attached to an instance of one of two structural classes. A subclass of policyConditionAuxClass is attached either to an instance of policyRuleConditionAssociation or to an instance of policyConditionInstance. Similarly, a subclass of policyActionAuxClass is attached either to an instance of policyRuleActionAssociation or to an instance of policyActionInstance. Of the nine attributes in the policyRule class, eight are mapped directly from corresponding properties in the information model. The ninth attribute, policyRuleValidityPeriodList, realizes the PolicyRuleValidityPeriod association from the information model. Strassner, et al. Expires: September 2001 [Page 21] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 Since this association has no "extra" properties (besides those that tie the association to its associated objects), the attribute policyRuleValidityPeriodList is simply a multi-valued DN pointer. (Relationships in the information model can have "extra" properties because CIM represents relationships as classes. See Sections 5.4 and 5.5 for examples of "extra" properties and how they are mapped to LDAP.) This attribute provides an unordered set of DN pointers to one or more instances of the policyTimePeriodConditionAuxClass, 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 policyTimePeriodConditionAuxClass instances pointed to by this attribute. The PolicyConditionInPolicyRule and PolicyActionInPolicyRule associations, however, have additional properties: PolicyActionInPolicyRule has an integer to sequence the actions, and PolicyConditionInPolicyRule has an integer to group the conditions, and a Boolean to specify whether a condition is to be negated. In the Core Schema, these extra association properties are represented as attributes of two classes introduced specifically to model the associations: policyRuleConditionAssociation and policyRuleActionAssociation, defined, respectively, in Sections 5.4 and 5.5. Thus they do not appear as attributes of the class policyRule. To maximize flexibility, the policyRule class is defined as abstract. A subclass policyRuleAuxClass provides for auxiliary attachment to another entry, while a structural subclass policyRuleInstance is available to represent a policy rule as a standalone entry. The class definitions for the three policyRule classes are as follows: ( NAME 'policyRule' DESC 'The central class for representing the "If Condition then Action" semantics associated with a policy rule.' SUP policy ABSTRACT MUST ( policyRuleName ) MAY ( policyRuleEnabled $ policyRuleConditionListType $ policyRuleConditionList $ policyRuleActionList $ policyRuleValidityPeriodList $ policyRuleUsage $ policyRulePriority $ policyRuleMandatory $ policyRuleSequencedActions $ policyRoles ) ) ( NAME 'policyRuleAuxClass' DESC 'The central class for representing the "If Condition then Action" semantics associated with a policy rule.' SUP policyRule AUXILIARY ) Strassner, et al. Expires: September 2001 [Page 22] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 ( NAME 'policyRuleInstance' DESC 'The central class for representing the "If Condition then Action" semantics associated with a policy rule.' SUP policyRule STRUCTURAL ) The following DIT content rule indicates that an instance of policyRuleInstance may have attached to it the auxiliary classes policyConditionAuxClass and policyActionAuxClass, or one of their subclasses. This combination represents a simple policy rule. ( NAME 'policyRuleContentRule' DESC 'shows what auxiliary classes go with this object' AUX ( policyConditionAuxClass $ policyActionAuxClass ) ) The following DIT structure rules indicate that an instance of policyRuleInstance may be named under any superior, using any of its three naming attributes. NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule are named within the scope of ("are weak to" in the CIM jargon) an instance of the CIM class System, or one of its subclasses. The most natural way to map a weak relationship of this type is to DIT structure rules specifying that an instance of policyGroupInstance or policyRuleInstance is subordinate to an object representing a CIM System. Since, however, the mapping of CIM's System class to an LDAP class falls outside the scope of this document, the DIT structure rules that follow do not constrain the superiors under which an instance of policyRuleInstance may be named. ( NAME 'policyRuleNameForm1' OC policyRuleInstance MUST ( cn ) ) ( NAME 'policyRuleStructuralRule1' FORM policyRuleNameForm1 ) ( NAME 'policyRuleNameForm2' OC policyRuleInstance MUST ( policyRuleName ) ) ( NAME 'policyRuleStructuralRule2' FORM policyRuleNameForm2 ) Strassner, et al. Expires: September 2001 [Page 23] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 ( NAME 'policyRuleNameForm3' OC policyRuleInstance MUST ( orderedCimKeys ) ) ( NAME 'policyRuleStructuralRule3' FORM policyRuleNameForm3 ) The attributes of policyRule are defined as follows: ( NAME 'policyRuleName' DESC 'The user-friendly name of this policy rule. This value is a Directory String' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( NAME 'policyRuleEnabled' DESC 'An enumeration indicating whether a policy rule is administratively enabled, administratively disabled, or enabled for debug mode. The defined values for this attribute are enabled(1), disabled(2), and enabledForDebug(3). This value is an INTEGER enumeration.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( NAME 'policyRuleConditionListType' DESC 'Indicates whether the list of policy conditions associated with this policy rule is in disjunctive normal form (DNF) or conjunctive normal form (CNF). Defined values are DNF(1) and CNF(2). This value is an INTEGER enumeration.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( NAME 'policyRuleConditionList' DESC 'Distinguished names of policyRuleConditionAssociation entries representing associations between this policy rule and its conditions. No order is implied. This value is a Distinguished Name (DN).' Strassner, et al. Expires: September 2001 [Page 24] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( NAME 'policyRuleActionList' DESC 'Distinguished names of policyRuleActionAssociation entries representing associations between this policy rule and its actions. No order is implied. This value is a Distinguished Name (DN).' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( NAME 'policyRuleValidityPeriodList' DESC 'Distinguished names of policyTimePeriodConditions that determine when the policyRule is scheduled to be active / inactive. No order is implied. This value is a Distinguished Name (DN).' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( NAME 'policyRuleUsage' DESC 'This attribute is used to provide guidelines on how this policy should be used. This value is a Directory String.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( NAME 'policyRulePriority' DESC 'A non-negative integer for prioritizing this policyRule relative to other policyRules. A larger value indicates a higher priority. This value is an INTEGER.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( NAME 'policyRuleMandatory' DESC 'A flag indicating that the evaluation of the policyConditions and execution of policyActions (if the condition list evaluates to True) is required. This value is a Boolean.' Strassner, et al. Expires: September 2001 [Page 25] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) ( NAME 'policyRuleSequencedActions' DESC 'An enumeration indicating how to interpret the action ordering indicated via the policyRuleActionList attribute. The defined values for this attribute are mandatory(1), recommended(2), and dontCare(3). This value is an INTEGER enumeration.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( NAME 'policyRoles' DESC 'Each value of this attribute represents a role combination, including the special case of a "combination" containing only one role. Since this is a multi-valued attribute, more than one role combination can be associated with a single policy rule. Each value is a string of the form [&&]* where the individual role names appear in alphabetical order according to the collating sequence for UCS-2. This value is a Directory String.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) The two matching rules for policyRoles support two different approaches that a PDP might take to the task of retrieving policyRules for its PEPs based on the roles they have reported to it. Suppose, for example, that a PEP has reported that it is interested in policyRules 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 get all of the policyRules that apply to the PEP, but they may also get some that do not apply, for example, ones for the role combination "R1&&R4". Another strategy would be for the PDP to use only equality filters. This approach eliminates the extraneous replies, but it requires the PDP to build the role combinations ("R1&&R2", "R1&&R3", etc.) itself, and it requires extra queries. Note that this approach is practical Strassner, et al. Expires: September 2001 [Page 26] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 only because the role names in a role combination are required to appear in alphabetical order. By having the two matching rules for policyRoles, the PCLS leaves to each PDP the choice of which of these approaches use. 5.4. The Class policyRuleConditionAssociation This class contains attributes to represent the "extra" properties of the information model's PolicyConditionInPolicyRule association. Instances of this class are related to an instance of policyRule via DIT containment. The policy conditions themselves are represented by auxiliary subclasses of the auxiliary class policyConditionAuxClass. These auxiliary classes are attached directly to instances of policyRuleConditionAssociation for rule-specific policy conditions. For a reusable policy condition, the auxiliary class is attached to an instance of the class policyConditionInstance, and there is a DN pointer to this instance from the instance of policyRuleConditionAssociation. The class definition is as follows: ( NAME 'policyRuleConditionAssociation' DESC 'The class contains attributes characterizing the relationship between a policy rule and one of its policy conditions.' SUP policy MUST ( policyConditionGroupNumber $ policyConditionNegated $ policyConditionName ) MAY ( policyConditionDN ) ) The following DIT content rule indicates that an instance of policyRuleConditionAssociation may have attached to it the auxiliary class policyConditionAuxClass, or one of its subclasses. This combination represents a rule-specific policy condition. ( NAME 'policyRuleConditionAssociationContentRule' DESC 'shows what auxiliary classes go with this object' AUX ( policyConditionAuxClass ) ) The following DIT structure rules indicate that an instance of policyRuleConditionAssociation may be named under an instance of policyRule, where each of these instances may be named using any of their three naming attributes. ( NAME 'policyRuleConditionAssociationNameForm1' OC policyRuleConditionAssociation MUST ( cn ) Strassner, et al. Expires: September 2001 [Page 27] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 ( NAME 'policyRuleConditionAssociationStructuralRule1' FORM policyRuleConditionAssociationNameForm1 SUP ) ( NAME 'policyRuleConditionAssociationNameForm2' OC policyRuleConditionAssociation MUST ( policyConditionName ) ) ( NAME 'policyRuleConditionAssociationStructuralRule2' FORM policyRuleConditionAssociationNameForm2 SUP ) ( NAME 'policyRuleConditionAssociationNameForm3' OC policyRuleConditionAssociation MUST ( orderedCimKeys ) ) ( NAME 'policyRuleConditionAssociationStructuralRule3' FORM policyRuleConditionAssociationNameForm3 SUP ) The attributes of policyRuleConditionAssociation are defined as follows. Note that the class-specific naming attribute policyConditionName is also used in the class policyConditionInstance, where it identifies a reusable policy condition. ( NAME 'policyConditionName' DESC 'A user-friendly name for a policy condition. This value is a Directory String.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( NAME 'policyConditionGroupNumber' DESC 'The number of the group to which a policy condition belongs. These groups are used to form the DNF or CNF expression associated with a policy rule. This value is an INTEGER.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) Strassner, et al. Expires: September 2001 [Page 28] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 ( NAME 'policyConditionNegated' DESC 'Indicates whether a policy condition is negated in the DNF or CNF expression associated with a policy rule. The value TRUE indicates that a condition is negated This value is a Boolean.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) ( NAME 'policyConditionDN' DESC 'A DN pointer to a reusable policy condition. This value is a Distinguised Name (DN).' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) 5.5. The Class policyRuleActionAssociation This class contains an attribute to represent the one "extra" property of the information model's PolicyActionInPolicyRule association, which makes it possible to specify an order for executing the actions associated with a policy rule. Instances of this class are related to an instance of policyRule via DIT containment. The actions themselves are represented by auxiliary subclasses of the auxiliary class policyActionAuxClass. These auxiliary classes are attached directly to instances of policyRuleActionAssociation for rule-specific policy actions. For a reusable policy action, the auxiliary class is attached to an instance of the class policyActionInstance, and there is a DN pointer to this instance from the instance of policyRuleActionAssociation. The class definition is as follows: ( NAME 'policyRuleActionAssociation' DESC 'The class contains an attribute that represents an execution order for an action in the context of a policy rule.' SUP policy MUST ( policyActionOrder $ policyActionName ) MAY ( policyActionDN ) ) The following DIT content rule indicates that an instance of policyRuleActionAssociation may have attached to it the auxiliary Strassner, et al. Expires: September 2001 [Page 29] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 class policyActionAuxClass, or one of its subclasses. This combination represents a rule-specific policy action. ( NAME 'policyRuleActionAssociationContentRule' DESC 'shows what auxiliary classes go with this object' AUX ( policyActionAuxClass ) ) The following DIT structure rules indicate that an instance of policyRuleActionAssociation may be named under an instance of policyRule, where each of these instances may be named using any of their three naming attributes. ( NAME 'policyRuleActionAssociationNameForm1' OC policyRuleActionAssociation MUST ( cn ) ) ( NAME 'policyRuleActionAssociationStructuralRule1' FORM policyRuleActionAssociationNameForm1 SUP ) ( NAME 'policyRuleActionAssociationNameForm2' OC policyRuleActionAssociation MUST ( policyActionName ) ) ( NAME 'policyRuleActionAssociationStructuralRule2' FORM policyRuleActionAssociationNameForm2 SUP ) ( NAME 'policyRuleActionAssociationNameForm3' OC policyRuleActionAssociation MUST ( orderedCimKeys ) ) ( NAME 'policyRuleActionAssociationStructuralRule3' FORM policyRuleActionAssociationNameForm3 SUP ) The attributes of policyRuleActionAssociation are defined as follows. Note that the class-specific naming attribute policyActionName is also used in the class policyActionInstance, where it identifies a reusable policy action. ( NAME 'policyActionName' DESC 'A user-friendly name for a policy action. Strassner, et al. Expires: September 2001 [Page 30] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 This value is a Directory String.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( NAME 'policyActionOrder' DESC 'An integer indicating the relative order of an action in the context of a policy rule. This value is an INTEGER.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( NAME 'policyActionDN' DESC 'A DN pointer to a reusable policy action. This value is a Distinguished Name (DN).' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) 5.6. The Auxiliary Class policyConditionAuxClass The purpose of a policy condition is to determine whether or not the set of actions (contained in the policyRule that the condition applies to) should be executed or not. This auxiliary class can be attached to instances of three other classes in the Core Policy Schema. When it is attached to an instance of policyRuleConditionAssociation, or to an instance of policyRule, it represents a rule-specific policy condition. When it is attached to an instance of policyConditionInstance, it represents a reusable policy condition. Since all of the classes to which this auxiliary class may be attached are derived from "policy", the attributes of "policy" will already be defined for the entries to which this class attaches. Thus this class is derived directly from "top". The class definition is as follows: ( NAME 'policyConditionAuxClass' DESC 'A class representing a condition to be evaluated in conjunction with a policy rule.' SUP top Strassner, et al. Expires: September 2001 [Page 31] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 AUXILIARY ) 5.7. The Auxiliary Class policyTimePeriodConditionAuxClass This class provides a means of representing the time periods during which a policy rule is valid, i.e., active. The class definition is as follows. ( NAME 'policyTimePeriodConditionAuxClass' DESC 'A class that provides the capability of enabling / disabling a policy rule according to a predetermined schedule.' SUP policyConditionAuxClass AUXILIARY MAY ( ptpConditionTime $ ptpConditionMonthOfYearMask $ ptpConditionDayOfMonthMask $ ptpConditionDayOfWeekMask $ ptpConditionTimeOfDayMask $ ptpConditionLocalOrUtcTime ) ) The attributes of policyTimePeriodConditionAuxClass are defined as follows. Note that several of the attributes are defined as bit strings of various fixed lengths. These attributes correspond to CIM properties that include four-octet length fields prior to their semantically significant bits. Since these length fields are unnecessary in LDAP, they are not included in the bit string attributes defined in this document. ( NAME 'ptpConditionTime' DESC 'The range of calendar dates on which a policy rule is valid. The format of the string is yyyymmddThhmmss/yyyymmddThhmmss, where the first date/time may be replaced with the string "THISANDPRIOR" or the second date/time may be replaced with the string "THISANDFUTURE". This value is a Printable String.' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 SINGLE-VALUE ) ( NAME 'ptpConditionMonthOfYearMask' DESC 'A 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.' EQUALITY bitStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 Strassner, et al. Expires: September 2001 [Page 32] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 SINGLE-VALUE ) ( NAME 'ptpConditionDayOfMonthMask' DESC '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.' EQUALITY bitStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE ) ( NAME 'ptpConditionDayOfWeekMask' DESC '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.' EQUALITY bitStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 SINGLE-VALUE ) ( NAME 'ptpConditionTimeOfDayMask' DESC '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. This value is a Printable String.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) ( NAME 'ptpConditionLocalOrUtcTime' DESC 'An indication of whether the other times in this instance represent local times or UTC times. The defined values for this attribute are localTime(1) and utcTime(2). This value is an INTEGER enumeration.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE Strassner, et al. Expires: September 2001 [Page 33] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 ) 5.8. The Auxiliary Class vendorPolicyConditionAuxClass The class definition is as follows: ( NAME 'vendorPolicyConditionAuxClass' DESC 'A class that defines a registered means to describe a policy condition.' SUP policyConditionAuxClass AUXILIARY MAY ( vendorPolicyConstraintData $ vendorPolicyConstraintEncoding ) ) The attribute definitions for vendorPolicyConditionAuxClass are as follows: ( NAME 'vendorPolicyConstraintData' DESC 'Escape mechanism for representing constraints that have not been modeled as specific attributes. The format of the values is identified by the OID stored in the attribute vendorPolicyConstraintEncoding. This value is an Octet String.' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) ( NAME 'vendorPolicyConstraintEncoding' DESC 'An OID identifying the format and semantics for this instance"s vendorPolicyConstraintData attribute.' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE ) 5.9. The Auxiliary Class policyActionAuxClass 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 auxiliary class can be attached to instances of three other classes in the Core Policy Schema. When it is attached to an instance of policyRuleActionAssociation, or to an instance of policyRule, it represents a rule-specific policy action. When it is attached to an instance of policyActionInstance, it represents a reusable policy action. Strassner, et al. Expires: September 2001 [Page 34] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 Since all of the classes to which this auxiliary class may be attached are derived from "policy", the attributes of "policy" will already be defined for the entries to which this class attaches. Thus this class is derived directly from "top". The class definition is as follows: ( NAME 'policyActionAuxClass' DESC 'A class representing an action to be performed as a result of a policy rule.' SUP top AUXILIARY ) 5.10. The Auxiliary Class vendorPolicyActionAuxClass The class definition is as follows: ( NAME 'vendorPolicyActionAuxClass' DESC 'A class that defines a registered means to describe a policy action.' SUP policyActionAuxClass AUXILIARY MAY ( vendorPolicyActionData $ vendorPolicyActionEncoding ) ) The attribute definitions for vendorPolicyActionAuxClass are as follows: ( NAME 'vendorPolicyActionData' DESC 'Escape mechanism for representing actions that have not been modeled as specific attributes. The format of the values is identified by the OID stored in the attribute vendorPolicyActionEncoding. This value is an Octet String.' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) ( NAME 'vendorPolicyActionEncoding' DESC 'An OID identifying the format and semantics for this instance"s vendorPolicyActionData attribute.' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE ) Strassner, et al. Expires: September 2001 [Page 35] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 5.11. The Class policyInstance The role of this class in the Core Schema 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 Sections 5.12 and 5.13. See Section 4.3 for a complete discussion of reusable policy conditions and actions, and of the role that this class plays in how they are represented. In addition to the cn attribute it inherits from "policy", this class uses the class-specific naming attribute policyInstanceName. The class definition is as follows: ( NAME 'policyInstance' DESC 'A structural class that contains reusable policy information.' SUP policy MAY ( policyInstanceName ) ) The following DIT content rule indicates that an instance of policyInstance may have attached to it instances of the auxiliary classes policyConditionAuxClass and policyActionAuxClass. Additional DIT content rules may be defined later, for attachment of other policy-related auxiliary classes to policyInstance. ( NAME 'policyInstanceContentRule' DESC 'shows what auxiliary classes go with this class' AUX ( policyConditionAuxClass $ policyActionAuxClass) ) The following DIT structure rules indicate that an instance of policyInstance may be named under an instance of policyRepository, using any of its three naming attributes. ( NAME 'policyInstanceNameForm1' OC policyInstance MUST ( cn ) ) ( ) ( NAME 'policyInstanceNameForm2' Strassner, et al. Expires: September 2001 [Page 36] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 OC policyInstance MUST ( policyInstanceName ) ) ( NAME 'policyInstanceStructuralRule2' FORM policyInstanceNameForm2 SUP ) ( NAME 'policyInstanceNameForm3' OC policyInstance MUST ( orderedCimKeys ) ) ( NAME 'policyInstanceStructuralRule3' FORM policyInstanceNameForm3 SUP ) The one attribute of policyInstance is defined as: ( NAME 'policyInstanceName' DESC 'The user-friendly name of this policy instance. This value is a Directory String.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) 5.12. The Class policyConditionInstance The role of this class in the Core Schema is to serve as a structural class to which the auxiliary class policyConditionAuxClass may be attached to form a reusable policy condition. Alternatively, a reusable policyConditionAuxClass may be attached to the more generic structural class policyInstance, defined in Section 5.11. See Section 4.3 for a complete discussion of reusable policy conditions and the role that this class plays in how they are represented. In addition to the cn attribute it inherits from "policy" and the policyInstanceName attribute it inherits from policyInstance, this class uses the naming attribute policyConditionName, which was defined above in Section 5.4. The class definition is as follows: ( NAME 'policyConditionInstance' DESC 'A structural class that contains a reusable policy condition.' SUP policyInstance Strassner, et al. Expires: September 2001 [Page 37] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 MAY ( policyConditionName ) ) The following DIT content rule indicates that an instance of policyConditionInstance may have attached to it an instance of the auxiliary class policyConditionAuxClass. ( NAME 'policyConditionInstanceContentRule' DESC 'shows what auxiliary classes go with this class' AUX ( policyConditionAuxClass ) ) The following DIT structure rules indicate that an instance of policyConditionInstance may be named under an instance of policyRepository, using any of its four naming attributes. ( NAME 'policyConditionInstanceNameForm1' OC policyConditionInstance MUST ( cn ) ) ( NAME 'policyConditionInstanceStructuralRule1' FORM policyConditionInstanceNameForm1 SUP ) ( NAME 'policyConditionInstanceNameForm2' OC policyConditionInstance MUST ( policyConditionName ) ) ( NAME 'policyConditionInstanceStructuralRule2' FORM policyConditionInstanceNameForm2 SUP ) ( NAME 'policyConditionInstanceNameForm3' OC policyConditionInstance MUST ( orderedCimKeys ) ) ( NAME 'policyConditionInstanceStructuralRule3' FORM policyConditionInstanceNameForm3 SUP ) ( NAME 'policyConditionInstanceNameForm4' OC policyConditionInstance MUST ( policyInstanceName ) Strassner, et al. Expires: September 2001 [Page 38] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 ) ( NAME 'policyConditionInstanceStructuralRule4' FORM policyConditionInstanceNameForm4 SUP ) 5.13. The Class policyActionInstance The role of this class in the Core Schema is to serve as a structural class to which the auxiliary class policyActionAuxClass may be attached to form a reusable policy action. Alternatively, a reusable policyActionAuxClass may be attached to the more generic structural class policyInstance, defined in Section 5.11. See Section 4.3 for a complete discussion of reusable policy actions and the role that this class plays in how they are represented. In addition to the cn attribute it inherits from "policy" and the policyInstanceName attribute it inherits from policyInstance, this class uses the naming attribute policyActionName, which was defined above in Section 5.5. The class definition is as follows: ( NAME 'policyActionInstance' DESC 'A structural class that contains a reusable policy action.' SUP policyInstance MAY ( policyActionName ) The following DIT content rule indicates that an instance of policyActionInstance may have attached to it an instance of the auxiliary class policyActionAuxClass. ( NAME 'policyActionInstanceContentRule' DESC 'shows what auxiliary classes go with this class' AUX ( policyActionAuxClass ) ) The following DIT structure rules indicate that an instance of policyActionInstance may be named under an instance of policyRepository, using any of its three naming attributes. ( NAME 'policyActionInstanceNameForm1' OC policyActionInstance MUST ( cn ) ) Strassner, et al. Expires: September 2001 [Page 39] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 ( NAME 'policyActionInstanceStructuralRule1' FORM policyActionInstanceNameForm1 SUP ) ( NAME 'policyActionInstanceNameForm2' OC policyActionInstance MUST ( policyActionName ) ) ( NAME 'policyActionInstanceStructuralRule2' FORM policyActionInstanceNameForm2 SUP ) ( NAME 'policyActionInstanceNameForm3' OC policyActionInstance MUST ( orderedCimKeys ) ) ( NAME 'policyActionInstanceStructuralRule3' FORM policyActionInstanceNameForm3 SUP ) ( NAME 'policyActionInstanceNameForm4' OC policyActionInstance MUST ( policyInstanceName ) ) ( NAME 'policyActionInstanceStructuralRule4' FORM policyActionInstanceNameForm4 SUP ) 5.14. The Auxiliary Class policyElementAuxClass This class introduces no additional attributes, beyond those defined in the class "policy" from which it is derived. Its role is to "tag" an instance of a class defined outside the realm of policy as being nevertheless relevant to a policy specification. This tagging can potentially take place at two levels: o Every instance to which policyElementAuxClass is attached becomes an instance of the class "policy", since policyElementAuxClass is a subclass of "policy". Thus a DIT search with the filter "objectClass=policy" 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 keyword "POLICY".) Strassner, et al. Expires: September 2001 [Page 40] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 o With the policyKeywords attribute that it inherits from "policy", an instance to which policyElementAuxClass is attached can be tagged as being relevant to a particular type or category of policy, using standard keywords, administrator-defined keywords, or both. The class definition is as follows: ( NAME 'policyElementAuxClass' DESC 'An auxiliary class used to tag instances of classes defined outside the realm of policy as relevant to a particular policy specification.' SUP policy AUXILIARY ) 5.15. The Three policyRepository Classes These classes provide a container for reusable policy information, such as reusable policy conditions and/or reusable policy actions. They are derived from several classes defined in reference [10]: top | +--dlm1ManagedElement (abstract) | +--dlm1ManagedSystemElement (abstract) | +--dlm1LogicalElement (abstract) | +--dlm1System (abstract) | +--dlm1AdminDomain (abstract) | +--policyRepository (abstract) | +--policyRepositoryAuxClass (auxiliary) | +--policyRepositoryInstance (structural) To maximize flexibility, the policyRepository class is defined as abstract. A subclass policyRepositoryAuxClass provides for auxiliary attachment to another entry, while a structural subclass policyRepositoryInstance is available to represent a policy repository as a standalone entry. The class definitions for the policyRepository classes are as follows: ( NAME 'policyRepository' DESC 'A container for reusable policy information.' SUP dlm1AdminDomain Strassner, et al. Expires: September 2001 [Page 41] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 ABSTRACT MUST ( policyRepositoryName ) ) ( NAME 'policyRepositoryAuxClass' DESC 'A container for reusable policy information.' SUP policyRepository AUXILIARY ) ( NAME 'policyRepositoryInstance' DESC 'A container for reusable policy information.' SUP policyRepository STRUCTURAL ) The following DIT structure rules indicate that an instance of policyRepositoryInstance may be named under any superior, using any of its three naming attributes. These DIT structure rules cover, as special cases, a policyRepositoryInstance that is named within the scope of another policyRepositoryInstance, or within the scope of an entry to which policyRepositoryAuxClass is attached. These special cases represent the mapping for the CIM aggregation PolicyRepositoryInPolicyRepository. ( NAME 'policyRepositoryNameForm1' OC policyRepositoryInstance MUST ( cn ) ) ( NAME 'policyRepositoryStructuralRule1' FORM policyRepositoryNameForm1 ) ( NAME 'policyRepositoryNameForm2' OC policyRepositoryInstance MUST ( policyRepositoryName ) ) ( NAME 'policyRepositoryStructuralRule2' FORM policyRepositoryNameForm2 ) ( NAME 'policyRepositoryNameForm3' OC policyRepositoryInstance MUST ( orderedCimKeys ) ) ( NAME 'policyRepositoryStructuralRule3' FORM policyRepositoryNameForm3 Strassner, et al. Expires: September 2001 [Page 42] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 ) The one attribute of policyRepository is defined as follows. ( NAME 'policyRepositoryName' DESC 'The user-friendly name of this policy repository. This value is a Directory String.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) 5.16. The Auxiliary Class policySubtreesPtrAuxClass This auxiliary class provides a single, multi-valued attribute that points to 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. These entries may be placed in the DIT such that a well-known DN can be used by placing the structural entry (e.g. container) with the policySubtreesPtrAuxClass attached thereto in the root of the directory suffix. In this case, the subtree entry point can contain and/or point to all related policy entries for any well-known policy disciplines. Similarly, the subtree entry point may be placed in the DIT such that the PDP's starting point is a subtree with policy- related entries that are dependent on a hierarchically-related set of subtrees (e.g., region, division, corporate). In this latter case, DNs may be provided to the PDPs via SNMP or other techniques. 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.4. Once the objects have been retrieved, a directory client can determine the semantic linkages by following DN pointers such as policyRulesAuxContainedSet locally. 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 pointers at the same time that it requests the pointers 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 Strassner, et al. Expires: September 2001 [Page 43] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 way results in a performance problem. For example, policySubtreesPtrAuxClass SHOULD NOT be attached to the partition root for a large directory partition containing a relatively few policy- related objects along with a large number of objects unrelated to policy. A better approach would be to introduce a container object immediately below the partition root, attach policySubtreesPtrAuxClass to this container object, and then place the policy-related objects in the subtree under it. The class definition is as follows: ( NAME 'policySubtreesPtrAuxClass' DESC 'An auxiliary class providing DN pointers to roots of DIT subtrees containing policy-related objects.' SUP top AUXILIARY MAY ( policySubtreesAuxContainedSet ) ) 5.16.1. The Attribute policySubtreesAuxContainedSet This attribute provides an unordered set of DN pointers to one or more objects under which policy-related information is present. The objects pointed to may or may not themselves contain policy-related information. The attribute definition is as follows: ( NAME 'policySubtreesAuxContainedSet' DESC 'Distinguished names of objects that serve as roots for DIT subtrees containing policy-related objects. No order is implied. This value is a Distinguished Name (DN).' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 5.17. The Auxiliary Class policyGroupContainmentAuxClass This auxiliary class provides a single, multi-valued attribute that points to a set of policyGroups. 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 policyGroups relevant to it. As is the case with policyRules, a policy administrator might have several different pointers to a policyGroup in the overall directory structure. The policyGroupContainmentAuxClass is the mechanism that Strassner, et al. Expires: September 2001 [Page 44] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 makes it possible for the policy administrator to define all these pointers. The class definition is as follows: ( NAME 'policyGroupContainmentAuxClass' DESC 'An auxiliary class used to bind policyGroups to an appropriate container object.' SUP top AUXILIARY MAY ( policyGroupsAuxContainedSet ) ) 5.17.1. The Attribute policyGroupsAuxContainedSet This attribute provides an unordered set of DN pointers to one or more policyGroups associated with the instance of a structural class to which this attribute has been appended. The attribute definition is as follows: ( NAME 'policyGroupsAuxContainedSet' DESC 'Distinguished names of policyGroups associated in some way with the instance to which this attribute has been appended. No order is implied. This value is a Distinguished Name (DN).' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 5.18. The Auxiliary Class policyRuleContainmentAuxClass This auxiliary class provides a single, multi-valued attribute that points to a set of policyRules. 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 policyRules relevant to it. A policy administrator might have several different pointers to a policyRule in the overall directory structure. For example, there might be pointers to all policyRules for traffic originating in a particular subnet from a directory entry that represents that subnet. At the same time, there might be pointers to all policyRules related to a particular DiffServ setting from an instance of a policyGroup explicitly introduced as a container for DiffServ-related policyRules. The policyRuleContainmentAuxClass is the mechanism that makes it possible for the policy administrator to define all these pointers. Strassner, et al. Expires: September 2001 [Page 45] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 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. The class definition is as follows: ( NAME 'policyRuleContainmentAuxClass' DESC 'An auxiliary class used to bind policyRules to an appropriate container object.' SUP top AUXILIARY MAY ( policyRulesAuxContainedSet ) ) 5.18.1. The Attribute policyRulesAuxContainedSet This attribute provides an unordered set of DN pointers to one or more policyRules associated with the instance of a structural class to which this attribute has been appended. The attribute definition is: ( NAME 'policyRulesAuxContainedSet' DESC 'Distinguished names of policyRules associated in some way with the instance to which this attribute has been appended. No order is implied. This value is a Distinguished Name (DN).' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 6. Extending the Core Schema The following subsections provide general guidance on how to create a domain-specific schema derived from the Core Schema, discuss how the vendor classes in the Core Schema should be used, and explain how policyTimePeriodConditions are related to other policy conditions. 6.1. Subclassing policyConditionAuxClass and policyActionAuxClass In Section 4.3 above, 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 Strassner, et al. Expires: September 2001 [Page 46] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 of policyConditionAuxClass and policyActionAuxClass. It is RECOMMENDED that non-standardized schemata follow this practice as well. 6.2. Using the Vendor Policy Encoding Attributes As discussed Section 5.8 "The Class vendorPolicyConditionAuxClass", the attributes vendorPolicyConstraintData and vendorPolicyConstraintEncoding are included in vendorPolicyConditionAuxClass to provide an escape mechanism for representing "exceptional" policy conditions. The attributes vendorPolicyActionData and vendorPolicyActionEncoding in vendorPolicyActionAuxClass class play the same role with respect to actions. This enables interoperability between different vendors. 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 escape conditions provide a way for vendor-specific commands to be encoded as OctetStrings, 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 a subclass of policyConditionAuxClass, called policyTimePeriodCondition. This is to allow their inclusion in the AND/OR condition definitions for a policyRule. Care should be taken not to subclass policyTimePeriodCondition to add domain-specific condition properties. For example, it would be incorrect to add IPSec- or QoS-specific condition properties to the policyTimePeriodCondition 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 policyConditionAuxClass and then combine instances of these domain-specific condition classes with the validity period criteria. This is accomplished using the AND/OR association capabilities for policyConditions in policyRules. 7. Security Considerations The Policy Core LDAP Schema (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. Strassner, et al. Expires: September 2001 [Page 47] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 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 RFC3060 for more information.) 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 schemas consistent with the the PCLS schema 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 which 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. Expires: September 2001 [Page 48] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 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: o RFC 2829 (Authentication Methods for LDAP) o 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. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. 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 practice this standard. Please address the information to the IETF Executive Director. 9. Acknowledgments 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) Service Level Agreements and Networks working groups. We would especially like to thank Andrea Westerinen, Lee Rafalow, Glenn Waters, David Black, Michael Strassner, et al. Expires: September 2001 [Page 49] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 Richardson, Mark Stevens, David Jones, Hugh Mahon, Yoram Snir, and Yoram Ramberg for their helpful comments. 10. References [1] Moore, B., and E. Ellesson, J. Strassner,, A. Westerinen "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. [2] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [5] Strassner, J. and S. Judd, "Directory-Enabled Networks", version 3.0c5 (August 1998). A PDF file is available at http://www.murchiso.com/den/#denspec. [6] 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. [7] DMTF web site, http://www.dmtf.org. [8] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [9] Distributed Management Task Force, Inc., "Guidelines for CIM-to- LDAP Directory Mapping", May 8, 2000. This document is available on the following DMTF web page: http://www.dmtf.org/spec/denh.html. [10] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the CIM v2.4 Core Information Model", November 20, 2000. This document is available on the following DMTF web page: http://www.dmtf.org/spec/denh.html. 11. Authors' Addresses John Strassner Cisco Systems Building 20 725 Alder Drive Milpitas, CA 95035 Phone: +1 408-527-1069 Strassner, et al. Expires: September 2001 [Page 50] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 Fax: +1 408-527-1722 E-mail: johns@cisco.com Ed Ellesson LongBoard, Inc. 2505 Meridian Pkwy, #100 Durham, NC 27713 Phone: +1 919-361-3230 E-mail: eellesson@lboard.com Bob Moore IBM Corporation, BRQA/502 4205 S. Miami Blvd. Research Triangle Park, NC 27709 Phone: +1 919-254-4436 Fax: +1 919-254-6243 E-mail: remoore@us.ibm.com Ryan Moats Coreon, Inc. 15621 Drexel Circle Omaha, NE 68135 USA Phone: +1-402-894-9456 E-mail: rmoats@coreon.net 12. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Strassner, et al. Expires: September 2001 [Page 51] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 13. Appendix: Constructing the Value of orderedCimKeys 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. In its mapping from the CIM_ManagedElement class to the LDAP class dlm1ManagedElement, reference [10] introduces a third attribute, orderedCimKeys, alongside the two attributes that it derives from the properties in the CIM class. The orderedCimKeys attribute is used only in an environment where it is necessary to map between an LDAP- accessible directory and a CIM repository. For other environments, LDAP entries are identified via their other attributes that are suitable for naming. 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: o 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. o 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 .=[,=]* where the = 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 element. As with alphabetizing the key properties, the goal of suppressing the spaces is once again to make the results of string operations predictable. The values of the elements are derived from the various CIM syntaxes according to a grammar specified in reference [9]. Strassner, et al. Expires: September 2001 [Page 52] Internet Draft draft-ietf-policy-core-schema-09.txt March 2001 Strassner, et al. Expires: September 2001 [Page 53]