From mailnull@www1.ietf.org Mon May 5 14:41:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10895 for ; Mon, 5 May 2003 14:41:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45InvA25208 for policy-archive@odin.ietf.org; Mon, 5 May 2003 14:49:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Ijv825001; Mon, 5 May 2003 14:45:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Ido824796 for ; Mon, 5 May 2003 14:39:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10567 for ; Mon, 5 May 2003 14:30:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ckls-0007YT-00 for policy@ietf.org; Mon, 05 May 2003 14:33:04 -0400 Received: from mx-relay21.treas.gov ([199.196.132.5]) by ietf-mx with esmtp (Exim 4.12) id 19Cklm-0007Xk-00 for policy@ietf.org; Mon, 05 May 2003 14:32:59 -0400 Received: from TIAS24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.9/8.12.9) with SMTP id h45IJSLs022982; Mon, 5 May 2003 14:19:28 -0400 (EDT) Received: from no.name.available by TIAS24.net.treas.gov via smtpd (for [199.196.132.5]) with SMTP; 5 May 2003 18:33:00 UT Received: from irsbd2.net.treas.gov (localhost [127.0.0.1]) by mailhub-22.net.treas.gov (8.12.9/8.12.9) with ESMTP id h45IWrQw022673; Mon, 5 May 2003 14:32:53 -0400 (EDT) Received: from no.name.available by irsbd2.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.13.252.12]) with ESMTP; Mon, 5 May 2003 14:32:53 -0400 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h45IWqb15794; Mon, 5 May 2003 13:32:52 -0500 Message-ID: <3EB6AE54.6090009@parnelli.indy.cr.irs.gov> Date: Mon, 05 May 2003 13:32:52 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: RFC Editor , Randy Bush , policy@ietf.org, "Joel M. Halpern" , Ed Ellesson Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt References: <7D5D48D2CAA3D84C813F5B154F43B155017C18B5@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155017C18B5@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I raised the following points last week, but didn't get a rise out of anybody... draft-ietf-policy-core-schema-16 uses three matching rules which haven't been explicitly defined as standard LDAP matching rules. They are booleanMatch, integerOrderingMatch, and octetStringOrderingMatch. These matching rules are the subject of draft-ietf-policy-core-schema- 16's dependence upon draft-zeilenga-ldap-user-schema. What does "adapted for use in LDAP" mean for those matching rules? According to draft-zeilenga-ldap-user-schema, the "adaptation" is little more than a restatement of the X.520 definitions. Obviously, X.520 provides the consensus-supported definitions for booleanMatch, integerOrderingMatch, and octetStringOrderingMatch. Some LDAP-conformant server implementations already support booleanMatch, integerOrderingMatch, and octetStringOrderingMatch in conformance with their X.520 definitions. Does it matter that these X.520-defined matching rules are not yet defined in an LDAP-specific RFC? The server doesn't care. The schema doesn't care. The applications which use the server and the schema don't care, either. Rough consensus and working code, right? How could consensus get any better for these three matching rules than it already is? I realize that Kurt, the ldapbis WG, and the IETF are working very hard to make LDAP more concise, precise, and complete. This is Good Work. But in the case of draft-ietf-policy-core-schema-16 and these three matching rules, if the subject of the normative reference at issue here isn't immediately forthcoming, there really isn't a good reason for draft-ietf-policy- core-schema-16 to wait any longer. If draft-zeilenga-ldap-user-schema still has serious issues, why not defer to pragmatism, drop the reference, and move on? Larry Wijnen, Bert (Bert) wrote, On 05/05/03 12:59: > 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:rfc-editor@rfc-editor.org] >>Sent: maandag 5 mei 2003 19:35 >>To: Bert Wijnen; Randy Bush >>Cc: policy@ietf.org; Joel M. Halpern; Ed Ellesson; RFC Editor; >>lbartz@parnelli.indy.cr.irs.gov >>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 >>? >> >>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? >>>> >>> -- -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Mon May 5 15:55:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14047 for ; Mon, 5 May 2003 15:55:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45K3Q230046 for policy-archive@odin.ietf.org; Mon, 5 May 2003 16:03:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Jw0829826; Mon, 5 May 2003 15:58:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Hff820251 for ; Mon, 5 May 2003 13:41:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08889 for ; Mon, 5 May 2003 13:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cjrr-0007GY-00 for policy@ietf.org; Mon, 05 May 2003 13:35:11 -0400 Received: from tnt.isi.edu ([128.9.128.128]) by ietf-mx with esmtp (Exim 4.12) id 19Cjri-0007GD-00 for policy@ietf.org; Mon, 05 May 2003 13:35:02 -0400 Received: from jet.isi.edu (jet.isi.edu [128.9.160.87]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h45HYbT01821; Mon, 5 May 2003 10:34:37 -0700 (PDT) Received: (from rfc-ed@localhost) by jet.isi.edu (8.9.3/8.8.6) id KAA04022; Mon, 5 May 2003 10:34:37 -0700 (PDT) Date: Mon, 5 May 2003 10:34:36 -0700 From: RFC Editor To: Bert Wijnen , Randy Bush Cc: policy@ietf.org, "Joel M. Halpern" , Ed Ellesson , RFC Editor , lbartz@parnelli.indy.cr.irs.gov Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt Message-ID: <20030505173435.GN3731@isi.edu> References: <3E9562F5.5090208@parnelli.indy.cr.irs.gov> <3EA40273.1090009@parnelli.indy.cr.irs.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA40273.1090009@parnelli.indy.cr.irs.gov> User-Agent: Mutt/1.4i Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Bert and Randy, Could you please let us know if removal of the normative reference is an acceptable resolution to unblocking ? 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", > , 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 | | > # lbartz@parnelli.indy.cr.irs.gov | 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:lbartz@parnelli.indy.cr.irs.gov] > >>>Sent: donderdag 14 november 2002 13:15 > >>>To: Wijnen, Bert (Bert) > >>>Cc: policy@ietf.org > >>>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 > >Policy@ietf.org > >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: > [&&]* > 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 "[&&]*" (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 (remoore@us.ibm.com) > 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 (remoore@us.ibm.com) > 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: john.strassner@intelliden.com > > 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: remoore@us.ibm.com > > Ryan Moats > Lemur Networks, Inc. > 15621 Drexel Circle > Omaha, NE 68135 > Phone: +1-402-894-9456 > E-mail: rmoats@lemurnetworks.net > > Ed Ellesson > 3026 Carriage Trail > Hillsborough, NC 27278 > Phone: +1 919-644-3977 > E-mail: ellesson@mindspring.com > > > > > > > > > > > > > > > > > > > > > > > > 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 > > .=[,=]* > > where the = 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 > 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 elements are derived from the various CIM > syntaxes according to a grammar specified in [5]. > > > Strassner, et al. Expires: April 2003 [Page 57] _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Mon May 5 15:59:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14086 for ; Mon, 5 May 2003 15:59:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45K7PX30713 for policy-archive@odin.ietf.org; Mon, 5 May 2003 16:07:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45K1x829991; Mon, 5 May 2003 16:01:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45I6d821656 for ; Mon, 5 May 2003 14:06:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09597 for ; Mon, 5 May 2003 13:58:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CkG1-0007OX-00 for policy@ietf.org; Mon, 05 May 2003 14:00:09 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19CkFs-0007OH-00 for policy@ietf.org; Mon, 05 May 2003 14:00:00 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h45Hxmx27775 for ; Mon, 5 May 2003 13:59:48 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R1987MB>; Mon, 5 May 2003 19:59:47 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C18B5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: RFC Editor , Bert Wijnen , Randy Bush Cc: policy@ietf.org, "Joel M. Halpern" , Ed Ellesson , lbartz@parnelli.indy.cr.irs.gov Subject: RE: [Policy] Approved: draft-ietf-policy-core-schema-16.txt Date: Mon, 5 May 2003 19:59:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , 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:rfc-editor@rfc-editor.org] > Sent: maandag 5 mei 2003 19:35 > To: Bert Wijnen; Randy Bush > Cc: policy@ietf.org; Joel M. Halpern; Ed Ellesson; RFC Editor; > lbartz@parnelli.indy.cr.irs.gov > 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 > ? > > 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", > > , 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 | > | > > # lbartz@parnelli.indy.cr.irs.gov | 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:lbartz@parnelli.indy.cr.irs.gov] > > >>>Sent: donderdag 14 november 2002 13:15 > > >>>To: Wijnen, Bert (Bert) > > >>>Cc: policy@ietf.org > > >>>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 > > >Policy@ietf.org > > >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: > > [&&]* > > 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 "[&&]*" (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 (remoore@us.ibm.com) > > 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 (remoore@us.ibm.com) > > 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: john.strassner@intelliden.com > > > > 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: remoore@us.ibm.com > > > > Ryan Moats > > Lemur Networks, Inc. > > 15621 Drexel Circle > > Omaha, NE 68135 > > Phone: +1-402-894-9456 > > E-mail: rmoats@lemurnetworks.net > > > > Ed Ellesson > > 3026 Carriage Trail > > Hillsborough, NC 27278 > > Phone: +1 919-644-3977 > > E-mail: ellesson@mindspring.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > .=[,=]* > > > > where the = 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 > > 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 elements are derived from the various CIM > > syntaxes according to a grammar specified in [5]. > > > > > > Strassner, et al. Expires: April 2003 > [Page 57] > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue May 6 11:48:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26756 for ; Tue, 6 May 2003 11:48:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46Fugs02270 for policy-archive@odin.ietf.org; Tue, 6 May 2003 11:56:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Fqi802058; Tue, 6 May 2003 11:52:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46FmQ801885 for ; Tue, 6 May 2003 11:48:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26546 for ; Tue, 6 May 2003 11:39:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D4ZN-00002F-00 for policy@ietf.org; Tue, 06 May 2003 11:41:29 -0400 Received: from [66.46.208.99] (helo=srvotgfi.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 19D4ZM-00002C-00 for policy@ietf.org; Tue, 06 May 2003 11:41:28 -0400 Received: from SRVOTEMAIL.metasolv.com ([10.13.1.25]) by srvotgfi.metasolv.com with Microsoft SMTPSVC(5.0.2172.1); Tue, 6 May 2003 11:44:57 -0400 Received: by SRVOTEMAIL.metasolv.com with Internet Mail Service (5.5.2653.19) id <20V969HN>; Tue, 6 May 2003 11:36:15 -0400 Message-ID: From: "Pana, Mircea" To: "'Larry S. Bartz'" Cc: policy@ietf.org Subject: RE: [Policy] Approved: draft-ietf-policy-core-schema-16.txt Date: Tue, 6 May 2003 11:36:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-OriginalArrivalTime: 06 May 2003 15:44:57.0282 (UTC) FILETIME=[7204AA20:01C313E6] Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Larry, I don't have a strong opinion about the booleanMatch and wrt. the octetStringOrderingMatch I don't even see where it might be necessary. However, the integerOrderingMatch might be critical to some policy aplications. Therefore, as much as I'd like to see this ID progress to RFC, I believe that the removal of the normative reference is detrimental to this document. I know that some Directory vendors already implement these matching rules. The problem is that, without a normative document, each vendor might implement different behavior for the same rule... Mircea. -----Original Message----- From: Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] Sent: Monday, May 05, 2003 2:33 PM To: Wijnen, Bert (Bert) Cc: RFC Editor; Randy Bush; policy@ietf.org; Joel M. Halpern; Ed Ellesson Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt I raised the following points last week, but didn't get a rise out of anybody... draft-ietf-policy-core-schema-16 uses three matching rules which haven't been explicitly defined as standard LDAP matching rules. They are booleanMatch, integerOrderingMatch, and octetStringOrderingMatch. These matching rules are the subject of draft-ietf-policy-core-schema- 16's dependence upon draft-zeilenga-ldap-user-schema. What does "adapted for use in LDAP" mean for those matching rules? According to draft-zeilenga-ldap-user-schema, the "adaptation" is little more than a restatement of the X.520 definitions. Obviously, X.520 provides the consensus-supported definitions for booleanMatch, integerOrderingMatch, and octetStringOrderingMatch. Some LDAP-conformant server implementations already support booleanMatch, integerOrderingMatch, and octetStringOrderingMatch in conformance with their X.520 definitions. Does it matter that these X.520-defined matching rules are not yet defined in an LDAP-specific RFC? The server doesn't care. The schema doesn't care. The applications which use the server and the schema don't care, either. Rough consensus and working code, right? How could consensus get any better for these three matching rules than it already is? I realize that Kurt, the ldapbis WG, and the IETF are working very hard to make LDAP more concise, precise, and complete. This is Good Work. But in the case of draft-ietf-policy-core-schema-16 and these three matching rules, if the subject of the normative reference at issue here isn't immediately forthcoming, there really isn't a good reason for draft-ietf-policy- core-schema-16 to wait any longer. If draft-zeilenga-ldap-user-schema still has serious issues, why not defer to pragmatism, drop the reference, and move on? Larry Wijnen, Bert (Bert) wrote, On 05/05/03 12:59: > 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:rfc-editor@rfc-editor.org] >>Sent: maandag 5 mei 2003 19:35 >>To: Bert Wijnen; Randy Bush >>Cc: policy@ietf.org; Joel M. Halpern; Ed Ellesson; RFC Editor; >>lbartz@parnelli.indy.cr.irs.gov >>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 >>? >> >>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? >>>> >>> -- -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue May 6 12:14:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27856 for ; Tue, 6 May 2003 12:14:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46GN9f05275 for policy-archive@odin.ietf.org; Tue, 6 May 2003 12:23:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46GJM804859; Tue, 6 May 2003 12:19:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46GI9804693 for ; Tue, 6 May 2003 12:18:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27500 for ; Tue, 6 May 2003 12:09:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D527-0000F5-00 for policy@ietf.org; Tue, 06 May 2003 12:11:11 -0400 Received: from mx-relay1.treas.gov ([199.196.144.5] helo=mx-relay1.net.treas.gov) by ietf-mx with esmtp (Exim 4.12) id 19D526-0000F2-00 for policy@ietf.org; Tue, 06 May 2003 12:11:10 -0400 Received: from tias5.treas.gov (tias-gw5.treas.gov [199.196.144.15]) by mx-relay1.net.treas.gov (8.12.9/8.12.9) with SMTP id h46GBtDB005033; Tue, 6 May 2003 12:11:56 -0400 (EDT) Received: from mailhub.net.treas.gov by tias5.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 6 May 2003 16:11:55 UT Received: from irsbd1.net.treas.gov (localhost [127.0.0.1]) by mailhub-5.net.treas.gov (8.12.9/8.12.9) with ESMTP id h46GBnQ2004108; Tue, 6 May 2003 12:11:49 -0400 (EDT) X-Authentication-Warning: mailhub-5.net.treas.gov: iscan owned process doing -bs Received: from no.name.available by irsbd1.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.7.14.15]) with ESMTP; Tue, 6 May 2003 12:11:49 -0400 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h46GBmb17517; Tue, 6 May 2003 11:11:48 -0500 Message-ID: <3EB7DEC4.3000600@parnelli.indy.cr.irs.gov> Date: Tue, 06 May 2003 11:11:48 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pana, Mircea" CC: policy@ietf.org, RFC Editor , Randy Bush , "Wijnen, Bert (Bert)" , "Joel M. Halpern" , Ed Ellesson Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mircea, all, Reference to X.520 (for which there is already a normative reference in the draft) is the *only* normative reference which is necessary to cover the three matching rules. X.520 defines booleanMatch, octetStringOrderingMatch, and integerOrderingMatch. Where draft-zeilenga-ldap-user-schema speaks of these three matching rules, it does little more than re-state X.520. There is no doubt about consensus regarding the origins and semantics of booleanMatch, octetStringOrderingMatch, and integerOrderingMatch. To remove the normative reference to draft-zeilenga-ldap-user-schema is simply to remove a redundancy. Removing the normative reference to draft-zeilenga-ldap-user-schema does not leave draft-ietf-policy-core -schema-16 without a normative reference for the three matching rules. Larry Pana, Mircea wrote, On 05/06/03 10:36: > Larry, > > I don't have a strong opinion about the booleanMatch and wrt. the > octetStringOrderingMatch I don't even see where it might be necessary. > However, the integerOrderingMatch might be critical to some policy > aplications. Therefore, as much as I'd like to see this ID progress to RFC, > I believe that the removal of the normative reference is detrimental to this > document. > > I know that some Directory vendors already implement these matching rules. > The problem is that, without a normative document, each vendor might > implement different behavior for the same rule... > > Mircea. > > > -----Original Message----- > From: Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] > Sent: Monday, May 05, 2003 2:33 PM > To: Wijnen, Bert (Bert) > Cc: RFC Editor; Randy Bush; policy@ietf.org; Joel M. Halpern; Ed > Ellesson > Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt > > > I raised the following points last week, but didn't get a rise > out of anybody... > > draft-ietf-policy-core-schema-16 uses three matching rules which > haven't been explicitly defined as standard LDAP matching rules. They > are booleanMatch, integerOrderingMatch, and octetStringOrderingMatch. > These matching rules are the subject of draft-ietf-policy-core-schema- > 16's dependence upon draft-zeilenga-ldap-user-schema. > > What does "adapted for use in LDAP" mean for those matching rules? > According to draft-zeilenga-ldap-user-schema, the "adaptation" is > little more than a restatement of the X.520 definitions. Obviously, > X.520 provides the consensus-supported definitions for booleanMatch, > integerOrderingMatch, and octetStringOrderingMatch. > > Some LDAP-conformant server implementations already support > booleanMatch, integerOrderingMatch, and octetStringOrderingMatch in > conformance with their X.520 definitions. Does it matter that these > X.520-defined matching rules are not yet defined in an LDAP-specific > RFC? The server doesn't care. The schema doesn't care. The applications > which use the server and the schema don't care, either. > > Rough consensus and working code, right? How could consensus get any > better for these three matching rules than it already is? I realize that > Kurt, the ldapbis WG, and the IETF are working very hard to make LDAP > more concise, precise, and complete. This is Good Work. But in the case > of draft-ietf-policy-core-schema-16 and these three matching rules, if > the subject of the normative reference at issue here isn't immediately > forthcoming, there really isn't a good reason for draft-ietf-policy- > core-schema-16 to wait any longer. > > If draft-zeilenga-ldap-user-schema still has serious issues, why not > defer to pragmatism, drop the reference, and move on? > > Larry > > > Wijnen, Bert (Bert) wrote, On 05/05/03 12:59: > >>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:rfc-editor@rfc-editor.org] >>>Sent: maandag 5 mei 2003 19:35 >>>To: Bert Wijnen; Randy Bush >>>Cc: policy@ietf.org; Joel M. Halpern; Ed Ellesson; RFC Editor; >>>lbartz@parnelli.indy.cr.irs.gov >>>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 >>>? >>> >>>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? >>>>> >>>> > > -- -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Wed May 7 23:54:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29002 for ; Wed, 7 May 2003 23:54:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4843uu22789 for policy-archive@odin.ietf.org; Thu, 8 May 2003 00:03:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48406822701; Thu, 8 May 2003 00:00:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47BOP805090 for ; Wed, 7 May 2003 07:24:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23746; Wed, 7 May 2003 07:14:58 -0400 (EDT) Message-Id: <200305071114.HAA23746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: policy@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 07 May 2003 07:14:58 -0400 Subject: [Policy] I-D ACTION:draft-ietf-policy-qos-info-model-05.txt Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Policy Framework Working Group of the IETF. Title : Policy QoS Information Model Author(s) : Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, B. Moore Filename : draft-ietf-policy-qos-info-model-05.txt Pages : 70 Date : 2003-5-6 This document presents an object-oriented information model for representing policies that administer, manage, and control access to network QoS resources. This document is based on the IETF Policy Core Information Model and its extensions. This defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-policy-qos-info-model-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-policy-qos-info-model-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-6153404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-policy-qos-info-model-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-policy-qos-info-model-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-6153404.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Thu May 8 14:18:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02350 for ; Thu, 8 May 2003 14:18:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48IRZR05030 for policy-archive@odin.ietf.org; Thu, 8 May 2003 14:27:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48INa804858; Thu, 8 May 2003 14:23:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48IMr804804 for ; Thu, 8 May 2003 14:22:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02244 for ; Thu, 8 May 2003 14:12:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dput-0004rN-00 for policy@ietf.org; Thu, 08 May 2003 14:14:51 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19Dput-0004rK-00 for policy@ietf.org; Thu, 08 May 2003 14:14:51 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4571157 for policy@ietf.org; Thu, 08 May 2003 14:15:45 -0400 Message-Id: <5.1.0.14.0.20030508141152.027372b8@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 08 May 2003 14:14:48 -0400 To: policy@ietf.org From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Policy] Revised Draft Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , The editor, Bob Moore, has submitted a revised draft of the Policy QoS Information Model, http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-05.txt This draft is believed to address the comments raised by the AD review, without violating the consensus of the working group on any items. If Bob has time he will write up a description of the changes, but he has already done a huge amount of work for us. Please take a look at this draft and speak quickly if you see problems. I do not anticipate having an explicit additional working group last call, but am giving you this window before asking Bert to run with this draft. Thanks again to Bob for his efforts, Joel _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Wed May 14 09:00:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16360 for ; Wed, 14 May 2003 09:00:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4ECRI910140 for policy-archive@odin.ietf.org; Wed, 14 May 2003 08:27:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ECMtB09839; Wed, 14 May 2003 08:22:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ECLSB09762 for ; Wed, 14 May 2003 08:21:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16117 for ; Wed, 14 May 2003 08:54:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fvny-0005Xv-00 for policy@ietf.org; Wed, 14 May 2003 08:56:22 -0400 Received: from [199.196.132.5] (helo=mx-relay21.treas.gov) by ietf-mx with esmtp (Exim 4.12) id 19Fvnx-0005Xs-00 for policy@ietf.org; Wed, 14 May 2003 08:56:21 -0400 Received: from TIAS24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.9/8.12.9) with SMTP id h4EChjRf018265; Wed, 14 May 2003 08:43:45 -0400 (EDT) Received: from no.name.available by TIAS24.net.treas.gov via smtpd (for [199.196.132.5]) with SMTP; 14 May 2003 12:57:23 UT Received: from irsbd3.net.treas.gov (localhost [127.0.0.1]) by mailhub-22.net.treas.gov (8.12.9/8.12.9) with ESMTP id h4ECvGNg022212; Wed, 14 May 2003 08:57:17 -0400 (EDT) Received: from no.name.available by irsbd3.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.13.252.12]) with ESMTP; Wed, 14 May 2003 08:57:17 -0400 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h4ECvFb09807; Wed, 14 May 2003 07:57:15 -0500 Message-ID: <3EC23D2B.3030804@parnelli.indy.cr.irs.gov> Date: Wed, 14 May 2003 07:57:15 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: policy@ietf.org CC: RFC Editor , Randy Bush , "Joel M. Halpern" , Ed Ellesson , "Wijnen, Bert (Bert)" Subject: PCLS when? [was: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt] References: <3EB7DEC4.3000600@parnelli.indy.cr.irs.gov> In-Reply-To: <3EB7DEC4.3000600@parnelli.indy.cr.irs.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Now it has been *six* months since the PCLS (Policy Core LDAP Schema) draft entered the RFC Editor's Queue. When will the RFC be published? I haven't seen a convincing argument for retaining PCLS's dependency upon draft-zeilenga-ldap-user-schema. Larry Larry S. Bartz wrote, On 05/06/03 11:11: > Mircea, all, > > Reference to X.520 (for which there is already a normative reference > in the draft) is the *only* normative reference which is necessary to > cover the three matching rules. > > X.520 defines booleanMatch, octetStringOrderingMatch, and > integerOrderingMatch. > > Where draft-zeilenga-ldap-user-schema speaks of these three matching > rules, it does little more than re-state X.520. There is no doubt > about consensus regarding the origins and semantics of booleanMatch, > octetStringOrderingMatch, and integerOrderingMatch. > > To remove the normative reference to draft-zeilenga-ldap-user-schema > is simply to remove a redundancy. Removing the normative reference to > draft-zeilenga-ldap-user-schema does not leave draft-ietf-policy-core > -schema-16 without a normative reference for the three matching rules. > > Larry > > > Pana, Mircea wrote, On 05/06/03 10:36: > >> Larry, >> >> I don't have a strong opinion about the booleanMatch and wrt. the >> octetStringOrderingMatch I don't even see where it might be necessary. >> However, the integerOrderingMatch might be critical to some policy >> aplications. Therefore, as much as I'd like to see this ID progress to >> RFC, >> I believe that the removal of the normative reference is detrimental >> to this >> document. >> >> I know that some Directory vendors already implement these matching >> rules. >> The problem is that, without a normative document, each vendor might >> implement different behavior for the same rule... >> >> Mircea. >> >> >> -----Original Message----- >> From: Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] >> Sent: Monday, May 05, 2003 2:33 PM >> To: Wijnen, Bert (Bert) >> Cc: RFC Editor; Randy Bush; policy@ietf.org; Joel M. Halpern; Ed >> Ellesson >> Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt >> >> >> I raised the following points last week, but didn't get a rise >> out of anybody... >> >> draft-ietf-policy-core-schema-16 uses three matching rules which >> haven't been explicitly defined as standard LDAP matching rules. They >> are booleanMatch, integerOrderingMatch, and octetStringOrderingMatch. >> These matching rules are the subject of draft-ietf-policy-core-schema- >> 16's dependence upon draft-zeilenga-ldap-user-schema. >> >> What does "adapted for use in LDAP" mean for those matching rules? >> According to draft-zeilenga-ldap-user-schema, the "adaptation" is >> little more than a restatement of the X.520 definitions. Obviously, >> X.520 provides the consensus-supported definitions for booleanMatch, >> integerOrderingMatch, and octetStringOrderingMatch. >> >> Some LDAP-conformant server implementations already support >> booleanMatch, integerOrderingMatch, and octetStringOrderingMatch in >> conformance with their X.520 definitions. Does it matter that these >> X.520-defined matching rules are not yet defined in an LDAP-specific >> RFC? The server doesn't care. The schema doesn't care. The applications >> which use the server and the schema don't care, either. >> >> Rough consensus and working code, right? How could consensus get any >> better for these three matching rules than it already is? I realize that >> Kurt, the ldapbis WG, and the IETF are working very hard to make LDAP >> more concise, precise, and complete. This is Good Work. But in the case >> of draft-ietf-policy-core-schema-16 and these three matching rules, if >> the subject of the normative reference at issue here isn't immediately >> forthcoming, there really isn't a good reason for draft-ietf-policy- >> core-schema-16 to wait any longer. >> >> If draft-zeilenga-ldap-user-schema still has serious issues, why not >> defer to pragmatism, drop the reference, and move on? >> >> Larry >> >> >> Wijnen, Bert (Bert) wrote, On 05/05/03 12:59: >> >>> 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:rfc-editor@rfc-editor.org] >>>> Sent: maandag 5 mei 2003 19:35 >>>> To: Bert Wijnen; Randy Bush >>>> Cc: policy@ietf.org; Joel M. Halpern; Ed Ellesson; RFC Editor; >>>> lbartz@parnelli.indy.cr.irs.gov >>>> 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 >>>> ? >>>> 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? >>>>>> >>>>> >> >> > > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Wed May 14 10:21:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19815 for ; Wed, 14 May 2003 10:21:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4EDmGt17382 for policy-archive@odin.ietf.org; Wed, 14 May 2003 09:48:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EDfXB17025; Wed, 14 May 2003 09:41:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EDepB16974 for ; Wed, 14 May 2003 09:40:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19403 for ; Wed, 14 May 2003 10:13:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fx2l-0006DL-00 for policy@ietf.org; Wed, 14 May 2003 10:15:43 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19Fx2l-0006DH-00 for policy@ietf.org; Wed, 14 May 2003 10:15:43 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4603666; Wed, 14 May 2003 10:16:45 -0400 Message-Id: <5.1.0.14.0.20030514101359.0228a158@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 May 2003 10:15:56 -0400 To: "Larry S. Bartz" , policy@ietf.org From: "Joel M. Halpern" Subject: Re: PCLS when? [was: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt] Cc: Randy Bush , Ed Ellesson , "Wijnen, Bert (Bert)" In-Reply-To: <3EC23D2B.3030804@parnelli.indy.cr.irs.gov> References: <3EB7DEC4.3000600@parnelli.indy.cr.irs.gov> <3EB7DEC4.3000600@parnelli.indy.cr.irs.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , At the moment I am still operating on the assumption that the IESG will get the user schema document unstuck. We went through a lot of discussion in earlier reviews to arrive at the agreement that we would use that document as the basis for those aspects of our LDAP work. I am loath to attempt to change that conclusion unless the AD informs us that the zeilenga document will not be going forward. Yours, Joel M. Halpern At 07:57 AM 5/14/2003 -0500, Larry S. Bartz wrote: >Now it has been *six* months since the PCLS (Policy Core LDAP Schema) >draft entered the RFC Editor's Queue. When will the RFC be published? > >I haven't seen a convincing argument for retaining PCLS's dependency >upon draft-zeilenga-ldap-user-schema. > >Larry > > >Larry S. Bartz wrote, On 05/06/03 11:11: >>Mircea, all, >>Reference to X.520 (for which there is already a normative reference >>in the draft) is the *only* normative reference which is necessary to >>cover the three matching rules. >>X.520 defines booleanMatch, octetStringOrderingMatch, and >>integerOrderingMatch. >>Where draft-zeilenga-ldap-user-schema speaks of these three matching >>rules, it does little more than re-state X.520. There is no doubt >>about consensus regarding the origins and semantics of booleanMatch, >>octetStringOrderingMatch, and integerOrderingMatch. >>To remove the normative reference to draft-zeilenga-ldap-user-schema >>is simply to remove a redundancy. Removing the normative reference to >>draft-zeilenga-ldap-user-schema does not leave draft-ietf-policy-core >>-schema-16 without a normative reference for the three matching rules. >>Larry >> >>Pana, Mircea wrote, On 05/06/03 10:36: >> >>>Larry, >>> >>>I don't have a strong opinion about the booleanMatch and wrt. the >>>octetStringOrderingMatch I don't even see where it might be necessary. >>>However, the integerOrderingMatch might be critical to some policy >>>aplications. Therefore, as much as I'd like to see this ID progress to RFC, >>>I believe that the removal of the normative reference is detrimental to this >>>document. >>> >>>I know that some Directory vendors already implement these matching rules. >>>The problem is that, without a normative document, each vendor might >>>implement different behavior for the same rule... >>> >>>Mircea. >>> >>> >>>-----Original Message----- >>>From: Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] >>>Sent: Monday, May 05, 2003 2:33 PM >>>To: Wijnen, Bert (Bert) >>>Cc: RFC Editor; Randy Bush; policy@ietf.org; Joel M. Halpern; Ed >>>Ellesson >>>Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt >>> >>> >>>I raised the following points last week, but didn't get a rise >>>out of anybody... >>> >>>draft-ietf-policy-core-schema-16 uses three matching rules which >>>haven't been explicitly defined as standard LDAP matching rules. They >>>are booleanMatch, integerOrderingMatch, and octetStringOrderingMatch. >>>These matching rules are the subject of draft-ietf-policy-core-schema- >>>16's dependence upon draft-zeilenga-ldap-user-schema. >>> >>>What does "adapted for use in LDAP" mean for those matching rules? >>>According to draft-zeilenga-ldap-user-schema, the "adaptation" is >>>little more than a restatement of the X.520 definitions. Obviously, >>>X.520 provides the consensus-supported definitions for booleanMatch, >>>integerOrderingMatch, and octetStringOrderingMatch. >>> >>>Some LDAP-conformant server implementations already support >>>booleanMatch, integerOrderingMatch, and octetStringOrderingMatch in >>>conformance with their X.520 definitions. Does it matter that these >>>X.520-defined matching rules are not yet defined in an LDAP-specific >>>RFC? The server doesn't care. The schema doesn't care. The applications >>>which use the server and the schema don't care, either. >>> >>>Rough consensus and working code, right? How could consensus get any >>>better for these three matching rules than it already is? I realize that >>>Kurt, the ldapbis WG, and the IETF are working very hard to make LDAP >>>more concise, precise, and complete. This is Good Work. But in the case >>>of draft-ietf-policy-core-schema-16 and these three matching rules, if >>>the subject of the normative reference at issue here isn't immediately >>>forthcoming, there really isn't a good reason for draft-ietf-policy- >>>core-schema-16 to wait any longer. >>> >>>If draft-zeilenga-ldap-user-schema still has serious issues, why not >>>defer to pragmatism, drop the reference, and move on? >>> >>>Larry >>> >>> >>>Wijnen, Bert (Bert) wrote, On 05/05/03 12:59: >>> >>>>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:rfc-editor@rfc-editor.org] >>>>>Sent: maandag 5 mei 2003 19:35 >>>>>To: Bert Wijnen; Randy Bush >>>>>Cc: policy@ietf.org; Joel M. Halpern; Ed Ellesson; RFC Editor; >>>>>lbartz@parnelli.indy.cr.irs.gov >>>>>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 >>>>>? >>>>>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? >>> > > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Sun May 18 20:18:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21295 for ; Sun, 18 May 2003 20:18:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4INlJC16257 for policy-archive@odin.ietf.org; Sun, 18 May 2003 19:47:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4INhPB16161; Sun, 18 May 2003 19:43:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4INfmB16127 for ; Sun, 18 May 2003 19:41:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21177 for ; Sun, 18 May 2003 20:12:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HYIM-00068G-00 for policy@ietf.org; Sun, 18 May 2003 20:14:26 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 19HYIL-00068A-00 for policy@ietf.org; Sun, 18 May 2003 20:14:25 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4J0FAuT138884; Sun, 18 May 2003 20:15:10 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4J0F94B163956; Sun, 18 May 2003 18:15:10 -0600 Subject: Re: [Policy] AD review of: draft-ietf-policy-qos-device-info-model-08.txt To: "Wijnen, Bert (Bert)" Cc: policy@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Robert Moore Date: Sun, 18 May 2003 20:15:05 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/18/2003 18:15:10 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , I've submitted QDDIM09 to the I-Ds repository, so it should be published in a day or two. I've summarized below what I did to address each of Bert's points. In a separate note, Bert asked whether QDDIM should still be standards track. I'm not sure how to answer that question. My inclination, though, would be to say that it should remain a standards track document, since (1) we've established the precedent that Information Models (specifically, PCIM and PCIMe) are standards track documents, and (2) of the two Data Models corresponding to QDDIM, the DiffServ MIB is a proposed standard, and the DiffServ PIB is informational because of SPPI / COPS reasons, not because of DiffServ reasons. Regards, Bob Bob Moore WebSphere Advanced Design and Technology WebSphere Platform System House IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Wijnen, Bert (Bert)" To: policy@ietf.org Subject: [Policy] AD review of: draft-ietf-policy-qos-device-info-model-08.txt Sent by: policy-admin@ietf .org 04/09/2003 12:42 PM OK, here is my review (finally... blush) - Needs to be checked against ID-NITS, see: http://www.ietf.org/ID-nits.html Also pls check against RFC2223bis see draft-rfc-editor-rfc2223bis-04.txt Things that fall under this category: - no citations in abstract - split references in normative and informative - expand Acronyms when used for the first time - use proper references in the references section - is the reference to cim 2.5 correct? - not sure if the IP address as on page 7 is allowed according to ID-NITs - I see some Msoft characters in the doc (page 12 and 64 are examples) - many referenced documents have become RFCs now. You may want to update those. - I suspect that security area is too weak. Specifically if you tell people to use IPSEC, you have to explain how that is done. But... maybe you can refer to PCIM and PCIMe, similar to how you did it for QPIM. Maybe there are some extra concerns since you also derive a lot directly from CIM ?? - In the abstract, I think that the last piece needs to be removed. That is: A separate draft could be written to provide a mapping of the data contained in this document to a form suitable for implementation in a directory that uses (L)DAP as its access protocol. Similarly, a draft could be written to provide a mapping of the data in [QPIM] to a directory. Together, these four drafts (information models and directory schema mappings) would then describe how to write QoS policy rules that can be used to store information in directories to configure device QoS mechanisms. Cause that tells what "could be done" but that cannot be the "abstract" for this document, can it? - The document speaks about "this draft" a lot. I think it should be changed throughout the document into "this document". So that once it is published we do not see "this draft" anymore. - Page 11. It might help if in the figure you indicate where we find CIM, PCIM, PCIMe, QPIM, QDDIM. etc - I see (as an example on page 16/17) QoSService as a class. Then the doc talks about the plural QoSServices, and I am not sure if it always means QoSService Instances or subclasses of QoSService. At other places it talks about "QoS services" which seems better to me - Page 17 I see: Note that this work is not yet completely aligned, as there are differences among the DiffServ Informal Management Model, the DiffServ MIB, the DiffServ PIB, and this draft. Work to finish aligning these drafts is in progress, and will be reflected in the next revision of this draft. Does this mean you were expecting a new rev of QDDIM anyway? Anyway, such text probably does not belong in a doc that goes for RFC publication. - AS an example: I see on page 21 Implementations may recognize other 's in addition to these. If collisions of implementation-specific 's become a problem, it is possible that 's may become an IANA- administered range in a future revision of this standard. This document itself should not claim that it is a standard. Or at least not in the text. If it gets approved as stds track then RFC-Editor will add that in the footing. I suggest to use "this document" instead of "this standard". Pls check if there are more occurences. - The figures on pages 26 to 32 are not consistent in their use of class names and such. I can understand that you need to abbreviate becuase of space constraints, but it might be good to do so in a consistent manner, and to list the abbreviations and explain which exact Class they represent. - On page 37 you claim (at top) that "is shown in figure 9" but I think it is actually figure 10. On page 38 it should be figure 11 instead of 10 (or so I think) - I am a bit surprised to see how the descriptions of Properties is done. In the PCIM (RFC3060) it was done pretty formal, for example: NAME CN DESCRIPTION A user-friendly name of a policy-related object. SYNTAX string Another one: NAME Mandatory DESCRIPTION A flag indicating that the evaluation of the PolicyConditions and execution of PolicyActions (if the condition list evaluates to TRUE) is required. SYNTAX boolean DEFAULT VALUE TRUE Or yet anbother one: NAME SequencedActions DESCRIPTION An enumeration indicating how to interpret the action ordering indicated via the PolicyActionInPolicyRule aggregation. SYNTAX uint16 VALUES mandatory(1), recommended(2), dontCare(3) DEFAULT VALUE dontCare(3) In RFC3460 I see it done in a similar way: NAME PolicyDecisionStrategy DESCRIPTION The evaluation method used for policies contained in the PolicySet. FirstMatching enforces the actions of the first rule that evaluates to TRUE; All Matching enforces the actions of all rules that evaluate to TRUE. SYNTAX uint16 VALUES 1 [FirstMatching], 2 [AllMatching] DEFAULT VALUE 1 [FirstMatching] So why is that not followed in this document? - Does Class TockenBucketMeterService not need a deltaInterval property? Otherwise what does the AverageRate property mean? - Do we still want/need a class TosMarkerService and a property of ToSValue? Has ToS not been obsoleted? - Class REDDropperService derives from DropperService. Does the ingeritedDropperType always have the value "Random" ?? - sect 4.3.21.2 does not even tell the datatype of the property - Sect 4.3.26 I am being told that the proper name for a flow label is FlowLabel and not FlowID. Not sure how serious this is. - Section 4.3.34 I do not see any of the properties described, do I? - sect 4.3.37.2 Would it not be better to use a 32bit unsigned? - sect 4.3.37.5 May I assume that the buffers are being shared? That is not so clear from the description (at least not to me). - Sect 4.3.40 Explain what WRR stands for - sect 4.3.40.1 Here I wonder if a 16 bit unsigned would not be more than sufficient Its units are "thousands" ?? Thousands of what? - sect 4.3.4.2 Does this property not add just extra complexity? Or is that just me thinking so? And... what happens if both WeightingFactor and Priority are equal? - Sect 4.4.18 and 4.4.19 Am I missing Property descriptions? - sec 4.4.28 Am I missing Property descriptions? Thanks, Bert _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Mon May 19 10:54:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23547 for ; Mon, 19 May 2003 10:54:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JEM2C22872 for policy-archive@odin.ietf.org; Mon, 19 May 2003 10:22:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JEHbB22727; Mon, 19 May 2003 10:17:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JEG8B22664 for ; Mon, 19 May 2003 10:16:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23478 for ; Mon, 19 May 2003 10:46:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HlwC-0003v1-00 for policy@ietf.org; Mon, 19 May 2003 10:48:28 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Hlw6-0003ue-00 for policy@ietf.org; Mon, 19 May 2003 10:48:22 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4JEjrK05194 for ; Mon, 19 May 2003 10:45:54 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10FVSY>; Mon, 19 May 2003 16:45:52 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155019C1FC5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Robert Moore Cc: policy@ietf.org Subject: RE: [Policy] AD review of: draft-ietf-policy-qos-device-info-mode l-08.txt Date: Mon, 19 May 2003 16:45:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Thanks. Looks good... a few questions remain: - Those places where you answer that my comment hits the model itself... it seems you did not make (or want to make) changes. In some of my comments, I think I was just looking for and answer (possibly add some explanatory text, so that the answer is also in the document). If the WG has consensus on something, then that is probably OK... but if it is a consensus that is not clear from what is described, then some extra explanatiory text may help. - Thanks for explaining why you want this stds track.. helps. I have detailed comments/questions below. Thanks, Bert > -----Original Message----- > From: Robert Moore [mailto:remoore@us.ibm.com] > Sent: maandag 19 mei 2003 2:15 > To: Wijnen, Bert (Bert) > Cc: policy@ietf.org > Subject: Re: [Policy] AD review of: > draft-ietf-policy-qos-device-info-model-08.txt > .. snip .. > > - is the reference to cim 2.5 correct? > CIM 2.5 is there to be referenced, permanently and immutably> My concern was if there is an issue if the base PCIM (RFC3060) refers to CIM 2.2, namely: [2] Distributed Management Task Force, Inc., "Common Information Model (CIM) Specification, version 2.2, June 1999. This document is available on the following DMTF web page: http://www.dmtf.org/spec/cims.html. And PCIMe als refers to CIM 2.2, namely [3] Distributed Management Task Force, Inc., "Common Information Model (CIM) Specification: Version 2.2", June 14, 1999, available at http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf. So is it then OK for this QDDIM to refer to extend on PCIM and PCIMe which refer to an older CIM version? Or am I confused here between the COM and the CIM Schema? .. snip .. > - I see some Msoft characters in the doc (page 12 and 64 are > examples) > however, I'm finding these solely by eyeball, so I may have > missed some> Your rev 9 does not have any non-ASCII characters according to my checking-script. It does however have: -: 311 lines longer than 72 characters, max 74 RFC-Editor will fix if you don't. > > - I suspect that security area is too weak. > Specifically if you tell people to use IPSEC, you have to > explain how that is done. But... maybe you can refer to > PCIM and PCIMe, similar to how you did it for QPIM. > Maybe there are some extra concerns since you also derive > a lot directly from CIM ?? > if the Security Area has some specific text, we can certainly > include it> > Mmm... I wonder if you cannot build on what you have in RFC3060 and RFC3460. This is (after all) an Information Model, and such a model itself should not have a security impact (does it?). Instead, when the model is translated into a LDAP Schema or such, then once such data is used, it needs to be transported securely. In any event, if you DO specify that IPsec SHOULD be used, I believe that the security ADs then want you to explain more about HOW to use it. A good document to check is: http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-00.txt Based on that, you can see a good Security COnsiderations section for the use of IPsec in RFC3474, which was created with the help of Steve Bellovin. .. snip .. > - Page 11. > It might help if in the figure you indicate where we find > CIM, PCIM, PCIMe, QPIM, QDDIM. etc > the bottom of; since I don't think that it's crucial to have > these labels here, I made no changes.> > Indeed not crucial... so I can pass if it is too difficult. Intersting that even the experts in this field would not be able to fill them in. Oh well. .. snip .. > - The figures on pages 26 to 32 are not consistent in their use of > class names and such. I can understand that you need to abbreviate > becuase of space constraints, but it might be good to do so in a > consistent manner, and to list the abbreviations and explain which > exact Class they represent. > quite easily which class an abbreviation is referring to.> > Mmmm... wil will live with it. .. snip .. > - I am a bit surprised to see how the descriptions of Properties is > done. In the PCIM (RFC3060) it was done pretty formal, for example: > > NAME CN > DESCRIPTION A user-friendly name of a policy-related object. > SYNTAX string > > Another one: > > NAME Mandatory > DESCRIPTION A flag indicating that the evaluation of the > PolicyConditions and execution of PolicyActions > (if the condition list evaluates to TRUE) is > required. > SYNTAX boolean > DEFAULT VALUE TRUE > > Or yet anbother one: > > NAME SequencedActions > DESCRIPTION An enumeration indicating how to interpret the > action ordering indicated via the > PolicyActionInPolicyRule aggregation. > SYNTAX uint16 > VALUES mandatory(1), recommended(2), dontCare(3) > DEFAULT VALUE dontCare(3) > > In RFC3460 I see it done in a similar way: > > > NAME PolicyDecisionStrategy > DESCRIPTION The evaluation method used for policies contained in > the PolicySet. FirstMatching enforces the actions > of the first rule that evaluates to TRUE; > All Matching enforces the actions of all rules > that evaluate to TRUE. > SYNTAX uint16 > VALUES 1 [FirstMatching], 2 [AllMatching] > DEFAULT VALUE 1 [FirstMatching] > > So why is that not followed in this document? > CIM MOF files. In many cases these files weren't there when QDDIM > was being written. I believe that the necessary modeling information > is all here in QDDIM; as always, though, implementation experience > may prove me wrong.> > So... what you are telling me is that all the info is in the document (which I believe is indeed the case, at least in the new rev), but that we do NOT specify it in such a formal way in this QDDIM doc as we did in PCIM and PCIMe. Did I get that correctly? And if so... why would we be so "lazy" ?? > - Does Class TockenBucketMeterService not need a deltaInterval property? > Otherwise what does the AverageRate property mean? > I've made no changes in response to these comments, because what's in the > document now reflects a consensus reached after *long* debates among the > authors and other in the WG. If anyone wants to reopen the debates, feel > free. But I'm going to pass.> > So can you answer the question what the AverageRate property means? Or is the answer fuzzy? > - Do we still want/need a class TosMarkerService and a property of ToSValue? > Has ToS not been obsoleted? > > is there no answer to my question, though? .. snip .. > - sect 4.3.37.2 > Would it not be better to use a 32bit unsigned? > > No answer? You understand that I can live with the 16bit value. But I wonder how future proof a 16bit value is when it needs to express the number of bytes for a bufferpool. .. snip .. > > - sect 4.3.4.2 > Does this property not add just extra complexity? Or is that just me > thinking so? > And... what happens if both WeightingFactor and Priority are equal? > > Could you suggest an answer to my question? Like: hey Bert cool off... Oh well > 4.4.17 that I had missed in -08. It's fixed now.> > OK thanks Bert _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Mon May 19 17:50:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07021 for ; Mon, 19 May 2003 17:50:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JLJVC21065 for policy-archive@odin.ietf.org; Mon, 19 May 2003 17:19:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JLFPB20915; Mon, 19 May 2003 17:15:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JLEZB20887 for ; Mon, 19 May 2003 17:14:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06936 for ; Mon, 19 May 2003 17:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HsSz-0006pA-00 for policy@ietf.org; Mon, 19 May 2003 17:46:45 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19HsSz-0006p3-00 for policy@ietf.org; Mon, 19 May 2003 17:46:45 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4JLlVK02278 for ; Mon, 19 May 2003 17:47:31 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10F59R>; Mon, 19 May 2003 23:47:30 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155019C2066@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Robert Moore Cc: policy@ietf.org Subject: RE: [Policy] AD review of: draft-ietf-policy-qos-device-info-mode l-08.txt Date: Mon, 19 May 2003 23:47:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Taking another look at the doc (rev 9) and checking for changes since rev 08, I see that you did not list that you removed section 4.3.20.2. That was not based on my comments but for some other reason I guess. So I am listing it just so thw WG knows and maybe Bob can explain why it was removed. In Sect 4.3.41 you changed PrioritySchedulingElement into PrioritySchedulerElement. Is that correct? I wonder cause I do not see PrioritySchedulerElement anywhere else in the document. In sect 4.4.5 You changed cardinality 1..n into 1..1 Good for people to know that too. And why was it done? Not based on my comments I assume. In sect 4.4.6 you changed cardinality 1..1 into 0..1. Explanation? In sect 4.4.9 You changed cardinality 1..n into 1..1 people who want to see all the changes colored in the text can take a look at: http://psg.com/~bwijnen/qddim.html Thanks, Bert > -----Original Message----- > From: Robert Moore [mailto:remoore@us.ibm.com] > Sent: maandag 19 mei 2003 2:15 > To: Wijnen, Bert (Bert) > Cc: policy@ietf.org > Subject: Re: [Policy] AD review of: > draft-ietf-policy-qos-device-info-model-08.txt > > > > > > > I've submitted QDDIM09 to the I-Ds repository, so it should > be published in > a day or two. I've summarized below what I did to address > each of Bert's > points. > > In a separate note, Bert asked whether QDDIM should still be standards > track. I'm not sure how to answer that question. My > inclination, though, > would be to say that it should remain a standards track > document, since (1) > we've established the precedent that Information Models > (specifically, PCIM > and PCIMe) are standards track documents, and (2) of the two > Data Models > corresponding to QDDIM, the DiffServ MIB is a proposed > standard, and the > DiffServ PIB is informational because of SPPI / COPS reasons, > not because > of DiffServ reasons. > > Regards, > Bob > > Bob Moore > WebSphere Advanced Design and Technology > WebSphere Platform System House > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > > > > > > "Wijnen, Bert > > > (Bert)" To: > policy@ietf.org > > > > om> Subject: > [Policy] AD review of: > draft-ietf-policy-qos-device-info-model-08.txt > Sent by: > > > policy-admin@ietf > > > .org > > > > > > > > > 04/09/2003 12:42 > > > PM > > > > > > > > > > > > > OK, here is my review (finally... blush) > > - Needs to be checked against ID-NITS, > see: http://www.ietf.org/ID-nits.html > Also pls check against RFC2223bis > see draft-rfc-editor-rfc2223bis-04.txt > Things that fall under this category: > - no citations in abstract > > - split references in normative and informative > > - expand Acronyms when used for the first time > > - use proper references in the references section > > - is the reference to cim 2.5 correct? > CIM 2.5 is there to be referenced, permanently and immutably> > - not sure if the IP address as on page 7 is allowed > according to ID-NITs > > - I see some Msoft characters in the doc (page 12 and 64 are > examples) > however, I'm finding these solely by eyeball, so I may have > missed some> > - many referenced documents have become RFCs now. You may want > to update those. > > > - I suspect that security area is too weak. > Specifically if you tell people to use IPSEC, you have to > explain how that is done. But... maybe you can refer to > PCIM and PCIMe, similar to how you did it for QPIM. > Maybe there are some extra concerns since you also derive > a lot directly from CIM ?? > if the Security Area has some specific text, we can certainly > include it> > > - In the abstract, I think that the last piece needs to > be removed. That is: > > A separate draft could be written to provide > a mapping of the data contained in this document to a form > suitable for implementation in a directory that uses (L)DAP as > its access protocol. Similarly, a draft could be written to > provide a mapping of the data in [QPIM] to a directory. > Together, these four drafts (information models and directory > schema mappings) would then describe how to write QoS policy > rules that can be used to store information in directories to > configure device QoS mechanisms. > > Cause that tells what "could be done" but that cannot be the > "abstract" for this document, can it? > > > - The document speaks about "this draft" a lot. I think it should > be changed throughout the document into "this document". So that > once it is published we do not see "this draft" anymore. > > > - Page 11. > It might help if in the figure you indicate where we find > CIM, PCIM, PCIMe, QPIM, QDDIM. etc > the bottom of; since I don't think that it's crucial to have > these labels here, I made no changes.> > > - I see (as an example on page 16/17) QoSService as a class. > Then the doc talks about the plural QoSServices, and I am not > sure if it always means QoSService Instances or subclasses of > QoSService. At other places it talks about "QoS services" > which seems better to me > > > - Page 17 I see: > Note that this work is not yet completely aligned, as there are > differences among the DiffServ Informal Management Model, the > DiffServ MIB, the DiffServ PIB, and this draft. Work to finish > aligning these drafts is in progress, and will be reflected in > the next revision of this draft. > Does this mean you were expecting a new rev of QDDIM anyway? > Anyway, such text probably does not belong in a doc that goes > for RFC publication. > > > - AS an example: I see on page 21 > Implementations may recognize other 's in addition to > these. If collisions of implementation-specific 's become > a problem, it is possible that 's may become an IANA- > administered range in a future revision of this standard. > This document itself should not claim that it is a standard. Or > at least not in the text. If it gets approved as stds track then > RFC-Editor will add that in the footing. I suggest to use > "this document" instead of "this standard". > Pls check if there are more occurences. > > > - The figures on pages 26 to 32 are not consistent in their use of > class names and such. I can understand that you need to abbreviate > becuase of space constraints, but it might be good to do so in a > consistent manner, and to list the abbreviations and explain which > exact Class they represent. > quite easily which class an abbreviation is referring to.> > > - On page 37 you claim (at top) that "is shown in figure 9" but > I think it is actually figure 10. > On page 38 it should be figure 11 instead of 10 (or so I think) > > > - I am a bit surprised to see how the descriptions of Properties is > done. In the PCIM (RFC3060) it was done pretty formal, for example: > > NAME CN > DESCRIPTION A user-friendly name of a > policy-related object. > SYNTAX string > > Another one: > > NAME Mandatory > DESCRIPTION A flag indicating that the evaluation of the > PolicyConditions and execution of PolicyActions > (if the condition list evaluates to TRUE) is > required. > SYNTAX boolean > DEFAULT VALUE TRUE > > Or yet anbother one: > > NAME SequencedActions > DESCRIPTION An enumeration indicating how to interpret the > action ordering indicated via the > PolicyActionInPolicyRule aggregation. > SYNTAX uint16 > VALUES mandatory(1), recommended(2), dontCare(3) > DEFAULT VALUE dontCare(3) > > In RFC3460 I see it done in a similar way: > > > NAME PolicyDecisionStrategy > DESCRIPTION The evaluation method used for policies > contained in > the PolicySet. FirstMatching enforces the actions > of the first rule that evaluates to TRUE; > All Matching enforces the actions of all rules > that evaluate to TRUE. > SYNTAX uint16 > VALUES 1 [FirstMatching], 2 [AllMatching] > DEFAULT VALUE 1 [FirstMatching] > > So why is that not followed in this document? > CIM MOF files. In many cases these files weren't there when QDDIM > was being written. I believe that the necessary modeling information > is all here in QDDIM; as always, though, implementation experience > may prove me wrong.> > > - Does Class TockenBucketMeterService not need a > deltaInterval property? > Otherwise what does the AverageRate property mean? > model itself. > I've made no changes in response to these comments, because > what's in the > document now reflects a consensus reached after *long* > debates among the > authors and other in the WG. If anyone wants to reopen the > debates, feel > free. But I'm going to pass.> > > - Do we still want/need a class TosMarkerService and a property of > ToSValue? > Has ToS not been obsoleted? > > > - Class REDDropperService derives from DropperService. > Does the ingeritedDropperType always have the value "Random" ?? > > > - sect 4.3.21.2 does not even tell the datatype of the property > > > - Sect 4.3.26 > I am being told that the proper name for a flow label is FlowLabel > and not FlowID. Not sure how serious this is. > that talks about "FlowLabel".> > > - Section 4.3.34 > I do not see any of the properties described, do I? > the reader > to CIM for the definition. This is how it should have been all along, > just as it is for the other CIM classes that QDDIM references.> > > - sect 4.3.37.2 > Would it not be better to use a 32bit unsigned? > > > - sect 4.3.37.5 > May I assume that the buffers are being shared? > That is not so clear from the description (at least not to me). > the property is "SharedBuffers".> > > - Sect 4.3.40 > Explain what WRR stands for > > > - sect 4.3.40.1 > Here I wonder if a 16 bit unsigned would not be more than sufficient > Its units are "thousands" ?? Thousands of what? > multiplier, it has > ^^ > no units> > > - sect 4.3.4.2 > Does this property not add just extra complexity? Or is that just me > thinking so? > And... what happens if both WeightingFactor and Priority are equal? > > > 4.4.17 that I had missed in -08. It's fixed now.> > > - Sect 4.4.18 and 4.4.19 > Am I missing Property descriptions? > > > - sec 4.4.28 > Am I missing Property descriptions? > > > Thanks, > Bert > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > > > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue May 20 09:07:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12001 for ; Tue, 20 May 2003 09:07:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KCaic30060 for policy-archive@odin.ietf.org; Tue, 20 May 2003 08:36:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KCWJB29706; Tue, 20 May 2003 08:32:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KCU7B29586 for ; Tue, 20 May 2003 08:30:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11672 for ; Tue, 20 May 2003 09:00:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19I6kh-000518-00 for policy@ietf.org; Tue, 20 May 2003 09:01:59 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19I6kg-00050i-00 for policy@ietf.org; Tue, 20 May 2003 09:01:58 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4KD2kN26467 for ; Tue, 20 May 2003 09:02:46 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10GKLD>; Tue, 20 May 2003 15:02:45 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155019C230B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Joel M. Halpern" , policy@ietf.org Subject: RE: [Policy] Revised Draft Date: Tue, 20 May 2003 15:02:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Mmm.. on page 46 and following I see afew FALSEFALSE values. Is that correct? If not, then you can keep that to be fixed at a later point. Same for [DIFF-MIB] Refernce, it should refernece RFC3289 For those who want to see the I-Ds with colored changes, See http://psg.com/~bwijnen/qpim.html http://psg.com/~bwijnen/qddim.html Is the doc ready for me to send it into IETF Last Call? Thanks, Bert > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: donderdag 8 mei 2003 20:15 > To: policy@ietf.org > Subject: [Policy] Revised Draft > > > The editor, Bob Moore, has submitted a revised draft of the > Policy QoS > Information Model, > http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info > -model-05.txt > > This draft is believed to address the comments raised by the > AD review, > without violating the consensus of the working group on any > items. If Bob > has time he will write up a description of the changes, but > he has already > done a huge amount of work for us. Please take a look at > this draft and > speak quickly if you see problems. I do not anticipate > having an explicit > additional working group last call, but am giving you this > window before > asking Bert to run with this draft. > > Thanks again to Bob for his efforts, > Joel > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue May 20 09:13:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12198 for ; Tue, 20 May 2003 09:13:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KChGh31193 for policy-archive@odin.ietf.org; Tue, 20 May 2003 08:43:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KCd7B31041; Tue, 20 May 2003 08:39:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KAv7B22822 for ; Tue, 20 May 2003 06:57:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06354; Tue, 20 May 2003 07:27:12 -0400 (EDT) Message-Id: <200305201127.HAA06354@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: policy@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 20 May 2003 07:27:12 -0400 Subject: [Policy] I-D ACTION:draft-ietf-policy-qos-device-info-model-09.txt Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Policy Framework Working Group of the IETF. Title : Information Model for Describing Network Device QoS Datapath Mechanisms Author(s) : B. Moore, D. Durham, J. Strassner, A. Westerinen, W. Weiss Filename : draft-ietf-policy-qos-device-info-model-09.txt Pages : 91 Date : 2003-5-19 The purpose of this documenthis document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This documenthis document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two drafts describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-policy-qos-device-info-model-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-policy-qos-device-info-model-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-19142201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-policy-qos-device-info-model-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-policy-qos-device-info-model-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-19142201.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue May 20 12:19:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20002 for ; Tue, 20 May 2003 12:19:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KFmnS12728 for policy-archive@odin.ietf.org; Tue, 20 May 2003 11:48:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KFijB12566; Tue, 20 May 2003 11:44:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KFhpB12531 for ; Tue, 20 May 2003 11:43:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19806 for ; Tue, 20 May 2003 12:13:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19I9m6-0006Wc-00 for policy@ietf.org; Tue, 20 May 2003 12:15:38 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19I9m4-0006WF-00 for policy@ietf.org; Tue, 20 May 2003 12:15:36 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4KGGOYp232956; Tue, 20 May 2003 12:16:24 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4KGGK7Z128974; Tue, 20 May 2003 10:16:20 -0600 Subject: RE: [Policy] AD review of: draft-ietf-policy-qos-device-info-mode l-08.txt To: "Wijnen, Bert (Bert)" Cc: policy@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Robert Moore Date: Tue, 20 May 2003 12:35:44 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/20/2003 10:16:20 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Hi Bert, I didn't list these changes because I wasn't aware I had made them! Checking back, it appears that I started the -09 edits on a slightly out-of-date version of the -08 source file. So I did an inadvertent rollback on the very last changes that were made for -08. I'm pretty sure the set of such changes exactly matches these you've identified here. I'll do a quick update to fix these items, and publish a -10. Meanwhile, if any of the authors who still do QoS for a living want to respond to your other set of comments, I'll factor in any changes they propose. I'm afraid that network QoS is now so far in my past that it would be a bad idea for me to even try to make any substantive changes to the document at this point. Regards, Bob Bob Moore WebSphere Advanced Design and Technology WebSphere Platform System House IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Wijnen, Bert (Bert)" To: Robert Moore/Raleigh/IBM@IBMUS Subject: RE: [Policy] AD review of: draft-ietf-policy-qos-device-info-mode l-08.txt 05/19/03 05:47 PM Taking another look at the doc (rev 9) and checking for changes since rev 08, I see that you did not list that you removed section 4.3.20.2. That was not based on my comments but for some other reason I guess. So I am listing it just so thw WG knows and maybe Bob can explain why it was removed. In Sect 4.3.41 you changed PrioritySchedulingElement into PrioritySchedulerElement. Is that correct? I wonder cause I do not see PrioritySchedulerElement anywhere else in the document. In sect 4.4.5 You changed cardinality 1..n into 1..1 Good for people to know that too. And why was it done? Not based on my comments I assume. In sect 4.4.6 you changed cardinality 1..1 into 0..1. Explanation? In sect 4.4.9 You changed cardinality 1..n into 1..1 people who want to see all the changes colored in the text can take a look at: http://psg.com/~bwijnen/qddim.html Thanks, Bert > -----Original Message----- > From: Robert Moore [mailto:remoore@us.ibm.com] > Sent: maandag 19 mei 2003 2:15 > To: Wijnen, Bert (Bert) > Cc: policy@ietf.org > Subject: Re: [Policy] AD review of: > draft-ietf-policy-qos-device-info-model-08.txt > > > > > > > I've submitted QDDIM09 to the I-Ds repository, so it should > be published in > a day or two. I've summarized below what I did to address > each of Bert's > points. > > In a separate note, Bert asked whether QDDIM should still be standards > track. I'm not sure how to answer that question. My > inclination, though, > would be to say that it should remain a standards track > document, since (1) > we've established the precedent that Information Models > (specifically, PCIM > and PCIMe) are standards track documents, and (2) of the two > Data Models > corresponding to QDDIM, the DiffServ MIB is a proposed > standard, and the > DiffServ PIB is informational because of SPPI / COPS reasons, > not because > of DiffServ reasons. > > Regards, > Bob > > Bob Moore > WebSphere Advanced Design and Technology > WebSphere Platform System House > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > > > > > > "Wijnen, Bert > > > (Bert)" To: > policy@ietf.org > > > > om> Subject: > [Policy] AD review of: > draft-ietf-policy-qos-device-info-model-08.txt > Sent by: > > > policy-admin@ietf > > > .org > > > > > > > > > 04/09/2003 12:42 > > > PM > > > > > > > > > > > > > OK, here is my review (finally... blush) > > - Needs to be checked against ID-NITS, > see: http://www.ietf.org/ID-nits.html > Also pls check against RFC2223bis > see draft-rfc-editor-rfc2223bis-04.txt > Things that fall under this category: > - no citations in abstract > > - split references in normative and informative > > - expand Acronyms when used for the first time > > - use proper references in the references section > > - is the reference to cim 2.5 correct? > CIM 2.5 is there to be referenced, permanently and immutably> > - not sure if the IP address as on page 7 is allowed > according to ID-NITs > > - I see some Msoft characters in the doc (page 12 and 64 are > examples) > however, I'm finding these solely by eyeball, so I may have > missed some> > - many referenced documents have become RFCs now. You may want > to update those. > > > - I suspect that security area is too weak. > Specifically if you tell people to use IPSEC, you have to > explain how that is done. But... maybe you can refer to > PCIM and PCIMe, similar to how you did it for QPIM. > Maybe there are some extra concerns since you also derive > a lot directly from CIM ?? > if the Security Area has some specific text, we can certainly > include it> > > - In the abstract, I think that the last piece needs to > be removed. That is: > > A separate draft could be written to provide > a mapping of the data contained in this document to a form > suitable for implementation in a directory that uses (L)DAP as > its access protocol. Similarly, a draft could be written to > provide a mapping of the data in [QPIM] to a directory. > Together, these four drafts (information models and directory > schema mappings) would then describe how to write QoS policy > rules that can be used to store information in directories to > configure device QoS mechanisms. > > Cause that tells what "could be done" but that cannot be the > "abstract" for this document, can it? > > > - The document speaks about "this draft" a lot. I think it should > be changed throughout the document into "this document". So that > once it is published we do not see "this draft" anymore. > > > - Page 11. > It might help if in the figure you indicate where we find > CIM, PCIM, PCIMe, QPIM, QDDIM. etc > the bottom of; since I don't think that it's crucial to have > these labels here, I made no changes.> > > - I see (as an example on page 16/17) QoSService as a class. > Then the doc talks about the plural QoSServices, and I am not > sure if it always means QoSService Instances or subclasses of > QoSService. At other places it talks about "QoS services" > which seems better to me > > > - Page 17 I see: > Note that this work is not yet completely aligned, as there are > differences among the DiffServ Informal Management Model, the > DiffServ MIB, the DiffServ PIB, and this draft. Work to finish > aligning these drafts is in progress, and will be reflected in > the next revision of this draft. > Does this mean you were expecting a new rev of QDDIM anyway? > Anyway, such text probably does not belong in a doc that goes > for RFC publication. > > > - AS an example: I see on page 21 > Implementations may recognize other 's in addition to > these. If collisions of implementation-specific 's become > a problem, it is possible that 's may become an IANA- > administered range in a future revision of this standard. > This document itself should not claim that it is a standard. Or > at least not in the text. If it gets approved as stds track then > RFC-Editor will add that in the footing. I suggest to use > "this document" instead of "this standard". > Pls check if there are more occurences. > > > - The figures on pages 26 to 32 are not consistent in their use of > class names and such. I can understand that you need to abbreviate > becuase of space constraints, but it might be good to do so in a > consistent manner, and to list the abbreviations and explain which > exact Class they represent. > quite easily which class an abbreviation is referring to.> > > - On page 37 you claim (at top) that "is shown in figure 9" but > I think it is actually figure 10. > On page 38 it should be figure 11 instead of 10 (or so I think) > > > - I am a bit surprised to see how the descriptions of Properties is > done. In the PCIM (RFC3060) it was done pretty formal, for example: > > NAME CN > DESCRIPTION A user-friendly name of a > policy-related object. > SYNTAX string > > Another one: > > NAME Mandatory > DESCRIPTION A flag indicating that the evaluation of the > PolicyConditions and execution of PolicyActions > (if the condition list evaluates to TRUE) is > required. > SYNTAX boolean > DEFAULT VALUE TRUE > > Or yet anbother one: > > NAME SequencedActions > DESCRIPTION An enumeration indicating how to interpret the > action ordering indicated via the > PolicyActionInPolicyRule aggregation. > SYNTAX uint16 > VALUES mandatory(1), recommended(2), dontCare(3) > DEFAULT VALUE dontCare(3) > > In RFC3460 I see it done in a similar way: > > > NAME PolicyDecisionStrategy > DESCRIPTION The evaluation method used for policies > contained in > the PolicySet. FirstMatching enforces the actions > of the first rule that evaluates to TRUE; > All Matching enforces the actions of all rules > that evaluate to TRUE. > SYNTAX uint16 > VALUES 1 [FirstMatching], 2 [AllMatching] > DEFAULT VALUE 1 [FirstMatching] > > So why is that not followed in this document? > CIM MOF files. In many cases these files weren't there when QDDIM > was being written. I believe that the necessary modeling information > is all here in QDDIM; as always, though, implementation experience > may prove me wrong.> > > - Does Class TockenBucketMeterService not need a > deltaInterval property? > Otherwise what does the AverageRate property mean? > model itself. > I've made no changes in response to these comments, because > what's in the > document now reflects a consensus reached after *long* > debates among the > authors and other in the WG. If anyone wants to reopen the > debates, feel > free. But I'm going to pass.> > > - Do we still want/need a class TosMarkerService and a property of > ToSValue? > Has ToS not been obsoleted? > > > - Class REDDropperService derives from DropperService. > Does the ingeritedDropperType always have the value "Random" ?? > > > - sect 4.3.21.2 does not even tell the datatype of the property > > > - Sect 4.3.26 > I am being told that the proper name for a flow label is FlowLabel > and not FlowID. Not sure how serious this is. > that talks about "FlowLabel".> > > - Section 4.3.34 > I do not see any of the properties described, do I? > the reader > to CIM for the definition. This is how it should have been all along, > just as it is for the other CIM classes that QDDIM references.> > > - sect 4.3.37.2 > Would it not be better to use a 32bit unsigned? > > > - sect 4.3.37.5 > May I assume that the buffers are being shared? > That is not so clear from the description (at least not to me). > the property is "SharedBuffers".> > > - Sect 4.3.40 > Explain what WRR stands for > > > - sect 4.3.40.1 > Here I wonder if a 16 bit unsigned would not be more than sufficient > Its units are "thousands" ?? Thousands of what? > multiplier, it has > ^^ > no units> > > - sect 4.3.4.2 > Does this property not add just extra complexity? Or is that just me > thinking so? > And... what happens if both WeightingFactor and Priority are equal? > > > 4.4.17 that I had missed in -08. It's fixed now.> > > - Sect 4.4.18 and 4.4.19 > Am I missing Property descriptions? > > > - sec 4.4.28 > Am I missing Property descriptions? > > > Thanks, > Bert > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > > > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Wed May 21 14:52:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01693 for ; Wed, 21 May 2003 14:52:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LIJho06088 for policy-archive@odin.ietf.org; Wed, 21 May 2003 14:19:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LIFoB05630; Wed, 21 May 2003 14:15:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LICaB05467 for ; Wed, 21 May 2003 14:12:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01177 for ; Wed, 21 May 2003 14:45:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IYZ4-0001GU-00 for policy@ietf.org; Wed, 21 May 2003 14:43:50 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19IYZ3-0001GP-00 for policy@ietf.org; Wed, 21 May 2003 14:43:50 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4644695; Wed, 21 May 2003 14:45:06 -0400 Message-Id: <5.1.0.14.0.20030521144046.021d8670@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 21 May 2003 14:42:08 -0400 To: "Wijnen, Bert (Bert)" , policy@ietf.org From: "Joel M. Halpern" Subject: RE: [Policy] Revised Draft In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155019C230B@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Bert, please accept the current draft of this information model and begin the IESG processing to start the IETF last call, etc. The editor has made the corrections you have requested, and the working group is happy with the changes (or so burned out that they can not be unhappy.) Yours, Joel PS: Again many thanks to Bob for his editing work. At 03:02 PM 5/20/2003 +0200, Wijnen, Bert (Bert) wrote: >Mmm.. on page 46 and following I see afew FALSEFALSE values. >Is that correct? If not, then you can keep that to be >fixed at a later point. > >Same for [DIFF-MIB] Refernce, it should refernece RFC3289 > >For those who want to see the I-Ds with colored changes, >See > http://psg.com/~bwijnen/qpim.html > http://psg.com/~bwijnen/qddim.html > >Is the doc ready for me to send it into IETF Last Call? > >Thanks, >Bert > > > -----Original Message----- > > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > > Sent: donderdag 8 mei 2003 20:15 > > To: policy@ietf.org > > Subject: [Policy] Revised Draft > > > > > > The editor, Bob Moore, has submitted a revised draft of the > > Policy QoS > > Information Model, > > http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info > > -model-05.txt > > > > This draft is believed to address the comments raised by the > > AD review, > > without violating the consensus of the working group on any > > items. If Bob > > has time he will write up a description of the changes, but > > he has already > > done a huge amount of work for us. Please take a look at > > this draft and > > speak quickly if you see problems. I do not anticipate > > having an explicit > > additional working group last call, but am giving you this > > window before > > asking Bert to run with this draft. > > > > Thanks again to Bob for his efforts, > > Joel > > > > > > _______________________________________________ > > Policy mailing list > > Policy@ietf.org > > https://www1.ietf.org/mailman/listinfo/policy > > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Wed May 21 17:12:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09119 for ; Wed, 21 May 2003 17:12:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LKdQw18289 for policy-archive@odin.ietf.org; Wed, 21 May 2003 16:39:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LKZMB17191; Wed, 21 May 2003 16:35:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LKYRB17112 for ; Wed, 21 May 2003 16:34:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08925 for ; Wed, 21 May 2003 17:06:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IamH-0002yK-00 for policy@ietf.org; Wed, 21 May 2003 17:05:37 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19IamH-0002xm-00 for policy@ietf.org; Wed, 21 May 2003 17:05:37 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4LL6R712610 for ; Wed, 21 May 2003 17:06:28 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10HKKD>; Wed, 21 May 2003 23:06:27 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501A9F49C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Joel M. Halpern" , policy@ietf.org Subject: RE: [Policy] Revised Draft Date: Wed, 21 May 2003 23:06:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Will do. I assume you mean http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-05.txt Thanks, Bert > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: woensdag 21 mei 2003 20:42 > To: Wijnen, Bert (Bert); policy@ietf.org > Subject: RE: [Policy] Revised Draft > > > Bert, please accept the current draft of this information > model and begin > the IESG processing to start the IETF last call, etc. The > editor has made > the corrections you have requested, and the working group is > happy with the > changes (or so burned out that they can not be unhappy.) > > Yours, > Joel > > PS: Again many thanks to Bob for his editing work. > > At 03:02 PM 5/20/2003 +0200, Wijnen, Bert (Bert) wrote: > >Mmm.. on page 46 and following I see afew FALSEFALSE values. > >Is that correct? If not, then you can keep that to be > >fixed at a later point. > > > >Same for [DIFF-MIB] Refernce, it should refernece RFC3289 > > > >For those who want to see the I-Ds with colored changes, > >See > > http://psg.com/~bwijnen/qpim.html > > http://psg.com/~bwijnen/qddim.html > > > >Is the doc ready for me to send it into IETF Last Call? > > > >Thanks, > >Bert > > > > > -----Original Message----- > > > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > > > Sent: donderdag 8 mei 2003 20:15 > > > To: policy@ietf.org > > > Subject: [Policy] Revised Draft > > > > > > > > > The editor, Bob Moore, has submitted a revised draft of the > > > Policy QoS > > > Information Model, > > > http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info > > > -model-05.txt > > > > > > This draft is believed to address the comments raised by the > > > AD review, > > > without violating the consensus of the working group on any > > > items. If Bob > > > has time he will write up a description of the changes, but > > > he has already > > > done a huge amount of work for us. Please take a look at > > > this draft and > > > speak quickly if you see problems. I do not anticipate > > > having an explicit > > > additional working group last call, but am giving you this > > > window before > > > asking Bert to run with this draft. > > > > > > Thanks again to Bob for his efforts, > > > Joel > > > > > > > > > _______________________________________________ > > > Policy mailing list > > > Policy@ietf.org > > > https://www1.ietf.org/mailman/listinfo/policy > > > > > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Fri May 23 15:26:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22109 for ; Fri, 23 May 2003 15:26:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NJQPo23422 for policy-archive@odin.ietf.org; Fri, 23 May 2003 15:26:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NJLiB23112; Fri, 23 May 2003 15:21:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NJKlB23071 for ; Fri, 23 May 2003 15:20:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21906 for ; Fri, 23 May 2003 15:20:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JI4V-0001UH-00 for policy@ietf.org; Fri, 23 May 2003 15:19:19 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19JI4N-0001U2-00 for policy@ietf.org; Fri, 23 May 2003 15:19:11 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4NJJtkc233010; Fri, 23 May 2003 15:19:56 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4NJJrKu041996; Fri, 23 May 2003 13:19:53 -0600 Subject: RE: [Policy] AD review of: draft-ietf-policy-qos-device-info-mode l-08.txt To: policy@ietf.org Cc: bwijnen@lucent.com, ellesson@mindspring.com, joel@stevecrocker.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Robert Moore Date: Fri, 23 May 2003 15:19:50 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|April 17, 2003) at 05/23/2003 13:19:53 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , I've submitted QDDIM-10 to the I-D's repository. The major change from QDDIM-09 is that I've reversed the inadvertent backouts from QDDIM-08 that I mentioned before. Sorry for that confusion -- QDDIM-10 now represents what I *thought* I was publishing in QDDIM-09. I've also made some changes, based on Walter's response to the list, to address many of Bert's latest comments. Here's Bert's note, with the details of the QDDIM-10 changes tagged with 's: *******Begin Bert's note: Thanks. Looks good... a few questions remain: - Those places where you answer that my comment hits the model itself... it seems you did not make (or want to make) changes. In some of my comments, I think I was just looking for and answer (possibly add some explanatory text, so that the answer is also in the document). If the WG has consensus on something, then that is probably OK... but if it is a consensus that is not clear from what is described, then some extra explanatiory text may help. - Thanks for explaining why you want this stds track.. helps. I have detailed comments/questions below. Thanks, Bert > -----Original Message----- > From: Robert Moore [mailto:remoore@us.ibm.com] > Sent: maandag 19 mei 2003 2:15 > To: Wijnen, Bert (Bert) > Cc: policy@ietf.org > Subject: Re: [Policy] AD review of: > draft-ietf-policy-qos-device-info-model-08.txt > .. snip .. > > - is the reference to cim 2.5 correct? > CIM 2.5 is there to be referenced, permanently and immutably> My concern was if there is an issue if the base PCIM (RFC3060) refers to CIM 2.2, namely: [2] Distributed Management Task Force, Inc., "Common Information Model (CIM) Specification, version 2.2, June 1999. This document is available on the following DMTF web page: http://www.dmtf.org/spec/cims.html. And PCIMe als refers to CIM 2.2, namely [3] Distributed Management Task Force, Inc., "Common Information Model (CIM) Specification: Version 2.2", June 14, 1999, available at http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf. So is it then OK for this QDDIM to refer to extend on PCIM and PCIMe which refer to an older CIM version? Or am I confused here between the COM and the CIM Schema? Where I think you're confused is between the CIM spec and the CIM Schema. In fact, PCIMe refers to exactly the same version of the CIM Schema as QDDIM does: CIM Schema 2.5. .. snip .. > - I see some Msoft characters in the doc (page 12 and 64 are > examples) > however, I'm finding these solely by eyeball, so I may have > missed some> Your rev 9 does not have any non-ASCII characters according to my checking-script. It does however have: -: 311 lines longer than 72 characters, max 74 RFC-Editor will fix if you don't. In case it was the headers/footers doing this, I shortened them a bit - but the RFC Editor is definitely going to change these anyway. > > - I suspect that security area is too weak. > Specifically if you tell people to use IPSEC, you have to > explain how that is done. But... maybe you can refer to > PCIM and PCIMe, similar to how you did it for QPIM. > Maybe there are some extra concerns since you also derive > a lot directly from CIM ?? > if the Security Area has some specific text, we can certainly > include it> > Mmm... I wonder if you cannot build on what you have in RFC3060 and RFC3460. This is (after all) an Information Model, and such a model itself should not have a security impact (does it?). Instead, when the model is translated into a LDAP Schema or such, then once such data is used, it needs to be transported securely. In any event, if you DO specify that IPsec SHOULD be used, I believe that the security ADs then want you to explain more about HOW to use it. A good document to check is: http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-00.txt Based on that, you can see a good Security COnsiderations section for the use of IPsec in RFC3474, which was created with the help of Steve Bellovin. Based on your comments and those from Joel and Walter, I took a shot at a shorter Security Considerations section that expresses two ideas: (1) we're just an information model, and (2) for some security- related thoughts for specific objects in the model, take a look at the DiffServ MIB (since it's already been approved as a PS, and hence is available for us to reference). .. snip .. > - Page 11. > It might help if in the figure you indicate where we find > CIM, PCIM, PCIMe, QPIM, QDDIM. etc > the bottom of; since I don't think that it's crucial to have > these labels here, I made no changes.> > Indeed not crucial... so I can pass if it is too difficult. Intersting that even the experts in this field would not be able to fill them in. Oh well. .. snip .. > - The figures on pages 26 to 32 are not consistent in their use of > class names and such. I can understand that you need to abbreviate > becuase of space constraints, but it might be good to do so in a > consistent manner, and to list the abbreviations and explain which > exact Class they represent. > quite easily which class an abbreviation is referring to.> > Mmmm... wil will live with it. .. snip .. > - I am a bit surprised to see how the descriptions of Properties is > done. In the PCIM (RFC3060) it was done pretty formal, for example: > > NAME CN > DESCRIPTION A user-friendly name of a policy-related object. > SYNTAX string > > Another one: > > NAME Mandatory > DESCRIPTION A flag indicating that the evaluation of the > PolicyConditions and execution of PolicyActions > (if the condition list evaluates to TRUE) is > required. > SYNTAX boolean > DEFAULT VALUE TRUE > > Or yet anbother one: > > NAME SequencedActions > DESCRIPTION An enumeration indicating how to interpret the > action ordering indicated via the > PolicyActionInPolicyRule aggregation. > SYNTAX uint16 > VALUES mandatory(1), recommended(2), dontCare(3) > DEFAULT VALUE dontCare(3) > > In RFC3460 I see it done in a similar way: > > > NAME PolicyDecisionStrategy > DESCRIPTION The evaluation method used for policies contained in > the PolicySet. FirstMatching enforces the actions > of the first rule that evaluates to TRUE; > All Matching enforces the actions of all rules > that evaluate to TRUE. > SYNTAX uint16 > VALUES 1 [FirstMatching], 2 [AllMatching] > DEFAULT VALUE 1 [FirstMatching] > > So why is that not followed in this document? > CIM MOF files. In many cases these files weren't there when QDDIM > was being written. I believe that the necessary modeling information > is all here in QDDIM; as always, though, implementation experience > may prove me wrong.> > So... what you are telling me is that all the info is in the document (which I believe is indeed the case, at least in the new rev), but that we do NOT specify it in such a formal way in this QDDIM doc as we did in PCIM and PCIMe. Did I get that correctly? And if so... why would we be so "lazy" ?? I'd prefer "otherwise focused" here:-) > - Does Class TockenBucketMeterService not need a deltaInterval property? > Otherwise what does the AverageRate property mean? > I've made no changes in response to these comments, because what's in the > document now reflects a consensus reached after *long* debates among the > authors and other in the WG. If anyone wants to reopen the debates, feel > free. But I'm going to pass.> > So can you answer the question what the AverageRate property means? Or is the answer fuzzy? This one is still unresolved -- Walter said that this probably "deserves" additional text, but he didn't provide it. > - Do we still want/need a class TosMarkerService and a property of ToSValue? > Has ToS not been obsoleted? > > is there no answer to my question, though? Walter has answered the question, but I'm not sure this answer needs to be reflected in the document itself. When historians read the QDDIM RFC 100 years from now, won't they conclude "Oh, this must have been right at the end of the ToS era," without any further help from us? .. snip .. > - sect 4.3.37.2 > Would it not be better to use a 32bit unsigned? > > No answer? You understand that I can live with the 16bit value. But I wonder how future proof a 16bit value is when it needs to express the number of bytes for a bufferpool. Based on Walter's response, I've change this to a uint32. .. snip .. > > - sect 4.3.4.2 > Does this property not add just extra complexity? Or is that just me > thinking so? > And... what happens if both WeightingFactor and Priority are equal? > > Could you suggest an answer to my question? Like: hey Bert cool off... Oh well I added some text based on Walter's response -- and as requested, it's a little more concise than his:-) > 4.4.17 that I had missed in -08. It's fixed now.> > OK thanks Bert *******End Bert's note: Regards, Bob Bob Moore WebSphere Advanced Design and Technology WebSphere Platform System House IBM Software Group +1-919-254-4436 remoore@us.ibm.com _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Fri May 30 19:48:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03661 for ; Fri, 30 May 2003 19:48:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UNltj18392 for policy-archive@odin.ietf.org; Fri, 30 May 2003 19:47:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UNhpB18241; Fri, 30 May 2003 19:43:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SBk2B28554 for ; Wed, 28 May 2003 07:46:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25638; Wed, 28 May 2003 07:46:00 -0400 (EDT) Message-Id: <200305281146.HAA25638@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: policy@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 28 May 2003 07:46:00 -0400 Subject: [Policy] I-D ACTION:draft-ietf-policy-qos-device-info-model-10.txt Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Policy Framework Working Group of the IETF. Title : Information Model for Describing Network Device QoS Datapath Mechanisms Author(s) : B. Moore, D. Durham, J. Strassner, A. Westerinen, W. Weiss Filename : draft-ietf-policy-qos-device-info-model-10.txt Pages : 91 Date : 2003-5-27 The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This documenthis document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two drafts describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-policy-qos-device-info-model-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-policy-qos-device-info-model-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-27145348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-policy-qos-device-info-model-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-policy-qos-device-info-model-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-27145348.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy