Re: Approved: draft-ietf-policy-core-schema-16.txt
RFC Editor <[email protected]> Mon, 5 May 2003 10:34:36 -0700
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
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 protected] | 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 protected]] > >>>Sent: donderdag 14 november 2002 13:15 > >>>To: Wijnen, Bert (Bert) > >>>Cc: [email protected] > >>>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 protected] > >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 protected]) > 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 protected]) > 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 protected] > > 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 protected] > > Ryan Moats > Lemur Networks, Inc. > 15621 Drexel Circle > Omaha, NE 68135 > Phone: +1-402-894-9456 > E-mail: [email protected] > > Ed Ellesson > 3026 Carriage Trail > Hillsborough, NC 27278 > Phone: +1 919-644-3977 > E-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > 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]