Policy Framework Working Group                             J. Strassner
 Internet-draft                                            Cisco Systems
 Category: Standards Track                                   E. Ellesson
                                                                B. Moore
                                                         IBM Corporation
                                                              Ryan Moats
                                                                  Coreon
                                                               July 2000
 
                          Policy Core LDAP Schema
                    draft-ietf-policy-core-schema-07.txt
                            July 14, 2000 14:26
 
 
   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 (2000).  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
   LDAP schema, the structural classes can be mapped more or less
 
 Strassner, et al.      Expires: January 14, 2001               [Page 1]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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:  January 14, 2001              [Page 2]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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.........................8
      4.3. Rule-Specific and Reusable Conditions and Actions............9
      4.4. Location and Retrieval of Policy Objects in the Directory...13
      4.4.1. Aliases and Other DIT-Optimization Techniques.............16
   5. Class Definitions................................................17
      5.1. The Abstract Class "policy".................................17
      5.2. The Class policyGroup.......................................18
      5.3. The Class policyRule........................................20
      5.4. The Class policyRuleConditionAssociation....................24
      5.5. The Class policyRuleActionAssociation.......................26
      5.6. The Auxiliary Class policyConditionAuxClass.................28
      5.7. The Auxiliary Class policyTimePeriodConditionAuxClass.......28
      5.8. The Auxiliary Class vendorPolicyConditionAuxClass...........30
      5.9. The Auxiliary Class policyActionAuxClass....................31
      5.10. The Auxiliary Class vendorPolicyActionAuxClass.............31
      5.11. The Class policyInstance...................................32
      5.12. The Class policyConditionInstance..........................33
      5.13. The Class policyActionInstance.............................35
      5.14. The Auxiliary Class policyElementAuxClass..................36
      5.15. The Class policyRepository.................................37
      5.16. The Auxiliary Class policySubtreesPtrAuxClass..............38
      5.16.1. The Attribute policySubtreesAuxContainedSet..............39
      5.17. The Auxiliary Class policyGroupContainmentAuxClass.........40
      5.17.1. The Attribute policyGroupsAuxContainedSet................40
      5.18. The Auxiliary Class policyRuleContainmentAuxClass..........41
      5.18.1. The Attribute policyRulesAuxContainedSet.................41
   6. Extending the Core Schema........................................42
      6.1. Subclassing policyConditionAuxClass and policyActionAuxClass42
      6.2. Using the Vendor Policy Encoding Attributes.................42
      6.3. Using Time Validity Periods.................................42
   7. Security Considerations..........................................43
   8. Intellectual Property............................................45
   9. Acknowledgments..................................................45
   10. References......................................................45
   11. Authors' Addresses..............................................46
   12. Full Copyright Statement........................................47
   13. Appendix:  Constructing the Value of orderedCimKeys.............47
 
 
 
 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
   Framework working group.  The IETF document defining this information
 
 Strassner, et al.      Expires:  January 14, 2001              [Page 3]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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
   companion document "Policy Core Information Model -- Version 1
   Specification" [1].  Other documents may subsequently be produced,
 
 Strassner, et al.      Expires:  January 14, 2001              [Page 4]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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:  January 14, 2001              [Page 5]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
     top
      |
      +--cim23ManagedElement (abstract)
      |   |
      |   +--policy (abstract)
      |   |   |
      |   |   +--policyGroup (structural)
      |   |   |
      |   |   +--policyRule (structural)
      |   |   |
      |   |   +--policyRuleConditionAssociation (structural)
      |   |   |
      |   |   +--policyRuleActionAssociation (structural)
      |   |   |
      |   |   +--policyInstance (structural)
      |   |   |   |
      |   |   |   +--policyConditionInstance (structural)
      |   |   |   |
      |   |   |   +--policyActionInstance (structural)
      |   |   |
      |   |   +--policyElementAuxClass (auxiliary)
      |   |
      |   +--cim23ManagedSystemElement (abstract)
      |       |
      |       +--cim23LogicalElement (abstract)
      |           |
      |           +--cim23System (abstract)
      |               |
      |               +--cim23AdminDomain (abstract)
      |                   |
      |                   +--policyRepository (structural)
      |
      +--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
 
 
 
 Strassner, et al.      Expires:  January 14, 2001              [Page 6]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
 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.
 
   +---------------------------+-----------------------------------+
   | 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:  January 14, 2001              [Page 7]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   +-----------------------------------+--------------------------------+
   | Information Model Association     | LDAP Attribute / Class         |
   +-----------------------------------+--------------------------------+
   +-----------------------------------+--------------------------------+
   | PolicyGroupInPolicyGroup          | policyGroupsAuxContainedSet in |
   |                                   |  policyGroupContainmentAuxClass|
   +-----------------------------------+--------------------------------+
   | PolicyRuleInPolicyGroup           | policyRulesAuxContainedSet in  |
   |                                   |  policyRuleContainmentAuxClass |
   +-----------------------------------+--------------------------------+
   | PolicyConditionInPolicyRule       | DIT containment +              |
   |                                   | containedConditionAssocSet in  |
   |                                   |  policyRule +                  |
   |                                   | policyConditionDN in           |
   |                                   |  policyRuleConditionAssociation|
   +-----------------------------------+--------------------------------+
   | PolicyActionInPolicyRule          | DIT containment +              |
   |                                   | containedActionAssocSet 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
   immediate superior, in the same way that a filename provides a unique
 
 Strassner, et al.      Expires:  January 14, 2001              [Page 8]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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 cim23ManagedElement,
   defined in reference [11], 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,
   differences in how they are treated in a policy repository.  For
   example, it's natural to make the access permissions for a rule-
 
 Strassner, et al.      Expires:  January 14, 2001              [Page 9]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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:  January 14, 2001             [Page 10]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
                 +-----+
                 |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:  January 14, 2001             [Page 11]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
       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:  January 14, 2001             [Page 12]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
                +-----+             +-------------+
                |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:  January 14, 2001             [Page 13]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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:  January 14, 2001             [Page 14]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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
   should also be prepared to find a pointer to another subtree attached
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 15]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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
   policy subtrees can still be done.  The administrator simply inserts
   into one of the subtrees of policy entries an alias entry aliasX
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 16]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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, attributes like seeAlso, and the extensible matching rule for
   dereferencing DN pointers discussed in reference [8].  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
   cim23ManagedElement, map directly to attributes in the class "policy".
   See reference [11] for the definition of the LDAP class
   cim23ManagedElement.
 
   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.
 
   The class definition is as follows:
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 17]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
     ( <oid-oc1> NAME 'policy'
       DESC 'An abstract class with five attributes for describing
            a policy-related instance.  The attributes cimCaption,
            cimDescription, and orderedCimKeys are inherited from
            cim23ManagedElement.'
       SUP cim23ManagedElement
       ABSTRACT
       MAY ( cn $ policyKeywords )
     )
 
   The three attributes cimCaption, cimDescription, and orderedCimKeys
   are defined in reference [11].  The attribute "cn" is defined in
   X.520.  The remaining attribute, policyKeywords, is defined as
   follows:
 
     ( <oid-at3> 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.'
            SYNTAX IA5String
            EQUALITY caseExactIA5Match
     )
 
 5.2. The Class policyGroup
 
   The class definition for policyGroup is as follows.  Note that this
   class definition does 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.
 
     ( <oid-oc2> NAME 'policyGroup'
            DESC 'A container for either a set of related policyRules or
                 a set of related policyGroups.'
            SUP policy
            MUST ( policyGroupName )
     )
 
   The following DIT content rule indicates that an instance of
   policyGroup may have attached to it either DN pointers to one or more
   other policyGroups, or DN pointers to one or more policyRules.
 
     ( <oid-oc2>
            NAME 'policyGroupContentRule'
            DESC 'shows what auxiliary classes go with this object'
            AUX ( policyGroupContainmentAuxClass $
                 policyRuleContainmentAuxClass )
     )
 
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 18]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   The following DIT structure rules indicate that an instance of
   policyGroup 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 policyGroup or
   policyRule 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
   PolicyGroup may be named.
 
     ( <oid-nf1> NAME 'policyGroupNameForm1'
       OC policyGroup
       MUST ( cn )
     )
 
     ( <sr1> NAME 'policyGroupStructuralRule1'
       FORM policyGroupNameForm1
     )
 
     ( <oid-nf2> NAME 'policyGroupNameForm2'
       OC policyGroup
       MUST ( policyGroupName )
     )
 
     ( <sr2> NAME 'policyGroupStructuralRule2'
       FORM policyGroupNameForm2
     )
 
     ( <oid-nf15> NAME 'policyGroupNameForm3'
       OC policyGroup
       MUST ( orderedCimKeys )
     )
 
     ( <sr15> NAME 'policyGroupStructuralRule3'
       FORM policyGroupNameForm3
     )
 
   The one attribute of policyGroup is defined as:
 
     ( <oid-at4> NAME 'policyGroupName'
            DESC 'The user-friendly name of this policy group.'
            SYNTAX IA5String
            EQUALITY caseExactIA5Match
            SINGLE-VALUE
     )
 
 
 
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 19]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
 5.3. The Class policyRule
 
   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.
   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.
 
   The class definition of policyRule is as follows:
 
     ( <oid-oc3> NAME 'policyRule'
            DESC 'The central class for representing the "If Condition
                 then Action" semantics associated with a policy rule.'
            SUP policy
            MUST ( policyRuleName )
            MAY ( policyRuleEnabled $ policyRuleConditionListType $
                 policyRuleConditionList $ policyRuleActionList $
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 20]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
                 policyRuleValidityPeriodList $ policyRuleUsage $
                 policyRulePriority $ policyRuleMandatory $
                 policyRuleSequencedActions $ policyRoles )
     )
 
   The following DIT content rule indicates that an instance of
   policyRule may have attached to it the auxiliary classes
   policyConditionAuxClass and policyActionAuxClass, or one of their
   subclasses.  This combination represents a simple policy rule.
 
     ( <oid-oc3>
            NAME 'policyRuleContentRule'
            DESC 'shows what auxiliary classes go with this object'
            AUX ( policyConditionAuxClass $ policyActionAuxClass )
     )
 
   The following DIT structure rules indicate that an instance of
   policyRule 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 policyGroup or
   policyRule 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
   PolicyRule may be named.
 
      ( <oid-nf3> NAME 'policyRuleNameForm1'
            OC policyRule
            MUST ( cn )
     )
 
     ( <sr3> NAME 'policyRuleStructuralRule1'
         FORM policyRuleNameForm1
     )
 
     ( <oid-nf4> NAME 'policyRuleNameForm2'
       OC policyRule
       MUST ( policyRuleName )
     )
 
     ( <sr4> NAME 'policyRuleStructuralRule2'
         FORM policyRuleNameForm2
     )
     ( <oid-nf16> NAME 'policyRuleNameForm3'
       OC policyRule
       MUST ( orderedCimKeys )
     )
 
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 21]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
     ( <sr16> NAME 'policyRuleStructuralRule3'
         FORM policyRuleNameForm3
     )
 
   The attributes of policyRule are defined as follows:
 
     ( <oid-at5> NAME 'policyRuleName'
            DESC 'The user-friendly name of this policy rule.'
            SYNTAX IA5String
            EQUALITY caseExactIA5Match
            SINGLE-VALUE
     )
 
     ( <oid-at6> 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).'
            SYNTAX INTEGER
            EQUALITY integerMatch
            SINGLE-VALUE
     )
 
     ( <oid-at7> 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).'
            SYNTAX INTEGER
            EQUALITY integerMatch
            SINGLE-VALUE
     )
 
     ( <oid-at36> NAME 'policyRuleConditionList'
            DESC 'Distinguished names of policyRuleConditionAssociation
                  entries representing associations between this policy
                  rule and its conditions.  No order is implied.'
            SYNTAX DN
            EQUALITY distinguishedNameMatch
     )
 
     ( <oid-at37> NAME 'policyRuleActionList'
            DESC 'Distinguished names of policyRuleActionAssociation
                  entries representing associations between this policy
                  rule and its actions.  No order is implied.'
 
            SYNTAX DN
            EQUALITY distinguishedNameMatch
     )
 
     ( <oid-at8> NAME 'policyRuleValidityPeriodList'
            DESC 'Distinguished names of policyTimePeriodConditions that
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 22]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
                 determine when the policyRule is scheduled to be active
                 / inactive.  No order is implied.'
            SYNTAX DN
            EQUALITY distinguishedNameMatch
     )
 
     ( <oid-at9> NAME 'policyRuleUsage'
            DESC 'This attribute is used to provide guidelines on how
                  this policy should be used.'
            SYNTAX DirectoryString
            EQUALITY caseIgnoreMatch
            SINGLE-VALUE
     )
 
     ( <oid-at10> NAME 'policyRulePriority'
            DESC 'A non-negative integer for prioritizing this policyRule
                  relative to other policyRules. A larger value indicates
                  a higher priority.'
            SYNTAX INTEGER
            EQUALITY integerMatch
            SINGLE-VALUE
     )
 
     ( <oid-at11> 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.'
            SYNTAX Boolean
            EQUALITY booleanMatch
            SINGLE-VALUE
     )
 
     ( <oid-at12> 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).'
            SYNTAX INTEGER
            EQUALITY integerMatch
     )
 
     ( <oid-at38> 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
 
                       <RoleName>[&&<RoleName>]*
 
                  where the individual role names appear in alphabetical
                  order according to the collating sequence for UCS-2.'
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 23]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
            SYNTAX DirectoryString
            EQUALITY caseIgnoreMatch
     )
 
 
 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:
 
     ( <oid-oc4> 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.
 
     ( <oid-oc4>
            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.
 
     ( <oid-nf5> NAME 'policyRuleConditionAssociationNameForm1'
            OC policyRuleConditionAssociation
            MUST ( cn )
 
     ( <sr5> NAME 'policyRuleConditionAssociationStructuralRule1'
            FORM policyRuleConditionAssociationNameForm1
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 24]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
            SUP <sr3> <sr4> <sr16>
     )
 
     ( <oid-nf6> NAME 'policyRuleConditionAssociationNameForm2'
            OC policyRuleConditionAssociation
            MUST ( policyConditionName )
     )
 
     ( <sr6> NAME 'policyRuleConditionAssociationStructuralRule2'
            FORM policyRuleConditionAssociationNameForm2
            SUP <sr3> <sr4> <sr16>
     )
     ( <oid-nf17> NAME 'policyRuleConditionAssociationNameForm3'
            OC policyRuleConditionAssociation
            MUST ( orderedCimKeys )
     )
 
     ( <sr17> NAME 'policyRuleConditionAssociationStructuralRule3'
            FORM policyRuleConditionAssociationNameForm3
            SUP <sr3> <sr4> <sr16>
     )
 
   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.
 
     ( <oid-at13>
            NAME 'policyConditionName'
            DESC 'A user-friendly name for a policy condition.'
            SYNTAX IA5String
            EQUALITY caseExactIA5Match
            SINGLE-VALUE
     )
 
     ( <oid-at14>
            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.
            SYNTAX INTEGER
            EQUALITY integerMatch
            SINGLE-VALUE
      )
 
     ( <oid-at15>
            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'
            SYNTAX Boolean
            EQUALITY booleanMatch
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 25]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
            SINGLE-VALUE
     )
 
     ( <oid-at16>
            NAME 'policyConditionDN'
            DESC 'A DN pointer to a reusable policy condition.'
            SYNTAX DN
            EQUALITY distinguishedNameMatch
            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:
 
     ( <oid-oc5> 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
   class policyActionAuxClass, or one of its subclasses.  This
   combination represents a rule-specific policy action.
 
     ( <oid-oc5>
            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.
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 26]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
     ( <oid-nf7> NAME 'policyRuleActionAssociationNameForm1'
            OC policyRuleActionAssociation
            MUST ( cn )
     )
 
     ( <sr7> NAME 'policyRuleActionAssociationStructuralRule1'
            FORM policyRuleActionAssociationNameForm1
            SUP <sr3> <sr4> <sr16>
     )
 
     ( <oid-nf8> NAME 'policyRuleActionAssociationNameForm2'
            OC policyRuleActionAssociation
            MUST ( policyActionName )
          )
 
     ( <sr8> NAME 'policyRuleActionAssociationStructuralRule2'
            FORM policyRuleActionAssociationNameForm2
            SUP <sr3> <sr4> <sr16>
     )
 
     ( <oid-nf18> NAME 'policyRuleActionAssociationNameForm3'
            OC policyRuleActionAssociation
            MUST ( orderedCimKeys )
     )
 
     ( <sr18> NAME 'policyRuleActionAssociationStructuralRule3'
            FORM policyRuleActionAssociationNameForm3
            SUP <sr3> <sr4> <sr16>
     )
 
   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.
 
     ( <oid-at17>
            NAME 'policyActionName'
            DESC 'A user-friendly name for a policy action.'
            SYNTAX IA5String
            EQUALITY caseExactIA5Match
            SINGLE-VALUE
     )
 
     ( <oid-at33>
            NAME 'policyActionOrder'
            DESC 'An integer indicating the relative order of an action
                  in the context of a policy rule.
            SYNTAX INTEGER
            EQUALITY integerMatch
            SINGLE-VALUE
     )
 
     ( <oid-at34>
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 27]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
            NAME 'policyActionDN'
            DESC 'A DN pointer to a reusable policy action.'
            SYNTAX DN
            EQUALITY distinguishedNameMatch
            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:
 
     ( <oid-oc6> NAME 'policyConditionAuxClass'
            DESC 'A class representing a condition to be evaluated in
                  conjunction with a policy rule.'
            SUP top
            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.
 
     ( <oid-oc7> 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
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 28]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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.
 
     ( <oid-at19>
            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".'
            SYNTAX PrintableString
            EQUALITY caseIgnoreMatch
            SINGLE-VALUE
     )
 
     ( <oid-at20>
            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.'
            SYNTAX Bit String
            EQUALITY bitStringMatch
            SINGLE-VALUE
     )
 
     ( <oid-at21>
            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.'
            SYNTAX Bit String
            EQUALITY bitStringMatch
            SINGLE-VALUE
     )
 
     ( <oid-at22>
            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.'
            SYNTAX Bit String
            EQUALITY bitStringMatch
            SINGLE-VALUE
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 29]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
     )
 
     ( <oid-at23>
            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.'
            SYNTAX PrintableString
            EQUALITY caseIgnoreMatch
     )
 
     ( <oid-at24>
            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).'
            SYNTAX INTEGER
            EQUALITY integerMatch
            SINGLE-VALUE
     )
 
 
 5.8. The Auxiliary Class vendorPolicyConditionAuxClass
 
   The class definition is as follows:
 
     ( <oid-oc8> 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:
 
     ( <oid-at25>
            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.'
            SYNTAX OctetString
            EQUALITY octetStringMatch
     )
 
     ( <oid-at26>
            NAME 'vendorPolicyConstraintEncoding'
            DESC 'An OID identifying the format and semantics for this
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 30]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
                  instance"s vendorPolicyConstraintData attribute.'
            SYNTAX OID
            EQUALITY objectIdentifierMatch
            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.
 
   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:
 
     ( <oid-oc9> 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:
 
     ( <oid-oc10> 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:
 
     ( <oid-at28>
            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.'
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 31]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
            SYNTAX OctetString
            EQUALITY octetStringMatch
     )
 
     ( <oid-at29>
            NAME 'vendorPolicyActionEncoding'
            DESC 'An OID identifying the format and semantics for this
                  instance"s vendorPolicyActionData attribute.'
            SYNTAX OID
            EQUALITY objectIdentifierMatch
            SINGLE-VALUE
     )
 
 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:
 
     ( <oid-oc18> 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.
 
     ( <oid-oc18>
            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.
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 32]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
     ( <oid-nf22> NAME 'policyInstanceNameForm1'
            OC policyInstance
            MUST ( cn )
     )
 
     ( <sr22 NAME 'policyInstanceStructuralRule1'
            FORM policyConditionInstanceNameForm1
            SUP <sr13> <sr14> <sr21>
     )
 
     ( <oid-nf23> NAME 'policyInstanceNameForm2'
            OC policyInstance
            MUST ( policyInstanceName )
     )
 
     ( <sr23> NAME 'policyInstanceStructuralRule2'
            FORM policyInstanceNameForm2
            SUP <sr13> <sr14> <sr21>
     )
 
     ( <oid-nf24> NAME 'policyInstanceNameForm3'
            OC policyInstance
            MUST ( orderedCimKeys )
     )
 
     ( <sr24> NAME 'policyInstanceStructuralRule3'
            FORM policyInstanceNameForm3
            SUP <sr13> <sr14> <sr21>
     )
 
   The one attribute of policyInstance is defined as:
 
     ( <oid-at39> NAME 'policyInstanceName'
            DESC 'The user-friendly name of this policy instance.'
            SYNTAX IA5String
            EQUALITY caseExactIA5Match
            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.
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 33]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   The class definition is as follows:
 
     ( <oid-oc11> NAME 'policyConditionInstance'
            DESC 'A structural class that contains a reusable policy
                  condition.'
            SUP policyInstance
            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.
 
     ( <oid-oc11>
            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.
 
     ( <oid-nf9> NAME 'policyConditionInstanceNameForm1'
            OC policyConditionInstance
            MUST ( cn )
     )
 
     ( <sr9> NAME 'policyConditionInstanceStructuralRule1'
            FORM policyConditionInstanceNameForm1
            SUP <sr13> <sr14> <sr21>
     )
 
     ( <oid-nf10> NAME 'policyConditionInstanceNameForm2'
            OC policyConditionInstance
            MUST ( policyConditionName )
     )
 
     ( <sr10> NAME 'policyConditionInstanceStructuralRule2'
            FORM policyConditionInstanceNameForm2
            SUP <sr13> <sr14> <sr21>
     )
 
     ( <oid-nf19> NAME 'policyConditionInstanceNameForm3'
            OC policyConditionInstance
            MUST ( orderedCimKeys )
     )
 
     ( <sr19> NAME 'policyConditionInstanceStructuralRule3'
            FORM policyConditionInstanceNameForm3
            SUP <sr13> <sr14> <sr21>
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 34]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
     )
 
     ( <oid-nf25> NAME 'policyConditionInstanceNameForm4'
            OC policyConditionInstance
            MUST ( policyInstanceName )
     )
 
     ( <sr25> NAME 'policyConditionInstanceStructuralRule4'
            FORM policyConditionInstanceNameForm4
            SUP <sr13> <sr14> <sr21>
     )
 
 
 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:
 
     ( <oid-oc12> 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.
 
     ( <oid-oc12>
            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.
 
     ( <oid-nf11> NAME 'policyActionInstanceNameForm1'
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 35]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
            OC policyActionInstance
            MUST ( cn )
     )
 
     ( <sr11> NAME 'policyActionInstanceStructuralRule1'
            FORM policyActionInstanceNameForm1
            SUP <sr13> <sr14> <sr21>
     )
 
     ( <oid-nf12> NAME 'policyActionInstanceNameForm2'
            OC policyActionInstance
            MUST ( policyActionName )
     )
 
     ( <sr12> NAME 'policyActionInstanceStructuralRule2'
            FORM policyActionInstanceNameForm2
            SUP <sr13> <sr14> <sr21>
     )
 
     ( <oid-nf20> NAME 'policyActionInstanceNameForm3'
            OC policyActionInstance
            MUST ( orderedCimKeys )
     )
 
     ( <sr20> NAME 'policyActionInstanceStructuralRule3'
            FORM policyActionInstanceNameForm3
            SUP <sr13> <sr14> <sr21>
     )
 
     ( <oid-nf26> NAME 'policyActionInstanceNameForm4'
            OC policyActionInstance
            MUST ( policyInstanceName )
     )
 
     ( <sr26> NAME 'policyActionInstanceStructuralRule4'
            FORM policyActionInstanceNameForm4
            SUP <sr13> <sr14> <sr21>
     )
 
 
 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
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 36]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
     accommodate these implementations, policy-related entries SHOULD be
     tagged with the keyword "POLICY".)
 
   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:
 
     ( <oid-oc13> 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 Class policyRepository
 
   This class provides a container for reusable policy information, such
   as reusable policy conditions and/or reusable policy actions.  It is
   derived from several classes defined in reference [11]:
 
   top
      |
      +--cim23ManagedElement (abstract)
          |
          +--cim23ManagedSystemElement (abstract)
             |
              +--cim23LogicalElement (abstract)
                  |
                  +--cim23System (abstract)
                      |
                      +--cim23AdminDomain (abstract)
                          |
                          +--policyRepository (structural)
 
 
   The class definition is as follows:
 
     ( <oid-oc17> NAME 'policyRepository'
            DESC 'A container for reusable information.'
            SUP cim23AdminDomain
            MUST ( policyRepositoryName )
     )
 
   The following DIT structure rules indicate that an instance of
   policyRepository may be named under any superior, using any of its
   three naming attributes.  These DIT structure rules cover, as a
   special case, a policyRepository that is named within the scope of
 
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 37]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   another policyRepository.  This special case is the mapping for the
   CIM aggregation PolicyRepositoryInPolicyRepository.
 
     ( <oid-nf13> NAME 'policyRepositoryNameForm1'
            OC policyRepository
            MUST ( cn )
     )
 
     ( <sr13> NAME 'policyRepositoryStructuralRule1'
            FORM policyRepositoryNameForm1
     )
 
     ( <oid-nf14> NAME 'policyRepositoryNameForm2'
            OC policyRepository
            MUST ( policyRepositoryName )
     )
 
     ( <sr14> NAME 'policyRepositoryStructuralRule2'
            FORM policyRepositoryNameForm2
     )
 
     ( <oid-nf21> NAME 'policyRepositoryNameForm3'
            OC policyRepository
            MUST ( orderedCimKeys )
     )
 
 
     ( <sr21> NAME 'policyRepositoryStructuralRule3'
            FORM policyRepositoryNameForm3
     )
 
   The one attribute of policyRepository is defined as follows.
 
     ( <oid-at35> NAME 'policyRepositoryName'
            DESC 'The user-friendly name of this policy repository.'
            SYNTAX IA5String
            EQUALITY caseExactIA5Match
            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
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 38]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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
   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:
 
     ( <oid-oc14> 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:
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 39]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
     ( <oid-at30>
            NAME 'policySubtreesAuxContainedSet'
            DESC 'Distinguished names of objects that serve as roots for
                  DIT subtrees containing policy-related objects. No
                  order is implied.'
            SYNTAX DN
            EQUALITY distinguishedNameMatch
     )
 
 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
   makes it possible for the policy administrator to define all these
   pointers.
 
   The class definition is as follows:
 
     ( <oid-oc15> 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:
 
     ( <oid-at31>
            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.'
            SYNTAX DN
            EQUALITY distinguishedNameMatch
     )
 
 
 
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 40]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
 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.
 
   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:
 
     ( <oid-oc16> 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:
 
     ( <oid-at32>
            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.'
            SYNTAX DN
            EQUALITY distinguishedNameMatch
     )
 
 
 
 
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 41]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
 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
   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
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 42]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   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
 
   o   General:  See reference [1].
 
   o   Users:  See reference [1].
 
   o   Administrators of Schema:  In general, most LDAP-accessible
       directories do not permit old or out-of-date schemas, or schema
       elements to be deleted.  Instead, they are rendered inactive.
       This makes it that much more important to get it right the first
       time on an operational system, in order to avoid complex inactive
       schema artifacts from lying about in the operational directory.
       The good news is that it is expected that large network operators
       will change schema design infrequently, and, when they do, the
       schema creation changes will be tested on an off-line copy of the
       directory before the operational directory is updated.
       Typically, a small group of directory schema administrators will
       be authorized to make these changes in a service provider or
       enterprise environment.  The ability to maintain audit trails is
       also required here.
 
   o   Administrators of Schema Content (Directory Entries): This group
       requires authorization to load values (entries) into a policy
       repository  directory schema, i.e. read/write access.  An audit
       trail capability is also required here.
 
   o   Applications and PDPs:  These entities must be authorized for
       read-only access to the policy repository directory, so that they
       may acquire policy for the purposes of passing it to their
       respective enforcement entities.
 
   o   Security Disciplines:
 
      o  Audit Trail (Non-repudiation):  In general, standardizing
         mechanisms for non-repudiation is outside the scope of the
         IETF; however, we can certainly document the need for this
         function in systems that maintain and distribute policy.  The
         dependency for support of this function is on the implementers
         of these systems, and not on any specific standards for
         implementation.  The requirement for a policy system is that a
         minimum level of auditing via an auditing facility must be
         provided.  Logging should be enabled.  This working group will
         not specify what this minimal auditing function consists of.
 
      o  Access Control/Authorization:  Access Control List (ACL)
         functionality must be provided.  Standards for directories that
         use LDAPv3 as an access mechanism are still being worked on in
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 43]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
         the LDAPext working group, as of this writing.  The two
         administrative sets of users documented above will form the
         basis for two administrative use cases that require support.
 
      o  Authentication:  In the LDAP-accessible directory case, both
         TLS and Kerberos are acceptable for authentication.  Existing
         LDAP implementations provide these functions within the context
         of the BIND request, which is adequate.  We advise against
         using weaker mechanisms, such as clear text and HTTP Digest.
         Mutual authentication is recommended.  The LDAPv3 protocol
         supports this, but implementations vary in the functionality
         that they support.
 
      o  Integrity/Privacy:  In the LDAP-accessible directory case, TLS
         is acceptable for encryption and data integrity on the wire.
         If physical or virtual access to the policy repository is in
         question, it may also be necessary to encrypt the policy data
         as it is stored on the file system; however, specification of
         mechanisms for this purpose are outside the scope of this
         working group.  In any case, we recommend that the physical
         server be located in a physically secure environment.
 
       In the case of PDP-to-PEP communications, the use of IPSEC is
       recommended for providing confidentiality, data origin
       authentication, integrity and replay prevention.  See reference
       [9].
 
   o   Denial of Service:  We recommend the use of multiple policy
       repository directories, such that a denial of service attack on
       any one directory server  will not make all policy data
       inaccessible to legitimate users.  However, this still leaves a
       denial of service attack exposure.  Our belief is that the use of
       a policy schema, in a centrally administered but physically
       distributed policy directory, does not increase the risk of
       denial of service attacks; however, such attacks are still
       possible.  If executed successfully, such an attack could prevent
       PDPs from accessing a policy repository, and thus prevent them
       from acquiring new policy.  In such a case, the PDPs, and
       associated PEPs would continue operating under the policies in
       force before the denial of service attack was launched.  Note
       that exposure of policy systems to denial of service attacks is
       not any greater than the exposure of DNS with DNSSEC in place.
 
   o   Other LDAP-accessible Directory Schema Considerations:
 
      o  Replication:  Replication among directory copies across servers
         should also be protected.  Replicating over connections secured
         by SSL or IPSEC is recommended.
 
 
 
 
 
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 44]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
 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
   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", draft-ietf-
      policy-core-info-model-07.txt, July 2000.
 
 [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.
 
 
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 45]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
 [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]  Moats, R., and J. Maziarski, J. Strassner, "Extensible Match Rule
      to Dereference Pointers", draft-moats-ldap-dereference-match-02.txt
      December 1999.
 
 [9]  Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for
      Policy-based Admission Control", RFC 2753, January 2000.
 
 [10] 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.
 
 [11] Distributed Management Task Force, Inc., "LDAP CIM Core Schema v2.3
      Mapping", May 8, 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, Bldg 15
      170 West Tasman Drive
      San Jose, CA 95134
      Phone:   +1 408-527-1069
      Fax:     +1 408-527-1722
      E-mail:  johns@cisco.com
 
   Ed Ellesson
      Tivoli Systems
      Building 10, Office R2D39
      3901 Miami Blvd.
      Durham, NC 27703
      Phone:   +1 919-224-2111
      Fax:     +1 919-224-2540
      E-mail:  ed_ellesson@tivoli.com
 
   Bob Moore
      IBM Corporation, BRQA/502
      4205 S. Miami Blvd.
      Research Triangle Park, NC 27709
      Phone:   +1 919-254-4436
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 46]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
      Fax:     +1 919-254-6243
      E-mail:  remoore@us.ibm.com
 
   Ryan Moats
      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 (2000).  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.
 
 
 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.
 
 
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 47]


 Internet Draft    draft-ietf-policy-core-schema-07.txt        July 2000
 
 
   In its mapping from the CIM_ManagedElement class to the LDAP class
   cim23ManagedElement, reference [11] 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
 
          <className>.<key>=<value>[,<key>=<value>]*
 
   where the <key>=<value> elements are ordered by the names of the key
   properties, according to the collating sequence for US ASCII.  The
   only spaces allowed in the DirectoryString are those that fall within
   a <value> element.  As with alphabetizing the key properties, the goal
   of suppressing the spaces is once again to make the results of string
   operations predictable.
 
   The values of the <value> elements are derived from the various CIM
   syntaxes according to a grammar specified in reference [10].
 
   NOTE:  This section diverges from the current versions of references
   [10] and [11].  Currently these documents define two separate
   attributes, one for the case where an instance is identified with both
   native and propagated keys, and the other for the case where it is
   identified only with native keys.  Implementation experience has shown
   that it is simpler to use a single attribute (orderedCimKeys) for both
   of these cases, so that is what's represented here.  In their next
   revision, it is expected that references [10] and [11] will be changed
   to match the description here, based on interactions with and among
   the team responsible for updating these documents.
 
 
 
 
 
 
 Strassner, et al.      Expires:  January 14, 2001             [Page 48]