Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 3703


Policy Core Lightweight Directory Access Protocol (LDAP) Schema

Part 3 of 3, p. 50 to 61
Prev RFC Part


prevText      Top      Up      ToC       Page 50 
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.

Top      Up      ToC       Page 51 
   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.

   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 RFC 3060 for more

Top      Up      ToC       Page 52 
   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.

   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

Top      Up      ToC       Page 53 
   General LDAP security considerations apply, as documented in RFC 3377
   [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

   Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA)
   Considerations for the Lightweight Directory Access Protocol (LDAP)"

8.1.  Object Identifiers

   The IANA has registered an LDAP Object Identifier 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 (
   Specification: RFC 3703
   Author/Change Controller: IESG
      The assigned OID will be used as a base for identifying
      a number of schema elements defined in this document.

   IANA has assigned an OID of with the name of pcimSchema
   to this registration as recorded in the following registry:

8.2.  Object Identifier Descriptors

   The IANA has registered 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

Top      Up      ToC       Page 54 
   Person & email address to contact for further information:
      Bob Moore (
   Usage: see comment
   Specification: RFC 3703
   Author/Change Controller: IESG

   The following descriptors have been added:

   NAME                            Type    OID
   --------------                  ----    ------------
   pcimPolicy                      O
   pcimGroup                       O
   pcimGroupAuxClass               O
   pcimGroupInstance               O
   pcimRule                        O
   pcimRuleAuxClass                O
   pcimRuleInstance                O
   pcimRuleConditionAssociation    O
   pcimRuleValidityAssociation     O
   pcimRuleActionAssociation       O
   pcimConditionAuxClass           O
   pcimTPCAuxClass                 O
   pcimConditionVendorAuxClass     O
   pcimActionAuxClass              O
   pcimActionVendorAuxClass        O
   pcimPolicyInstance              O
   pcimElementAuxClass             O
   pcimRepository                  O
   pcimRepositoryAuxClass          O
   pcimRepositoryInstance          O
   pcimSubtreesPtrAuxClass         O
   pcimGroupContainmentAuxClass    O
   pcimRuleContainmentAuxClass     O
   pcimKeywords                    A
   pcimGroupName                   A
   pcimRuleName                    A
   pcimRuleEnabled                 A
   pcimRuleConditionListType       A
   pcimRuleConditionList           A
   pcimRuleActionList              A
   pcimRuleValidityPeriodList      A
   pcimRuleUsage                   A
   pcimRulePriority                A
   pcimRuleMandatory               A
   pcimRuleSequencedActions        A
   pcimRoles                       A
   pcimConditionGroupNumber        A

Top      Up      ToC       Page 55 
   NAME                            Type    OID
   --------------                  ----    ------------
   pcimConditionNegated            A
   pcimConditionName               A
   pcimConditionDN                 A
   pcimValidityConditionName       A
   pcimTimePeriodConditionDN       A
   pcimActionName                  A
   pcimActionOrder                 A
   pcimActionDN                    A
   pcimTPCTime                     A
   pcimTPCMonthOfYearMask          A
   pcimTPCDayOfMonthMask           A
   pcimTPCDayOfWeekMask            A
   pcimTPCTimeOfDayMask            A
   pcimTPCLocalOrUtcTime           A
   pcimVendorConstraintData        A
   pcimVendorConstraintEncoding    A
   pcimVendorActionData            A
   pcimVendorActionEncoding        A
   pcimPolicyInstanceName          A
   pcimRepositoryName              A
   pcimSubtreesAuxContainedSet     A
   pcimGroupsAuxContainedSet       A
   pcimRulesAuxContainedSet        A

   where Type A is Attribute, Type O is ObjectClass

   These assignments are recorded in the following registry:

Top      Up      ToC       Page 56 
9.  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.

Top      Up      ToC       Page 57 
10.  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 <key>=<value> elements are ordered by the names of the key
   properties, according to the collating sequence for US ASCII.  The
   only spaces allowed in the DirectoryString are those that fall within
   a <value> element.  As with alphabetizing the key properties, the

Top      Up      ToC       Page 58 
   goal of suppressing the spaces is once again to make the results of
   string operations predictable.

   The values of the <value> elements are derived from the various CIM
   syntaxes according to a grammar specified in [5].

11.  References

11.1.  Normative References

   [1]   Moore, B., Ellesson,E., Strassner, J. and A. Westerinen "Policy
         Core Information Model -- Version 1 Specification", RFC 3060,
         February 2001.

   [2]   Hodges, J. and R. Morgan, "Lightweight Directory Access
         Protocol (v3): Technical Specification", RFC 3377, September

   [3]   Wahl, M., Coulbeck, A., Howes,T. and 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:

   [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:

   [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.

   [9]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
         (LDAP): Additional Matching Rules", RFC 3698, February 2004.

   [10]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

Top      Up      ToC       Page 59 
11.2.  Informative References

   [11]  Hovey, R. and S. Bradner, "The Organizations Involved in the
         IETF Standards Process", BCP 11, RFC 2028, October 1996.

   [12]  Strassner, J., policy architecture BOF presentation, 42nd IETF
         Meeting, Chicago, Illinois, October 1998.  Minutes of this BOF
         are available at the following location:

   [13]  Yavatkar, R., Guerin, R. and D. Pendarakis, "A Framework for
         Policy-based Admission Control", RFC 2753, January 2000.

   [14]  Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
         "Authentication Methods for LDAP", RFC 2829, May 2000

   [15]  Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
         Access Protocol (v3): Extension for Transport Layer Security",
         RFC 2830, May 2000.

   [16]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
         Considerations for the Lightweight Directory Access Protocol
         (LDAP)", BCP 64, RFC 3383, September 2002.

Top      Up      ToC       Page 60 
12.  Authors' Addresses

   John Strassner
   Intelliden Corporation
   90 South Cascade Avenue
   Colorado Springs, CO  80903

   Phone: +1.719.785.0648
   Fax:   +1.719.785.0644

   Bob Moore
   IBM Corporation
   P. O. Box 12195, BRQA/B501/G206
   3039 Cornwallis Rd.
   Research Triangle Park, NC  27709-2195

   Phone: +1 919-254-4436
   Fax:   +1 919-254-6243

   Ryan Moats
   Lemur Networks, Inc.
   15621 Drexel Circle
   Omaha, NE 68135

   Phone: +1-402-894-9456

   Ed Ellesson
   3026 Carriage Trail
   Hillsborough, NC 27278

   Phone: +1 919-644-3977

Top      Up      ToC       Page 61 
13.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to
   rights in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository

   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 implement this standard.  Please address the information to the
   IETF at


   Funding for the RFC Editor function is currently provided by the
   Internet Society.