RE: Approved: draft-ietf-policy-core-schema-16.txt
"Wijnen, Bert (Bert)" <[email protected]> Mon, 5 May 2003 19:59:45 +0200
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <7D5D48D2CAA3D84C813F5B154F43B155017C18B5@nl0006exch001u.nl.lucent.com> |
RFC-Editor (and policy FW WG) As far as my current understanding of the issues, it is NOT acceptable to remove this normative reference. I am working in the IESG to try and get that normative document approved. But there are still serious issues with it, so things are not going smooth/fast. Thanks, Bert > -----Original Message----- > From: RFC Editor [mailto:[email protected]] > Sent: maandag 5 mei 2003 19:35 > To: Bert Wijnen; Randy Bush > Cc: [email protected]; Joel M. Halpern; Ed Ellesson; RFC Editor; > [email protected] > Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt > > > 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] >