tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 3703

Proposed STD
Pages: 61
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: POLICY

Policy Core Lightweight Directory Access Protocol (LDAP) Schema

Part 1 of 3, p. 1 to 19
None       Next RFC Part

Updated by:    4104

Top       ToC       Page 1 
Network Working Group                                       J. Strassner
Request for Comments: 3703                        Intelliden Corporation
Category: Standards Track                                       B. Moore
                                                         IBM Corporation
                                                                R. Moats
                                                    Lemur Networks, Inc.
                                                             E. Ellesson
                                                           February 2004

    Policy Core Lightweight Directory Access Protocol (LDAP) Schema

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   This document defines a mapping of the Policy Core Information Model
   to a form that can be implemented in a directory that uses
   Lightweight Directory Access Protocol (LDAP) as its access protocol.
   This model defines two hierarchies of object classes: structural
   classes representing information for representing and controlling
   policy data as specified in RFC 3060, and relationship classes that
   indicate how instances of the structural classes are related to each
   other.  Classes are also added to the LDAP schema to improve the
   performance of a client's interactions with an LDAP server when the
   client is retrieving large amounts of policy-related information.
   These classes exist only to optimize LDAP retrievals: there are no
   classes in the information model that correspond to them.

Table of Contents

   1.  Introduction .................................................  2
   2.  The Policy Core Information Model ............................  4
   3.  Inheritance Hierarchy for the PCLS ...........................  5
   4.  General Discussion of Mapping the Information Model to LDAP ..  6
       4.1.  Summary of Class and Association Mappings ..............  7
       4.2.  Usage of DIT Content and Structure Rules and Name Forms.  9
       4.3.  Naming Attributes in the PCLS .......................... 10

Top      ToC       Page 2 
       4.4.  Rule-Specific and Reusable Conditions and Actions ...... 11
       4.5.  Location and Retrieval of Policy Objects in the
             Directory .............................................. 16
             4.5.1.  Aliases and Other DIT-Optimization Techniques .. 19
   5.  Class Definitions ............................................ 19
       5.1.  The Abstract Class "pcimPolicy" ........................ 21
       5.2.  The Three Policy Group Classes ......................... 22
       5.3.  The Three Policy Rule Classes .......................... 23
       5.4.  The Class pcimRuleConditionAssociation ................. 30
       5.5.  The Class pcimRuleValidityAssociation .................. 32
       5.6.  The Class pcimRuleActionAssociation .................... 34
       5.7.  The Auxiliary Class pcimConditionAuxClass .............. 36
       5.8.  The Auxiliary Class pcimTPCAuxClass .................... 36
       5.9.  The Auxiliary Class pcimConditionVendorAuxClass ........ 40
       5.10. The Auxiliary Class pcimActionAuxClass ................. 41
       5.11. The Auxiliary Class pcimActionVendorAuxClass ........... 42
       5.12. The Class pcimPolicyInstance ........................... 43
       5.13. The Auxiliary Class pcimElementAuxClass ................ 44
       5.14. The Three Policy Repository Classes .................... 45
       5.15. The Auxiliary Class pcimSubtreesPtrAuxClass ............ 46
       5.16. The Auxiliary Class pcimGroupContainmentAuxClass ....... 48
       5.17. The Auxiliary Class pcimRuleContainmentAuxClass ........ 49
   6.  Extending the Classes Defined in This Document ............... 50
       6.1.  Subclassing pcimConditionAuxClass and pcimActionAuxClass 50
       6.2.  Using the Vendor Policy Attributes ..................... 50
       6.3.  Using Time Validity Periods ............................ 51
   7.  Security Considerations ...................................... 51
   8.  IANA Considerations .......................................... 53
       8.1.  Object Identifiers ..................................... 53
       8.2.  Object Identifier Descriptors .......................... 53
   9.  Acknowledgments .............................................. 56
   10. Appendix:  Constructing the Value of orderedCIMKeys .......... 57
   11. References ................................................... 58
       11.1. Normative References ................................... 58
       11.2. Informative References ................................. 59
   12. Authors' Addresses ........................................... 60
   13. Full Copyright Statement ..................................... 61

1.  Introduction

   This document takes as its starting point the object-oriented
   information model for representing information for representing and
   controlling policy data as specified in [1].  Lightweight Directory
   Access Protocol (LDAP) [2] implementers, please note that the use of
   the term "policy" in this document does not refer to the use of the
   term "policy" as defined in X.501 [4].  Rather, the use of the term
   "policy" throughout this document is defined as follows:

Top      ToC       Page 3 
      Policy is defined as a set of rules to administer, manage, and
      control access to network resources.

   This work is currently under joint development in the IETF's Policy
   Framework working group and in the Policy working group of the
   Distributed Management Task Force (DMTF).  This model defines two
   hierarchies of object classes: structural classes representing policy
   information and control of policies, and relationship classes that
   indicate how instances of the structural classes are related to each
   other.  In general, both of these class hierarchies will need to be
   mapped to a particular data store.

   This document defines the mapping of these information model classes
   to a directory that uses LDAP as its access protocol.  Two types of
   mappings are involved:

      -  For the structural classes in the information model, the
         mapping is basically one-for-one: information model classes map
         to LDAP classes, information model properties map to LDAP

      -  For the relationship classes in the information model,
         different mappings are possible.  In this document, the Policy
         Core Information Model's (PCIM's) relationship classes and
         their properties are mapped in three ways: to LDAP auxiliary
         classes, to attributes representing distinguished name (DN)
         references, and to superior-subordinate relationships in the
         Directory Information Tree (DIT).

   Implementations that use an LDAP directory as their policy repository
   and want to implement policy information according to RFC 3060 [1]
   SHALL use the LDAP schema defined in this document, or a schema that
   subclasses from the schema defined in this document.  The use of the
   information model defined in reference [1] as the starting point
   enables the inheritance and the relationship class hierarchies to be
   extensible, such that other types of policy repositories, such as
   relational databases, can also use this information.

   This document fits into the overall framework for representing,
   deploying, and managing policies being developed by the Policy
   Framework Working Group.

   The LDAP schema described in this document uses the prefix "pcim" to
   identify its classes and attributes.  It consists of ten very general
   classes: pcimPolicy (an abstract class), three policy group classes
   (pcimGroup, pcimGroupAuxClass, and pcimGroupInstance), three policy
   rule classes (pcimRule, pcimRuleAuxClass, and pcimRuleInstance), and
   three special auxiliary classes (pcimConditionAuxClass,

Top      ToC       Page 4 
   pcimTPCAuxClass, and pcimActionAuxClass).  (Note that the
   PolicyTimePeriodCondition auxiliary class defined in [1] would
   normally have been named pcimTimePeriodConditionAuxClass, but this
   name is too long for some directories.  Therefore, we have
   abbreviated this name to be pcimTPCAuxClass).

   The mapping for the PCIM classes pcimGroup and pcimRule is designed
   to be as flexible as possible.  Three classes are defined for these
   two PCIM classes.  First, an abstract superclass is defined that
   contains all required properties of each PCIM class.  Then, both an
   auxiliary class as well as a structural class are derived from the
   abstract superclass.  This provides maximum flexibility for the

   The schema also contains two less general classes:
   pcimConditionVendorAuxClass and pcimActionVendorAuxClass.  To achieve
   the mapping of the information model's relationships, the schema also
   contains two auxiliary classes: pcimGroupContainmentAuxClass and
   pcimRuleContainmentAuxClass.  Capturing the distinction between
   rule-specific and reusable policy conditions and policy actions
   introduces seven other classes: pcimRuleConditionAssociation,
   pcimRuleValidityAssociation, pcimRuleActionAssociation,
   pcimPolicyInstance, and three policy repository classes
   (pcimRepository, pcimRepositoryAuxClass, and pcimRepositoryInstance).
   Finally, the schema includes two classes (pcimSubtreesPtrAuxClass and
   pcimElementAuxClass) for optimizing LDAP retrievals.  In all, the
   schema contains 23 classes.

   Within the context of this document, the term "PCLS" (Policy Core
   LDAP Schema) is used to refer to the LDAP class definitions that this
   document contains.  The term "PCIM" refers to classes defined in [1].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [10].

2.  The Policy Core Information Model

   This document contains an LDAP schema representing the classes
   defined in the companion document "Policy Core Information
   Model -- Version 1 Specification" [1].  Other documents may
   subsequently be produced, with mappings of this same PCIM to other
   storage technologies.  Since the detailed semantics of the PCIM
   classes appear only in [1], that document is a prerequisite for
   reading and understanding this document.

Top      ToC       Page 5 
3.  Inheritance Hierarchy for the PCLS

   The following diagram illustrates the class hierarchy for the LDAP
   Classes defined in this document:

         +--dlm1ManagedElement (abstract)
         |   |
         |   +--pcimPolicy (abstract)
         |   |   |
         |   |   +--pcimGroup (abstract)
         |   |   |  |
         |   |   |  +--pcimGroupAuxClass (auxiliary)
         |   |   |  |
         |   |   |  +--pcimGroupInstance (structural)
         |   |   |
         |   |   +--pcimRule (abstract)
         |   |   |  |
         |   |   |  +--pcimRuleAuxClass (auxiliary)
         |   |   |  |
         |   |   |  +--pcimRuleInstance (structural)
         |   |   |
         |   |   +--pcimRuleConditionAssociation (structural)
         |   |   |
         |   |   +--pcimRuleValidityAssociation (structural)
         |   |   |
         |   |   +--pcimRuleActionAssociation (structural)
         |   |   |
         |   |   +--pcimPolicyInstance (structural)
         |   |   |
         |   |   +--pcimElementAuxClass (auxiliary)
         |   |
         |   +--dlm1ManagedSystemElement (abstract)
         |       |
         |       +--dlm1LogicalElement (abstract)
         |           |
         |           +--dlm1System (abstract)
         |               |
         |               +--dlm1AdminDomain (abstract)
         |                   |
         |                   +--pcimRepository (abstract)
         |                      |
         |                      +--pcimRepositoryAuxClass (auxiliary)

Top      ToC       Page 6 
         |                      |
         |                      +--pcimRepositoryInstance
         |                         (structural)
         +--pcimConditionAuxClass (auxiliary)
         |   |
         |   +---pcimTPCAuxClass (auxiliary)
         |   |
         |   +---pcimConditionVendorAuxClass (auxiliary)
         +--pcimActionAuxClass (auxiliary)
         |   |
         |   +---pcimActionVendorAuxClass (auxiliary)
         +--pcimSubtreesPtrAuxClass (auxiliary)
         +--pcimGroupContainmentAuxClass (auxiliary)
         +--pcimRuleContainmentAuxClass (auxiliary)

         Figure 1.  LDAP Class Inheritance Hierarchy for the PCLS

4.  General Discussion of Mapping the Information Model to LDAP

   The classes described in Section 5 below contain certain
   optimizations for a directory that uses LDAP as its access protocol.
   One example of this is the use of auxiliary classes to represent some
   of the associations defined in the information model.  Other data
   stores might need to implement these associations differently.  A
   second example is the introduction of classes specifically designed
   to optimize retrieval of large amounts of policy-related data from a
   directory.  This section discusses some general topics related to the
   mapping from the information model to LDAP.

   The remainder of this section will discuss the following topics.
   Section 4.1 will discuss the strategy used in mapping the classes and
   associations defined in [1] to a form that can be represented in a
   directory that uses LDAP as its access protocol.  Section 4.2
   discusses DIT content and structure rules, as well as name forms.
   Section 4.3 describes the strategy used in defining naming attributes
   for the schema described in Section 5 of this document.  Section 4.4
   defines the strategy recommended for locating and retrieving
   PCIM-derived objects in the directory.

Top      ToC       Page 7 
4.1.  Summary of Class and Association Mappings

   Fifteen of the classes in the PCLS come directly from the nine
   corresponding classes in the information model.  Note that names of
   classes begin with an upper case character in the information model
   (although for CIM in particular, case is not significant in class and
   property names), but with a lower case character in LDAP.  This is
   because although LDAP doesn't care, X.500 doesn't allow class names
   to begin with an uppercase character.  Note also that the prefix
   "pcim" is used to identify these LDAP classes.

      | Information Model         | LDAP Class(es)                |
      | Policy                    | pcimPolicy                    |
      | PolicyGroup               | pcimGroup                     |
      |                           |   pcimGroupAuxClass           |
      |                           |   pcimGroupInstance           |
      | PolicyRule                | pcimRule                      |
      |                           |   pcimRuleAuxClass            |
      |                           |   pcimRuleInstance            |
      | PolicyCondition           | pcimConditionAuxClass         |
      | PolicyAction              | pcimActionAuxClass            |
      | VendorPolicyCondition     | pcimConditionVendorAuxClass   |
      | VendorPolicyAction        | pcimActionVendorAuxClass      |
      | PolicyTimePeriodCondition | pcimTPCAuxClass               |
      | PolicyRepository          | pcimRepository                |
      |                           |   pcimRepositoryAuxClass      |
      |                           |   pcimRepositoryInstance      |

          Figure 2.  Mapping of Information Model Classes to LDAP

   The associations in the information model map to attributes that
   reference DNs (Distinguished Names) or to Directory Information Tree
   (DIT) containment (i.e., superior-subordinate relationships) in LDAP.
   Two of the attributes that reference DNs appear in auxiliary classes,
   which allow each of them to represent several relationships from the
   information model.

Top      ToC       Page 8 
| Information Model Association     | LDAP Attribute / Class          |
| PolicyGroupInPolicyGroup          | pcimGroupsAuxContainedSet in    |
|                                   |  pcimGroupContainmentAuxClass   |
| PolicyRuleInPolicyGroup           | pcimRulesAuxContainedSet in     |
|                                   |  pcimRuleContainmentAuxClass    |
| PolicyConditionInPolicyRule       | DIT containment or              |
|                                   | pcimRuleConditionList in        |
|                                   |  pcimRule or                    |
|                                   | pcimConditionDN in              |
|                                   |  pcimRuleConditionAssociation   |
| PolicyActionInPolicyRule          | DIT containment or              |
|                                   | pcimRuleActionList in           |
|                                   |  pcimRule or                    |
|                                   | pcimActionDN in                 |
|                                   |  pcimRuleActionAssociation      |
| PolicyRuleValidityPeriod          | pcimRuleValidityPeriodList      |
|                                   |  in pcimRule or (if reusable)   |
|                                   |  referenced through the         |
|                                   | pcimTimePeriodConditionDN in    |
|                                   |  pcimRuleValidityAssociation    |
| PolicyConditionInPolicyRepository | DIT containment                 |
| PolicyActionInPolicyRepository    | DIT containment                 |
| PolicyRepositoryInPolicyRepository| DIT containment                 |

      Figure 3.  Mapping of Information Model Associations to LDAP

   Of the remaining classes in the PCLS, two (pcimElementAuxClass and
   pcimSubtreesPtrAuxClass) are included to make navigation through the
   DIT and retrieval of the entries found there more efficient.  This
   topic is discussed below in Section 4.5.

   The remaining four classes in the PCLS, pcimRuleConditionAssociation,
   pcimRuleValidityAssociation, pcimRuleActionAssociation, and
   pcimPolicyInstance, are all involved with the representation of
   policy conditions and policy actions in an LDAP directory.  This
   topic is discussed below in Section 4.4.

Top      ToC       Page 9 
4.2.  Usage of DIT Content and Structure Rules and Name Forms

   There are three powerful tools that can be used to help define
   schemata. The first, DIT content rules, is a way of defining the
   content of an entry for a structural object class.  It can be used to
   specify the following characteristics of the entry:

      -  additional mandatory attributes that the entries are required
         to contain
      -  additional optional attributes the entries are allowed to
      -  the set of additional auxiliary object classes that these
         entries are allowed to be members of
      -  any optional attributes from the structural and auxiliary
         object class definitions that the entries are required to

   DIT content rules are NOT mandatory for any structural object class.

   A DIT structure rule, together with a name form, controls the
   placement and naming of an entry within the scope of a subschema.
   Name forms define which attribute type(s) are required and are
   allowed to be used in forming the Relative Distinguished Names (RDNs)
   of entries.  DIT structure rules specify which entries are allowed to
   be superior to other entries, and hence control the way that RDNs are
   added together to make DNs.

   A name form specifies the following:

      -  the structural object class of the entries named by this name
      -  attributes that are required to be used in forming the RDNs of
         these entries
      -  attributes that are allowed to be used in forming the RDNs of
         these entries
      -  an object identifier to uniquely identify this name form

   Note that name forms can only be specified for structural object
   classes.  However, every entry in the DIT must have a name form
   controlling it.

   Unfortunately, current LDAP servers vary quite a lot in their support
   of these features.  There are also three crucial implementation
   points that must be followed.  First, X.500 use of structure rules
   requires that a structural object class with no superior structure
   rule be a subschema administrative point.  This is exactly NOT what
   we want for policy information.  Second, when an auxiliary class is
   subclassed, if a content rule exists for the structural class that

Top      ToC       Page 10 
   the auxiliary class refers to, then that content rule needs to be
   augmented.  Finally, most LDAP servers unfortunately do not support
   inheritance of structure and content rules.

   Given these concerns, DIT structure and content rules have been
   removed from the PCLS.  This is because, if included, they would be
   normative references and would require OIDs.  However, we don't want
   to lose the insight gained in building the structure and content
   rules of the previous version of the schema.  Therefore, we describe
   where such rules could be used in this schema, what they would
   control, and what their effect would be.

4.3.  Naming Attributes in the PCLS

   Instances in a directory are identified by distinguished names (DNs),
   which provide the same type of hierarchical organization that a file
   system provides in a computer system.  A distinguished name is a
   sequence of RDNs.  An RDN provides a unique identifier for an
   instance within the context of its immediate superior, in the same
   way that a filename provides a unique identifier for a file within
   the context of the folder in which it resides.

   To preserve maximum naming flexibility for policy administrators,
   three optional (i.e., "MAY") naming attributes have been defined.
   They are:

      -  Each of the structural classes defined in this schema has its
         own unique ("MAY") naming attribute.  Since the naming
         attributes are different, a policy administrator can, by using
         these attributes, guarantee that there will be no name
         collisions between instances of different classes, even if the
         same value is assigned to the instances' respective naming

      -  The LDAP attribute cn (corresponding to X.500's commonName) is
         included as a MAY attribute in the abstract class pcimPolicy,
         and thus by inheritance in all of its subclasses.  In X.500,
         commonName typically functions as an RDN attribute, for naming
         instances of many classes (e.g., X.500's person class).

      -  A special attribute is provided for implementations that expect
         to map between native CIM and LDAP representations of policy
         information.  This attribute, called orderedCimKeys, is defined
         in the class dlm1ManagedElement [6].  The value of this
         attribute is derived algorithmically from values that are
         already present in a CIM policy instance.  The normative
         reference for this algorithm is contained in [6].  See the
         appendix of this document for a description of the algorithm.

Top      ToC       Page 11 
   Since any of these naming attributes MAY be used for naming an
   instance of a PCLS class, implementations MUST be able to accommodate
   instances named in any of these ways.

   Note that it is recommended that two or more of these attributes
   SHOULD NOT be used together to form a multi-part RDN, since support
   for multi-part RDNs is limited among existing directory

4.4.  Rule-Specific and Reusable Conditions and Actions

   The PCIM [1] distinguishes between two types of policy conditions and
   policy actions:  those associated with a single policy rule, and
   those that are reusable, in the sense that they may be associated
   with more than one policy rule.  While there is no inherent
   functional difference between a rule-specific condition or action and
   a reusable one, there is both a usage, as well as, an implementation
   difference between them.

   Defining a condition or action as reusable vs. rule-specific reflects
   a conscious decision on the part of the administrator in defining how
   they are used.  In addition, there are variations that reflect
   implementing rule-specific vs. reusable policy conditions and actions
   and how they are treated in a policy repository.  The major
   implementation differences between a rule-specific and a reusable
   condition or action are delineated below:

   1.  It is natural for a rule-specific condition or action to be
       removed from the policy repository at the same time the rule is.
       It is just the opposite for reusable conditions and actions.
       This is because the condition or action is conceptually attached
       to the rule in the rule-specific case, whereas it is referenced
       (e.g., pointed at) in the reusable case.  The persistence of a
       pcimRepository instance is independent of the persistence of a
       pcimRule instance.
   2.  Access permissions for a rule-specific condition or action are
       usually identical to those for the rule itself.  On the other
       hand, access permissions of reusable conditions and actions must
       be expressible without reference to a policy rule.
   3.  Rule-specific conditions and actions require fewer accesses,
       because the conditions and actions are "attached" to the rule.
       In contrast, reusable conditions and actions require more
       accesses, because each condition or action that is reusable
       requires a separate access.
   4.  Rule-specific conditions and actions are designed for use by a
       single rule.  As the number of rules that use the same
       rule-specific condition increase, subtle problems are created
       (the most obvious being how to keep the rule-specific conditions

Top      ToC       Page 12 
       and actions updated to reflect the same value).  Reusable
       conditions and actions lend themselves for use by multiple
       independent rules.
   5.  Reusable conditions and actions offer an optimization when
       multiple rules are using the same condition or action.  This is
       because the reusable condition or action only needs be updated
       once, and by virtue of DN reference, the policy rules will be
       automatically updated.

   The preceding paragraph does not contain an exhaustive list of the
   ways in which reusable and rule-specific conditions should be treated
   differently.  Its purpose is merely to justify making a semantic
   distinction between rule-specific and reusable, and then reflecting
   this distinction in the policy repository itself.

   When the policy repository is realized in an LDAP-accessible
   directory, the distinction between rule-specific and reusable
   conditions and actions is realized via placement of auxiliary classes
   and via DIT containment.  Figure 4 illustrates a policy rule Rule1
   with one rule-specific condition CA and one rule-specific action AB.

                    |     |
              +-----|-   -|-----+
              |     +-----+     |
              |       * *       |
              |       * *       |
              |    **** ****    |
              |    *       *    |
              v    *       *    v
            +--------+   +--------+
            | CA+ca  |   | AB+ab  |
            +--------+   +--------+

                          |LEGEND:                       |
                          |  ***** DIT containment       |
                          |    +   auxiliary attachment  |
                          |  ----> DN reference          |

           Figure 4  Rule-Specific Policy Conditions and Actions

Top      ToC       Page 13 
   Because the condition and action are specific to Rule1, the auxiliary
   classes ca and ab that represent them are attached, respectively, to
   the structural classes CA and AB.  These structural classes represent
   not the condition ca and action ab themselves, but rather the
   associations between Rule1 and ca, and between Rule1 and ab.

   As Figure 4 illustrates, Rule1 contains DN references to the
   structural classes CA and AB that appear below it in the DIT.  At
   first glance it might appear that these DN references are
   unnecessary, since a subtree search below Rule1 would find all of the
   structural classes representing the associations between Rule1 and
   its conditions and actions.  Relying only on a subtree search,
   though, runs the risk of missing conditions or actions that should
   have appeared in the subtree, but for some reason did not, or of
   finding conditions or actions that were inadvertently placed in the
   subtree, or that should have been removed from the subtree, but for
   some reason were not.  Implementation experience has suggested that
   many (but not all) of these risks are eliminated.

   However, it must be noted that this comes at a price.  The use of DN
   references, as shown in Figure 4 above, thwarts inheritance of access
   control information as well as existence dependency information.  It
   also is subject to referential integrity considerations.  Therefore,
   it is being included as an option for the designer.

   Figure 5 illustrates a second way of representing rule-specific
   conditions and actions in an LDAP-accessible directory: attachment of
   the auxiliary classes directly to the instance representing the
   policy rule.  When all of the conditions and actions are attached to
   a policy rule in this way, the rule is termed a "simple" policy rule.
   When conditions and actions are not attached directly to a policy
   rule, the rule is termed a "complex" policy rule.

                    |           |

                          |LEGEND:                       |
                          |    +   auxiliary attachment  |

                      Figure 5.  A Simple Policy Rule

Top      ToC       Page 14 
   The simple/complex distinction for a policy rule is not all or
   nothing.  A policy rule may have its conditions attached to itself
   and its actions attached to other entries, or it may have its actions
   attached to itself and its conditions attached to other entries.
   However, it SHALL NOT have either its conditions or its actions
   attached both to itself and to other entries, with one exception:  a
   policy rule may reference its validity periods with the
   pcimRuleValidityPeriodList attribute, but have its other conditions
   attached to itself.

   The tradeoffs between simple and complex policy rules are between the
   efficiency of simple rules and the flexibility and greater potential
   for reuse of complex rules.  With a simple policy rule, the semantic
   options are limited:

   -   All conditions are ANDed together.  This combination can be
       represented in two ways in the Disjunctive Normal Form (DNF)/
       Conjunctive Normal Form (CNF) (please see [1] for definitions of
       these terms) expressions characteristic of policy conditions:  as
       a DNF expression with a single AND group, or as a CNF expression
       with multiple single-condition OR groups.  The first of these is
       arbitrarily chosen as the representation for the ANDed conditions
       in a simple policy rule.

   -   If multiple actions are included, no order can be specified for

   If a policy administrator needs to combine conditions in some other
   way, or if there is a set of actions that must be ordered, then the
   only option is to use a complex policy rule.

   Finally, Figure 6 illustrates the same policy rule Rule1, but this
   time its condition and action are reusable.  The association classes
   CA and AB are still present, and they are still DIT contained under
   Rule1.  But rather than having the auxiliary classes ca and ab
   attached directly to the association classes CA and AB, each now
   contains DN references to other entries to which these auxiliary
   classes are attached.  These other entries, CIA and AIB, are DIT
   contained under RepositoryX, which is an instance of the class
   pcimRepository.  Because they are named under an instance of
   pcimRepository, ca and ab are clearly identified as reusable.

Top      ToC       Page 15 
                   +-----+             +-------------+
                   |Rule1|             | RepositoryX |
                 +-|-   -|--+          |             |
                 | +-----+  |          +-------------+
                 |   * *    |             *       *
                 |   * *    |             *       *
                 | *** **** |             *       *
                 | *      * v             *       *
                 | *     +---+            *       *
                 | *     |AB |         +------+   *
                 v *     |  -|-------->|AIB+ab|   *
                +---+    +---+         +------+   *
                |CA |                         +------+
                |  -|------------------------>|CIA+ca|
                +---+                         +------+

                          |LEGEND:                       |
                          |  ***** DIT containment       |
                          |    +   auxiliary attachment  |
                          |  ----> DN reference          |

             Figure 6.  Reusable Policy Conditions and Actions

   The classes pcimConditionAuxClass and pcimActionAuxClass do not
   themselves represent actual conditions and actions:  these are
   introduced in their subclasses.  What pcimConditionAuxClass and
   pcimActionAuxClass do introduce are the semantics of being a policy
   condition or a policy action.  These are the semantics that all the
   subclasses of pcimConditionAuxClass and pcimActionAuxClass inherit.
   Among these semantics are those of representing either a
   rule-specific or a reusable policy condition or policy action.

   In order to preserve the ability to represent a rule-specific or a
   reusable condition or action, as well as a simple policy rule, all
   the subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST
   also be auxiliary classes.

Top      ToC       Page 16 
4.5.  Location and Retrieval of Policy Objects in the Directory

   When a Policy Decision Point (PDP) goes to an LDAP directory to
   retrieve the policy object instances relevant to the Policy
   Enforcement Points (PEPs) it serves, it is faced with two related

   -   How does it locate and retrieve the directory entries that apply
       to its PEPs?  These entries may include instances of the PCLS
       classes, instances of domain-specific subclasses of these
       classes, and instances of other classes modeling such resources
       as user groups, interfaces, and address ranges.

   -   How does it retrieve the directory entries it needs in an
       efficient manner, so that retrieval of policy information from
       the directory does not become a roadblock to scalability?  There
       are two facets to this efficiency:  retrieving only the relevant
       directory entries, and retrieving these entries using as few LDAP
       calls as possible.

   The placement of objects in the Directory Information Tree (DIT)
   involves considerations other than how the policy-related objects
   will be retrieved by a PDP.  Consequently, all that the PCLS can do
   is to provide a "toolkit" of classes to assist the policy
   administrator as the DIT is being designed and built.  A PDP SHOULD
   be able to take advantage of any tools that the policy administrator
   is able to build into the DIT, but it MUST be able to use a less
   efficient means of retrieval if that is all it has available to it.

   The basic idea behind the LDAP optimization classes is a simple one:
   make it possible for a PDP to retrieve all the policy-related objects
   it needs, and only those objects, using as few LDAP calls as
   possible.  An important assumption underlying this approach is that
   the policy administrator has sufficient control over the underlying
   DIT structure to define subtrees for storing policy information.  If
   the policy administrator does not have this level of control over DIT
   structure, a PDP can still retrieve the policy-related objects it
   needs individually.  But it will require more LDAP access operations
   to do the retrieval in this way.  Figure 7 illustrates how LDAP
   optimization is accomplished.

Top      ToC       Page 17 
      ---------------->|  A  |
      DN reference to  |     |    DN references to subtrees   +---+
      starting object  +-----+    +-------------------------->| C |
                       |  o--+----+         +---+             +---+
                       |  o--+------------->| B |            /     \
                       +-----+              +---+           /       \
                      /       \            /     \         /   ...   \
                     /         \          /       \
                    /           \        /   ...   \

      Figure 7.  Using the pcimSubtreesPtrAuxClass to Locate Policies

   The PDP is configured initially with a DN reference to some entry in
   the DIT.  The structural class of this entry is not important; the
   PDP is interested only in the pcimSubtreesPtrAuxClass attached to it.
   This auxiliary class contains a multi-valued attribute with DN
   references to objects that anchor subtrees containing policy-related
   objects of interest to the PDP.  Since pcimSubtreesPtrAuxClass is an
   auxiliary class, it can be attached to an entry that the PDP would
   need to access anyway - perhaps an entry containing initial
   configuration settings for the PDP, or for a PEP that uses the PDP.

   Once it has retrieved the DN references, the PDP will direct to each
   of the objects identified by them an LDAP request that all entries in
   its subtree be evaluated against the selection criteria specified in
   the request.  The LDAP-enabled directory then returns all entries in
   that subtree that satisfy the specified criteria.

   The selection criteria always specify that object class="pcimPolicy".
   Since all classes representing policy rules, policy conditions, and
   policy actions, both in the PCLS and in any domain-specific schema
   derived from it, are subclasses of the abstract class policy, this
   criterion evaluates to TRUE for all instances of these classes.  To
   accommodate special cases where a PDP needs to retrieve objects that
   are not inherently policy-related (for example, an IP address range
   object referenced by a subclass of pcimActionAuxClass representing
   the DHCP action "assign from this address range"), the auxiliary
   class pcimElementAuxClass can be used to "tag" an entry, so that it
   will be found by the selection criterion "object class=pcimPolicy".

   The approach described in the preceding paragraph will not work for
   certain directory implementations, because these implementations do
   not support matching of auxiliary classes in the objectClass
   attribute.  For environments where these implementations are expected
   to be present, the "tagging" of entries as relevant to policy can be

Top      ToC       Page 18 
   accomplished by inserting the special value "POLICY" into the list of
   values contained in the pcimKeywords attribute (provided by the
   pcimPolicy class).

   If a PDP needs only a subset of the policy-related objects in the
   indicated subtrees, then it can be configured with additional
   selection criteria based on the pcimKeywords attribute defined in the
   pcimPolicy class.  This attribute supports both standardized and
   administrator- defined values.  For example, a PDP could be
   configured to request only those policy-related objects containing
   the keywords "DHCP" and "Eastern US".

   To optimize what is expected to be a typical case, the initial
   request from the client includes not only the object to which its
   "seed" DN references, but also the subtree contained under this
   object.  The filter for searching this subtree is whatever the client
   is going to use later to search the other subtrees:  object
   class="pcimPolicy" or the presence of the keyword "POLICY", and/or
   presence of a more specific value of pcimKeywords (e.g., "QoS Edge

   Returning to the example in Figure 7, we see that in the best case, a
   PDP can get all the policy-related objects it needs, and only those
   objects, with exactly three LDAP requests:  one to its starting
   object A to get the references to B and C, as well as the
   policy-related objects it needs from the subtree under A, and then
   one each to B and C to get all the policy-related objects that pass
   the selection criteria with which it was configured.  Once it has
   retrieved all of these objects, the PDP can then traverse their
   various DN references locally to understand the semantic
   relationships among them.  The PDP should also be prepared to find a
   reference to another subtree attached to any of the objects it
   retrieves, and to follow this reference first, before it follows any
   of the semantically significant references it has received.  This
   recursion permits a structured approach to identifying related
   policies.  In Figure 7, for example, if the subtree under B includes
   departmental policies and the one under C includes divisional
   policies, then there might be a reference from the subtree under C to
   an object D that roots the subtree of corporate-level policies.

   A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be
   capable of retrieving and processing the entries in the subtrees it
   references, and SHOULD be capable of doing all of this recursively.
   The same requirements apply to any other entity needing to retrieve
   policy information from the directory.  Thus, a Policy Management
   Tool that retrieves policy entries from the directory in order to
   perform validation and conflict detection SHOULD also understand and
   be capable of using the pcimSubtreesPtrAuxClass.  All of these

Top      ToC       Page 19 
   requirements are "SHOULD"s rather than "MUST"s because an LDAP client
   that doesn't implement them can still access and retrieve the
   directory entries it needs.  The process of doing so will just be
   less efficient than it would have been if the client had implemented
   these optimizations.

   When it is serving as a tool for creating policy entries in the
   directory, a Policy Management Tool SHOULD support creation of
   pcimSubtreesPtrAuxClass entries and their references to object

4.5.1.  Aliases and Other DIT-Optimization Techniques

   Additional flexibility in DIT structure is available to the policy
   administrator via LDAP aliasing and other techniques.  Previous
   versions of this document have used aliases.  However, because
   aliases are experimental, the use of aliases has been removed from
   this version of this document.  This is because the IETF has yet to
   produce a specification on how aliases are represented in the
   directory or how server implementations are to process aliases.

(page 19 continued on part 2)

Next RFC Part