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.
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
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.
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 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)"
[16].
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 (remoore@us.ibm.com)
Specification: RFC 3703
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.
IANA has assigned an OID of 1.3.6.1.1.6 with the name of pcimSchema
to this registration as recorded in the following registry:
http://www.iana.org/assignments/smi-numbers
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
Person & email address to contact for further information:
Bob Moore (remoore@us.ibm.com)
Usage: see comment
Specification: RFC 3703
Author/Change Controller: IESG
Comments:
The following descriptors have been added:
NAME Type OID
-------------- ---- ------------
pcimPolicy O 1.3.6.1.1.6.1.1
pcimGroup O 1.3.6.1.1.6.1.2
pcimGroupAuxClass O 1.3.6.1.1.6.1.3
pcimGroupInstance O 1.3.6.1.1.6.1.4
pcimRule O 1.3.6.1.1.6.1.5
pcimRuleAuxClass O 1.3.6.1.1.6.1.6
pcimRuleInstance O 1.3.6.1.1.6.1.7
pcimRuleConditionAssociation O 1.3.6.1.1.6.1.8
pcimRuleValidityAssociation O 1.3.6.1.1.6.1.9
pcimRuleActionAssociation O 1.3.6.1.1.6.1.10
pcimConditionAuxClass O 1.3.6.1.1.6.1.11
pcimTPCAuxClass O 1.3.6.1.1.6.1.12
pcimConditionVendorAuxClass O 1.3.6.1.1.6.1.13
pcimActionAuxClass O 1.3.6.1.1.6.1.14
pcimActionVendorAuxClass O 1.3.6.1.1.6.1.15
pcimPolicyInstance O 1.3.6.1.1.6.1.16
pcimElementAuxClass O 1.3.6.1.1.6.1.17
pcimRepository O 1.3.6.1.1.6.1.18
pcimRepositoryAuxClass O 1.3.6.1.1.6.1.19
pcimRepositoryInstance O 1.3.6.1.1.6.1.20
pcimSubtreesPtrAuxClass O 1.3.6.1.1.6.1.21
pcimGroupContainmentAuxClass O 1.3.6.1.1.6.1.22
pcimRuleContainmentAuxClass O 1.3.6.1.1.6.1.23
pcimKeywords A 1.3.6.1.1.6.2.3
pcimGroupName A 1.3.6.1.1.6.2.4
pcimRuleName A 1.3.6.1.1.6.2.5
pcimRuleEnabled A 1.3.6.1.1.6.2.6
pcimRuleConditionListType A 1.3.6.1.1.6.2.7
pcimRuleConditionList A 1.3.6.1.1.6.2.8
pcimRuleActionList A 1.3.6.1.1.6.2.9
pcimRuleValidityPeriodList A 1.3.6.1.1.6.2.10
pcimRuleUsage A 1.3.6.1.1.6.2.11
pcimRulePriority A 1.3.6.1.1.6.2.12
pcimRuleMandatory A 1.3.6.1.1.6.2.13
pcimRuleSequencedActions A 1.3.6.1.1.6.2.14
pcimRoles A 1.3.6.1.1.6.2.15
pcimConditionGroupNumber A 1.3.6.1.1.6.2.16
NAME Type OID
-------------- ---- ------------
pcimConditionNegated A 1.3.6.1.1.6.2.17
pcimConditionName A 1.3.6.1.1.6.2.18
pcimConditionDN A 1.3.6.1.1.6.2.19
pcimValidityConditionName A 1.3.6.1.1.6.2.20
pcimTimePeriodConditionDN A 1.3.6.1.1.6.2.21
pcimActionName A 1.3.6.1.1.6.2.22
pcimActionOrder A 1.3.6.1.1.6.2.23
pcimActionDN A 1.3.6.1.1.6.2.24
pcimTPCTime A 1.3.6.1.1.6.2.25
pcimTPCMonthOfYearMask A 1.3.6.1.1.6.2.26
pcimTPCDayOfMonthMask A 1.3.6.1.1.6.2.27
pcimTPCDayOfWeekMask A 1.3.6.1.1.6.2.28
pcimTPCTimeOfDayMask A 1.3.6.1.1.6.2.29
pcimTPCLocalOrUtcTime A 1.3.6.1.1.6.2.30
pcimVendorConstraintData A 1.3.6.1.1.6.2.31
pcimVendorConstraintEncoding A 1.3.6.1.1.6.2.32
pcimVendorActionData A 1.3.6.1.1.6.2.33
pcimVendorActionEncoding A 1.3.6.1.1.6.2.34
pcimPolicyInstanceName A 1.3.6.1.1.6.2.35
pcimRepositoryName A 1.3.6.1.1.6.2.36
pcimSubtreesAuxContainedSet A 1.3.6.1.1.6.2.37
pcimGroupsAuxContainedSet A 1.3.6.1.1.6.2.38
pcimRulesAuxContainedSet A 1.3.6.1.1.6.2.39
where Type A is Attribute, Type O is ObjectClass
These assignments are recorded in the following registry:
http://www.iana.org/assignments/ldap-parameters
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.
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
<className>.<key>=<value>[,<key>=<value>]*
where the <key>=<value> elements are ordered by the names of the key
properties, according to the collating sequence for US ASCII. The
only spaces allowed in the DirectoryString are those that fall within
a <value> element. As with alphabetizing the key properties, the
goal of suppressing the spaces is once again to make the results of
string operations predictable.
The values of the <value> elements are derived from the various CIM
syntaxes according to a grammar specified in [5].
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
2002.
[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:
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.
[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.
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:
http://www.ietf.org/proceedings/98aug/index.html.
[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.
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
EMail: john.strassner@intelliden.com
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
EMail: remoore@us.ibm.com
Ryan Moats
Lemur Networks, Inc.
15621 Drexel Circle
Omaha, NE 68135
Phone: +1-402-894-9456
EMail: rmoats@lemurnetworks.net
Ed Ellesson
3026 Carriage Trail
Hillsborough, NC 27278
Phone: +1 919-644-3977
EMail: ellesson@mindspring.com
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
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
at http://www.ietf.org/ipr.
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 ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.