Policy Framework Working Group J. Strassner
Internet-draft A. Westerinen
Category: Standards Track Cisco Systems
E. Ellesson
LongBoard, Inc.
B. Moore
IBM Corporation
R. Moats
Coreon, Inc.
March 2001
Policy Core LDAP Schema
draft-ietf-policy-core-schema-10.txt
March 29, 2001 09:23
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 (2001). All Rights Reserved.
Abstract
This document takes as its starting point the object-oriented
information model for representing policy information currently under
joint development in the Service Level Agreements (SLA) Policy working
group of the Distributed Management Task Force (DMTF) and in the
IETF's Policy Framework working group. The IETF document defining
this information model is the "Policy Core Information Model --
Version 1 Specification" [1]. 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.
Strassner, et al. Expires: September 2001 [Page 1]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
This draft defines the mapping of these information model classes to a
directory that uses LDAPv3 as its access protocol. When mapping to an
LDAP schema, the structural classes can be mapped more or less
directly. The relationship hierarchy, however, must be mapped to a
form suitable for directory implementation. Since this mapping of the
relationship classes could be done in a number of different ways,
there is the risk of non-interoperable implementations. To avoid this
possibility, this document provides a single mapping that all
implementations using an LDAP directory as their policy repository
SHALL use.
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.
The LDAP schema described in this document consists of ten very
general classes: policy (an abstract class), three policyGroup
classes, three policyRule classes, policyConditionAuxClass,
ptpConditionAuxClass, and policyActionAuxClass. (Note that the
PolicyTimePeriodCondition auxiliary class would normally have been
named policyTimePeriodConditionAuxClass, but this name is too long for
some directories. Therefore, we have abbreviated this name as
ptpConditionAuxClass). The mapping for the PCIM classes PolicyGroup
and PolicyRule is similar to the mapping in [10] for several CIM
concrete classes: an abstract superclass, with an auxiliary class and
a structural class derived from it. See [10] for more details on this
mapping approach. The schema also contains two less general classes:
vendorPolicyConditionAuxClass and vendorPolicyActionAuxClass. To
achieve the mapping of the information model's relationships, the
schema contains two auxiliary classes: policyGroupContainmentAuxClass
and policyRuleContainmentAuxClass. Capturing the distinction between
rule-specific and reusable policy conditions and policy actions
introduces seven other classes: policyRuleConditionAssociation,
policyRuleValidityAssociation, policyRuleActionAssociation,
policyInstance, and three policyRepository classes. Finally, the
schema includes two classes policySubtreesPtrAuxClass and
policyElementAuxClass for optimizing LDAP retrievals. In all,
therefore, the schema contains 23 classes.
Within the context of this document, the term "Core [Policy] Schema"
is used to refer to the LDAP class definitions it contains.
Strassner, et al. Expires: September 2001 [Page 2]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
Table of Contents
1. Introduction......................................................3
2. The Policy Core Information Model.................................4
3. Inheritance Hierarchy for the LDAP Core Policy Schema.............5
4. General Discussion of Mapping the Information Model to LDAP.......7
4.1. Summary of Class and Association Mappings....................7
4.2. Naming Attributes in the Core Schema........................10
4.3. Rule-Specific and Reusable Conditions and Actions...........11
4.4. Location and Retrieval of Policy Objects in the Directory...14
4.4.1. Aliases and Other DIT-Optimization Techniques.............17
5. Class Definitions................................................18
5.1. The Abstract Class "policy".................................18
5.2. The Three policyGroup Classes...............................19
5.3. The Three policyRule Classes................................21
5.4. The Class policyRuleConditionAssociation....................27
5.5. The Class policyRuleValidityAssociation.....................29
5.6. The Class policyRuleActionAssociation.......................31
5.7. The Auxiliary Class policyConditionAuxClass.................34
5.8. The Auxiliary Class ptpConditionAuxClass....................34
5.9. The Auxiliary Class vendorPolicyConditionAuxClass...........36
5.10. The Auxiliary Class policyActionAuxClass...................37
5.11. The Auxiliary Class vendorPolicyActionAuxClass.............38
5.12. The Class policyInstance...................................38
5.13. The Auxiliary Class policyElementAuxClass..................40
5.14. The Three policyRepository Classes.........................41
5.15. The Auxiliary Class policySubtreesPtrAuxClass..............43
5.15.1. The Attribute policySubtreesAuxContainedSet..............44
5.16. The Auxiliary Class policyGroupContainmentAuxClass.........44
5.16.1. The Attribute policyGroupsAuxContainedSet................45
5.17. The Auxiliary Class policyRuleContainmentAuxClass..........45
5.17.1. The Attribute policyRulesAuxContainedSet.................46
6. Extending the Core Schema........................................46
6.1. Subclassing policyConditionAuxClass and policyActionAuxClass46
6.2. Using the Vendor Policy Encoding Attributes.................46
6.3. Using Time Validity Periods.................................47
7. Security Considerations..........................................47
8. Intellectual Property............................................49
9. Acknowledgments..................................................49
10. References......................................................49
11. Authors' Addresses..............................................50
12. Full Copyright Statement........................................51
13. Appendix: Constructing the Value of orderedCimKeys.............52
1. Introduction
This document takes as its starting point the object-oriented
information model for representing policy information currently under
joint development in the Service Level Agreements working group of the
Distributed Management Task Force (DMTF) and in the IETF's Policy
Framework working group. The IETF document defining this information
model is the "Policy Core Information Model -- Version 1
Strassner, et al. Expires: September 2001 [Page 3]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
Specification" [1]. 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 LDAPv3 as its access protocol. Two types of
mappings are involved:
o 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.
o For the relationship classes in the information model, different
mappings are possible. In this document the information model's
relationship classes and their properties are mapped in three ways:
to LDAP auxiliary classes, to attributes representing DN pointers,
and to containment in the Directory Information Tree (DIT).
Implementations that use an LDAP directory as their policy repository
SHALL use the LDAP policy schema defined in this document. The use of
the information model defined in reference [1] as the starting point
enables the schema and the relationship class hierarchy to be
extensible, such that other types of policy repositories, such as
relational databases, can also use this information.
This document fits into the overall framework for representing,
deploying, and managing policies being developed by the Policy
Framework Working Group. It traces its origins to work that was
originally done for the Directory-enabled Networks (DEN)
specification, reference [5]. Work on the DEN specification by the
DEN Ad-Hoc Working Group itself has been completed. Further work to
standardize the models contained in it will be the responsibility of
selected working groups of the Common Information Model (CIM) effort
in the Distributed Management Task Force (DMTF). DMTF standardization
of the core policy model is the responsibility of the SLA Policy
working group in the DMTF.
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 [3].
2. The Policy Core Information Model
This document contains an LDAP schema representing the Policy Core
Information Model (abbreviated "PCIM"), which is 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
Strassner, et al. Expires: September 2001 [Page 4]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
the detailed semantics of the Core Policy classes appear only in
reference [1], that document is a prerequisite for reading and
understanding this document.
3. Inheritance Hierarchy for the LDAP Core Policy Schema
The following diagram illustrates the class hierarchy for the LDAP
Core Policy Schema classes:
Strassner, et al. Expires: September 2001 [Page 5]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
top
|
+--dlm1ManagedElement (abstract)
| |
| +--policy (abstract)
| | |
| | +--policyGroup (abstract)
| | | |
| | | +--policyGroupAuxClass (auxiliary)
| | | |
| | | +--policyGroupInstance (structural)
| | |
| | +--policyRule (abstract)
| | | |
| | | +--policyRuleAuxClass (auxiliary)
| | | |
| | | +--policyRuleInstance (structural)
| | |
| | +--policyRuleConditionAssociation (structural)
| | |
| | +--policyRuleValidityAssociation (structural)
| | |
| | +--policyRuleActionAssociation (structural)
| | |
| | +--policyInstance (structural)
| | |
| | +--policyElementAuxClass (auxiliary)
| |
| +--dlm1ManagedSystemElement (abstract)
| |
| +--dlm1LogicalElement (abstract)
| |
| +--dlm1System (abstract)
| |
| +--dlm1AdminDomain (abstract)
| |
| +--policyRepository (abstract)
| |
| +--policyRepositoryAuxClass (auxiliary)
| |
| +--policyRepositoryInstance (structural)
(continued on following page)
Strassner, et al. Expires: September 2001 [Page 6]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
(continued from previous page)
top
|
+--policyConditionAuxClass (auxiliary)
| |
| +---ptpConditionAuxClass (auxiliary)
| |
| +---vendorPolicyConditionAuxClass (auxiliary)
|
+--policyActionAuxClass (auxiliary)
| |
| +---vendorPolicyActionAuxClass (auxiliary)
|
+--policySubtreesPtrAuxClass (auxiliary)
|
+--policyGroupContainmentAuxClass (auxiliary)
|
+--policyRuleContainmentAuxClass (auxiliary)
Figure 1. LDAP Class Inheritance Hierarchy for the Core Policy
Schema
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 content and structure rules provided here are suggestions; they
may be modified as needed to support a particular directory structure.
Directory administrators do not need to subclass/instantiate all of
the classes in this schema. They are free to choose the subset that
meets their particular needs.
4.1. Summary of Class and Association Mappings
Fifteen of the classes in the LDAP Core Policy Schema 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.
Strassner, et al. Expires: September 2001 [Page 7]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
+---------------------------+-----------------------------------+
| Information Model | LDAP Class |
+---------------------------+-----------------------------------+
+---------------------------+-----------------------------------+
| Policy | policy |
+---------------------------+-----------------------------------+
| PolicyGroup | policyGroup |
| | policyGroupAuxClass |
| | policyGroupInstance |
+---------------------------+-----------------------------------+
| PolicyRule | policyRule |
| | policyRuleAuxClass |
| | policyRuleInstance |
+---------------------------+-----------------------------------+
| PolicyCondition | policyConditionAuxClass |
+---------------------------+-----------------------------------+
| PolicyAction | policyActionAuxClass |
+---------------------------+-----------------------------------+
| VendorPolicyCondition | vendorPolicyConditionAuxClass |
+---------------------------+-----------------------------------+
| VendorPolicyAction | vendorPolicyActionAuxClass |
+---------------------------+-----------------------------------+
| PolicyTimePeriodCondition | ptpConditionAuxClass |
+---------------------------+-----------------------------------+
| PolicyRepository | policyRepository |
| | policyRepositoryAuxClass |
| | policyRepositoryInstance |
+---------------------------+-----------------------------------+
Figure 2. Mapping of Information Model Classes to LDAP
The associations in the information model map to DN-pointer attributes
or to Directory Information Tree (DIT) containment in LDAP. Two of
the DN-pointer attributes appear in auxiliary classes, which allow
each of them to represent several relationships from the information
model.
Strassner, et al. Expires: September 2001 [Page 8]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
+-----------------------------------+--------------------------------+
| Information Model Association | LDAP Attribute / Class |
+-----------------------------------+--------------------------------+
+-----------------------------------+--------------------------------+
| PolicyGroupInPolicyGroup | policyGroupsAuxContainedSet in |
| | policyGroupContainmentAuxClass|
+-----------------------------------+--------------------------------+
| PolicyRuleInPolicyGroup | policyRulesAuxContainedSet in |
| | policyRuleContainmentAuxClass |
+-----------------------------------+--------------------------------+
| PolicyConditionInPolicyRule | DIT containment + |
| | policyRuleConditionList in |
| | policyRule + |
| | policyConditionDN in |
| | policyRuleConditionAssociation|
+-----------------------------------+--------------------------------+
| PolicyActionInPolicyRule | DIT containment + |
| | policyRuleActionList in |
| | policyRule + |
| | policyActionDN in |
| | policyRuleActionAssociation |
+-----------------------------------+--------------------------------+
| PolicyRuleValidityPeriod | policyRuleValidityAssociation |
| | + ptpConditionAuxClass or |
| | referenced through the |
| | policyTimePeriodConditionDN |
+-----------------------------------+--------------------------------+
| PolicyConditionInPolicyRepository | DIT containment |
+-----------------------------------+--------------------------------+
| PolicyActionInPolicyRepository | DIT containment |
+-----------------------------------+--------------------------------+
| PolicyRepositoryInPolicyRepository| DIT containment |
+-----------------------------------+--------------------------------+
Figure 3. Mapping of Information Model Associations to LDAP
Of the remaining classes in the LDAP Core Schema, two
(policyElementAuxClass and policySubtreesPtrAuxClass) are included to
make navigation through the DIT and retrieval of the entries found
there more efficient. This topic is discussed in Section 4.4 below.
The remaining four classes in the LDAP Core Schema,
policyRuleConditionAssociation, policyRuleValidityAssociation,
policyRuleActionAssociation, and policyInstance are all involved with
the representation of policy conditions and policy actions in an LDAP
directory. This topic is discussed in Section 4.3 below.
4.2. Naming Attributes in the Core Schema
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 relative distinguished names (RDNs), where an RDN provides
Strassner, et al. Expires: September 2001 [Page 9]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
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, each
of the structural classes defined in this schema has its own optional
("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 policy, and thus by
inheritance in all of its subclasses. In X.500, commonName typically
functions as an RDN attribute, for naming instances of such classes as
X.500's person.
Finally, for implementations that expect to map between native CIM and
LDAP representations of policy information, a second MAY attribute,
orderedCimKeys, is inherited from the class dlm1ManagedElement,
defined in reference [10], into the abstract class "policy". The
value of this attribute is derived algorithmically from values that
are already present in a CIM policy instance. See the appendix of
this document for a complete description of the algorithm.
Each of the Core Schema classes thus has three attributes suitable for
naming: cn, its own class-specific attribute, and orderedCimKeys. Any
of these attributes MAY be used for naming an instance of a Core
Schema class. Consequently, implementations MUST be able to
accommodate instances named in any of these ways.
Note that cn, the class-specific naming attribute, and orderedCimKeys
SHOULD NOT be used together to form a multi-part RDN, since support
for multi-part RDNs is limited among existing directory
implementations.
4.3. 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. There is no inherent difference between a rule-
specific condition or action and a reusable one. There are, however,
differences in how they are treated in a policy repository. For
example, it's natural to make the access permissions for a rule-
specific condition or action identical to those for the rule itself.
It's also natural for a rule-specific condition or action to be
removed from the policy repository at the same time the rule is. With
reusable conditions and actions, on the other hand, access permissions
Strassner, et al. Expires: September 2001 [Page 10]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
and existence criteria must be expressible without reference to a
policy rule.
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.
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.
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 pointers to the structural
classes CA and AB that appear below it in the DIT. At first glance it
might appear that these DN pointers 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.
With the use of DN pointers, many (but not all) of these risks are
eliminated.
Note that the existence dependency of a rule-specific condition or
action on its policy rule follows in this case from the semantics of
DNs. Note also that for directory implementations supporting subtree-
based access permissions, it's easy to indicate that parties with
access to Rule1 also have access to its condition and action.
Strassner, et al. Expires: September 2001 [Page 11]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
+-----+
|Rule1|
| |
+-----|- -|-----+
| +-----+ |
| * * |
| * * |
| **** **** |
| * * |
v * * v
+--------+ +--------+
| CA+ca | | AB+ab |
+--------+ +--------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN pointer |
+------------------------------+
Figure 4. Rule-Specific Policy Conditions and Actions
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 "complex".
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 point to its validity periods with the
policyRuleValidityPeriodList 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:
o All conditions are ANDed together. This combination can be
represented in two ways in the DNF / CNF 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
Strassner, et al. Expires: September 2001 [Page 12]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
the representation for the ANDed conditions in a simple policy
rule.
o 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.
+-----------+
|Rule1+ca+ab|
| |
+-----------+
+------------------------------+
|LEGEND: |
| + auxiliary attachment |
+------------------------------+
Figure 5. A Simple Policy Rule
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 to themselves, CA and AB now contain DN pointers 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 policyRepository. Because they are named under
an instance of policyRepository, ca and ab are clearly identified as
reusable.
The structural classes CIA and AIB in Figure 6 may either be instances
of the generic class policyInstance (defined in Section 5.11).
Strassner, et al. Expires: September 2001 [Page 13]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
+-----+ +-------------+
|Rule1| | RepositoryX |
+-|- -|--+ | |
| +-----+ | +-------------+
| * * | * *
| * * | * *
| *** **** | * *
| * * v * *
| * +---+ * *
| * |AB | +------+ *
v * | -|-------->|AIB+ab| *
+---+ +---+ +------+ *
|CA | +------+
| -|------------------------>|CIA+ca|
+---+ +------+
+------------------------------+
|LEGEND: |
| ***** DIT containment |
| + auxiliary attachment |
| ----> DN pointer |
+------------------------------+
Figure 6. Reusable Policy Conditions and Actions
The classes policyConditionAuxClass and policyActionAuxClass do not
themselves represent actual conditions and actions: these are
introduced in their subclasses. What policyConditionAuxClass and
policyActionAuxClass do introduce are the semantics of being a policy
condition or a policy action. These are the semantics that all the
subclasses of policyConditionAuxClass and policyActionAuxClass
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 policyConditionAuxClass and policyActionAuxClass MUST
also be auxiliary classes.
4.4. Location and Retrieval of Policy Objects in the Directory
When a PDP goes to an LDAP directory to retrieve the policy object
instances relevant to the PEPs it serves, it is faced with two related
problems:
o How does it locate and retrieve the directory entries that apply to
its PEPs? These entries may include instances of the Core Schema
classes, instances of domain-specific subclasses of these classes,
and instances of other classes modeling such resources as user
groups, interfaces, and address ranges.
Strassner, et al. Expires: September 2001 [Page 14]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
o 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 Core Schema 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 pointer to | | DN pointers to subtrees +---+
starting object +-----+ +------------------------->| C |
| o--+----+ +---+ +---+
| o--+------------->| B | / \
+-----+ +---+ / \
/ \ / \ / ... \
/ \ / \
/ \ / ... \
Figure 7. Using policySubtreesPtrAuxClass to Locate Policies
The PDP is configured initially with a DN pointer to some entry in the
DIT. The structural class of this entry is not important; the PDP is
interested only in the policySubtreesPtrAuxClass attached to it. This
auxiliary class contains a multi-valued attribute with DN pointers to
objects that anchor subtrees containing policy-related objects of
interest to the PDP. Since policySubtreesPtrAuxClass 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.
Strassner, et al. Expires: September 2001 [Page 15]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
Once it has retrieved the DN pointers, 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 = "policy".
Since all classes representing policy rules, policy conditions, and
policy actions, both in the Core Schema 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 pointed to by a subclass of policyActionAuxClass
representing the DHCP action "assign from this address range), the
auxiliary class policyElementAuxClass can be used to "tag" an entry,
so that it will be found by the selection criterion "object class =
policy".
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 policyKeywords attribute.
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 policyKeywords attribute defined in
the policy class. This attribute supports both standardized and
administrator-defined values. Thus 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
pointer points, 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 = policy",
presence of the keyword "POLICY", or presence of a more specific
policyKeyword.
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 these
objects, with exactly three LDAP requests: one to its starting object
A to get the pointers 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 pointers
locally to understand the semantic relationships among them. The PDP
Strassner, et al. Expires: September 2001 [Page 16]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
should also be prepared to find a pointer to another subtree attached
to any of the objects it retrieves, and to follow this pointer first,
before it follows any of the semantically significant pointers 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 pointer from the subtree under C to an
object D that roots the subtree of corporate-level policies.
Since a PDP has no guarantee that the entity that populates the
directory won't use the policySubtreesPtrAuxClass, a PDP SHOULD
understand this class, SHOULD be capable of retrieving and processing
the entries in the subtrees it points to, 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
policySubtreesPtrAuxClass. 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
policySubtreesPtrAuxClass entries and their DN pointers.
4.4.1. Aliases and Other DIT-Optimization Techniques
Additional flexibility in DIT structure is available to the policy
administrator via LDAP aliasing. Figure 8 illustrates this
flexibility.
+-----+
---------------->| A |
DN pointer to | | DN pointers to subtrees +---+
starting object +-----+ +------------------------->| C |
| o--+----+ +---+ +---+
| o--+------------->| B | / \
+-----+ +---+ / \
/ \ / \ / ... \
/ \ / \
/ \ / \
+---+ / +------+ \
| X |<***************************|aliasX|
+---+ +------+
Figure 8. Addition of an Alias Object
Even if it is necessary to store a policy entry X in a directory
location separate from the other policy entries, batch retrieval using
Strassner, et al. Expires: September 2001 [Page 17]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
policy subtrees can still be done. The administrator simply inserts
into one of the subtrees of policy entries an alias entry aliasX
pointing to the outlying entry X. When the PDP requests all entries
in the subtree under B, a response will be returned for entry X, just
as responses are returned for all the (non-alias) entries that
actually are in the subtree.
Since resolution of an alias to its true entry is handled entirely by
the LDAP directory, and is invisible to directory clients, PDPs need
not do anything extra to support aliases. A Policy Management Tool
MAY make available to a policy administrator the ability to create
alias entries like the one in Figure 7.
In addition to aliases, there are several other techniques for
managing the placement of entries in the DIT and their retrieval by
directory clients. Among these other techniques are referrals, LDAP
URLs, and attributes like seeAlso. Discussion of how these other
techniques might be applied to policy-related entries in a directory
is outside the scope of this document.
5. Class Definitions
The semantics for the LDAP classes mapped directly from the
information model are detailed in reference [1]. Consequently, all
that this document presents for these classes is a bare specification
of the LDAP classes and attributes. More details are provided for the
attributes listed above in Figure 3, which realize in LDAP the
relationships defined in the information model. Finally, the classes
that exist only in the LDAP Core Schema are documented fully in this
document.
The formal language for specifying the classes, attributes, and DIT
structure and content rules is that defined in reference [2].
Note: all attribute, object class, and name form OIDs, and all
structure rule integers, are place holders, and syntax OIDs in
definitions have been replaced by names for clarity.
5.1. The Abstract Class "policy"
The abstract class "policy" is a direct mapping of the abstract class
Policy from the Core Information Model. The five properties in
Policy, three of which are inherited from the class
dlm1ManagedElement, map directly to attributes in the class "policy".
See reference [10] for the definition of the LDAP class
dlm1ManagedElement.
The class value "policy" 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 policyElementAuxClass.
Strassner, et al. Expires: September 2001 [Page 18]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
The class definition is as follows:
( <oid-oc1> NAME 'policy'
DESC 'An abstract class with five attributes for describing
a policy-related instance. The attributes dlmCaption,
dlmDescription, and orderedCimKeys are inherited from
dlm1ManagedElement.'
SUP dlm1ManagedElement
ABSTRACT
MAY ( cn $ policyKeywords )
)
The three attributes dlmCaption, dlmDescription, and orderedCimKeys
are defined in reference [10]. The attribute cn is defined in RFC
2256 [11]. The remaining attribute, policyKeywords, is defined as
follows:
( <oid-at3> NAME 'policyKeywords'
DESC 'A set of keywords to assist directory clients in
locating the policy objects applicable to them. Each
value of the multi-valued attribute contains a single
keyword. Standard keyword values are listed in the
Policy Core Information Model document.
This value is a Directory String.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
5.2. The Three policyGroup Classes
The information model defines a policyGroup class to serve as a
generalized aggregation container. It enables policyRules and
policyGroups to be aggregated in the same container. The LDAP schema
maps this class into three LDAP classes. The class definitions for the
three policyGroup classes are as follows. Note that these class
definitions do not include attributes to realize the
PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from
the object model, since a policyGroup object points to instances of
policyGroup and policyRule via, respectively, the pointer in
policyGroupContainmentAuxClass and the pointer in
policyRuleContainmentAuxClass.
To maximize flexibility, the policyGroup class is defined as abstract.
A subclass policyGroupAuxClass provides for auxiliary attachment to
another entry, while a structural subclass policyGroupInstance is
available to represent a policy group as a standalone entry.
( <oid-oc2> NAME 'policyGroup'
DESC 'A container for either a set of related policyRules or
a set of related policyGroups. A policyGroup may also
Strassner, et al. Expires: September 2001 [Page 19]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
contain a mixture of policyRules and other
policyGroups.'
SUP policy
ABSTRACT
MAY ( policyGroupName )
)
( <oid-oc21> NAME 'policyGroupAuxClass'
DESC 'A container for either a set of related policyRules or
a set of related policyGroups. A policyGroup may also
contain a mixture of policyRules and other
policyGroups.'
SUP policyGroup
AUXILIARY
)
( <oid-oc22> NAME 'policyGroupInstance'
DESC 'A container for either a set of related policyRules or
a set of related policyGroups. A policyGroup may also
contain a mixture of policyRules and other
policyGroups.'
SUP policyGroup
STRUCTURAL
)
The following DIT content rule indicates that an instance of
policyGroupInstance may have attached to it either DN pointers to one
or more other policyGroups, or DN pointers to one or more policyRules.
( <oid-oc23>
NAME 'policyGroupContentRule'
DESC 'shows what auxiliary classes go with this object'
AUX ( policyGroupContainmentAuxClass $
policyRuleContainmentAuxClass )
)
The following DIT structure rules indicate that an instance of
policyGroupInstance may be named under any superior, using any of its
three naming attributes.
NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule
are named within the scope of ("are weak to" in the CIM jargon) an
instance of the CIM class System, or one of its subclasses. The most
natural way to map a weak relationship of this type is to map it to
DIT structure rules specifying that an instance of policyGroupInstance
or policyRuleInstance is subordinate to an object representing a CIM
System. Since, however, the mapping of CIM's System class to an LDAP
class falls outside the scope of this document, the DIT structure
rules that follow do not constrain the superiors under which an
instance of policyGroupInstance may be named.
( <oid-nf1> NAME 'policyGroupNameForm1'
Strassner, et al. Expires: September 2001 [Page 20]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
OC policyGroupInstance
MUST ( cn )
)
( <sr1> NAME 'policyGroupStructuralRule1'
FORM policyGroupNameForm1
)
( <oid-nf2> NAME 'policyGroupNameForm2'
OC policyGroupInstance
MUST ( policyGroupName )
)
( <sr2> NAME 'policyGroupStructuralRule2'
FORM policyGroupNameForm2
)
( <oid-nf15> NAME 'policyGroupNameForm3'
OC policyGroupInstance
MUST ( orderedCimKeys )
)
( <sr15> NAME 'policyGroupStructuralRule3'
FORM policyGroupNameForm3
)
The one attribute of policyGroup is defined as:
( <oid-at4> NAME 'policyGroupName'
DESC 'The user-friendly name of this policy group.
This value is a Directory String.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.3. The Three policyRule Classes
The information model defines a policyRule class to represent the "If
Condition then Action" semantics associated with a policy. For
maximum flexibility, the LDAP schema maps this class into three LDAP
classes.
The conditions and actions associated with a policy rule are modeled,
respectively, with auxiliary subclasses of the auxiliary classes
policyConditionAuxClass and policyActionAuxClass. Each of these
auxiliary subclasses is attached to an instance of one of two
structural classes. A subclass of policyConditionAuxClass is attached
either to an instance of policyRuleConditionAssociation or to an
instance of policyInstance. Similarly, a subclass of
Strassner, et al. Expires: September 2001 [Page 21]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
policyActionAuxClass is attached either to an instance of
policyRuleActionAssociation or to an instance of policyInstance.Of the
nine attributes in the policyRule class, eight are mapped directly
from corresponding properties in the information model. The ninth
attribute, policyRuleValidityPeriodList, realizes the
PolicyRuleValidityPeriod association from the information model.
Since this association has no additional properties besides those that
tie the association to its associated objects, the attribute
policyRuleValidityPeriodList is simply a multi-valued DN pointer.
(Relationships in the information model can have additional properties
because CIM represents relationships as classes. See Sections 5.4 and
5.5 for examples of additional properties and how they are mapped to
LDAP.) This attribute provides an unordered set of DN pointers to one
or more instances of the ptpConditionAuxClass, 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 ptpConditionAuxClass instances
pointed to by this attribute.
The PolicyConditionInPolicyRule and PolicyActionInPolicyRule
associations, however, have additional properties:
PolicyActionInPolicyRule has an integer to sequence the actions, and
PolicyConditionInPolicyRule has an integer to group the conditions,
and a Boolean to specify whether a condition is to be negated. In the
Core Schema, these additional association properties are represented
as attributes of two classes introduced specifically to model the
associations: policyRuleConditionAssociation and
policyRuleActionAssociation, defined, respectively, in Sections 5.4
and 5.5. Thus they do not appear as attributes of the class
policyRule.
To maximize flexibility, the policyRule class is defined as abstract.
A subclass policyRuleAuxClass provides for auxiliary attachment to
another entry, while a structural subclass policyRuleInstance is
available to represent a policy rule as a standalone entry.
The class definitions for the three policyRule classes are as follows:
( <oid-oc3> NAME 'policyRule'
DESC 'The central class for representing the "If Condition
then Action" semantics associated with a policy rule.'
SUP policy
ABSTRACT
MAY ( policyRuleName $ policyRuleEnabled $
policyRuleConditionListType $
policyRuleConditionList $ policyRuleActionList $
policyRuleValidityPeriodList $ policyRuleUsage $
policyRulePriority $ policyRuleMandatory $
policyRuleSequencedActions $ policyRoles )
)
( <oid-oc31> NAME 'policyRuleAuxClass'
Strassner, et al. Expires: September 2001 [Page 22]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
DESC 'The central class for representing the "If Condition
then Action" semantics associated with a policy rule.'
SUP policyRule
AUXILIARY
)
( <oid-oc33> NAME 'policyRuleInstance'
DESC 'The central class for representing the "If Condition
then Action" semantics associated with a policy rule.'
SUP policyRule
STRUCTURAL
)
The following DIT content rule indicates that an instance of
policyRuleInstance may have attached to it the auxiliary classes
policyConditionAuxClass and policyActionAuxClass, or one of their
subclasses. This combination represents a simple policy rule.
( <oid-oc32>
NAME 'policyRuleContentRule'
DESC 'shows what auxiliary classes go with this object'
AUX ( policyConditionAuxClass $ policyActionAuxClass )
)
The following DIT structure rules indicate that an instance of
policyRuleInstance may be named under any superior, using any of its
three naming attributes.
NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule
are named within the scope of ("are weak to" in the CIM jargon) an
instance of the CIM class System, or one of its subclasses. The most
natural way to map a weak relationship of this type is to DIT
structure rules specifying that an instance of policyGroupInstance or
policyRuleInstance is subordinate to an object representing a CIM
System. Since, however, the mapping of CIM's System class to an LDAP
class falls outside the scope of this document, the DIT structure
rules that follow do not constrain the superiors under which an
instance of policyRuleInstance may be named.
( <oid-nf3> NAME 'policyRuleNameForm1'
OC policyRuleInstance
MUST ( cn )
)
( <sr3> NAME 'policyRuleStructuralRule1'
FORM policyRuleNameForm1
)
( <oid-nf4> NAME 'policyRuleNameForm2'
OC policyRuleInstance
MUST ( policyRuleName )
Strassner, et al. Expires: September 2001 [Page 23]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
)
( <sr4> NAME 'policyRuleStructuralRule2'
FORM policyRuleNameForm2
)
( <oid-nf16> NAME 'policyRuleNameForm3'
OC policyRuleInstance
MUST ( orderedCimKeys )
)
( <sr16> NAME 'policyRuleStructuralRule3'
FORM policyRuleNameForm3
)
The attributes of policyRule are defined as follows:
( <oid-at5> NAME 'policyRuleName'
DESC 'The user-friendly name of this policy rule.
This value is a Directory String'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
( <oid-at6> NAME 'policyRuleEnabled'
DESC 'An enumeration indicating whether a policy rule is
administratively enabled, administratively disabled, or
enabled for debug mode. The defined values for this
attribute are enabled(1), disabled(2), and
enabledForDebug(3).
This value is an INTEGER enumeration.'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
( <oid-at7> NAME 'policyRuleConditionListType'
DESC 'Indicates whether the list of policy conditions
associated with this policy rule is in disjunctive
normal form (DNF) or conjunctive normal form (CNF).
Defined values are DNF(1) and CNF(2).
This value is an INTEGER enumeration.'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
( <oid-at36> NAME 'policyRuleConditionList'
DESC 'Distinguished names of policyRuleConditionAssociation
Strassner, et al. Expires: September 2001 [Page 24]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
entries representing associations between this policy
rule and its conditions. No order is implied.
These values are Distinguished Names (DNs).'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)
( <oid-at37> NAME 'policyRuleActionList'
DESC 'Distinguished names of policyRuleActionAssociation
entries representing associations between this policy
rule and its actions. No order is implied.
These values are Distinguished Names (DNs).'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)
( <oid-at8> NAME 'policyRuleValidityPeriodList'
DESC 'Distinguished names of policyRuleValidityAssociation
entries that
determine when the policyRule is scheduled to be active
/ inactive. No order is implied.
These values are Distinguished Names (DNs).'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)
( <oid-at9> NAME 'policyRuleUsage'
DESC 'This attribute is a free-form string providing
guidelines on how
this policy should be used.
This value is a Directory String.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
( <oid-at10> NAME 'policyRulePriority'
DESC 'A non-negative integer for prioritizing this policyRule
relative to other policyRules. A larger value indicates
a higher priority.
This value is an INTEGER.'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
Strassner, et al. Expires: September 2001 [Page 25]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
( <oid-at11> NAME 'policyRuleMandatory'
DESC 'A flag indicating that the evaluation of the
policyConditions and execution of policyActions (if the
condition list evaluates to True) is required.
This value is a Boolean.'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
)
( <oid-at12> NAME 'policyRuleSequencedActions'
DESC 'An enumeration indicating how to interpret the action
ordering indicated via the policyActionOrder
attribute. The defined values for this attribute are
mandatory(1), recommended(2), and dontCare(3).
This value is an INTEGER enumeration.'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
( <oid-at38> NAME 'policyRoles'
DESC 'Each value of this attribute represents a role
combination, including the special case of a
"combination" containing only one role. Since this
is a multi-valued attribute, more than one role
combination can be associated with a single policy
rule. Each value is a string of the form
<RoleName>[&&<RoleName>]*
where the individual role names appear in alphabetical
order according to the collating sequence for UCS-2.
These values are Directory Strings.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
The two matching rules for policyRoles support two different
approaches that a PDP might take to the task of retrieving policyRules
for its PEPs based on the roles they have reported to it. Suppose,
for example, that a PEP has reported that it is interested in
policyRules 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. These queries will get all of the
policyRules that apply to the PEP, but they may also get some that do
not apply, for example, ones for the role combination "R1&&R4".
Strassner, et al. Expires: September 2001 [Page 26]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
Another strategy would be for the PDP to use only equality filters.
This approach eliminates the extraneous replies, but it requires the
PDP to build the role combinations ("R1&&R2", "R1&&R3", etc.) itself,
and it 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.
By having the two matching rules for policyRoles, the PCLS leaves to
each PDP the choice of which of these approaches use.
5.4. The Class policyRuleConditionAssociation
This class contains attributes to represent the properties of the
information model's PolicyConditionInPolicyRule association.
Instances of this class are related to an instance of policyRule via
DIT containment. The policy conditions themselves are represented by
auxiliary subclasses of the auxiliary class policyConditionAuxClass.
These auxiliary classes are attached directly to instances of
policyRuleConditionAssociation for rule-specific policy conditions.
For a reusable policy condition, the auxiliary class is attached to an
instance of the class policyInstance, and there is a DN pointer to
this instance from the instance of policyRuleConditionAssociation.
The class definition is as follows:
( <oid-oc4> NAME 'policyRuleConditionAssociation'
DESC 'The class contains attributes characterizing the
relationship between a policy rule and one of its
policy conditions.'
SUP policy
MUST ( policyConditionGroupNumber $ policyConditionNegated )
MAY ( policyConditionName $ policyConditionDN )
)
The following DIT content rule indicates that an instance of
policyRuleConditionAssociation may have attached to it the auxiliary
class policyConditionAuxClass, or one of its subclasses. This
combination represents a rule-specific policy condition.
( <oid-oc24>
NAME
'prcAssociationContentRule'
DESC 'shows what auxiliary classes go with this object'
AUX ( policyConditionAuxClass )
)
The following DIT structure rules indicate that an instance of
policyRuleConditionAssociation may be named under an instance of
policyRule, where each of these instances may be named using any of
their three naming attributes.
Strassner, et al. Expires: September 2001 [Page 27]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
( <oid-nf5> NAME
'prcAssociationNameForm1'
OC policyRuleConditionAssociation
MUST ( cn )
( <sr5> NAME
'prcAssociationStructureRule1'
FORM prcAssociationNameForm1
SUP <sr3> <sr4> <sr16>
)
( <oid-nf6> NAME
'prcAssociationNameForm2'
OC policyRuleConditionAssociation
MUST ( policyConditionName )
)
( <sr6> NAME
'prcAssociationStructureRule2'
FORM prcAssociationNameForm2
SUP <sr3> <sr4> <sr16>
)
( <oid-nf17> NAME
'prcAssociationNameForm3'
OC policyRuleConditionAssociation
MUST ( orderedCimKeys )
)
( <sr17> NAME
'prcAssociationStructureRule3'
FORM prcAssociationNameForm3
SUP <sr3> <sr4> <sr16>
)
The attributes of policyRuleConditionAssociation are defined as
follows.
( <oid-at13>
NAME 'policyConditionName'
DESC 'A user-friendly name for a policy condition.
This value is a Directory String.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
( <oid-at14>
NAME 'policyConditionGroupNumber'
DESC 'The number of the group to which a policy condition
belongs. These groups are used to form the DNF or
Strassner, et al. Expires: September 2001 [Page 28]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
CNF expression associated with a policy rule.
This value is an INTEGER.'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
( <oid-at15>
NAME 'policyConditionNegated'
DESC 'Indicates whether a policy condition is negated in
the DNF or CNF expression associated with a policy
rule. The value TRUE indicates that a condition is
negated
This value is a Boolean.'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
)
( <oid-at16>
NAME 'policyConditionDN'
DESC 'A DN pointer to a reusable policy condition.
This value is a Distinguished Name (DN).'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE
)
5.5. The Class policyRuleValidityAssociation
The policyRuleValidityPeriod aggregation is mapped to the
policyRuleValidityAssociation class, which is defined below:
( <oid-oc71> NAME 'policyRuleValidityAssociation'
DESC '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, ptpConditionAuxClass, or are referenced through
the policyTimePeriodConditionDN attribute.'
SUP policy
STRUCTURAL
MAY (policyValidityConditionName $
policyTimePeriodConditionDN)
)
The following DIT content rule indicates that an instance of
policyRuleValidityAssociation may have attached to it the auxiliary
Strassner, et al. Expires: September 2001 [Page 29]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
class ptpConditionAuxClass, or one of its subclasses. This
combination represents a policy validity period.
( <oid-oc34>
NAME 'prvAssociationContentRule'
DESC 'shows what auxiliary classes go with this object'
AUX ( ptpConditionAuxClass )
)
The following DIT structure rules indicate that an instance of
policyRuleValidityAssociation may be named under an instance of
policyRule, where each of these instances may be named using any of
their three naming attributes.
( <oid-nf40> NAME 'prvAssociationNameForm1'
OC policyRuleValidityAssociation
MUST ( cn )
( <sr40> NAME 'prvAssociationStructureRule1'
FORM prvAssociationNameForm1
SUP <sr3> <sr4> <sr16>
)
( <oid-nf41> NAME 'prvAssociationNameForm2'
OC policyRuleValidityAssociation
MUST ( policyConditionName )
)
( <sr41> NAME 'prvAssociationStructureRule2'
FORM prvAssociationNameForm2
SUP <sr3> <sr4> <sr16>
)
( <oid-nf42> NAME 'prvAssociationNameForm3'
OC policyRuleValidityAssociation
MUST ( orderedCimKeys )
)
( <sr42> NAME 'prvAssociationStructureRule3'
FORM prvAssociationNameForm3
SUP <sr3> <sr4> <sr16>
)
The attributes of policyRuleValidityAssociation are defined as
follows.
( <oid-at50>
NAME 'policyValidityConditionName'
DESC 'A user-friendly name for expressing the times that a
policy rule is active.
This value is a Directory String.'
Strassner, et al. Expires: September 2001 [Page 30]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
( <oid-at51>
NAME 'policyTimePeriodConditionDN'
DESC 'A DN pointer to a reusable policy time period
condition.
This value is a Distinguised Name (DN).
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE
)
5.6. The Class policyRuleActionAssociation
This class contains an attribute to represent the one property of the
information model's PolicyActionInPolicyRule association, which makes
it possible to specify an order for executing the actions associated
with a policy rule. Instances of this class are related to an
instance of policyRule via DIT containment. The actions themselves
are represented by auxiliary subclasses of the auxiliary class
policyActionAuxClass. These auxiliary classes are attached directly
to instances of policyRuleActionAssociation for rule-specific policy
actions. For a reusable policy action, the auxiliary class is
attached to an instance of the class policyInstance, and there is a DN
pointer to this instance from the instance of
policyRuleActionAssociation.
The class definition is as follows:
( <oid-oc5> NAME 'policyRuleActionAssociation'
DESC 'The class contains an attribute that represents an
execution order for an action in the context of a
policy rule.'
SUP policy
MUST ( policyActionOrder )
MAY ( policyActionName $ policyActionDN )
)
The following DIT content rule indicates that an instance of
policyRuleActionAssociation may have attached to it the auxiliary
class policyActionAuxClass, or one of its subclasses. This
combination represents a rule-specific policy action.
( <oid-oc25>
Strassner, et al. Expires: September 2001 [Page 31]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
NAME
'praAssociationContentRule'
DESC 'shows what auxiliary classes go with this object'
AUX ( policyActionAuxClass )
)
The following DIT structure rules indicate that an instance of
policyRuleActionAssociation may be named under an instance of
policyRule, where each of these instances may be named using any of
their three naming attributes.
( <oid-nf7> NAME
'praAssociationNameForm1'
OC policyRuleActionAssociation
MUST ( cn )
)
( <sr7> NAME
'praAssociationStructuralRule1'
FORM praAssociationNameForm1
SUP <sr3> <sr4> <sr16>
)
( <oid-nf8> NAME
'praAssociationNameForm2'
OC policyRuleActionAssociation
MUST ( policyActionName )
)
( <sr8> NAME
'praAssociationStructuralRule2'
FORM praAssociationNameForm2
SUP <sr3> <sr4> <sr16>
)
( <oid-nf18> NAME
'praAssociationNameForm3'
OC policyRuleActionAssociation
MUST ( orderedCimKeys )
)
( <sr18> NAME
'praAssociationStructuralRule3'
FORM praAssociationNameForm3
SUP <sr3> <sr4> <sr16>
)
The attributes of policyRuleActionAssociation are defined as follows.
( <oid-at17>
NAME 'policyActionName'
DESC 'A user-friendly name for a policy action.
Strassner, et al. Expires: September 2001 [Page 32]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
This value is a Directory String.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
( <oid-at33>
NAME 'policyActionOrder'
DESC 'An integer indicating the relative order of an action
in the context of a policy rule.
This value is an INTEGER.'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
( <oid-at34>
NAME 'policyActionDN'
DESC 'A DN pointer to a reusable policy action.
This value is a Distinguished Name (DN).'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE
)
5.7. The Auxiliary Class policyConditionAuxClass
The purpose of a policy condition is to determine whether or not the
set of actions (contained in the policyRule that the condition applies
to) should be executed or not. This auxiliary class can be attached
to instances of three other classes in the Core Policy Schema. When
it is attached to an instance of policyRuleConditionAssociation, or to
an instance of policyRule, it represents a rule-specific policy
condition. When it is attached to an instance of policyInstance, it
represents a reusable policy condition.
Since all of the classes to which this auxiliary class may be attached
are derived from "policy", the attributes of "policy" will already be
defined for the entries to which this class attaches. Thus this class
is derived directly from "top".
The class definition is as follows:
( <oid-oc6> NAME 'policyConditionAuxClass'
DESC 'A class representing a condition to be evaluated in
conjunction with a policy rule.'
SUP top
Strassner, et al. Expires: September 2001 [Page 33]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
AUXILIARY
)
5.8. The Auxiliary Class ptpConditionAuxClass
The information model 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 information model, this class is named
PolicyTimePeriodCondition. However, the resulting name of the
auxiliary class in this mapping (policyTimePeriodConditionAuxClass)
exceeds the length of a name that some directories can store.
Therefore, we have shortened the name to ptpConditionAuxClass.
The class definition is as follows.
( <oid-oc7> NAME 'ptpConditionAuxClass'
DESC 'A class that provides the capability of enabling /
disabling a policy rule according to a predetermined
schedule.'
SUP policyConditionAuxClass
AUXILIARY
MAY ( ptpConditionTime $ ptpConditionMonthOfYearMask $
ptpConditionDayOfMonthMask $ ptpConditionDayOfWeekMask $
ptpConditionTimeOfDayMask $ ptpConditionLocalOrUtcTime )
)
The attributes of ptpConditionAuxClass are defined as follows. Note
that several of the attributes are defined as bit strings of various
fixed lengths. These attributes correspond to CIM properties that
include four-octet length fields prior to their semantically
significant bits. Since these length fields are unnecessary in LDAP,
they are not included in the bit string attributes defined in this
document.
( <oid-at19>
NAME 'ptpConditionTime'
DESC 'The range of calendar dates on which a policy rule is
valid. The format of the string is
yyyymmddThhmmss/yyyymmddThhmmss, where the first
date/time may be replaced with the string
"THISANDPRIOR" or the second date/time may be replaced
with the string "THISANDFUTURE".
This value is a Printable String.'
EQUALITY caseIgnoreMatch
Strassner, et al. Expires: September 2001 [Page 34]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
SINGLE-VALUE
)
( <oid-at20>
NAME 'ptpConditionMonthOfYearMask'
DESC 'A 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.'
EQUALITY bitStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
SINGLE-VALUE
)
( <oid-at21>
NAME 'ptpConditionDayOfMonthMask'
DESC '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.'
EQUALITY bitStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
SINGLE-VALUE
)
( <oid-at22>
NAME 'ptpConditionDayOfWeekMask'
DESC '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.'
EQUALITY bitStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
SINGLE-VALUE
)
( <oid-at23>
NAME 'ptpConditionTimeOfDayMask'
DESC '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.
This value is a Printable String.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
SINGLE-VALUE
Strassner, et al. Expires: September 2001 [Page 35]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
)
( <oid-at24>
NAME 'ptpConditionLocalOrUtcTime'
DESC 'An indication of whether the other times in this
instance represent local times or UTC times. The
defined values for this attribute are localTime(1)
and utcTime(2).
This value is an INTEGER enumeration.'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
)
5.9. The Auxiliary Class vendorPolicyConditionAuxClass
The class definition is as follows:
( <oid-oc8> NAME 'vendorPolicyConditionAuxClass'
DESC 'A class that defines a registered means to describe a
policy condition.'
SUP policyConditionAuxClass
AUXILIARY
MAY ( vendorPolicyConstraintData $
vendorPolicyConstraintEncoding )
)
The attribute definitions for vendorPolicyConditionAuxClass are as
follows:
( <oid-at25>
NAME 'vendorPolicyConstraintData'
DESC 'Escape mechanism for representing constraints that have
not been modeled as specific attributes. The format of
the values is identified by the OID stored in the
attribute vendorPolicyConstraintEncoding.
This value is an Octet String.'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
)
( <oid-at26>
NAME 'vendorPolicyConstraintEncoding'
DESC 'An OID identifying the format and semantics for this
InstanceÆs vendorPolicyConstraintData attribute.'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE
)
Strassner, et al. Expires: September 2001 [Page 36]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
5.10. The Auxiliary Class policyActionAuxClass
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 auxiliary class can be
attached to instances of three other classes in the Core Policy
Schema. When it is attached to an instance of
policyRuleActionAssociation, or to an instance of policyRule, it
represents a rule-specific policy action. When it is attached to an
instance of policyInstance, it represents a reusable policy action.
Since all of the classes to which this auxiliary class may be attached
are derived from "policy", the attributes of "policy" will already be
defined for the entries to which this class attaches. Thus this class
is derived directly from "top".
The class definition is as follows:
( <oid-oc9> NAME 'policyActionAuxClass'
DESC 'A class representing an action to be performed as a
result of a policy rule.'
SUP top
AUXILIARY
)
5.11. The Auxiliary Class vendorPolicyActionAuxClass
The class definition is as follows:
( <oid-oc10> NAME 'vendorPolicyActionAuxClass'
DESC 'A class that defines a registered means to describe a
policy action.'
SUP policyActionAuxClass
AUXILIARY
MAY ( vendorPolicyActionData $ vendorPolicyActionEncoding )
)
The attribute definitions for vendorPolicyActionAuxClass are as
follows:
( <oid-at28>
NAME 'vendorPolicyActionData'
DESC 'Escape mechanism for representing actions that have not
been modeled as specific attributes. The format of the
values is identified by the OID stored in the attribute
vendorPolicyActionEncoding.
This value is an Octet String.'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
)
Strassner, et al. Expires: September 2001 [Page 37]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
( <oid-at29>
NAME 'vendorPolicyActionEncoding'
DESC 'An OID identifying the format and semantics for this
InstanceÆs vendorPolicyActionData attribute.'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE
)
5.12. The Class policyInstance
The role of this class in the Core Schema 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 Sections 5.12
and 5.13. See Section 4.3 for a complete discussion of reusable
policy conditions and actions, and of the role that this class plays
in how they are represented.
In addition to the cn attribute it inherits from "policy", this class
uses the class-specific naming attribute policyInstanceName.
The class definition is as follows:
( <oid-oc18> NAME 'policyInstance'
DESC 'A structural class that contains reusable policy
information.'
SUP policy
MAY ( policyInstanceName )
)
The following DIT content rule indicates that an instance of
policyInstance may have attached to it instances of the auxiliary
classes policyConditionAuxClass and policyActionAuxClass. Additional
DIT content rules may be defined later, for attachment of other
policy-related auxiliary classes to policyInstance.
( <oid-oc19>
NAME 'policyInstanceContentRule'
DESC 'shows what auxiliary classes go with this class'
AUX ( policyConditionAuxClass $ policyActionAuxClass)
)
The following DIT structure rules indicate that an instance of
policyInstance may be named under an instance of policyRepository,
using any of its three naming attributes.
( <oid-nf22> NAME 'policyInstanceNameForm1'
OC policyInstance
Strassner, et al. Expires: September 2001 [Page 38]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
MUST ( cn )
)
( <sr22 NAME 'policyInstanceStructuralRule1'
FORM policyInstanceNameForm1
SUP <sr13> <sr14> <sr21>
)
( <oid-nf23> NAME 'policyInstanceNameForm2'
OC policyInstance
MUST ( policyInstanceName )
)
( <sr23> NAME 'policyInstanceStructuralRule2'
FORM policyInstanceNameForm2
SUP <sr13> <sr14> <sr21>
)
( <oid-nf24> NAME 'policyInstanceNameForm3'
OC policyInstance
MUST ( orderedCimKeys )
)
( <sr24> NAME 'policyInstanceStructuralRule3'
FORM policyInstanceNameForm3
SUP <sr13> <sr14> <sr21>
)
The one attribute of policyInstance is defined as:
( <oid-at39> NAME 'policyInstanceName'
DESC 'The user-friendly name of this policy instance.
This value is a Directory String.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.13. The Auxiliary Class policyElementAuxClass
This class introduces no additional attributes, beyond those defined
in the class "policy" from which it is derived. Its role is to "tag"
an instance of a class defined outside the realm of policy as being
nevertheless relevant to a policy specification. This tagging can
potentially take place at two levels:
o Every instance to which policyElementAuxClass is attached becomes
an instance of the class "policy", since policyElementAuxClass is a
Strassner, et al. Expires: September 2001 [Page 39]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
subclass of "policy". Thus a DIT search with the filter
"objectClass=policy" 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 keyword "POLICY".)
o With the policyKeywords attribute that it inherits from "policy",
an instance to which policyElementAuxClass is attached can be
tagged as being relevant to a particular type or category of
policy, using standard keywords, administrator-defined keywords, or
both.
The class definition is as follows:
( <oid-oc13> NAME 'policyElementAuxClass'
DESC 'An auxiliary class used to tag instances of classes
defined outside the realm of policy as relevant to a
particular policy specification.'
SUP policy
AUXILIARY
)
5.14. The Three policyRepository Classes
These classes provide a container for reusable policy information,
such as reusable policy conditions and/or reusable policy actions.
They are derived from several classes defined in reference [10]:
top
|
+--dlm1ManagedElement (abstract)
|
+--dlm1ManagedSystemElement (abstract)
|
+--dlm1LogicalElement (abstract)
|
+--dlm1System (abstract)
|
+--dlm1AdminDomain (abstract)
|
+--policyRepository (abstract)
|
+--policyRepositoryAuxClass (auxiliary)
|
+--policyRepositoryInstance (structural)
To maximize flexibility, the policyRepository class is defined as
abstract. A subclass policyRepositoryAuxClass provides for auxiliary
attachment to another entry, while a structural subclass
policyRepositoryInstance is available to represent a policy repository
as a standalone entry.
Strassner, et al. Expires: September 2001 [Page 40]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
The class definitions for the policyRepository classes are as follows:
( <oid-oc17> NAME 'policyRepository'
DESC 'A container for reusable policy information.'
SUP dlm1AdminDomain
ABSTRACT
MAY ( policyRepositoryName )
)
( <oid-oc171> NAME 'policyRepositoryAuxClass'
DESC 'A container for reusable policy information.'
SUP policyRepository
AUXILIARY
)
( <oid-oc172> NAME 'policyRepositoryInstance'
DESC 'A container for reusable policy information.'
SUP policyRepository
STRUCTURAL
)
The following DIT structure rules indicate that an instance of
policyRepositoryInstance may be named under any superior, using any of
its three naming attributes. These DIT structure rules cover, as
special cases, a policyRepositoryInstance that is named within the
scope of another policyRepositoryInstance, or within the scope of an
entry to which policyRepositoryAuxClass is attached. These special
cases represent the mapping for the CIM aggregation
PolicyRepositoryInPolicyRepository.
( <oid-nf13> NAME 'policyRepositoryNameForm1'
OC policyRepositoryInstance
MUST ( cn )
)
( <sr13> NAME 'policyRepositoryStructuralRule1'
FORM policyRepositoryNameForm1
)
( <oid-nf14> NAME 'policyRepositoryNameForm2'
OC policyRepositoryInstance
MUST ( policyRepositoryName )
)
( <sr14> NAME 'policyRepositoryStructuralRule2'
FORM policyRepositoryNameForm2
)
( <oid-nf21> NAME 'policyRepositoryNameForm3'
OC policyRepositoryInstance
MUST ( orderedCimKeys )
Strassner, et al. Expires: September 2001 [Page 41]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
)
( <sr21> NAME 'policyRepositoryStructuralRule3'
FORM policyRepositoryNameForm3
)
The one attribute of policyRepository is defined as follows.
( <oid-at35> NAME 'policyRepositoryName'
DESC 'The user-friendly name of this policy repository.
This value is a Directory String.'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
5.15. The Auxiliary Class policySubtreesPtrAuxClass
This auxiliary class provides a single, multi-valued attribute that
points to 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.
These entries may be placed in the DIT such that a well-known DN can
be used by placing the structural entry (e.g. container) with the
policySubtreesPtrAuxClass attached thereto in the root of the
directory suffix. In this case, the subtree entry point can contain
and/or point to all related policy entries for any well-known policy
disciplines. Similarly, the subtree entry point may be placed in the
DIT such that the PDP's starting point is a subtree with policy-
related entries that are dependent on a hierarchically-related set of
subtrees (e.g., region, division, corporate). In this latter case,
DNs may be provided to the PDPs via SNMP or other techniques.
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.4.
Once the objects have been retrieved, a directory client can determine
the semantic linkages by following DN pointers such as
policyRulesAuxContainedSet locally.
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
Strassner, et al. Expires: September 2001 [Page 42]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
object with these pointers at the same time that it requests the
pointers 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. For example,
policySubtreesPtrAuxClass SHOULD NOT be attached to the partition root
for a large directory partition containing a relatively few policy-
related objects along with a large number of objects unrelated to
policy. A better approach would be to introduce a container object
immediately below the partition root, attach policySubtreesPtrAuxClass
to this container object, and then place the policy-related objects in
the subtree under it.
The class definition is as follows:
( <oid-oc14> NAME 'policySubtreesPtrAuxClass'
DESC 'An auxiliary class providing DN pointers to roots of
DIT subtrees containing policy-related objects.'
SUP top
AUXILIARY
MAY ( policySubtreesAuxContainedSet )
)
5.15.1. The Attribute policySubtreesAuxContainedSet
This attribute provides an unordered set of DN pointers to one or more
objects under which policy-related information is present. The
objects pointed to may or may not themselves contain policy-related
information.
The attribute definition is as follows:
( <oid-at30>
NAME 'policySubtreesAuxContainedSet'
DESC 'Distinguished names of objects that serve as roots for
DIT subtrees containing policy-related objects. No
order is implied.
This value is a Distinguished Name (DN).'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)
5.16. The Auxiliary Class policyGroupContainmentAuxClass
This auxiliary class provides a single, multi-valued attribute that
points to a set of policyGroups. 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
Strassner, et al. Expires: September 2001 [Page 43]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
allows a client to locate and retrieve the policyGroups relevant to
it.
As is the case with policyRules, a policy administrator might have
several different pointers to a policyGroup in the overall directory
structure. The policyGroupContainmentAuxClass is the mechanism that
makes it possible for the policy administrator to define all these
pointers.
The class definition is as follows:
( <oid-oc15> NAME 'policyGroupContainmentAuxClass'
DESC 'An auxiliary class used to bind policyGroups to an
appropriate container object.'
SUP top
AUXILIARY
MAY ( policyGroupsAuxContainedSet )
)
5.16.1. The Attribute policyGroupsAuxContainedSet
This attribute provides an unordered set of DN pointers to one or more
policyGroups associated with the instance of a structural class to
which this attribute has been appended. The attribute definition is
as follows:
( <oid-at31>
NAME 'policyGroupsAuxContainedSet'
DESC 'Distinguished names of policyGroups associated in some
way with the instance to which this attribute has been
appended. No order is implied.
This value is a Distinguished Name (DN).'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)
5.17. The Auxiliary Class policyRuleContainmentAuxClass
This auxiliary class provides a single, multi-valued attribute that
points to a set of policyRules. 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 policyRules relevant to it.
A policy administrator might have several different pointers to a
policyRule in the overall directory structure. For example, there
might be pointers to all policyRules for traffic originating in a
particular subnet from a directory entry that represents that subnet.
At the same time, there might be pointers to all policyRules related
Strassner, et al. Expires: September 2001 [Page 44]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
to a particular DiffServ setting from an instance of a policyGroup
explicitly introduced as a container for DiffServ-related policyRules.
The policyRuleContainmentAuxClass is the mechanism that makes it
possible for the policy administrator to define all these pointers.
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.
The class definition is as follows:
( <oid-oc16> NAME 'policyRuleContainmentAuxClass'
DESC 'An auxiliary class used to bind policyRules to an
appropriate container object.'
SUP top
AUXILIARY
MAY ( policyRulesAuxContainedSet )
)
5.17.1. The Attribute policyRulesAuxContainedSet
This attribute provides an unordered set of DN pointers to one or more
policyRules associated with the instance of a structural class to
which this attribute has been appended. The attribute definition is:
( <oid-at32>
NAME 'policyRulesAuxContainedSet'
DESC 'Distinguished names of policyRules associated in some
way with the instance to which this attribute has been
appended. No order is implied.
This value is a Distinguished Name (DN).'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)
6. Extending the Core Schema
The following subsections provide general guidance on how to create a
domain-specific schema derived from the Core Schema, discuss how the
vendor classes in the Core Schema should be used, and explain how
policyTimePeriodConditions are related to other policy conditions.
6.1. Subclassing policyConditionAuxClass and policyActionAuxClass
In Section 4.3 above, there is a discussion of how, by representing
policy conditions and policy actions as auxiliary classes in a schema,
Strassner, et al. Expires: September 2001 [Page 45]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
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 policyConditionAuxClass and policyActionAuxClass. It is
RECOMMENDED that non-standardized schemata follow this practice as
well.
6.2. Using the Vendor Policy Encoding Attributes
As discussed Section 5.8 "The Class vendorPolicyConditionAuxClass",
the attributes vendorPolicyConstraintData and
vendorPolicyConstraintEncoding are included in
vendorPolicyConditionAuxClass to provide an escape mechanism for
representing "exceptional" policy conditions. The attributes
vendorPolicyActionData and vendorPolicyActionEncoding in
vendorPolicyActionAuxClass class play the same role with respect to
actions. This enables interoperability between different vendors.
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 escape conditions provide a way for vendor-specific
commands to be encoded as OctetStrings, 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 a subclass of
policyConditionAuxClass, called policyTimePeriodCondition. This is to
allow their inclusion in the AND/OR condition definitions for a
policyRule. Care should be taken not to subclass
policyTimePeriodCondition to add domain-specific condition properties.
For example, it would be incorrect to add IPSec- or QoS-specific
condition properties to the policyTimePeriodCondition 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 policyConditionAuxClass and then combine instances of
these domain-specific condition classes with the validity period
criteria. This is accomplished using the AND/OR association
capabilities for policyConditions in policyRules.
7. Security Considerations
The Policy Core LDAP Schema (PCLS), presented in this document,
provides a mapping of the object-oriented model for describing policy
Strassner, et al. Expires: September 2001 [Page 46]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
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 schemas
consistent with the the PCLS schema 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 which 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
Strassner, et al. Expires: September 2001 [Page 47]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
authorization implicit in a requirement that restricts read and/or
read- write access to these values stored in a directory.
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:
o RFC 2829 (Authentication Methods for LDAP)
o 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. 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 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.
9. Acknowledgments
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) Service Level Agreements and
Strassner, et al. Expires: September 2001 [Page 48]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
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. References
[1] Moore, B., and E. Ellesson, J. Strassner, A. Westerinen "Policy
Core Information Model -- Version 1 Specification", RFC 3060,
February 2001.
[2] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
2252, December 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF
Standards Process", BCP 11, RFC 2028, October 1996.
[5] Strassner, J. and S. Judd, "Directory-Enabled Networks", version
3.0c5 (August 1998). A PDF file is available at
http://www.murchiso.com/den/#denspec.
[6] 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.
[7] DMTF web site, http://www.dmtf.org.
[8] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for
Policy-based Admission Control", RFC 2753, January 2000.
[9] Distributed Management Task Force, Inc., "Guidelines for CIM-to-
LDAP Directory Mapping", May 8, 2000. This document is available
on the following DMTF web page: http://www.dmtf.org/spec/denh.html.
[10] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the
CIM v2.4 Core Information Model", November 20, 2000. This document
is available on the following DMTF web page:
http://www.dmtf.org/spec/denh.html.
[11] Wahl, M., " A Summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
11. Authors' Addresses
John Strassner
Strassner, et al. Expires: September 2001 [Page 49]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
Cisco Systems
Building 20
725 Alder Drive
Milpitas, CA 95035
Phone: +1 408-527-1069
Fax: +1 408-527-1722
E-mail: johns@cisco.com
Andrea Westerinen
Cisco Systems
Building 20
725 Alder Drive
Milpitas, CA 95035
Phone: +1-408-853-8294
Fax: +1-408-527-6351
E-mail: andreaw@cisco.com
Ed Ellesson
LongBoard, Inc.
2505 Meridian Pkwy, #100
Durham, NC 27713
Phone: +1 919-361-3230
E-mail: eellesson@lboard.com
Bob Moore
IBM Corporation, BRQA/502
4205 S. Miami Blvd.
Research Triangle Park, NC 27709
Phone: +1 919-254-4436
Fax: +1 919-254-6243
E-mail: remoore@us.ibm.com
Ryan Moats
Coreon, Inc.
15621 Drexel Circle
Omaha, NE 68135
USA
Phone: +1-402-894-9456
E-mail: rmoats@coreon.net
12. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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
Strassner, et al. Expires: September 2001 [Page 50]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
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.
13. Appendix: Constructing the Value of orderedCimKeys
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.
In its mapping from the CIM_ManagedElement class to the LDAP class
dlm1ManagedElement, reference [10] introduces a third attribute,
orderedCimKeys, alongside the two attributes that it derives from the
properties in the CIM class. The orderedCimKeys attribute is used
only in an environment where it is necessary to map between an LDAP-
accessible directory and a CIM repository. For other environments,
LDAP entries are identified via their other attributes that are
suitable for naming.
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:
o 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.
o 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.
Strassner, et al. Expires: September 2001 [Page 51]
Internet Draft draft-ietf-policy-core-schema-10.txt March 2001
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 reference [9].
Strassner, et al. Expires: September 2001 [Page 52]
