Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt

From: RFC Editor <[email-masked]>
Date: Mon, 5 May 2003 10:34:36 -0700

Bert and Randy,

Could you please let us know if removal of the normative reference is
an acceptable resolution to unblocking
<draft-ietf-policy-core-schema-16.txt>? 

Thanks,

RFC Editor

On Mon, Apr 21, 2003 at 09:38:43AM -0500, Larry S. Bartz wrote:
> Larry S. Bartz wrote, On 04/10/03 07:26:
> >It has been more than five months since we were advised that the
> >PCLS was approved by the IESG. Why hasn't the RFC been published?
> >
> 
> 
> PROBLEM:
> 
> When I looked at the RFC Editor's queue a few weeks ago, I didn't
> see a definition of the "REF" status which had been assigned to
> draft-ietf-policy-core-schema-16.txt. Now the reason for the lack
> of further action on PCLS is clear. PCLS is stuck. It is waiting
> for an event which will apparently never happen. Without some
> overt remedial action, PCLS cannot become an RFC.
> 
> The draft-ietf-policy-core-schema-16.txt cites another draft,
> draft-zeilenga-ldap-user-schema-06.txt, as a normative reference.
> The RFC Editor's assignment of the "REF" status to PCLS acknowledges
> this dependency, as "holding for normative reference".
> 
> The problem lies in the fact that draft-zeilenga-ldap-user-schema-
> 06.txt expired in November 2002. It has not been superseded by an
> "07" version. This leaves PCLS dependent upon a document which is
> obviously not a work in progress. PCLS cannot move forward under
> this condition.
> 
> 
> REMEDY:
> 
> This situation can be remedied by a minor edit of the PCLS draft.
> Simply removing the reference to the expired draft will free PCLS
> of its dependency. This should allow PCLS to proceed to the
> intermediate step of OID assignment by IANA, then on to publication
> as an RFC.
> 
> On close inspection of draft-ietf-policy-core-schema-16.txt, it
> appears that the dependency on the now-expired draft-zeilenga-ldap-
> user-schema-06.txt is not necessary. PCLS cites the expired draft
> as one of three normative references for the definitions of matching
> rules. The other mormative references cited by PCLS for matching
> rules include RFC3377 (which, in turn, defers to RFC2252), and
> X.520. Together, RFC3377 (and its normative references) and X.520
> define all of the matching rules which are employed by PCLS.
> 
> Relieving  draft-ietf-policy-core-schema-16.txt of its unecessary
> dependency upon draft-zeilenga-ldap-user-schema-06.txt requires
> the following edits:
> 
> 
> ###### under "5. Class Definitions", page 18, third paragraph:
> 
> #### FROM THIS:
> 
> Note 4: in the following definitions, note that all LDAP matching rules
> are defined in [3] and in [9]. The corresponding X.500 matching rules
> are defined in [8].
> 
> #### TO THIS:
> 
> Note 4: in the following definitions, note that all matching rules
> are defined in [3] and in [8].
> 
> 
> ###### under "11. Normative References", page 52
> 
> #### elide this:
> 
> [9] K. Zeilenga, ed., "LDAPv3: A Collection of User Schema",
>      <draft-zeilenga-ldap-user-schema-06.txt>, May 2002.
> 
> 
> ###### under "12. Informative References", page 53
> 
> #### renumber references 10 through 16 as 9 through 15
> #### repair citations of these references throughout document
>  as necessary to accomodate renumbering
> 
> 
> I have attached an edited version of draft-ietf-policy-core-schema-
> 16.txt to this messge. This document differs from the original only
> in the changes I described above. I have named it draft-ietf-policy-
> core-schema-16a.txt
> 
> 
> HOW-TO?
> 
> Can the RFC Editor effect these changes to the current WG-approved and
> IESG-approved draft and send it on its way? Or must the draft come back
> to the WG for edit? If so, must it then go all the way back through WG
> Last Call and IESG review and approval?
> 
> -- 
> --
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> # Larry Bartz                           |                              |
> #  [email-masked]      | Ooo, ooo,                    |
> #                                       | Ooo, ooo, oooooo!            |
> #                                       | I've got a gnu attitude!     |
> #  voice (317) 226-7060                 |                              |
> #  FAX   (317) 226-6378                 |                              |
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> 
> 
> 
> 
> >
> >
> >
> >Wijnen, Bert (Bert) wrote, On 11/14/02 08:25:
> >
> >>It is impossible to say when the RFC will be published. You can
> >>track the progress at:
> >>  http://www.rfc-editor.org/queue.html
> >>
> >>Experience tells us that it takes from one to a couple of months.
> >>
> >>Hope this helps
> >>Bert
> >>
> >>>-----Original Message-----
> >>>From: Larry S. Bartz [mailto:[email-masked]]
> >>>Sent: donderdag 14 november 2002 13:15
> >>>To: Wijnen, Bert (Bert)
> >>>Cc: [email-masked]
> >>>Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt
> >>>
> >>>
> >>>Wijnen, Bert (Bert) wrote, On 10/31/2002 12:52 PM:
> >>>
> >>>>The IESG just approved this document.
> >>>>Formal announcement to be posted by IESG secretary
> >>>>in a few days.
> >>>
> >>>
> >>>My ecstasy over this event has cooled somewhat. But I am
> >>>fully prepared to be thrilled again. When will the RFC
> >>>be published?
> >>>
> >>>
> >
> >_______________________________________________
> >Policy mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/policy
> 
> 

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

_______________________________________________
Policy mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/policy