]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc3703.txt
Remove many (but not all) references to slurpd(8).
[openldap] / doc / rfc / rfc3703.txt
1
2
3
4
5
6
7 Network Working Group                                       J. Strassner
8 Request for Comments: 3703                        Intelliden Corporation
9 Category: Standards Track                                       B. Moore
10                                                          IBM Corporation
11                                                                 R. Moats
12                                                     Lemur Networks, Inc.
13                                                              E. Ellesson
14                                                            February 2004
15
16
17     Policy Core Lightweight Directory Access Protocol (LDAP) Schema
18
19 Status of this Memo
20
21    This document specifies an Internet standards track protocol for the
22    Internet community, and requests discussion and suggestions for
23    improvements.  Please refer to the current edition of the "Internet
24    Official Protocol Standards" (STD 1) for the standardization state
25    and status of this protocol.  Distribution of this memo is unlimited.
26
27 Copyright Notice
28
29    Copyright (C) The Internet Society (2004).  All Rights Reserved.
30
31 Abstract
32
33    This document defines a mapping of the Policy Core Information Model
34    to a form that can be implemented in a directory that uses
35    Lightweight Directory Access Protocol (LDAP) as its access protocol.
36    This model defines two hierarchies of object classes: structural
37    classes representing information for representing and controlling
38    policy data as specified in RFC 3060, and relationship classes that
39    indicate how instances of the structural classes are related to each
40    other.  Classes are also added to the LDAP schema to improve the
41    performance of a client's interactions with an LDAP server when the
42    client is retrieving large amounts of policy-related information.
43    These classes exist only to optimize LDAP retrievals: there are no
44    classes in the information model that correspond to them.
45
46 Table of Contents
47
48    1.  Introduction .................................................  2
49    2.  The Policy Core Information Model ............................  4
50    3.  Inheritance Hierarchy for the PCLS ...........................  5
51    4.  General Discussion of Mapping the Information Model to LDAP ..  6
52        4.1.  Summary of Class and Association Mappings ..............  7
53        4.2.  Usage of DIT Content and Structure Rules and Name Forms.  9
54        4.3.  Naming Attributes in the PCLS .......................... 10
55
56
57
58 Strassner, et al.           Standards Track                     [Page 1]
59 \f
60 RFC 3703                Policy Core LDAP Schema            February 2004
61
62
63        4.4.  Rule-Specific and Reusable Conditions and Actions ...... 11
64        4.5.  Location and Retrieval of Policy Objects in the
65              Directory .............................................. 16
66              4.5.1.  Aliases and Other DIT-Optimization Techniques .. 19
67    5.  Class Definitions ............................................ 19
68        5.1.  The Abstract Class "pcimPolicy" ........................ 21
69        5.2.  The Three Policy Group Classes ......................... 22
70        5.3.  The Three Policy Rule Classes .......................... 23
71        5.4.  The Class pcimRuleConditionAssociation ................. 30
72        5.5.  The Class pcimRuleValidityAssociation .................. 32
73        5.6.  The Class pcimRuleActionAssociation .................... 34
74        5.7.  The Auxiliary Class pcimConditionAuxClass .............. 36
75        5.8.  The Auxiliary Class pcimTPCAuxClass .................... 36
76        5.9.  The Auxiliary Class pcimConditionVendorAuxClass ........ 40
77        5.10. The Auxiliary Class pcimActionAuxClass ................. 41
78        5.11. The Auxiliary Class pcimActionVendorAuxClass ........... 42
79        5.12. The Class pcimPolicyInstance ........................... 43
80        5.13. The Auxiliary Class pcimElementAuxClass ................ 44
81        5.14. The Three Policy Repository Classes .................... 45
82        5.15. The Auxiliary Class pcimSubtreesPtrAuxClass ............ 46
83        5.16. The Auxiliary Class pcimGroupContainmentAuxClass ....... 48
84        5.17. The Auxiliary Class pcimRuleContainmentAuxClass ........ 49
85    6.  Extending the Classes Defined in This Document ............... 50
86        6.1.  Subclassing pcimConditionAuxClass and pcimActionAuxClass 50
87        6.2.  Using the Vendor Policy Attributes ..................... 50
88        6.3.  Using Time Validity Periods ............................ 51
89    7.  Security Considerations ...................................... 51
90    8.  IANA Considerations .......................................... 53
91        8.1.  Object Identifiers ..................................... 53
92        8.2.  Object Identifier Descriptors .......................... 53
93    9.  Acknowledgments .............................................. 56
94    10. Appendix:  Constructing the Value of orderedCIMKeys .......... 57
95    11. References ................................................... 58
96        11.1. Normative References ................................... 58
97        11.2. Informative References ................................. 59
98    12. Authors' Addresses ........................................... 60
99    13. Full Copyright Statement ..................................... 61
100
101 1.  Introduction
102
103    This document takes as its starting point the object-oriented
104    information model for representing information for representing and
105    controlling policy data as specified in [1].  Lightweight Directory
106    Access Protocol (LDAP) [2] implementers, please note that the use of
107    the term "policy" in this document does not refer to the use of the
108    term "policy" as defined in X.501 [4].  Rather, the use of the term
109    "policy" throughout this document is defined as follows:
110
111
112
113
114 Strassner, et al.           Standards Track                     [Page 2]
115 \f
116 RFC 3703                Policy Core LDAP Schema            February 2004
117
118
119       Policy is defined as a set of rules to administer, manage, and
120       control access to network resources.
121
122    This work is currently under joint development in the IETF's Policy
123    Framework working group and in the Policy working group of the
124    Distributed Management Task Force (DMTF).  This model defines two
125    hierarchies of object classes: structural classes representing policy
126    information and control of policies, and relationship classes that
127    indicate how instances of the structural classes are related to each
128    other.  In general, both of these class hierarchies will need to be
129    mapped to a particular data store.
130
131    This document defines the mapping of these information model classes
132    to a directory that uses LDAP as its access protocol.  Two types of
133    mappings are involved:
134
135       -  For the structural classes in the information model, the
136          mapping is basically one-for-one: information model classes map
137          to LDAP classes, information model properties map to LDAP
138          attributes.
139
140       -  For the relationship classes in the information model,
141          different mappings are possible.  In this document, the Policy
142          Core Information Model's (PCIM's) relationship classes and
143          their properties are mapped in three ways: to LDAP auxiliary
144          classes, to attributes representing distinguished name (DN)
145          references, and to superior-subordinate relationships in the
146          Directory Information Tree (DIT).
147
148    Implementations that use an LDAP directory as their policy repository
149    and want to implement policy information according to RFC 3060 [1]
150    SHALL use the LDAP schema defined in this document, or a schema that
151    subclasses from the schema defined in this document.  The use of the
152    information model defined in reference [1] as the starting point
153    enables the inheritance and the relationship class hierarchies to be
154    extensible, such that other types of policy repositories, such as
155    relational databases, can also use this information.
156
157    This document fits into the overall framework for representing,
158    deploying, and managing policies being developed by the Policy
159    Framework Working Group.
160
161    The LDAP schema described in this document uses the prefix "pcim" to
162    identify its classes and attributes.  It consists of ten very general
163    classes: pcimPolicy (an abstract class), three policy group classes
164    (pcimGroup, pcimGroupAuxClass, and pcimGroupInstance), three policy
165    rule classes (pcimRule, pcimRuleAuxClass, and pcimRuleInstance), and
166    three special auxiliary classes (pcimConditionAuxClass,
167
168
169
170 Strassner, et al.           Standards Track                     [Page 3]
171 \f
172 RFC 3703                Policy Core LDAP Schema            February 2004
173
174
175    pcimTPCAuxClass, and pcimActionAuxClass).  (Note that the
176    PolicyTimePeriodCondition auxiliary class defined in [1] would
177    normally have been named pcimTimePeriodConditionAuxClass, but this
178    name is too long for some directories.  Therefore, we have
179    abbreviated this name to be pcimTPCAuxClass).
180
181    The mapping for the PCIM classes pcimGroup and pcimRule is designed
182    to be as flexible as possible.  Three classes are defined for these
183    two PCIM classes.  First, an abstract superclass is defined that
184    contains all required properties of each PCIM class.  Then, both an
185    auxiliary class as well as a structural class are derived from the
186    abstract superclass.  This provides maximum flexibility for the
187    developer.
188
189    The schema also contains two less general classes:
190    pcimConditionVendorAuxClass and pcimActionVendorAuxClass.  To achieve
191    the mapping of the information model's relationships, the schema also
192    contains two auxiliary classes: pcimGroupContainmentAuxClass and
193    pcimRuleContainmentAuxClass.  Capturing the distinction between
194    rule-specific and reusable policy conditions and policy actions
195    introduces seven other classes: pcimRuleConditionAssociation,
196    pcimRuleValidityAssociation, pcimRuleActionAssociation,
197    pcimPolicyInstance, and three policy repository classes
198    (pcimRepository, pcimRepositoryAuxClass, and pcimRepositoryInstance).
199    Finally, the schema includes two classes (pcimSubtreesPtrAuxClass and
200    pcimElementAuxClass) for optimizing LDAP retrievals.  In all, the
201    schema contains 23 classes.
202
203    Within the context of this document, the term "PCLS" (Policy Core
204    LDAP Schema) is used to refer to the LDAP class definitions that this
205    document contains.  The term "PCIM" refers to classes defined in [1].
206
207    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
208    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
209    document are to be interpreted as described in RFC 2119 [10].
210
211 2.  The Policy Core Information Model
212
213    This document contains an LDAP schema representing the classes
214    defined in the companion document "Policy Core Information
215    Model -- Version 1 Specification" [1].  Other documents may
216    subsequently be produced, with mappings of this same PCIM to other
217    storage technologies.  Since the detailed semantics of the PCIM
218    classes appear only in [1], that document is a prerequisite for
219    reading and understanding this document.
220
221
222
223
224
225
226 Strassner, et al.           Standards Track                     [Page 4]
227 \f
228 RFC 3703                Policy Core LDAP Schema            February 2004
229
230
231 3.  Inheritance Hierarchy for the PCLS
232
233    The following diagram illustrates the class hierarchy for the LDAP
234    Classes defined in this document:
235
236         top
237          |
238          +--dlm1ManagedElement (abstract)
239          |   |
240          |   +--pcimPolicy (abstract)
241          |   |   |
242          |   |   +--pcimGroup (abstract)
243          |   |   |  |
244          |   |   |  +--pcimGroupAuxClass (auxiliary)
245          |   |   |  |
246          |   |   |  +--pcimGroupInstance (structural)
247          |   |   |
248          |   |   +--pcimRule (abstract)
249          |   |   |  |
250          |   |   |  +--pcimRuleAuxClass (auxiliary)
251          |   |   |  |
252          |   |   |  +--pcimRuleInstance (structural)
253          |   |   |
254          |   |   +--pcimRuleConditionAssociation (structural)
255          |   |   |
256          |   |   +--pcimRuleValidityAssociation (structural)
257          |   |   |
258          |   |   +--pcimRuleActionAssociation (structural)
259          |   |   |
260          |   |   +--pcimPolicyInstance (structural)
261          |   |   |
262          |   |   +--pcimElementAuxClass (auxiliary)
263          |   |
264          |   +--dlm1ManagedSystemElement (abstract)
265          |       |
266          |       +--dlm1LogicalElement (abstract)
267          |           |
268          |           +--dlm1System (abstract)
269          |               |
270          |               +--dlm1AdminDomain (abstract)
271          |                   |
272          |                   +--pcimRepository (abstract)
273          |                      |
274          |                      +--pcimRepositoryAuxClass (auxiliary)
275
276
277
278
279
280
281
282 Strassner, et al.           Standards Track                     [Page 5]
283 \f
284 RFC 3703                Policy Core LDAP Schema            February 2004
285
286
287         top
288          |                      |
289          |                      +--pcimRepositoryInstance
290          |                         (structural)
291          |
292          +--pcimConditionAuxClass (auxiliary)
293          |   |
294          |   +---pcimTPCAuxClass (auxiliary)
295          |   |
296          |   +---pcimConditionVendorAuxClass (auxiliary)
297          |
298          +--pcimActionAuxClass (auxiliary)
299          |   |
300          |   +---pcimActionVendorAuxClass (auxiliary)
301          |
302          +--pcimSubtreesPtrAuxClass (auxiliary)
303          |
304          +--pcimGroupContainmentAuxClass (auxiliary)
305          |
306          +--pcimRuleContainmentAuxClass (auxiliary)
307
308          Figure 1.  LDAP Class Inheritance Hierarchy for the PCLS
309
310 4.  General Discussion of Mapping the Information Model to LDAP
311
312    The classes described in Section 5 below contain certain
313    optimizations for a directory that uses LDAP as its access protocol.
314    One example of this is the use of auxiliary classes to represent some
315    of the associations defined in the information model.  Other data
316    stores might need to implement these associations differently.  A
317    second example is the introduction of classes specifically designed
318    to optimize retrieval of large amounts of policy-related data from a
319    directory.  This section discusses some general topics related to the
320    mapping from the information model to LDAP.
321
322    The remainder of this section will discuss the following topics.
323    Section 4.1 will discuss the strategy used in mapping the classes and
324    associations defined in [1] to a form that can be represented in a
325    directory that uses LDAP as its access protocol.  Section 4.2
326    discusses DIT content and structure rules, as well as name forms.
327    Section 4.3 describes the strategy used in defining naming attributes
328    for the schema described in Section 5 of this document.  Section 4.4
329    defines the strategy recommended for locating and retrieving
330    PCIM-derived objects in the directory.
331
332
333
334
335
336
337
338 Strassner, et al.           Standards Track                     [Page 6]
339 \f
340 RFC 3703                Policy Core LDAP Schema            February 2004
341
342
343 4.1.  Summary of Class and Association Mappings
344
345    Fifteen of the classes in the PCLS come directly from the nine
346    corresponding classes in the information model.  Note that names of
347    classes begin with an upper case character in the information model
348    (although for CIM in particular, case is not significant in class and
349    property names), but with a lower case character in LDAP.  This is
350    because although LDAP doesn't care, X.500 doesn't allow class names
351    to begin with an uppercase character.  Note also that the prefix
352    "pcim" is used to identify these LDAP classes.
353
354       +---------------------------+-------------------------------+
355       | Information Model         | LDAP Class(es)                |
356       +---------------------------+-------------------------------+
357       +---------------------------+-------------------------------+
358       | Policy                    | pcimPolicy                    |
359       +---------------------------+-------------------------------+
360       | PolicyGroup               | pcimGroup                     |
361       |                           |   pcimGroupAuxClass           |
362       |                           |   pcimGroupInstance           |
363       +---------------------------+-------------------------------+
364       | PolicyRule                | pcimRule                      |
365       |                           |   pcimRuleAuxClass            |
366       |                           |   pcimRuleInstance            |
367       +---------------------------+-------------------------------+
368       | PolicyCondition           | pcimConditionAuxClass         |
369       +---------------------------+-------------------------------+
370       | PolicyAction              | pcimActionAuxClass            |
371       +---------------------------+-------------------------------+
372       | VendorPolicyCondition     | pcimConditionVendorAuxClass   |
373       +---------------------------+-------------------------------+
374       | VendorPolicyAction        | pcimActionVendorAuxClass      |
375       +---------------------------+-------------------------------+
376       | PolicyTimePeriodCondition | pcimTPCAuxClass               |
377       +---------------------------+-------------------------------+
378       | PolicyRepository          | pcimRepository                |
379       |                           |   pcimRepositoryAuxClass      |
380       |                           |   pcimRepositoryInstance      |
381       +---------------------------+-------------------------------+
382
383           Figure 2.  Mapping of Information Model Classes to LDAP
384
385    The associations in the information model map to attributes that
386    reference DNs (Distinguished Names) or to Directory Information Tree
387    (DIT) containment (i.e., superior-subordinate relationships) in LDAP.
388    Two of the attributes that reference DNs appear in auxiliary classes,
389    which allow each of them to represent several relationships from the
390    information model.
391
392
393
394 Strassner, et al.           Standards Track                     [Page 7]
395 \f
396 RFC 3703                Policy Core LDAP Schema            February 2004
397
398
399 +----------------------------------+----------------------------------+
400 | Information Model Association     | LDAP Attribute / Class          |
401 +-----------------------------------+---------------------------------+
402 +-----------------------------------+---------------------------------+
403 | PolicyGroupInPolicyGroup          | pcimGroupsAuxContainedSet in    |
404 |                                   |  pcimGroupContainmentAuxClass   |
405 +-----------------------------------+---------------------------------+
406 | PolicyRuleInPolicyGroup           | pcimRulesAuxContainedSet in     |
407 |                                   |  pcimRuleContainmentAuxClass    |
408 +-----------------------------------+---------------------------------+
409 | PolicyConditionInPolicyRule       | DIT containment or              |
410 |                                   | pcimRuleConditionList in        |
411 |                                   |  pcimRule or                    |
412 |                                   | pcimConditionDN in              |
413 |                                   |  pcimRuleConditionAssociation   |
414 +-----------------------------------+---------------------------------+
415 | PolicyActionInPolicyRule          | DIT containment or              |
416 |                                   | pcimRuleActionList in           |
417 |                                   |  pcimRule or                    |
418 |                                   | pcimActionDN in                 |
419 |                                   |  pcimRuleActionAssociation      |
420 +-----------------------------------+---------------------------------+
421 | PolicyRuleValidityPeriod          | pcimRuleValidityPeriodList      |
422 |                                   |  in pcimRule or (if reusable)   |
423 |                                   |  referenced through the         |
424 |                                   | pcimTimePeriodConditionDN in    |
425 |                                   |  pcimRuleValidityAssociation    |
426 +-----------------------------------+---------------------------------+
427 | PolicyConditionInPolicyRepository | DIT containment                 |
428 +-----------------------------------+---------------------------------+
429 | PolicyActionInPolicyRepository    | DIT containment                 |
430 +-----------------------------------+---------------------------------+
431 | PolicyRepositoryInPolicyRepository| DIT containment                 |
432 +-----------------------------------+---------------------------------+
433
434       Figure 3.  Mapping of Information Model Associations to LDAP
435
436    Of the remaining classes in the PCLS, two (pcimElementAuxClass and
437    pcimSubtreesPtrAuxClass) are included to make navigation through the
438    DIT and retrieval of the entries found there more efficient.  This
439    topic is discussed below in Section 4.5.
440
441    The remaining four classes in the PCLS, pcimRuleConditionAssociation,
442    pcimRuleValidityAssociation, pcimRuleActionAssociation, and
443    pcimPolicyInstance, are all involved with the representation of
444    policy conditions and policy actions in an LDAP directory.  This
445    topic is discussed below in Section 4.4.
446
447
448
449
450 Strassner, et al.           Standards Track                     [Page 8]
451 \f
452 RFC 3703                Policy Core LDAP Schema            February 2004
453
454
455 4.2.  Usage of DIT Content and Structure Rules and Name Forms
456
457    There are three powerful tools that can be used to help define
458    schemata. The first, DIT content rules, is a way of defining the
459    content of an entry for a structural object class.  It can be used to
460    specify the following characteristics of the entry:
461
462       -  additional mandatory attributes that the entries are required
463          to contain
464       -  additional optional attributes the entries are allowed to
465          contain
466       -  the set of additional auxiliary object classes that these
467          entries are allowed to be members of
468       -  any optional attributes from the structural and auxiliary
469          object class definitions that the entries are required to
470          preclude
471
472    DIT content rules are NOT mandatory for any structural object class.
473
474    A DIT structure rule, together with a name form, controls the
475    placement and naming of an entry within the scope of a subschema.
476    Name forms define which attribute type(s) are required and are
477    allowed to be used in forming the Relative Distinguished Names (RDNs)
478    of entries.  DIT structure rules specify which entries are allowed to
479    be superior to other entries, and hence control the way that RDNs are
480    added together to make DNs.
481
482    A name form specifies the following:
483
484       -  the structural object class of the entries named by this name
485          form
486       -  attributes that are required to be used in forming the RDNs of
487          these entries
488       -  attributes that are allowed to be used in forming the RDNs of
489          these entries
490       -  an object identifier to uniquely identify this name form
491
492    Note that name forms can only be specified for structural object
493    classes.  However, every entry in the DIT must have a name form
494    controlling it.
495
496    Unfortunately, current LDAP servers vary quite a lot in their support
497    of these features.  There are also three crucial implementation
498    points that must be followed.  First, X.500 use of structure rules
499    requires that a structural object class with no superior structure
500    rule be a subschema administrative point.  This is exactly NOT what
501    we want for policy information.  Second, when an auxiliary class is
502    subclassed, if a content rule exists for the structural class that
503
504
505
506 Strassner, et al.           Standards Track                     [Page 9]
507 \f
508 RFC 3703                Policy Core LDAP Schema            February 2004
509
510
511    the auxiliary class refers to, then that content rule needs to be
512    augmented.  Finally, most LDAP servers unfortunately do not support
513    inheritance of structure and content rules.
514
515    Given these concerns, DIT structure and content rules have been
516    removed from the PCLS.  This is because, if included, they would be
517    normative references and would require OIDs.  However, we don't want
518    to lose the insight gained in building the structure and content
519    rules of the previous version of the schema.  Therefore, we describe
520    where such rules could be used in this schema, what they would
521    control, and what their effect would be.
522
523 4.3.  Naming Attributes in the PCLS
524
525    Instances in a directory are identified by distinguished names (DNs),
526    which provide the same type of hierarchical organization that a file
527    system provides in a computer system.  A distinguished name is a
528    sequence of RDNs.  An RDN provides a unique identifier for an
529    instance within the context of its immediate superior, in the same
530    way that a filename provides a unique identifier for a file within
531    the context of the folder in which it resides.
532
533    To preserve maximum naming flexibility for policy administrators,
534    three optional (i.e., "MAY") naming attributes have been defined.
535    They are:
536
537       -  Each of the structural classes defined in this schema has its
538          own unique ("MAY") naming attribute.  Since the naming
539          attributes are different, a policy administrator can, by using
540          these attributes, guarantee that there will be no name
541          collisions between instances of different classes, even if the
542          same value is assigned to the instances' respective naming
543          attributes.
544
545       -  The LDAP attribute cn (corresponding to X.500's commonName) is
546          included as a MAY attribute in the abstract class pcimPolicy,
547          and thus by inheritance in all of its subclasses.  In X.500,
548          commonName typically functions as an RDN attribute, for naming
549          instances of many classes (e.g., X.500's person class).
550
551       -  A special attribute is provided for implementations that expect
552          to map between native CIM and LDAP representations of policy
553          information.  This attribute, called orderedCimKeys, is defined
554          in the class dlm1ManagedElement [6].  The value of this
555          attribute is derived algorithmically from values that are
556          already present in a CIM policy instance.  The normative
557          reference for this algorithm is contained in [6].  See the
558          appendix of this document for a description of the algorithm.
559
560
561
562 Strassner, et al.           Standards Track                    [Page 10]
563 \f
564 RFC 3703                Policy Core LDAP Schema            February 2004
565
566
567    Since any of these naming attributes MAY be used for naming an
568    instance of a PCLS class, implementations MUST be able to accommodate
569    instances named in any of these ways.
570
571    Note that it is recommended that two or more of these attributes
572    SHOULD NOT be used together to form a multi-part RDN, since support
573    for multi-part RDNs is limited among existing directory
574    implementations.
575
576 4.4.  Rule-Specific and Reusable Conditions and Actions
577
578    The PCIM [1] distinguishes between two types of policy conditions and
579    policy actions:  those associated with a single policy rule, and
580    those that are reusable, in the sense that they may be associated
581    with more than one policy rule.  While there is no inherent
582    functional difference between a rule-specific condition or action and
583    a reusable one, there is both a usage, as well as, an implementation
584    difference between them.
585
586    Defining a condition or action as reusable vs. rule-specific reflects
587    a conscious decision on the part of the administrator in defining how
588    they are used.  In addition, there are variations that reflect
589    implementing rule-specific vs. reusable policy conditions and actions
590    and how they are treated in a policy repository.  The major
591    implementation differences between a rule-specific and a reusable
592    condition or action are delineated below:
593
594    1.  It is natural for a rule-specific condition or action to be
595        removed from the policy repository at the same time the rule is.
596        It is just the opposite for reusable conditions and actions.
597        This is because the condition or action is conceptually attached
598        to the rule in the rule-specific case, whereas it is referenced
599        (e.g., pointed at) in the reusable case.  The persistence of a
600        pcimRepository instance is independent of the persistence of a
601        pcimRule instance.
602    2.  Access permissions for a rule-specific condition or action are
603        usually identical to those for the rule itself.  On the other
604        hand, access permissions of reusable conditions and actions must
605        be expressible without reference to a policy rule.
606    3.  Rule-specific conditions and actions require fewer accesses,
607        because the conditions and actions are "attached" to the rule.
608        In contrast, reusable conditions and actions require more
609        accesses, because each condition or action that is reusable
610        requires a separate access.
611    4.  Rule-specific conditions and actions are designed for use by a
612        single rule.  As the number of rules that use the same
613        rule-specific condition increase, subtle problems are created
614        (the most obvious being how to keep the rule-specific conditions
615
616
617
618 Strassner, et al.           Standards Track                    [Page 11]
619 \f
620 RFC 3703                Policy Core LDAP Schema            February 2004
621
622
623        and actions updated to reflect the same value).  Reusable
624        conditions and actions lend themselves for use by multiple
625        independent rules.
626    5.  Reusable conditions and actions offer an optimization when
627        multiple rules are using the same condition or action.  This is
628        because the reusable condition or action only needs be updated
629        once, and by virtue of DN reference, the policy rules will be
630        automatically updated.
631
632    The preceding paragraph does not contain an exhaustive list of the
633    ways in which reusable and rule-specific conditions should be treated
634    differently.  Its purpose is merely to justify making a semantic
635    distinction between rule-specific and reusable, and then reflecting
636    this distinction in the policy repository itself.
637
638    When the policy repository is realized in an LDAP-accessible
639    directory, the distinction between rule-specific and reusable
640    conditions and actions is realized via placement of auxiliary classes
641    and via DIT containment.  Figure 4 illustrates a policy rule Rule1
642    with one rule-specific condition CA and one rule-specific action AB.
643
644                     +-----+
645                     |Rule1|
646                     |     |
647               +-----|-   -|-----+
648               |     +-----+     |
649               |       * *       |
650               |       * *       |
651               |    **** ****    |
652               |    *       *    |
653               v    *       *    v
654             +--------+   +--------+
655             | CA+ca  |   | AB+ab  |
656             +--------+   +--------+
657
658
659                           +------------------------------+
660                           |LEGEND:                       |
661                           |  ***** DIT containment       |
662                           |    +   auxiliary attachment  |
663                           |  ----> DN reference          |
664                           +------------------------------+
665
666            Figure 4  Rule-Specific Policy Conditions and Actions
667
668
669
670
671
672
673
674 Strassner, et al.           Standards Track                    [Page 12]
675 \f
676 RFC 3703                Policy Core LDAP Schema            February 2004
677
678
679    Because the condition and action are specific to Rule1, the auxiliary
680    classes ca and ab that represent them are attached, respectively, to
681    the structural classes CA and AB.  These structural classes represent
682    not the condition ca and action ab themselves, but rather the
683    associations between Rule1 and ca, and between Rule1 and ab.
684
685    As Figure 4 illustrates, Rule1 contains DN references to the
686    structural classes CA and AB that appear below it in the DIT.  At
687    first glance it might appear that these DN references are
688    unnecessary, since a subtree search below Rule1 would find all of the
689    structural classes representing the associations between Rule1 and
690    its conditions and actions.  Relying only on a subtree search,
691    though, runs the risk of missing conditions or actions that should
692    have appeared in the subtree, but for some reason did not, or of
693    finding conditions or actions that were inadvertently placed in the
694    subtree, or that should have been removed from the subtree, but for
695    some reason were not.  Implementation experience has suggested that
696    many (but not all) of these risks are eliminated.
697
698    However, it must be noted that this comes at a price.  The use of DN
699    references, as shown in Figure 4 above, thwarts inheritance of access
700    control information as well as existence dependency information.  It
701    also is subject to referential integrity considerations.  Therefore,
702    it is being included as an option for the designer.
703
704    Figure 5 illustrates a second way of representing rule-specific
705    conditions and actions in an LDAP-accessible directory: attachment of
706    the auxiliary classes directly to the instance representing the
707    policy rule.  When all of the conditions and actions are attached to
708    a policy rule in this way, the rule is termed a "simple" policy rule.
709    When conditions and actions are not attached directly to a policy
710    rule, the rule is termed a "complex" policy rule.
711
712                     +-----------+
713                     |Rule1+ca+ab|
714                     |           |
715                     +-----------+
716
717                           +------------------------------+
718                           |LEGEND:                       |
719                           |    +   auxiliary attachment  |
720                           +------------------------------+
721
722                       Figure 5.  A Simple Policy Rule
723
724
725
726
727
728
729
730 Strassner, et al.           Standards Track                    [Page 13]
731 \f
732 RFC 3703                Policy Core LDAP Schema            February 2004
733
734
735    The simple/complex distinction for a policy rule is not all or
736    nothing.  A policy rule may have its conditions attached to itself
737    and its actions attached to other entries, or it may have its actions
738    attached to itself and its conditions attached to other entries.
739    However, it SHALL NOT have either its conditions or its actions
740    attached both to itself and to other entries, with one exception:  a
741    policy rule may reference its validity periods with the
742    pcimRuleValidityPeriodList attribute, but have its other conditions
743    attached to itself.
744
745    The tradeoffs between simple and complex policy rules are between the
746    efficiency of simple rules and the flexibility and greater potential
747    for reuse of complex rules.  With a simple policy rule, the semantic
748    options are limited:
749
750    -   All conditions are ANDed together.  This combination can be
751        represented in two ways in the Disjunctive Normal Form (DNF)/
752        Conjunctive Normal Form (CNF) (please see [1] for definitions of
753        these terms) expressions characteristic of policy conditions:  as
754        a DNF expression with a single AND group, or as a CNF expression
755        with multiple single-condition OR groups.  The first of these is
756        arbitrarily chosen as the representation for the ANDed conditions
757        in a simple policy rule.
758
759    -   If multiple actions are included, no order can be specified for
760        them.
761
762    If a policy administrator needs to combine conditions in some other
763    way, or if there is a set of actions that must be ordered, then the
764    only option is to use a complex policy rule.
765
766    Finally, Figure 6 illustrates the same policy rule Rule1, but this
767    time its condition and action are reusable.  The association classes
768    CA and AB are still present, and they are still DIT contained under
769    Rule1.  But rather than having the auxiliary classes ca and ab
770    attached directly to the association classes CA and AB, each now
771    contains DN references to other entries to which these auxiliary
772    classes are attached.  These other entries, CIA and AIB, are DIT
773    contained under RepositoryX, which is an instance of the class
774    pcimRepository.  Because they are named under an instance of
775    pcimRepository, ca and ab are clearly identified as reusable.
776
777
778
779
780
781
782
783
784
785
786 Strassner, et al.           Standards Track                    [Page 14]
787 \f
788 RFC 3703                Policy Core LDAP Schema            February 2004
789
790
791                    +-----+             +-------------+
792                    |Rule1|             | RepositoryX |
793                  +-|-   -|--+          |             |
794                  | +-----+  |          +-------------+
795                  |   * *    |             *       *
796                  |   * *    |             *       *
797                  | *** **** |             *       *
798                  | *      * v             *       *
799                  | *     +---+            *       *
800                  | *     |AB |         +------+   *
801                  v *     |  -|-------->|AIB+ab|   *
802                 +---+    +---+         +------+   *
803                 |CA |                         +------+
804                 |  -|------------------------>|CIA+ca|
805                 +---+                         +------+
806
807                           +------------------------------+
808                           |LEGEND:                       |
809                           |  ***** DIT containment       |
810                           |    +   auxiliary attachment  |
811                           |  ----> DN reference          |
812                           +------------------------------+
813
814              Figure 6.  Reusable Policy Conditions and Actions
815
816    The classes pcimConditionAuxClass and pcimActionAuxClass do not
817    themselves represent actual conditions and actions:  these are
818    introduced in their subclasses.  What pcimConditionAuxClass and
819    pcimActionAuxClass do introduce are the semantics of being a policy
820    condition or a policy action.  These are the semantics that all the
821    subclasses of pcimConditionAuxClass and pcimActionAuxClass inherit.
822    Among these semantics are those of representing either a
823    rule-specific or a reusable policy condition or policy action.
824
825    In order to preserve the ability to represent a rule-specific or a
826    reusable condition or action, as well as a simple policy rule, all
827    the subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST
828    also be auxiliary classes.
829
830
831
832
833
834
835
836
837
838
839
840
841
842 Strassner, et al.           Standards Track                    [Page 15]
843 \f
844 RFC 3703                Policy Core LDAP Schema            February 2004
845
846
847 4.5.  Location and Retrieval of Policy Objects in the Directory
848
849    When a Policy Decision Point (PDP) goes to an LDAP directory to
850    retrieve the policy object instances relevant to the Policy
851    Enforcement Points (PEPs) it serves, it is faced with two related
852    problems:
853
854    -   How does it locate and retrieve the directory entries that apply
855        to its PEPs?  These entries may include instances of the PCLS
856        classes, instances of domain-specific subclasses of these
857        classes, and instances of other classes modeling such resources
858        as user groups, interfaces, and address ranges.
859
860    -   How does it retrieve the directory entries it needs in an
861        efficient manner, so that retrieval of policy information from
862        the directory does not become a roadblock to scalability?  There
863        are two facets to this efficiency:  retrieving only the relevant
864        directory entries, and retrieving these entries using as few LDAP
865        calls as possible.
866
867    The placement of objects in the Directory Information Tree (DIT)
868    involves considerations other than how the policy-related objects
869    will be retrieved by a PDP.  Consequently, all that the PCLS can do
870    is to provide a "toolkit" of classes to assist the policy
871    administrator as the DIT is being designed and built.  A PDP SHOULD
872    be able to take advantage of any tools that the policy administrator
873    is able to build into the DIT, but it MUST be able to use a less
874    efficient means of retrieval if that is all it has available to it.
875
876    The basic idea behind the LDAP optimization classes is a simple one:
877    make it possible for a PDP to retrieve all the policy-related objects
878    it needs, and only those objects, using as few LDAP calls as
879    possible.  An important assumption underlying this approach is that
880    the policy administrator has sufficient control over the underlying
881    DIT structure to define subtrees for storing policy information.  If
882    the policy administrator does not have this level of control over DIT
883    structure, a PDP can still retrieve the policy-related objects it
884    needs individually.  But it will require more LDAP access operations
885    to do the retrieval in this way.  Figure 7 illustrates how LDAP
886    optimization is accomplished.
887
888
889
890
891
892
893
894
895
896
897
898 Strassner, et al.           Standards Track                    [Page 16]
899 \f
900 RFC 3703                Policy Core LDAP Schema            February 2004
901
902
903                        +-----+
904       ---------------->|  A  |
905       DN reference to  |     |    DN references to subtrees   +---+
906       starting object  +-----+    +-------------------------->| C |
907                        |  o--+----+         +---+             +---+
908                        |  o--+------------->| B |            /     \
909                        +-----+              +---+           /       \
910                       /       \            /     \         /   ...   \
911                      /         \          /       \
912                     /           \        /   ...   \
913
914       Figure 7.  Using the pcimSubtreesPtrAuxClass to Locate Policies
915
916    The PDP is configured initially with a DN reference to some entry in
917    the DIT.  The structural class of this entry is not important; the
918    PDP is interested only in the pcimSubtreesPtrAuxClass attached to it.
919    This auxiliary class contains a multi-valued attribute with DN
920    references to objects that anchor subtrees containing policy-related
921    objects of interest to the PDP.  Since pcimSubtreesPtrAuxClass is an
922    auxiliary class, it can be attached to an entry that the PDP would
923    need to access anyway - perhaps an entry containing initial
924    configuration settings for the PDP, or for a PEP that uses the PDP.
925
926    Once it has retrieved the DN references, the PDP will direct to each
927    of the objects identified by them an LDAP request that all entries in
928    its subtree be evaluated against the selection criteria specified in
929    the request.  The LDAP-enabled directory then returns all entries in
930    that subtree that satisfy the specified criteria.
931
932    The selection criteria always specify that object class="pcimPolicy".
933    Since all classes representing policy rules, policy conditions, and
934    policy actions, both in the PCLS and in any domain-specific schema
935    derived from it, are subclasses of the abstract class policy, this
936    criterion evaluates to TRUE for all instances of these classes.  To
937    accommodate special cases where a PDP needs to retrieve objects that
938    are not inherently policy-related (for example, an IP address range
939    object referenced by a subclass of pcimActionAuxClass representing
940    the DHCP action "assign from this address range"), the auxiliary
941    class pcimElementAuxClass can be used to "tag" an entry, so that it
942    will be found by the selection criterion "object class=pcimPolicy".
943
944    The approach described in the preceding paragraph will not work for
945    certain directory implementations, because these implementations do
946    not support matching of auxiliary classes in the objectClass
947    attribute.  For environments where these implementations are expected
948    to be present, the "tagging" of entries as relevant to policy can be
949
950
951
952
953
954 Strassner, et al.           Standards Track                    [Page 17]
955 \f
956 RFC 3703                Policy Core LDAP Schema            February 2004
957
958
959    accomplished by inserting the special value "POLICY" into the list of
960    values contained in the pcimKeywords attribute (provided by the
961    pcimPolicy class).
962
963    If a PDP needs only a subset of the policy-related objects in the
964    indicated subtrees, then it can be configured with additional
965    selection criteria based on the pcimKeywords attribute defined in the
966    pcimPolicy class.  This attribute supports both standardized and
967    administrator- defined values.  For example, a PDP could be
968    configured to request only those policy-related objects containing
969    the keywords "DHCP" and "Eastern US".
970
971    To optimize what is expected to be a typical case, the initial
972    request from the client includes not only the object to which its
973    "seed" DN references, but also the subtree contained under this
974    object.  The filter for searching this subtree is whatever the client
975    is going to use later to search the other subtrees:  object
976    class="pcimPolicy" or the presence of the keyword "POLICY", and/or
977    presence of a more specific value of pcimKeywords (e.g., "QoS Edge
978    Policy").
979
980    Returning to the example in Figure 7, we see that in the best case, a
981    PDP can get all the policy-related objects it needs, and only those
982    objects, with exactly three LDAP requests:  one to its starting
983    object A to get the references to B and C, as well as the
984    policy-related objects it needs from the subtree under A, and then
985    one each to B and C to get all the policy-related objects that pass
986    the selection criteria with which it was configured.  Once it has
987    retrieved all of these objects, the PDP can then traverse their
988    various DN references locally to understand the semantic
989    relationships among them.  The PDP should also be prepared to find a
990    reference to another subtree attached to any of the objects it
991    retrieves, and to follow this reference first, before it follows any
992    of the semantically significant references it has received.  This
993    recursion permits a structured approach to identifying related
994    policies.  In Figure 7, for example, if the subtree under B includes
995    departmental policies and the one under C includes divisional
996    policies, then there might be a reference from the subtree under C to
997    an object D that roots the subtree of corporate-level policies.
998
999    A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be
1000    capable of retrieving and processing the entries in the subtrees it
1001    references, and SHOULD be capable of doing all of this recursively.
1002    The same requirements apply to any other entity needing to retrieve
1003    policy information from the directory.  Thus, a Policy Management
1004    Tool that retrieves policy entries from the directory in order to
1005    perform validation and conflict detection SHOULD also understand and
1006    be capable of using the pcimSubtreesPtrAuxClass.  All of these
1007
1008
1009
1010 Strassner, et al.           Standards Track                    [Page 18]
1011 \f
1012 RFC 3703                Policy Core LDAP Schema            February 2004
1013
1014
1015    requirements are "SHOULD"s rather than "MUST"s because an LDAP client
1016    that doesn't implement them can still access and retrieve the
1017    directory entries it needs.  The process of doing so will just be
1018    less efficient than it would have been if the client had implemented
1019    these optimizations.
1020
1021    When it is serving as a tool for creating policy entries in the
1022    directory, a Policy Management Tool SHOULD support creation of
1023    pcimSubtreesPtrAuxClass entries and their references to object
1024    instances.
1025
1026 4.5.1.  Aliases and Other DIT-Optimization Techniques
1027
1028    Additional flexibility in DIT structure is available to the policy
1029    administrator via LDAP aliasing and other techniques.  Previous
1030    versions of this document have used aliases.  However, because
1031    aliases are experimental, the use of aliases has been removed from
1032    this version of this document.  This is because the IETF has yet to
1033    produce a specification on how aliases are represented in the
1034    directory or how server implementations are to process aliases.
1035
1036 5.  Class Definitions
1037
1038    The semantics for the policy information classes that are to be
1039    mapped directly from the information model to an LDAP representation
1040    are detailed in [1].  Consequently, all that this document presents
1041    for these classes is the specification for how to do the mapping from
1042    the information model (which is independent of repository type and
1043    access protocol) to a form that can be accessed using LDAP.  Remember
1044    that some new classes needed to be created (that were not part of
1045    [1]) to implement the LDAP mapping.  These new LDAP-only classes are
1046    fully documented in this document.
1047
1048    The formal language for specifying the classes, attributes, and DIT
1049    structure and content rules is that defined in reference [3].  If
1050    your implementation does not support auxiliary class inheritance, you
1051    will have to list auxiliary classes in content rules explicitly or
1052    define them in another (implementation-specific) way.
1053
1054    The following notes apply to this section in its entirety.
1055
1056    Note 1: in the following definitions, the class and attribute
1057    definitions follow RFC 2252 [3] but they are line-wrapped to enhance
1058    human readability.
1059
1060    Note 2: where applicable, the possibilities for specifying DIT
1061    structure and content rules are noted.  However, care must be taken
1062    in specifying DIT structure rules.  This is because X.501 [4] states
1063
1064
1065
1066 Strassner, et al.           Standards Track                    [Page 19]
1067 \f
1068 RFC 3703                Policy Core LDAP Schema            February 2004
1069
1070
1071    that an entry may only exist in the DIT as a subordinate to another
1072    superior entry (the superior) if a DIT structure rule exists in the
1073    governing subschema which:
1074
1075    1)  indicates a name form for the structural object class of the
1076        subordinate entry, and
1077    2)  either includes the entry's superior structure rule as a possible
1078        superior structure rule, or
1079    3)  does not specify a superior structure rule.
1080
1081    If this last case (3) applies, then the entry is defined to be a
1082    subschema administrative point.  This is not what is desired.
1083    Therefore, care must be taken in defining structure rules, and in
1084    particular, they must be locally augmented.
1085
1086    Note 3: Wherever possible, both an equality and a substring matching
1087    rule are defined for a particular attribute (as well as an ordering
1088    match rule to enable sorting of matching results).  This provides two
1089    different choices for the developer for maximum flexibility.
1090
1091    For example, consider the pcimRoles attribute (section 5.3).  Suppose
1092    that a PEP has reported that it is interested in pcimRules for three
1093    roles R1, R2, and R3.  If the goal is to minimize queries, then the
1094    PDP can supply three substring filters containing the three role
1095    names.
1096
1097    These queries will return all of the pcimRules that apply to the PEP,
1098    but they may also get some that do not apply (e.g., ones that contain
1099    one of the roles R1, R2, or R3 and one or more other roles present in
1100    a role-combination [1]).
1101
1102    Another strategy would be for the PDP to use only equality filters.
1103    This approach eliminates the extraneous replies, but it requires the
1104    PDP to explicitly build the desired role-combinations itself.  It
1105    also requires extra queries.  Note that this approach is practical
1106    only because the role names in a role combination are required to
1107    appear in alphabetical order.
1108
1109    Note 4: in the following definitions, note that all LDAP matching
1110    rules are defined in [3] and in [9].  The corresponding X.500
1111    matching rules are defined in [8].
1112
1113    Note 5: some of the following attribute definitions specify
1114    additional constraints on various data types (e.g., this integer has
1115    values that are valid  from 1..10).  Text has been added to instruct
1116    servers and applications what to do if a value outside of this range
1117
1118
1119
1120
1121
1122 Strassner, et al.           Standards Track                    [Page 20]
1123 \f
1124 RFC 3703                Policy Core LDAP Schema            February 2004
1125
1126
1127    is encountered.  In all cases, if a constraint is violated, then the
1128    policy rule SHOULD be treated as being disabled, meaning that
1129    execution of the policy rule SHOULD be stopped.
1130
1131 5.1.  The Abstract Class pcimPolicy
1132
1133    The abstract class pcimPolicy is a direct mapping of the abstract
1134    class Policy from the PCIM.  The class value "pcimPolicy" is also
1135    used as the mechanism for identifying policy-related instances in the
1136    Directory Information Tree.  An instance of any class may be "tagged"
1137    with this class value by attaching to it the auxiliary class
1138    pcimElementAuxClass.  Since pcimPolicy is derived from the class
1139    dlm1ManagedElement defined in reference [6], this specification has a
1140    normative dependency on that element of reference [6].
1141
1142    The class definition is as follows:
1143
1144        ( 1.3.6.1.1.6.1.1 NAME 'pcimPolicy'
1145          DESC 'An abstract class that is the base class for all classes
1146                that describe policy-related instances.'
1147          SUP dlm1ManagedElement
1148          ABSTRACT
1149          MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $
1150                pcimKeywords )
1151        )
1152
1153    The attribute cn is defined in RFC 2256 [7].  The dlmCaption,
1154    dlmDescription, and orderedCimKeys attributes are defined in [6].
1155
1156    The pcimKeywords attribute is a multi-valued attribute that contains
1157    a set of keywords to assist directory clients in locating the policy
1158    objects identified by these keywords.  It is defined as follows:
1159
1160        ( 1.3.6.1.1.6.2.3 NAME 'pcimKeywords'
1161               DESC 'A set of keywords to assist directory clients in
1162                     locating the policy objects applicable to them.'
1163               EQUALITY caseIgnoreMatch
1164               ORDERING caseIgnoreOrderingMatch
1165               SUBSTR caseIgnoreSubstringsMatch
1166               SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1167        )
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178 Strassner, et al.           Standards Track                    [Page 21]
1179 \f
1180 RFC 3703                Policy Core LDAP Schema            February 2004
1181
1182
1183 5.2.  The Three Policy Group Classes
1184
1185    PCIM [1] defines the PolicyGroup class to serve as a generalized
1186    aggregation mechanism, enabling PolicyRules and/or PolicyGroups to be
1187    aggregated together.  PCLS maps this class into three LDAP classes,
1188    called pcimGroup, pcimGroupAuxClass, and pcimGroupInstance.  This is
1189    done in order to provide maximum flexibility for the DIT designer.
1190
1191    The class definitions for the three policy group classes are listed
1192    below.  These class definitions do not include attributes to realize
1193    the PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations
1194    from the PCIM.  This is because a pcimGroup object refers to
1195    instances of pcimGroup and pcimRule via, respectively, the attribute
1196    pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object
1197    class and the attribute pcimRulesAuxContainedSet in the
1198    pcimRuleContainmentAuxClass object class.
1199
1200    To maximize flexibility, the pcimGroup class is defined as abstract.
1201    The subclass pcimGroupAuxClass provides for auxiliary attachment to
1202    another entry, while the structural subclass pcimGroupInstance is
1203    available to represent a policy group as a standalone entry.
1204
1205    The class definitions are as follows.  First, the definition of the
1206    abstract class pcimGroup:
1207
1208        ( 1.3.6.1.1.6.1.2 NAME 'pcimGroup'
1209               DESC 'A container for a set of related pcimRules and/or
1210                     a set of related pcimGroups.'
1211               SUP pcimPolicy
1212               ABSTRACT
1213               MAY ( pcimGroupName )
1214        )
1215
1216    The one attribute of pcimGroup is pcimGroupName.  This attribute is
1217    used to define a user-friendly name of this policy group, and may be
1218    used as a naming attribute if desired.  It is defined as follows:
1219
1220        ( 1.3.6.1.1.6.2.4 NAME 'pcimGroupName'
1221               DESC 'The user-friendly name of this policy group.'
1222               EQUALITY caseIgnoreMatch
1223               ORDERING caseIgnoreOrderingMatch
1224               SUBSTR caseIgnoreSubstringsMatch
1225               SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1226               SINGLE-VALUE
1227        )
1228
1229
1230
1231
1232
1233
1234 Strassner, et al.           Standards Track                    [Page 22]
1235 \f
1236 RFC 3703                Policy Core LDAP Schema            February 2004
1237
1238
1239    The two subclasses of pcimGroup are defined as follows.  The class
1240    pcimGroupAuxClass is an auxiliary class that can be used to collect a
1241    set of related pcimRule and/or pcimGroup classes.  It is defined as
1242    follows:
1243
1244        ( 1.3.6.1.1.6.1.3 NAME 'pcimGroupAuxClass'
1245               DESC 'An auxiliary class that collects a set of related
1246                     pcimRule and/or pcimGroup entries.'
1247               SUP pcimGroup
1248               AUXILIARY
1249        )
1250
1251    The class pcimGroupInstance is a structural class that can be used to
1252    collect a set of related pcimRule and/or pcimGroup classes.  It is
1253    defined as follows:
1254
1255        ( 1.3.6.1.1.6.1.4 NAME 'pcimGroupInstance'
1256               DESC 'A structural class that collects a set of related
1257                     pcimRule and/or pcimGroup entries.'
1258               SUP pcimGroup
1259               STRUCTURAL
1260        )
1261
1262    A DIT content rule could be written to enable an instance of
1263    pcimGroupInstance to have attached to it either references to one or
1264    more policy groups (using pcimGroupContainmentAuxClass) or references
1265    to one or more policy rules (using pcimRuleContainmentAuxClass).
1266    This would be used to formalize the semantics of the PolicyGroup
1267    class [1].  Since these semantics do not include specifying any
1268    properties of the PolicyGroup class, the content rule would not need
1269    to specify any attributes.
1270
1271    Similarly, three separate DIT structure rules could be written, each
1272    of which would refer to a specific name form that identified one of
1273    the three possible naming attributes (i.e., pcimGroupName, cn, and
1274    orderedCIMKeys) for the pcimGroup object class.  This structure rule
1275    SHOULD include a superiorStructureRule (see Note 2 at the beginning
1276    of section 5).  The three name forms referenced by the three
1277    structure rules would each define one of the three naming attributes.
1278
1279 5.3.  The Three Policy Rule Classes
1280
1281    The information model defines a PolicyRule class to represent the "If
1282    Condition then Action" semantics associated with processing policy
1283    information.  For maximum flexibility, the PCLS maps this class into
1284    three LDAP classes.
1285
1286
1287
1288
1289
1290 Strassner, et al.           Standards Track                    [Page 23]
1291 \f
1292 RFC 3703                Policy Core LDAP Schema            February 2004
1293
1294
1295    To maximize flexibility, the pcimRule class is defined as abstract.
1296    The subclass pcimRuleAuxClass provides for auxiliary attachment to
1297    another entry, while the structural subclass pcimRuleInstance is
1298    available to represent a policy rule as a standalone entry.
1299
1300    The conditions and actions associated with a policy rule are modeled,
1301    respectively, with auxiliary subclasses of the auxiliary classes
1302    pcimConditionAuxClass and pcimActionAuxClass.  Each of these
1303    auxiliary subclasses is attached to an instance of one of three
1304    structural classes.  A subclass of pcimConditionAuxClass is attached
1305    to an instance of pcimRuleInstance, to an instance of
1306    pcimRuleConditionAssociation, or to an instance of
1307    pcimPolicyInstance.  Similarly, a subclass of pcimActionAuxClass is
1308    attached to an instance of pcimRuleInstance, to an instance of
1309    pcimRuleActionAssociation, or to an instance of pcimPolicyInstance.
1310
1311    The pcimRuleValidityPeriodList attribute (defined below) realizes the
1312    PolicyRuleValidityPeriod association defined in the PCIM.  Since this
1313    association has no additional properties besides those that tie the
1314    association to its associated objects, this association can be
1315    realized by simply using an attribute.  Thus, the
1316    pcimRuleValidityPeriodList attribute is simply a multi-valued
1317    attribute that provides an unordered set of DN references to one or
1318    more instances of the pcimTPCAuxClass, indicating when the policy
1319    rule is scheduled to be active and when it is scheduled to be
1320    inactive.  A policy rule is scheduled to be active if it is active
1321    according to AT LEAST ONE of the pcimTPCAuxClass instances referenced
1322    by this attribute.
1323
1324    The PolicyConditionInPolicyRule and PolicyActionInPolicyRule
1325    associations, however, do have additional attributes.  The
1326    association PolicyActionInPolicyRule defines an integer attribute to
1327    sequence the actions, and the association PolicyConditionInPolicyRule
1328    has both an integer attribute to group the condition terms as well as
1329    a Boolean property to specify whether a condition is to be negated.
1330
1331    In the PCLS, these additional association attributes are represented
1332    as attributes of two classes introduced specifically to model these
1333    associations.  These classes are the pcimRuleConditionAssociation
1334    class and the pcimRuleActionAssociation class, which are defined in
1335    Sections 5.4 and 5.5, respectively.  Thus, they do not appear as
1336    attributes of the class pcimRule.  Instead, the pcimRuleConditionList
1337    and pcimRuleActionList attributes can be used to reference these
1338    classes.
1339
1340
1341
1342
1343
1344
1345
1346 Strassner, et al.           Standards Track                    [Page 24]
1347 \f
1348 RFC 3703                Policy Core LDAP Schema            February 2004
1349
1350
1351    The class definitions for the three pcimRule classes are as follows.
1352
1353    The abstract class pcimRule is a base class for representing the "If
1354    Condition then Action" semantics associated with a policy rule.  It
1355    is defined as follows:
1356
1357      ( 1.3.6.1.1.6.1.5 NAME 'pcimRule'
1358             DESC 'The base class for representing the "If Condition
1359                   then Action" semantics associated with a policy rule.'
1360             SUP pcimPolicy
1361             ABSTRACT
1362             MAY ( pcimRuleName $ pcimRuleEnabled $
1363                   pcimRuleConditionListType $ pcimRuleConditionList $
1364                   pcimRuleActionList $ pcimRuleValidityPeriodList $
1365                   pcimRuleUsage $ pcimRulePriority $
1366                   pcimRuleMandatory $ pcimRuleSequencedActions $
1367                   pcimRoles )
1368      )
1369
1370    The PCIM [1] defines seven properties for the PolicyRule class.  The
1371    PCLS defines eleven attributes for the pcimRule class, which is the
1372    LDAP equivalent of the PolicyRule class.  Of these eleven attributes,
1373    seven are mapped directly from corresponding properties in PCIM's
1374    PolicyRule class.  The remaining four attributes are a class-specific
1375    optional naming attribute, and three attributes used to realize the
1376    three associations that the pcimRule class participates in.
1377
1378    The pcimRuleName attribute is used as a user-friendly name of this
1379    policy rule, and can also serve as the class-specific optional naming
1380    attribute.  It is defined as follows:
1381
1382         ( 1.3.6.1.1.6.2.5 NAME 'pcimRuleName'
1383                DESC 'The user-friendly name of this policy rule.'
1384                EQUALITY caseIgnoreMatch
1385                ORDERING caseIgnoreOrderingMatch
1386                SUBSTR caseIgnoreSubstringsMatch
1387                SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1388                SINGLE-VALUE
1389         )
1390
1391    The pcimRuleEnabled attribute is an integer enumeration indicating
1392    whether a policy rule is administratively enabled (value=1),
1393    administratively disabled (value=2), or enabled for debug (value=3).
1394    It is defined as follows:
1395
1396         ( 1.3.6.1.1.6.2.6 NAME 'pcimRuleEnabled'
1397                DESC 'An integer indicating whether a policy rule is
1398                      administratively enabled (value=1), disabled
1399
1400
1401
1402 Strassner, et al.           Standards Track                    [Page 25]
1403 \f
1404 RFC 3703                Policy Core LDAP Schema            February 2004
1405
1406
1407                      (value=2), or enabled for debug (value=3).'
1408                EQUALITY integerMatch
1409                ORDERING integerOrderingMatch
1410                SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1411                SINGLE-VALUE
1412         )
1413
1414    Note: All other values for the pcimRuleEnabled attribute are
1415    considered errors, and the administrator SHOULD treat this rule as
1416    being disabled if an invalid value is found.
1417
1418    The pcimRuleConditionListType attribute is used to indicate whether
1419    the list of policy conditions associated with this policy rule is in
1420    disjunctive normal form (DNF, value=1) or conjunctive normal form
1421    (CNF, value=2).  It is defined as follows:
1422
1423      ( 1.3.6.1.1.6.2.7 NAME 'pcimRuleConditionListType'
1424             DESC 'A value of 1 means that this policy rule is in
1425                   disjunctive normal form; a value of 2 means that this
1426                   policy rule is in conjunctive normal form.'
1427             EQUALITY integerMatch
1428             ORDERING integerOrderingMatch
1429             SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1430             SINGLE-VALUE
1431      )
1432
1433    Note: any value other than 1 or 2 for the pcimRuleConditionListType
1434    attribute is considered an error.  Administrators SHOULD treat this
1435    rule as being disabled if an invalid value is found, since it is
1436    unclear how to structure the condition list.
1437
1438    The pcimRuleConditionList attribute is a multi-valued attribute that
1439    is used to realize the policyRuleInPolicyCondition association
1440    defined in [1].  It contains a set of DNs of
1441    pcimRuleConditionAssociation entries representing associations
1442    between this policy rule and its conditions.  No order is implied.
1443    It is defined as follows:
1444
1445      ( 1.3.6.1.1.6.2.8 NAME 'pcimRuleConditionList'
1446             DESC 'Unordered set of DNs of pcimRuleConditionAssociation
1447                   entries representing associations between this policy
1448                   rule and its conditions.'
1449             EQUALITY distinguishedNameMatch
1450             SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1451      )
1452
1453
1454
1455
1456
1457
1458 Strassner, et al.           Standards Track                    [Page 26]
1459 \f
1460 RFC 3703                Policy Core LDAP Schema            February 2004
1461
1462
1463    The pcimRuleActionList attribute is a multi-valued attribute that is
1464    used to realize the policyRuleInPolicyAction association defined in
1465    [1].  It contains a set of DNs of pcimRuleActionAssociation entries
1466    representing associations between this policy rule and its actions.
1467    No order is implied.  It is defined as follows:
1468
1469      ( 1.3.6.1.1.6.2.9 NAME 'pcimRuleActionList'
1470             DESC 'Unordered set of DNs of pcimRuleActionAssociation
1471                   entries representing associations between this policy
1472                   rule and its actions.'
1473            EQUALITY distinguishedNameMatch
1474            SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1475      )
1476
1477    The pcimRuleValidityPeriodList attribute is a multi-valued attribute
1478    that is used to realize the pcimRuleValidityPeriod association that
1479    is defined in [1].  It contains a set of DNs of
1480    pcimRuleValidityAssociation entries that determine when the pcimRule
1481    is scheduled to be active or inactive.  No order is implied.  It is
1482    defined as follows:
1483
1484      ( 1.3.6.1.1.6.2.10 NAME 'pcimRuleValidityPeriodList'
1485             DESC 'Unordered set of DNs of pcimRuleValidityAssociation
1486                   entries that determine when the pcimRule is scheduled
1487                   to be active or inactive.'
1488             EQUALITY distinguishedNameMatch
1489             SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1490      )
1491
1492    The pcimRuleUsage attribute is a free-form string providing
1493    guidelines on how this policy should be used.  It is defined as
1494    follows:
1495
1496      ( 1.3.6.1.1.6.2.11 NAME 'pcimRuleUsage'
1497             DESC 'This attribute is a free-form sting providing
1498                   guidelines on how this policy should be used.'
1499             EQUALITY caseIgnoreMatch
1500             ORDERING caseIgnoreOrderingMatch
1501             SUBSTR caseIgnoreSubstringsMatch
1502             SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1503             SINGLE-VALUE
1504      )
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514 Strassner, et al.           Standards Track                    [Page 27]
1515 \f
1516 RFC 3703                Policy Core LDAP Schema            February 2004
1517
1518
1519    The pcimRulePriority attribute is a non-negative integer that is used
1520    to prioritize this pcimRule relative to other pcimRules.  A larger
1521    value indicates a higher priority.  It is defined as follows:
1522
1523      ( 1.3.6.1.1.6.2.12 NAME 'pcimRulePriority'
1524             DESC 'A non-negative integer for prioritizing this
1525                   pcimRule relative to other pcimRules.  A larger
1526                   value indicates a higher priority.'
1527             EQUALITY integerMatch
1528             ORDERING integerOrderingMatch
1529             SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1530             SINGLE-VALUE
1531      )
1532
1533    Note: if the value of the pcimRulePriority field is 0, then it SHOULD
1534    be treated as "don't care".  On the other hand, if the value is
1535    negative, then it SHOULD be treated as an error and Administrators
1536    SHOULD treat this rule as being disabled.
1537
1538    The pcimRuleMandatory attribute is a Boolean attribute that, if TRUE,
1539    indicates that for this policy rule, the evaluation of its conditions
1540    and execution of its actions (if the condition is satisfied) is
1541    required.  If it is FALSE, then the evaluation of its conditions and
1542    execution of its actions (if the condition is satisfied) is not
1543    required.  This attribute is defined as follows:
1544
1545      ( 1.3.6.1.1.6.2.13 NAME 'pcimRuleMandatory'
1546             DESC 'If TRUE, indicates that for this policy rule, the
1547                   evaluation of its conditions and execution of its
1548                   actions (if the condition is satisfied) is required.'
1549             EQUALITY booleanMatch
1550             SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
1551             SINGLE-VALUE
1552      )
1553
1554    The pcimRuleSequencedActions attribute is an integer enumeration that
1555    is used to indicate that the ordering of actions defined by the
1556    pcimActionOrder attribute is either  mandatory(value=1),
1557    recommended(value=2), or dontCare(value=3).  It is defined as
1558    follows:
1559
1560      ( 1.3.6.1.1.6.2.14 NAME 'pcimRuleSequencedActions'
1561             DESC 'An integer enumeration indicating that the ordering of
1562                   actions defined by the pcimActionOrder attribute is
1563                   mandatory(1), recommended(2), or dontCare(3).'
1564             EQUALITY integerMatch
1565             ORDERING integerOrderingMatch
1566
1567
1568
1569
1570 Strassner, et al.           Standards Track                    [Page 28]
1571 \f
1572 RFC 3703                Policy Core LDAP Schema            February 2004
1573
1574
1575             SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1576             SINGLE-VALUE
1577      )
1578
1579    Note: if the value of pcimRulesSequencedActions field is not one of
1580    these three values, then Administrators SHOULD treat this rule as
1581    being disabled.
1582
1583    The pcimRoles attribute represents the policyRoles property of [1].
1584    Each value of this attribute represents a role-combination, which is
1585    a string of the form:
1586        <RoleName>[&&<RoleName>]* where the individual role names appear
1587    in alphabetical order according to the collating sequence for UCS-2.
1588    This attribute is defined as follows:
1589
1590      ( 1.3.6.1.1.6.2.15 NAME 'pcimRoles'
1591             DESC 'Each value of this attribute represents a role-
1592                   combination.'
1593             EQUALITY caseIgnoreMatch
1594             ORDERING caseIgnoreOrderingMatch
1595             SUBSTR caseIgnoreSubstringsMatch
1596             SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1597      )
1598
1599    Note: if the value of the pcimRoles attribute does not conform to the
1600    format "<RoleName>[&&<RoleName>]*" (see Section 6.3.7 of [1]), then
1601    this attribute is malformed and its policy rule SHOULD be treated as
1602    being disabled.
1603
1604    The two subclasses of the pcimRule class are defined as follows.
1605    First, the pcimRuleAuxClass is an auxiliary class for representing
1606    the "If Condition then Action" semantics associated with a policy
1607    rule.  Its class definition is as follows:
1608
1609      ( 1.3.6.1.1.6.1.6 NAME 'pcimRuleAuxClass'
1610             DESC 'An auxiliary class for representing the "If Condition
1611                  then Action" semantics associated with a policy rule.'
1612             SUP pcimRule
1613             AUXILIARY
1614      )
1615
1616    The pcimRuleInstance is a structural class for representing the "If
1617    Condition then Action" semantics associated with a policy rule.  Its
1618    class definition is as follows:
1619
1620      ( 1.3.6.1.1.6.1.7 NAME 'pcimRuleInstance'
1621             DESC 'A structural class for representing the "If Condition
1622                  then Action" semantics associated with a policy rule.'
1623
1624
1625
1626 Strassner, et al.           Standards Track                    [Page 29]
1627 \f
1628 RFC 3703                Policy Core LDAP Schema            February 2004
1629
1630
1631             SUP pcimRule
1632             STRUCTURAL
1633      )
1634
1635    A DIT content rule could be written to enable an instance of
1636    pcimRuleInstance to have attached to it either references to one or
1637    more policy conditions (using pcimConditionAuxClass) or references to
1638    one or more policy actions (using pcimActionAuxClass).  This would be
1639    used to formalize the semantics of the PolicyRule class [1].  Since
1640    these semantics do not include specifying any properties of the
1641    PolicyRule class, the content rule would not need to specify any
1642    attributes.
1643
1644    Similarly, three separate DIT structure rules could be written, each
1645    of which would refer to a specific name form that identified one of
1646    its three possible naming attributes (i.e., pcimRuleName, cn, and
1647    orderedCIMKeys).  This structure rule SHOULD include a
1648    superiorStructureRule (see Note 2 at the beginning of section 5).
1649    The three name forms referenced by the three structure rules would
1650    each define one of the three naming attributes.
1651
1652 5.4.  The Class pcimRuleConditionAssociation
1653
1654    This class contains attributes to represent the properties of the
1655    PCIM's PolicyConditionInPolicyRule association.  Instances of this
1656    class are related to an instance of pcimRule via DIT containment.
1657    The policy conditions themselves are represented by auxiliary
1658    subclasses of the auxiliary class pcimConditionAuxClass.  These
1659    auxiliary classes are attached directly to instances of
1660    pcimRuleConditionAssociation for rule-specific policy conditions.
1661    For a reusable policy condition, the policyCondition auxiliary
1662    subclass is attached to an instance of the class pcimPolicyInstance
1663    (which is presumably associated with a pcimRepository by DIT
1664    containment), and the policyConditionDN attribute (of this class) is
1665    used to reference the reusable policyCondition instance.
1666
1667    The class definition is as follows:
1668
1669      ( 1.3.6.1.1.6.1.8 NAME 'pcimRuleConditionAssociation'
1670             DESC 'This class contains attributes characterizing the
1671                   relationship between a policy rule and one of its
1672                   policy conditions.'
1673             SUP pcimPolicy
1674             MUST ( pcimConditionGroupNumber $ pcimConditionNegated )
1675             MAY ( pcimConditionName $ pcimConditionDN )
1676      )
1677
1678
1679
1680
1681
1682 Strassner, et al.           Standards Track                    [Page 30]
1683 \f
1684 RFC 3703                Policy Core LDAP Schema            February 2004
1685
1686
1687    The attributes of this class are defined as follows.
1688
1689    The pcimConditionGroupNumber attribute is a non-negative integer.  It
1690    is used to identify the group to which the condition referenced by
1691    this association is assigned.  This attribute is defined as follows:
1692
1693      ( 1.3.6.1.1.6.2.16
1694             NAME 'pcimConditionGroupNumber'
1695             DESC 'The number of the group to which a policy condition
1696                   belongs.  This is used to form the DNF or CNF
1697                   expression associated with a policy rule.'
1698             EQUALITY integerMatch
1699             ORDERING integerOrderingMatch
1700             SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1701             SINGLE-VALUE
1702      )
1703
1704    Note that this number is non-negative.  A negative value for this
1705    attribute is invalid, and any policy rule that refers to an invalid
1706    entry SHOULD be treated as being disabled.
1707
1708    The pcimConditionNegated attribute is a Boolean attribute that
1709    indicates whether this policy condition is to be negated or not.  If
1710    it is TRUE (FALSE), it indicates that a policy condition IS (IS NOT)
1711    negated in the DNF or CNF expression associated with a policy rule.
1712    This attribute is defined as follows:
1713
1714      ( 1.3.6.1.1.6.2.17
1715             NAME 'pcimConditionNegated'
1716             DESC 'If TRUE (FALSE), it indicates that a policy condition
1717                   IS (IS NOT) negated in the DNF or CNF expression
1718                   associated with a policy rule.'
1719             EQUALITY booleanMatch
1720             SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
1721             SINGLE-VALUE
1722      )
1723
1724    The pcimConditionName is a user-friendly name for identifying this
1725    policy condition, and may be used as a naming attribute if desired.
1726    This attribute is defined as follows:
1727
1728      ( 1.3.6.1.1.6.2.18
1729             NAME 'pcimConditionName'
1730             DESC 'A user-friendly name for a policy condition.'
1731             EQUALITY caseIgnoreMatch
1732             ORDERING caseIgnoreOrderingMatch
1733             SUBSTR caseIgnoreSubstringsMatch
1734
1735
1736
1737
1738 Strassner, et al.           Standards Track                    [Page 31]
1739 \f
1740 RFC 3703                Policy Core LDAP Schema            February 2004
1741
1742
1743             SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1744             SINGLE-VALUE
1745      )
1746
1747    The pcimConditionDN attribute is a DN that references an instance of
1748    a reusable policy condition.  This attribute is defined as follows:
1749
1750      ( 1.3.6.1.1.6.2.19
1751             NAME 'pcimConditionDN'
1752             DESC 'A DN that references an instance of a reusable policy
1753                   condition.'
1754             EQUALITY distinguishedNameMatch
1755             SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1756             SINGLE-VALUE
1757      )
1758
1759    A DIT content rule could be written to enable an instance of
1760    pcimRuleConditionAssociation to have attached to it an instance of
1761    the auxiliary class pcimConditionAuxClass, or one of its subclasses.
1762    This would be used to formalize the semantics of the
1763    PolicyConditionInPolicyRule association.  Specifically, this would be
1764    used to represent a rule-specific policy condition [1].
1765    Similarly, three separate DIT structure rules could be written.  Each
1766    of these DIT structure rules would refer to a specific name form that
1767    defined two important semantics.  First, each name form would
1768    identify one of the three possible naming attributes (i.e.,
1769    pcimConditionName, cn, and orderedCIMKeys) for the
1770    pcimRuleConditionAssociation object class.  Second, each name form
1771    would require that an instance of the pcimRuleConditionAssociation
1772    class have as its superior an instance of the pcimRule class.  This
1773    structure rule SHOULD also include a superiorStructureRule (see Note
1774    2 at the beginning of section 5).
1775
1776 5.5.  The Class pcimRuleValidityAssociation
1777
1778    The policyRuleValidityPeriod aggregation is mapped to the PCLS
1779    pcimRuleValidityAssociation class.  This class represents the
1780    scheduled activation and deactivation of a policy rule by binding the
1781    definition of times that the policy is active to the policy rule
1782    itself.  The "scheduled" times are either identified through an
1783    attached auxiliary class pcimTPCAuxClass, or are referenced through
1784    its pcimTimePeriodConditionDN attribute.
1785
1786    This class is defined as follows:
1787
1788      ( 1.3.6.1.1.6.1.9 NAME 'pcimRuleValidityAssociation'
1789            DESC 'This defines the scheduled activation or deactivation
1790                  of a policy rule.'
1791
1792
1793
1794 Strassner, et al.           Standards Track                    [Page 32]
1795 \f
1796 RFC 3703                Policy Core LDAP Schema            February 2004
1797
1798
1799            SUP pcimPolicy
1800            STRUCTURAL
1801            MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN )
1802      )
1803
1804    The attributes of this class are defined as follows:
1805
1806    The pcimValidityConditionName attribute is used to define a
1807    user-friendly name of this condition, and may be used as a naming
1808    attribute if desired.  This attribute is defined as follows:
1809
1810      ( 1.3.6.1.1.6.2.20
1811             NAME 'pcimValidityConditionName'
1812             DESC 'A user-friendly name for identifying an instance of
1813                   a pcimRuleValidityAssociation entry.'
1814             EQUALITY caseIgnoreMatch
1815             ORDERING caseIgnoreOrderingMatch
1816             SUBSTR caseIgnoreSubstringsMatch
1817             SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1818             SINGLE-VALUE
1819      )
1820
1821    The pcimTimePeriodConditionDN attribute is a DN that references a
1822    reusable time period condition.  It is defined as follows:
1823
1824      ( 1.3.6.1.1.6.2.21
1825             NAME 'pcimTimePeriodConditionDN'
1826              DESC 'A reference to a reusable policy time period
1827                    condition.'
1828             EQUALITY distinguishedNameMatch
1829             SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1830             SINGLE-VALUE
1831      )
1832
1833    A DIT content rule could be written to enable an instance of
1834    pcimRuleValidityAssociation to have attached to it an instance of the
1835    auxiliary class pcimTPCAuxClass, or one of its subclasses.  This
1836    would be used to formalize the semantics of the
1837    PolicyRuleValidityPeriod aggregation [1].
1838
1839    Similarly, three separate DIT structure rules could be written.  Each
1840    of these DIT structure rules would refer to a specific name form that
1841    defined two important semantics.  First, each name form would
1842    identify one of the three possible naming attributes (i.e.,
1843    pcimValidityConditionName, cn, and orderedCIMKeys) for the
1844    pcimRuleValidityAssociation object class.  Second, each name form
1845    would require that an instance of the pcimRuleValidityAssociation
1846    class have as its superior an instance of the pcimRule class.  This
1847
1848
1849
1850 Strassner, et al.           Standards Track                    [Page 33]
1851 \f
1852 RFC 3703                Policy Core LDAP Schema            February 2004
1853
1854
1855    structure rule SHOULD also include a superiorStructureRule (see Note
1856    2 at the beginning of section 5).
1857
1858 5.6.  The Class pcimRuleActionAssociation
1859
1860    This class contains an attribute to represent the one property of the
1861    PCIM PolicyActionInPolicyRule association, ActionOrder.  This
1862    property is used to specify an order for executing the actions
1863    associated with a policy rule.  Instances of this class are related
1864    to an instance of pcimRule via DIT containment.  The actions
1865    themselves are represented by auxiliary subclasses of the auxiliary
1866    class pcimActionAuxClass.
1867
1868    These auxiliary classes are attached directly to instances of
1869    pcimRuleActionAssociation for rule-specific policy actions.  For a
1870    reusable policy action, the pcimAction auxiliary subclass is attached
1871    to an instance of the class pcimPolicyInstance (which is presumably
1872    associated with a pcimRepository by DIT containment), and the
1873    pcimActionDN attribute (of this class) is used to reference the
1874    reusable pcimCondition instance.
1875
1876    The class definition is as follows:
1877
1878      ( 1.3.6.1.1.6.1.10 NAME 'pcimRuleActionAssociation'
1879             DESC 'This class contains attributes characterizing the
1880                   relationship between a policy rule and one of its
1881                   policy actions.'
1882             SUP pcimPolicy
1883             MUST ( pcimActionOrder )
1884             MAY ( pcimActionName $ pcimActionDN )
1885      )
1886
1887    The pcimActionName attribute is used to define a user-friendly name
1888    of this action, and may be used as a naming attribute if desired.
1889    This attribute is defined as follows:
1890
1891      ( 1.3.6.1.1.6.2.22
1892             NAME 'pcimActionName'
1893             DESC 'A user-friendly name for a policy action.'
1894             EQUALITY caseIgnoreMatch
1895             ORDERING caseIgnoreOrderingMatch
1896             SUBSTR caseIgnoreSubstringsMatch
1897             SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
1898             SINGLE-VALUE
1899      )
1900
1901
1902
1903
1904
1905
1906 Strassner, et al.           Standards Track                    [Page 34]
1907 \f
1908 RFC 3703                Policy Core LDAP Schema            February 2004
1909
1910
1911    The pcimActionOrder attribute is an unsigned integer that is used to
1912    indicate the relative position of an action in a sequence of actions
1913    that are associated with a given policy rule.  When this number is
1914    positive, it indicates a place in the sequence of actions to be
1915    performed, with smaller values indicating earlier positions in the
1916    sequence.  If the value is zero, then this indicates that the order
1917    is irrelevant.  Note that if two or more actions have the same
1918    non-zero value, they may be performed in any order as long as they
1919    are each performed in the correct place in the overall sequence of
1920    actions.  This attribute is defined as follows:
1921
1922      ( 1.3.6.1.1.6.2.23
1923             NAME 'pcimActionOrder'
1924             DESC 'An integer indicating the relative order of an action
1925                   in the context of a policy rule.'
1926             EQUALITY integerMatch
1927             ORDERING integerOrderingMatch
1928             SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1929             SINGLE-VALUE
1930      )
1931
1932    Note: if the value of the pcimActionOrder field is negative, then it
1933    SHOULD be treated as an error and any policy rule that refers to such
1934    an entry SHOULD be treated as being disabled.
1935
1936    The pcimActionDN attribute is a DN that references a reusable policy
1937    action.  It is defined as follows:
1938
1939      ( 1.3.6.1.1.6.2.24
1940             NAME 'pcimActionDN'
1941             DESC 'A DN that references a reusable policy action.'
1942             EQUALITY distinguishedNameMatch
1943             SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1944             SINGLE-VALUE
1945      )
1946
1947    A DIT content rule could be written to enable an instance of
1948    pcimRuleActionAssociation to have attached to it an instance of the
1949    auxiliary class pcimActionAuxClass, or one of its subclasses.  This
1950    would be used to formalize the semantics of the
1951    PolicyActionInPolicyRule association.  Specifically, this would be
1952    used to represent a rule-specific policy action [1].
1953
1954    Similarly, three separate DIT structure rules could be written.  Each
1955    of these DIT structure rules would refer to a specific name form that
1956    defined two important semantics.  First, each name form would
1957    identify one of the three possible naming attributes (i.e.,
1958    pcimActionName, cn, and orderedCIMKeys) for the
1959
1960
1961
1962 Strassner, et al.           Standards Track                    [Page 35]
1963 \f
1964 RFC 3703                Policy Core LDAP Schema            February 2004
1965
1966
1967    pcimRuleActionAssociation object class.  Second, each name form would
1968    require that an instance of the pcimRuleActionAssociation class have
1969    as its superior an instance of the pcimRule class.  This structure
1970    rule should also include a superiorStructureRule (see Note 2 at the
1971    beginning of section 5).
1972
1973 5.7.  The Auxiliary Class pcimConditionAuxClass
1974
1975    The purpose of a policy condition is to determine whether or not the
1976    set of actions (contained in the pcimRule that the condition applies
1977    to) should be executed or not.  This class defines the basic
1978    organizational semantics of a policy condition, as specified in [1].
1979    Subclasses of this auxiliary class can be attached to instances of
1980    three other classes in the PCLS.  When a subclass of this class is
1981    attached to an instance of pcimRuleConditionAssociation, or to an
1982    instance of pcimRule, it represents a rule-specific policy condition.
1983    When a subclass of this class is attached to an instance of
1984    pcimPolicyInstance, it represents a reusable policy condition.
1985
1986    Since all of the classes to which subclasses of this auxiliary class
1987    may be attached are derived from the pcimPolicy class, the attributes
1988    of pcimPolicy will already be defined for the entries to which these
1989    subclasses attach.  Thus, this class is derived directly from "top".
1990
1991    The class definition is as follows:
1992
1993      ( 1.3.6.1.1.6.1.11 NAME 'pcimConditionAuxClass'
1994             DESC 'A class representing a condition to be evaluated in
1995                   conjunction with a policy rule.'
1996             SUP top
1997             AUXILIARY
1998      )
1999
2000 5.8.  The Auxiliary Class pcimTPCAuxClass
2001
2002    The PCIM defines a time period class, PolicyTimePeriodCondition, to
2003    provide a means of representing the time periods during which a
2004    policy rule is valid, i.e., active.  It also defines an aggregation,
2005    PolicyRuleValidityPeriod, so that time periods can be associated with
2006    a PolicyRule.  The LDAP mapping also provides two classes, one for
2007    the time condition itself, and one for the aggregation.
2008
2009    In the PCIM, the time period class is named
2010    PolicyTimePeriodCondition. However, the resulting name of the
2011    auxiliary class in this mapping (pcimTimePeriodConditionAuxClass)
2012    exceeds the length of a name that some directories can store.
2013    Therefore, the name has been shortened to pcimTPCAuxClass.
2014
2015
2016
2017
2018 Strassner, et al.           Standards Track                    [Page 36]
2019 \f
2020 RFC 3703                Policy Core LDAP Schema            February 2004
2021
2022
2023    The class definition is as follows:
2024
2025      ( 1.3.6.1.1.6.1.12 NAME 'pcimTPCAuxClass'
2026             DESC 'This provides the capability of enabling or disabling
2027                   a policy rule according to a predetermined schedule.'
2028             SUP pcimConditionAuxClass
2029             AUXILIARY
2030             MAY ( pcimTPCTime $ pcimTPCMonthOfYearMask $
2031                   pcimTPCDayOfMonthMask $ pcimTPCDayOfWeekMask $
2032                   pcimTPCTimeOfDayMask $ pcimTPCLocalOrUtcTime )
2033      )
2034
2035    The attributes of the pcimTPCAuxClass are defined as follows.
2036
2037    The pcimTPCTime attribute represents the time period that a policy
2038    rule is enabled for.  This attribute is defined as a string in [1]
2039    with a special format which defines a time period with a starting
2040    date and an ending date separated by a forward slash ("/"), as
2041    follows:
2042
2043        yyyymmddThhmmss/yyyymmddThhmmss
2044
2045    where the first date and time may be replaced with the string
2046    "THISANDPRIOR" or the second date and time may be replaced with the
2047    string "THISANDFUTURE".  This attribute is defined as follows:
2048
2049         ( 1.3.6.1.1.6.2.25
2050                NAME 'pcimTPCTime'
2051                DESC 'The start and end times on which a policy rule is
2052                      valid.'
2053                EQUALITY caseIgnoreMatch
2054                ORDERING caseIgnoreOrderingMatch
2055                SUBSTR caseIgnoreSubstringsMatch
2056                SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
2057                SINGLE-VALUE
2058         )
2059
2060    The value of this attribute SHOULD be checked against its defined
2061    format ("yyyymmddThhmmss/yyyymmddThhmmss", where the first and second
2062    date strings may be replaced with the strings "THISANDPRIOR" and
2063    "THISANDFUTURE").  If the value of this attribute does not conform to
2064    this syntax, then this SHOULD be considered an error and the policy
2065    rule SHOULD be treated as being disabled.
2066
2067    The next four attributes (pcimTPCMonthOfYearMask,
2068    pcimTPCDayOfMonthMask, pcimTPCDayOfWeekMask, and
2069    pcimTPCTimeOfDayMask) are all defined as octet strings in [1].
2070    However, the semantics of each of these attributes are contained in
2071
2072
2073
2074 Strassner, et al.           Standards Track                    [Page 37]
2075 \f
2076 RFC 3703                Policy Core LDAP Schema            February 2004
2077
2078
2079    bit strings of various fixed lengths.  Therefore, the PCLS uses a
2080    syntax of Bit String to represent each of them.  The definition of
2081    these four attributes are as follows.
2082
2083    The pcimTPCMonthOfYearMask attribute defines a 12-bit mask
2084    identifying the months of the year in which a policy rule is valid.
2085    The format is a bit string of length 12, representing the months of
2086    the year from January through December.  The definition of this
2087    attribute is as follows:
2088
2089      ( 1.3.6.1.1.6.2.26
2090             NAME 'pcimTPCMonthOfYearMask'
2091             DESC 'This identifies the valid months of the year for a
2092                   policy rule using a 12-bit string that represents the
2093                   months of the year from January through December.'
2094             EQUALITY bitStringMatch
2095             SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
2096             SINGLE-VALUE
2097      )
2098
2099    The value of this attribute SHOULD be checked against its defined
2100    format.  If the value of this attribute does not conform to this
2101    syntax, then this SHOULD be considered an error and the policy rule
2102    SHOULD be treated as being disabled.
2103
2104    The pcimTPCMonthOfDayMask attribute defines a mask identifying the
2105    days of the month on which a policy rule is valid.  The format is a
2106    bit string of length 62.  The first 31 positions represent the days
2107    of the month in ascending order, from day 1 to day 31.  The next 31
2108    positions represent the days of the month in descending order, from
2109    the last day to the day 31 days from the end.  The definition of this
2110    attribute is as follows:
2111
2112      ( 1.3.6.1.1.6.2.27
2113             NAME 'pcimTPCDayOfMonthMask'
2114             DESC 'This identifies the valid days of the month for a
2115                   policy rule using a 62-bit string. The first 31
2116                   positions represent the days of the month in ascending
2117                   order, and the next 31 positions represent the days of
2118                   the month in descending order.'
2119             EQUALITY bitStringMatch
2120             SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
2121             SINGLE-VALUE
2122      )
2123
2124
2125
2126
2127
2128
2129
2130 Strassner, et al.           Standards Track                    [Page 38]
2131 \f
2132 RFC 3703                Policy Core LDAP Schema            February 2004
2133
2134
2135    The value of this attribute SHOULD be checked against its defined
2136    format.  If the value of this attribute does not conform to this
2137    syntax, then this SHOULD be considered an error and the policy rule
2138    SHOULD be treated as being disabled.
2139
2140    The pcimTPCDayOfWeekMask attribute defines a mask identifying the
2141    days of the week on which a policy rule is valid.  The format is a
2142    bit string of length 7, representing the days of the week from Sunday
2143    through Saturday.  The definition of this attribute is as follows:
2144
2145      ( 1.3.6.1.1.6.2.28
2146             NAME 'pcimTPCDayOfWeekMask'
2147             DESC 'This identifies the valid days of the week for a
2148                   policy rule using a 7-bit string. This represents
2149                   the days of the week from Sunday through Saturday.'
2150             EQUALITY bitStringMatch
2151             SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
2152             SINGLE-VALUE
2153      )
2154
2155    The value of this attribute SHOULD be checked against its defined
2156    format.  If the value of this attribute does not conform to this
2157    syntax, then this SHOULD be considered an error and the policy rule
2158    SHOULD be treated as being disabled.
2159
2160    The pcimTPCTimeOfDayMask attribute defines the range of times at
2161    which a policy rule is valid.  If the second time is earlier than the
2162    first, then the interval spans midnight.  The format of the string is
2163    Thhmmss/Thhmmss.  The definition of this attribute is as follows:
2164
2165      ( 1.3.6.1.1.6.2.29
2166             NAME 'pcimTPCTimeOfDayMask'
2167             DESC 'This identifies the valid range of times for a policy
2168                   using the format Thhmmss/Thhmmss.'
2169             EQUALITY caseIgnoreMatch
2170             ORDERING caseIgnoreOrderingMatch
2171             SUBSTR caseIgnoreSubstringsMatch
2172             SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
2173             SINGLE-VALUE
2174      )
2175
2176    The value of this attribute SHOULD be checked against its defined
2177    format.  If the value of this attribute does not conform to this
2178    syntax, then this SHOULD be considered an error and the policy rule
2179    SHOULD be treated as being disabled.
2180
2181
2182
2183
2184
2185
2186 Strassner, et al.           Standards Track                    [Page 39]
2187 \f
2188 RFC 3703                Policy Core LDAP Schema            February 2004
2189
2190
2191    Finally, the pcimTPCLocalOrUtcTime attribute is used to choose
2192    between local or UTC time representation.  This is mapped as a simple
2193    integer syntax, with the value of 1 representing local time and the
2194    value of 2 representing UTC time.  The definition of this attribute
2195    is as follows:
2196
2197      ( 1.3.6.1.1.6.2.30
2198             NAME 'pcimTPCLocalOrUtcTime'
2199             DESC 'This defines whether the times in this instance
2200                   represent local (value=1) times or UTC (value=2)
2201                   times.'
2202             EQUALITY integerMatch
2203             ORDERING integerOrderingMatch
2204             SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
2205             SINGLE-VALUE
2206      )
2207
2208    Note: if the value of the pcimTPCLocalOrUtcTime is not 1 or 2, then
2209    this SHOULD be considered an error and the policy rule SHOULD be
2210    disabled. If the attribute is not present at all, then all times are
2211    interpreted as if it were present with the value 2, that is, UTC
2212    time.
2213
2214 5.9.  The Auxiliary Class pcimConditionVendorAuxClass
2215
2216    This class provides a general extension mechanism for representing
2217    policy conditions that have not been modeled with specific
2218    properties. Instead, its two properties are used to define the
2219    content and format of the condition, as explained below.  This class
2220    is intended for vendor-specific extensions that are not amenable to
2221    using pcimCondition; standardized extensions SHOULD NOT use this
2222    class.
2223
2224    The class definition is as follows:
2225
2226      ( 1.3.6.1.1.6.1.13 NAME 'pcimConditionVendorAuxClass'
2227             DESC 'A class that defines a registered means to describe a
2228                   policy condition.'
2229             SUP pcimConditionAuxClass
2230             AUXILIARY
2231             MAY ( pcimVendorConstraintData $
2232                  pcimVendorConstraintEncoding )
2233      )
2234
2235    The pcimVendorConstraintData attribute is a multi-valued attribute.
2236    It provides a general mechanism for representing policy conditions
2237    that have not been modeled as specific attributes.  This information
2238    is encoded in a set of octet strings.  The format of the octet
2239
2240
2241
2242 Strassner, et al.           Standards Track                    [Page 40]
2243 \f
2244 RFC 3703                Policy Core LDAP Schema            February 2004
2245
2246
2247    strings is identified by the OID stored in the
2248    pcimVendorConstraintEncoding attribute.  This attribute is defined as
2249    follows:
2250
2251      ( 1.3.6.1.1.6.2.31
2252             NAME 'pcimVendorConstraintData'
2253             DESC 'Mechanism for representing constraints that have not
2254                   been modeled as specific attributes.  Their format is
2255                   identified by the OID stored in the attribute
2256                   pcimVendorConstraintEncoding.'
2257             EQUALITY octetStringMatch
2258             ORDERING octetStringOrderingMatch
2259             SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
2260      )
2261
2262    The pcimVendorConstraintEncoding attribute is used to identify the
2263    format and semantics for the pcimVendorConstraintData attribute.
2264    This attribute is defined as follows:
2265
2266      ( 1.3.6.1.1.6.2.32
2267             NAME 'pcimVendorConstraintEncoding'
2268             DESC 'An OID identifying the format and semantics for the
2269                   pcimVendorConstraintData for this instance.'
2270             EQUALITY objectIdentifierMatch
2271             SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2272             SINGLE-VALUE
2273      )
2274
2275 5.10.  The Auxiliary Class pcimActionAuxClass
2276
2277    The purpose of a policy action is to execute one or more operations
2278    that will affect network traffic and/or systems, devices, etc. in
2279    order to achieve a desired policy state.  This class is used to
2280    represent an action to be performed as a result of a policy rule
2281    whose condition clause was satisfied.
2282
2283    Subclasses of this auxiliary class can be attached to instances of
2284    three other classes in the PCLS.  When a subclass of this class is
2285    attached to an instance of pcimRuleActionAssociation, or to an
2286    instance of pcimRule, it represents a rule-specific policy action.
2287    When a subclass of this class is attached to an instance of
2288    pcimPolicyInstance, it represents a reusable policy action.
2289
2290    Since all of the classes to which subclasses of this auxiliary class
2291    may be attached are derived from the pcimPolicy class, the attributes
2292    of the pcimPolicy class will already be defined for the entries to
2293    which these subclasses attach.  Thus, this class is derived directly
2294    from "top".
2295
2296
2297
2298 Strassner, et al.           Standards Track                    [Page 41]
2299 \f
2300 RFC 3703                Policy Core LDAP Schema            February 2004
2301
2302
2303    The class definition is as follows:
2304
2305      ( 1.3.6.1.1.6.1.14 NAME 'pcimActionAuxClass'
2306             DESC 'A class representing an action to be performed as a
2307                   result of a policy rule.'
2308             SUP top
2309             AUXILIARY
2310      )
2311
2312 5.11.  The Auxiliary Class pcimActionVendorAuxClass
2313
2314    The purpose of this class is to provide a general extension mechanism
2315    for representing policy actions that have not been modeled with
2316    specific properties.  Instead, its two properties are used to define
2317    the content and format of the action, as explained below.
2318
2319    As its name suggests, this class is intended for vendor-specific
2320    extensions that are not amenable to using the standard pcimAction
2321    class.  Standardized extensions SHOULD NOT use this class.
2322
2323    The class definition is as follows:
2324
2325      ( 1.3.6.1.1.6.1.15 NAME 'pcimActionVendorAuxClass'
2326             DESC 'A class that defines a registered means to describe a
2327                   policy action.'
2328             SUP pcimActionAuxClass
2329             AUXILIARY
2330             MAY ( pcimVendorActionData $ pcimVendorActionEncoding )
2331      )
2332
2333    The pcimVendorActionData attribute is a multi-valued attribute.  It
2334    provides a general mechanism for representing policy actions that
2335    have not been modeled as specific attributes.  This information is
2336    encoded in a set of octet strings.  The format of the octet strings
2337    is identified by the OID stored in the pcimVendorActionEncoding
2338    attribute.  This attribute is defined as follows:
2339
2340      ( 1.3.6.1.1.6.2.33
2341             NAME 'pcimVendorActionData'
2342             DESC ' Mechanism for representing policy actions that have
2343                    not been modeled as specific attributes.  Their
2344                    format is identified by the OID stored in the
2345                    attribute pcimVendorActionEncoding.'
2346             EQUALITY octetStringMatch
2347             ORDERING octetStringOrderingMatch
2348             SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
2349      )
2350
2351
2352
2353
2354 Strassner, et al.           Standards Track                    [Page 42]
2355 \f
2356 RFC 3703                Policy Core LDAP Schema            February 2004
2357
2358
2359    The pcimVendorActionEncoding attribute is used to identify the format
2360    and semantics for the pcimVendorActionData attribute.  This attribute
2361    is defined as follows:
2362
2363      ( 1.3.6.1.1.6.2.34
2364             NAME 'pcimVendorActionEncoding'
2365             DESC 'An OID identifying the format and semantics for the
2366                   pcimVendorActionData attribute of this instance.'
2367             EQUALITY objectIdentifierMatch
2368             SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2369             SINGLE-VALUE
2370      )
2371
2372 5.12.  The Class pcimPolicyInstance
2373
2374    This class is not defined in the PCIM.  Its role is to serve as a
2375    structural class to which auxiliary classes representing policy
2376    information are attached when the information is reusable.  For
2377    auxiliary classes representing policy conditions and policy actions,
2378    there are alternative structural classes that may be used.  See
2379    Section 4.4 for a complete discussion of reusable policy conditions
2380    and actions, and of the role that this class plays in how they are
2381    represented.
2382
2383    The class definition is as follows:
2384
2385      ( 1.3.6.1.1.6.1.16 NAME 'pcimPolicyInstance'
2386             DESC 'A structural class to which aux classes containing
2387                   reusable policy information can be attached.'
2388             SUP pcimPolicy
2389             MAY ( pcimPolicyInstanceName )
2390      )
2391
2392    The pcimPolicyInstanceName attribute is used to define a
2393    user-friendly name of this class, and may be used as a naming
2394    attribute if desired.  It is defined as follows:
2395
2396      ( 1.3.6.1.1.6.2.35 NAME 'pcimPolicyInstanceName'
2397             DESC 'The user-friendly name of this policy instance.'
2398             EQUALITY caseIgnoreMatch
2399             ORDERING caseIgnoreOrderingMatch
2400             SUBSTR caseIgnoreSubstringsMatch
2401             SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
2402             SINGLE-VALUE
2403      )
2404
2405
2406
2407
2408
2409
2410 Strassner, et al.           Standards Track                    [Page 43]
2411 \f
2412 RFC 3703                Policy Core LDAP Schema            February 2004
2413
2414
2415    A DIT content rule could be written to enable an instance of
2416    pcimPolicyInstance to have attached to it either instances of one or
2417    more of the auxiliary object classes pcimConditionAuxClass and
2418    pcimActionAuxClass.  Since these semantics do not include specifying
2419    any properties, the content rule would not need to specify any
2420    attributes.  Note that other content rules could be defined to enable
2421    other policy-related auxiliary classes to be attached to
2422    pcimPolicyInstance.
2423
2424    Similarly, three separate DIT structure rules could be written.  Each
2425    of these DIT structure rules would refer to a specific name form that
2426    defined two important semantics.  First, each name form would
2427    identify one of the three possible naming attributes (i.e.,
2428    pcimPolicyInstanceName, cn, and orderedCIMKeys) for this object
2429    class.  Second, each name form would require that an instance of the
2430    pcimPolicyInstance class have as its superior an instance of the
2431    pcimRepository class.  This structure rule SHOULD also include a
2432    superiorStructureRule (see Note 2 at the beginning of section 5).
2433
2434 5.13.  The Auxiliary Class pcimElementAuxClass
2435
2436    This class introduces no additional attributes, beyond those defined
2437    in the class pcimPolicy from which it is derived.  Its role is to
2438    "tag" an instance of a class defined outside the realm of policy
2439    information as represented by PCIM as being nevertheless relevant to
2440    a policy specification.  This tagging can potentially take place at
2441    two levels:
2442
2443    -   Every instance to which pcimElementAuxClass is attached becomes
2444        an instance of the class pcimPolicy, since pcimElementAuxClass is
2445        a subclass of pcimPolicy.  Searching for object
2446        class="pcimPolicy" will return the instance.  (As noted earlier,
2447        this approach does NOT work for some directory implementations.
2448        To accommodate these implementations, policy-related entries
2449        SHOULD be tagged with the pcimKeyword "POLICY".)
2450
2451    -   With the pcimKeywords attribute that it inherits from pcimPolicy,
2452        an instance to which pcimElementAuxClass is attached can be
2453        tagged as being relevant to a particular type or category of
2454        policy information, using standard keywords,
2455        administrator-defined keywords, or both.
2456
2457    The class definition is as follows:
2458
2459      ( 1.3.6.1.1.6.1.17 NAME 'pcimElementAuxClass'
2460             DESC 'An auxiliary class used to tag instances of classes
2461                   defined outside the realm of policy as relevant to a
2462                   particular policy specification.'
2463
2464
2465
2466 Strassner, et al.           Standards Track                    [Page 44]
2467 \f
2468 RFC 3703                Policy Core LDAP Schema            February 2004
2469
2470
2471             SUP pcimPolicy
2472             AUXILIARY
2473      )
2474
2475 5.14.  The Three Policy Repository Classes
2476
2477    These classes provide a container for reusable policy information,
2478    such as reusable policy conditions and/or reusable policy actions.
2479    This document is concerned with mapping just the properties that
2480    appear in these classes.  Conceptually, this may be thought of as a
2481    special location in the DIT where policy information may reside.
2482    Since pcimRepository is derived from the class dlm1AdminDomain
2483    defined in reference [6], this specification has a normative
2484    dependency on that element of reference [6] (as well as on its entire
2485    derivation hierarchy, which also appears in reference [6]).  To
2486    maximize flexibility, the pcimRepository class is defined as
2487    abstract.  A subclass pcimRepositoryAuxClass provides for auxiliary
2488    attachment to another entry, while a structural subclass
2489    pcimRepositoryInstance is available to represent a policy repository
2490    as a standalone entry.
2491
2492    The definition for the pcimRepository class is as follows:
2493
2494      ( 1.3.6.1.1.6.1.18 NAME 'pcimRepository'
2495             DESC 'A container for reusable policy information.'
2496             SUP dlm1AdminDomain
2497             ABSTRACT
2498             MAY ( pcimRepositoryName )
2499      )
2500
2501    The pcimRepositoryName attribute is used to define a user-friendly
2502    name of this class, and may be used as a naming attribute if desired.
2503    It is defined as follows:
2504
2505      ( 1.3.6.1.1.6.2.36 NAME 'pcimRepositoryName'
2506             DESC 'The user-friendly name of this policy repository.'
2507             EQUALITY caseIgnoreMatch
2508             ORDERING caseIgnoreOrderingMatch
2509             SUBSTR caseIgnoreSubstringsMatch
2510             SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
2511             SINGLE-VALUE
2512      )
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522 Strassner, et al.           Standards Track                    [Page 45]
2523 \f
2524 RFC 3703                Policy Core LDAP Schema            February 2004
2525
2526
2527    The two subclasses of pcimRepository are defined as follows.  First,
2528    the pcimRepositoryAuxClass is an auxiliary class that can be used to
2529    aggregate reusable policy information.  It is defined as follows:
2530
2531      ( 1.3.6.1.1.6.1.19 NAME 'pcimRepositoryAuxClass'
2532             DESC 'An auxiliary class that can be used to aggregate
2533                   reusable policy information.'
2534             SUP pcimRepository
2535             AUXILIARY
2536      )
2537
2538    In cases where structural classes are needed instead of an auxiliary
2539    class, the pcimRepositoryInstance class is a structural class that
2540    can be used to aggregate reusable policy information.  It is defined
2541    as follows:
2542
2543      ( 1.3.6.1.1.6.1.20 NAME 'pcimRepositoryInstance'
2544             DESC 'A structural class that can be used to aggregate
2545                   reusable policy information.'
2546             SUP pcimRepository
2547             STRUCTURAL
2548      )
2549
2550    Three separate DIT structure rules could be written for this class.
2551    Each of these DIT structure rules would refer to a specific name form
2552    that enabled an instance of the pcimRepository class to be named
2553    under any superior using one of the three possible naming attributes
2554    (i.e., pcimRepositoryName, cn, and orderedCIMKeys).  This structure
2555    rule SHOULD also include a superiorStructureRule (see Note 2 at the
2556    beginning of section 5).
2557
2558 5.15.  The Auxiliary Class pcimSubtreesPtrAuxClass
2559
2560    This auxiliary class provides a single, multi-valued attribute that
2561    references a set of objects that are at the root of DIT subtrees
2562    containing policy-related information.  By attaching this attribute
2563    to instances of various other classes, a policy administrator has a
2564    flexible way of providing an entry point into the directory that
2565    allows a client to locate and retrieve the policy information
2566    relevant to it.
2567
2568    It is intended that these entries are placed in the DIT such that
2569    well-known DNs can be used to reference a well-known structural entry
2570    that has the pcimSubtreesPtrAuxClass attached to it.  In effect, this
2571    defines a set of entry points.  Each of these entry points can
2572    contain and/or reference all related policy entries for
2573
2574
2575
2576
2577
2578 Strassner, et al.           Standards Track                    [Page 46]
2579 \f
2580 RFC 3703                Policy Core LDAP Schema            February 2004
2581
2582
2583    any well-known policy domains.  The pcimSubtreesPtrAuxClass functions
2584    as a tag to identify portions of the DIT that contain policy
2585    information.
2586
2587    This object does not provide the semantic linkages between individual
2588    policy objects, such as those between a policy group and the policy
2589    rules that belong to it.  Its only role is to enable efficient bulk
2590    retrieval of policy-related objects, as described in Section 4.5.
2591
2592    Once the objects have been retrieved, a directory client can
2593    determine the semantic linkages by following references contained in
2594    multi-valued attributes, such as pcimRulesAuxContainedSet.
2595
2596    Since policy-related objects will often be included in the DIT
2597    subtree beneath an object to which this auxiliary class is attached,
2598    a client SHOULD request the policy-related objects from the subtree
2599    under the object with these references at the same time that it
2600    requests the references themselves.
2601
2602    Since clients are expected to behave in this way, the policy
2603    administrator SHOULD make sure that this subtree does not contain so
2604    many objects unrelated to policy that an initial search done in this
2605    way results in a performance problem.  The pcimSubtreesPtrAuxClass
2606    SHOULD NOT be attached to the partition root for a large directory
2607    partition containing a relatively few number of policy-related
2608    objects along with a large number of objects unrelated to policy
2609    (again, "policy" here refers to the PCIM, not the X.501, definition
2610    and use of "policy").  A better approach would be to introduce a
2611    container object immediately below the partition root, attach
2612    pcimSubtreesPtrAuxClass to this container object, and then place all
2613    of the policy-related objects in that subtree.
2614
2615    The class definition is as follows:
2616
2617      ( 1.3.6.1.1.6.1.21 NAME 'pcimSubtreesPtrAuxClass'
2618             DESC 'An auxiliary class providing DN references to roots of
2619                   DIT subtrees containing policy-related objects.'
2620             SUP top
2621             AUXILIARY
2622             MAY ( pcimSubtreesAuxContainedSet )
2623      )
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634 Strassner, et al.           Standards Track                    [Page 47]
2635 \f
2636 RFC 3703                Policy Core LDAP Schema            February 2004
2637
2638
2639    The attribute pcimSubtreesAuxContainedSet provides an unordered set
2640    of DN references to instances of one or more objects under which
2641    policy-related information is present.  The objects referenced may or
2642    may not themselves contain policy-related information.  The attribute
2643    definition is as follows:
2644
2645      ( 1.3.6.1.1.6.2.37
2646             NAME 'pcimSubtreesAuxContainedSet'
2647             DESC 'DNs of objects that serve as roots for DIT subtrees
2648                   containing policy-related objects.'
2649             EQUALITY distinguishedNameMatch
2650             SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
2651      )
2652
2653    Note that the cn attribute does NOT need to be defined for this
2654    class. This is because an auxiliary class is used as a means to
2655    collect common attributes and treat them as properties of an object.
2656    A good analogy is a #include file, except that since an auxiliary
2657    class is a class, all the benefits of a class (e.g., inheritance) can
2658    be applied to an auxiliary class.
2659
2660 5.16.  The Auxiliary Class pcimGroupContainmentAuxClass
2661
2662    This auxiliary class provides a single, multi-valued attribute that
2663    references a set of pcimGroups.  By attaching this attribute to
2664    instances of various other classes, a policy administrator has a
2665    flexible way of providing an entry point into the directory that
2666    allows a client to locate and retrieve the pcimGroups relevant to it.
2667
2668    As is the case with pcimRules, a policy administrator might have
2669    several different references to a pcimGroup in the overall directory
2670    structure. The pcimGroupContainmentAuxClass is the mechanism that
2671    makes it possible for the policy administrator to define all these
2672    different references.
2673
2674    The class definition is as follows:
2675
2676      ( 1.3.6.1.1.6.1.22 NAME 'pcimGroupContainmentAuxClass'
2677             DESC 'An auxiliary class used to bind pcimGroups to an
2678                   appropriate container object.'
2679             SUP top
2680             AUXILIARY
2681             MAY ( pcimGroupsAuxContainedSet )
2682      )
2683
2684
2685
2686
2687
2688
2689
2690 Strassner, et al.           Standards Track                    [Page 48]
2691 \f
2692 RFC 3703                Policy Core LDAP Schema            February 2004
2693
2694
2695    The attribute pcimGroupsAuxContainedSet provides an unordered set of
2696    references to instances of one or more pcimGroups associated with the
2697    instance of a structural class to which this attribute has been
2698    appended.
2699
2700    The attribute definition is as follows:
2701
2702      ( 1.3.6.1.1.6.2.38
2703             NAME 'pcimGroupsAuxContainedSet'
2704             DESC 'DNs of pcimGroups associated in some way with the
2705                   instance to which this attribute has been appended.'
2706             EQUALITY distinguishedNameMatch
2707             SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
2708      )
2709
2710    Note that the cn attribute does NOT have to be defined for this class
2711    for the same reasons as those given for the pcimSubtreesPtrAuxClass
2712    in section 5.15.
2713
2714 5.17.  The Auxiliary Class pcimRuleContainmentAuxClass
2715
2716    This auxiliary class provides a single, multi-valued attribute that
2717    references a set of pcimRules.  By attaching this attribute to
2718    instances of various other classes, a policy administrator has a
2719    flexible way of providing an entry point into the directory that
2720    allows a client to locate and retrieve the pcimRules relevant to it.
2721
2722    A policy administrator might have several different references to a
2723    pcimRule in the overall directory structure.  For example, there
2724    might be references to all pcimRules for traffic originating in a
2725    particular subnet from a directory entry that represents that subnet.
2726    At the same time, there might be references to all pcimRules related
2727    to a particular DiffServ setting from an instance of a pcimGroup
2728    explicitly introduced as a container for DiffServ-related pcimRules.
2729    The pcimRuleContainmentAuxClass is the mechanism that makes it
2730    possible for the policy administrator to define all these separate
2731    references.
2732
2733    The class definition is as follows:
2734
2735      ( 1.3.6.1.1.6.1.23 NAME 'pcimRuleContainmentAuxClass'
2736             DESC 'An auxiliary class used to bind pcimRules to an
2737                   appropriate container object.'
2738             SUP top
2739             AUXILIARY
2740             MAY ( pcimRulesAuxContainedSet )
2741      )
2742
2743
2744
2745
2746 Strassner, et al.           Standards Track                    [Page 49]
2747 \f
2748 RFC 3703                Policy Core LDAP Schema            February 2004
2749
2750
2751    The attribute pcimRulesAuxContainedSet provides an unordered set of
2752    references to one or more instances of pcimRules associated with the
2753    instance of a structural class to which this attribute has been
2754    appended.  The attribute definition is as follows:
2755
2756      ( 1.3.6.1.1.6.2.39
2757             NAME 'pcimRulesAuxContainedSet'
2758             DESC 'DNs of pcimRules associated in some way with the
2759                   instance to which this attribute has been appended.'
2760             EQUALITY distinguishedNameMatch
2761             SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
2762      )
2763
2764    The cn attribute does NOT have to be defined for this class for the
2765    same reasons as those given for the pcimSubtreesPtrAuxClass in
2766    section 5.15.
2767
2768 6.  Extending the Classes Defined in This Document
2769
2770    The following subsections provide general guidance on how to create a
2771    domain-specific schema derived from this document, discuss how the
2772    vendor classes in the PCLS should be used, and explain how
2773    policyTimePeriodConditions are related to other policy conditions.
2774
2775 6.1.  Subclassing pcimConditionAuxClass and pcimActionAuxClass
2776
2777    In Section 4.4, there is a discussion of how, by representing policy
2778    conditions and policy actions as auxiliary classes in a schema, the
2779    flexibility is retained to instantiate a particular condition or
2780    action as either rule-specific or reusable.  This flexibility is lost
2781    if a condition or action class is defined as structural rather than
2782    auxiliary.  For standardized schemata, this document specifies that
2783    domain-specific information MUST be expressed in auxiliary subclasses
2784    of pcimConditionAuxClass and pcimActionAuxClass.  It is RECOMMENDED
2785    that non-standardized schemata follow this practice as well.
2786
2787 6.2.  Using the Vendor Policy Attributes
2788
2789    As discussed Section 5.9, the attributes pcimVendorConstraintData and
2790    pcimVendorConstraintEncoding are included in the
2791    pcimConditionVendorAuxClass to provide a mechanism for representing
2792    vendor-specific policy conditions that are not amenable to being
2793    represented with the pcimCondition class (or its subclasses).  The
2794    attributes pcimVendorActionData and pcimVendorActionEncoding in the
2795    pcimActionVendorAuxClass class play the same role with respect to
2796    actions.  This enables interoperability between different vendors who
2797    could not otherwise interoperate.
2798
2799
2800
2801
2802 Strassner, et al.           Standards Track                    [Page 50]
2803 \f
2804 RFC 3703                Policy Core LDAP Schema            February 2004
2805
2806
2807    For example, imagine a network composed of access devices from vendor
2808    A, edge and core devices from vendor B, and a policy server from
2809    vendor C. It is desirable for this policy server to be able to
2810    configure and manage all of the devices from vendors A and B.
2811    Unfortunately, these devices will in general have little in common
2812    (e.g., different mechanisms, different ways for controlling those
2813    mechanisms, different operating systems, different commands, and so
2814    forth).  The extension conditions provide a way for vendor-specific
2815    commands to be encoded as octet strings, so that a single policy
2816    server can commonly manage devices from different vendors.
2817
2818 6.3.  Using Time Validity Periods
2819
2820    Time validity periods are defined as an auxiliary subclass of
2821    pcimConditionAuxClass, called pcimTPCAuxClass.  This is to allow
2822    their inclusion in the AND/OR condition definitions for a pcimRule.
2823    Care should be taken not to subclass pcimTPCAuxClass to add
2824    domain-specific condition properties.
2825
2826    For example, it would be incorrect to add IPsec- or QoS-specific
2827    condition properties to the pcimTPCAuxClass class, just because IPsec
2828    or QoS includes time in its condition definition.  The correct
2829    subclassing would be to create IPsec or QoS-specific subclasses of
2830    pcimConditionAuxClass and then combine instances of these
2831    domain-specific condition classes with the appropriate validity
2832    period criteria.  This is accomplished using the AND/OR association
2833    capabilities for policy conditions in pcimRules.
2834
2835 7.  Security Considerations
2836
2837    The PCLS, presented in this document, provides a mapping of the
2838    object-oriented model for describing policy information (PCIM) into a
2839    data model that forms the basic framework for describing the
2840    structure of policy data, in the case where the policy repository
2841    takes the form of an LDAP-accessible directory.
2842
2843    PCLS is not intended to represent any particular system design or
2844    implementation.  PCLS is not directly useable in a real world system,
2845    without the discipline-specific mappings that are works in progress
2846    in the Policy Framework Working Group of the IETF.
2847
2848    These other derivative documents, which use PCIM and its
2849    discipline-specific extensions as a base, will need to convey more
2850    specific security considerations (refer to RFC 3060 for more
2851    information.)
2852
2853
2854
2855
2856
2857
2858 Strassner, et al.           Standards Track                    [Page 51]
2859 \f
2860 RFC 3703                Policy Core LDAP Schema            February 2004
2861
2862
2863    The reason that PCLS, as defined here, is not representative of any
2864    real-world system, is that its object classes were designed to be
2865    independent of any specific discipline, or policy domain.  For
2866    example, DiffServ and IPsec represent two different policy domains.
2867    Each document that extends PCIM to one of these domains will derive
2868    subclasses from the classes and relationships defined in PCIM, in
2869    order to represent extensions of a generic model to cover specific
2870    technical domains.
2871
2872    PCIM-derived documents will thus subclass the PCIM classes into
2873    classes specific to each technical policy domain (QOS, IPsec, etc.),
2874    which will, in turn, be mapped, to directory-specific schemata
2875    consistent with the PCLS documented here.
2876
2877    Even though discipline-specific security requirements are not
2878    appropriate for PCLS, specific security requirements MUST be defined
2879    for each operational real-world application of PCIM.  Just as there
2880    will be a wide range of operational, real-world systems using PCIM,
2881    there will also be a wide range of security requirements for these
2882    systems.  Some operational, real-world systems that are deployed
2883    using PCLS may have extensive security requirements that impact
2884    nearly all object classes utilized by such a system, while other
2885    systems' security requirements might have very little impact.
2886
2887    The derivative documents, discussed above, will create the context
2888    for applying operational, real-world, system-level security
2889    requirements against the various models that derive from PCIM,
2890    consistent with PCLS.
2891
2892    In some real-world scenarios, the values associated with certain
2893    properties, within certain instantiated object classes, may represent
2894    information associated with scarce, and/or costly (and therefore
2895    valuable) resources.  It may be the case that these values must not
2896    be disclosed to, or manipulated by, unauthorized parties.
2897
2898    Since this document forms the basis for the representation of a
2899    policy data model in a specific format (an LDAP-accessible
2900    directory), it is herein appropriate to reference the data
2901    model-specific tools and mechanisms that are available for achieving
2902    the authentication and authorization implicit in a requirement that
2903    restricts read and/or read- write access to these values stored in a
2904    directory.
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914 Strassner, et al.           Standards Track                    [Page 52]
2915 \f
2916 RFC 3703                Policy Core LDAP Schema            February 2004
2917
2918
2919    General LDAP security considerations apply, as documented in RFC 3377
2920    [2]. LDAP-specific authentication and authorization tools and
2921    mechanisms are found in the following standards track documents,
2922    which are appropriate for application to the management of security
2923    applied to policy data models stored in an LDAP-accessible directory:
2924
2925      -   RFC 2829 (Authentication Methods for LDAP)
2926      -   RFC 2830 (Lightweight Directory Access Protocol (v3): Extension
2927          for Transport Layer Security)
2928
2929    Any identified security requirements that are not dealt with in the
2930    appropriate discipline-specific information model documents, or in
2931    this document, MUST be dealt with in the derivative data model
2932    documents which are specific to each discipline.
2933
2934 8.  IANA Considerations
2935
2936    Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA)
2937    Considerations for the Lightweight Directory Access Protocol (LDAP)"
2938    [16].
2939
2940 8.1.  Object Identifiers
2941
2942    The IANA has registered an LDAP Object Identifier for use in this
2943    technical specification according to the following template:
2944
2945    Subject: Request for LDAP OID Registration
2946    Person & email address to contact for further information:
2947       Bob Moore (remoore@us.ibm.com)
2948    Specification: RFC 3703
2949    Author/Change Controller: IESG
2950    Comments:
2951       The assigned OID will be used as a base for identifying
2952       a number of schema elements defined in this document.
2953
2954    IANA has assigned an OID of 1.3.6.1.1.6 with the name of pcimSchema
2955    to this registration as recorded in the following registry:
2956
2957       http://www.iana.org/assignments/smi-numbers
2958
2959 8.2.  Object Identifier Descriptors
2960
2961    The IANA has registered the LDAP Descriptors used in this technical
2962    specification as detailed in the following template:
2963
2964    Subject: Request for LDAP Descriptor Registration Update
2965    Descriptor (short name): see comment
2966    Object Identifier: see comment
2967
2968
2969
2970 Strassner, et al.           Standards Track                    [Page 53]
2971 \f
2972 RFC 3703                Policy Core LDAP Schema            February 2004
2973
2974
2975    Person & email address to contact for further information:
2976       Bob Moore (remoore@us.ibm.com)
2977    Usage: see comment
2978    Specification: RFC 3703
2979    Author/Change Controller: IESG
2980    Comments:
2981
2982    The following descriptors have been added:
2983
2984    NAME                            Type    OID
2985    --------------                  ----    ------------
2986    pcimPolicy                      O       1.3.6.1.1.6.1.1
2987    pcimGroup                       O       1.3.6.1.1.6.1.2
2988    pcimGroupAuxClass               O       1.3.6.1.1.6.1.3
2989    pcimGroupInstance               O       1.3.6.1.1.6.1.4
2990    pcimRule                        O       1.3.6.1.1.6.1.5
2991    pcimRuleAuxClass                O       1.3.6.1.1.6.1.6
2992    pcimRuleInstance                O       1.3.6.1.1.6.1.7
2993    pcimRuleConditionAssociation    O       1.3.6.1.1.6.1.8
2994    pcimRuleValidityAssociation     O       1.3.6.1.1.6.1.9
2995    pcimRuleActionAssociation       O       1.3.6.1.1.6.1.10
2996    pcimConditionAuxClass           O       1.3.6.1.1.6.1.11
2997    pcimTPCAuxClass                 O       1.3.6.1.1.6.1.12
2998    pcimConditionVendorAuxClass     O       1.3.6.1.1.6.1.13
2999    pcimActionAuxClass              O       1.3.6.1.1.6.1.14
3000    pcimActionVendorAuxClass        O       1.3.6.1.1.6.1.15
3001    pcimPolicyInstance              O       1.3.6.1.1.6.1.16
3002    pcimElementAuxClass             O       1.3.6.1.1.6.1.17
3003    pcimRepository                  O       1.3.6.1.1.6.1.18
3004    pcimRepositoryAuxClass          O       1.3.6.1.1.6.1.19
3005    pcimRepositoryInstance          O       1.3.6.1.1.6.1.20
3006    pcimSubtreesPtrAuxClass         O       1.3.6.1.1.6.1.21
3007    pcimGroupContainmentAuxClass    O       1.3.6.1.1.6.1.22
3008    pcimRuleContainmentAuxClass     O       1.3.6.1.1.6.1.23
3009    pcimKeywords                    A       1.3.6.1.1.6.2.3
3010    pcimGroupName                   A       1.3.6.1.1.6.2.4
3011    pcimRuleName                    A       1.3.6.1.1.6.2.5
3012    pcimRuleEnabled                 A       1.3.6.1.1.6.2.6
3013    pcimRuleConditionListType       A       1.3.6.1.1.6.2.7
3014    pcimRuleConditionList           A       1.3.6.1.1.6.2.8
3015    pcimRuleActionList              A       1.3.6.1.1.6.2.9
3016    pcimRuleValidityPeriodList      A       1.3.6.1.1.6.2.10
3017    pcimRuleUsage                   A       1.3.6.1.1.6.2.11
3018    pcimRulePriority                A       1.3.6.1.1.6.2.12
3019    pcimRuleMandatory               A       1.3.6.1.1.6.2.13
3020    pcimRuleSequencedActions        A       1.3.6.1.1.6.2.14
3021    pcimRoles                       A       1.3.6.1.1.6.2.15
3022    pcimConditionGroupNumber        A       1.3.6.1.1.6.2.16
3023
3024
3025
3026 Strassner, et al.           Standards Track                    [Page 54]
3027 \f
3028 RFC 3703                Policy Core LDAP Schema            February 2004
3029
3030
3031    NAME                            Type    OID
3032    --------------                  ----    ------------
3033    pcimConditionNegated            A       1.3.6.1.1.6.2.17
3034    pcimConditionName               A       1.3.6.1.1.6.2.18
3035    pcimConditionDN                 A       1.3.6.1.1.6.2.19
3036    pcimValidityConditionName       A       1.3.6.1.1.6.2.20
3037    pcimTimePeriodConditionDN       A       1.3.6.1.1.6.2.21
3038    pcimActionName                  A       1.3.6.1.1.6.2.22
3039    pcimActionOrder                 A       1.3.6.1.1.6.2.23
3040    pcimActionDN                    A       1.3.6.1.1.6.2.24
3041    pcimTPCTime                     A       1.3.6.1.1.6.2.25
3042    pcimTPCMonthOfYearMask          A       1.3.6.1.1.6.2.26
3043    pcimTPCDayOfMonthMask           A       1.3.6.1.1.6.2.27
3044    pcimTPCDayOfWeekMask            A       1.3.6.1.1.6.2.28
3045    pcimTPCTimeOfDayMask            A       1.3.6.1.1.6.2.29
3046    pcimTPCLocalOrUtcTime           A       1.3.6.1.1.6.2.30
3047    pcimVendorConstraintData        A       1.3.6.1.1.6.2.31
3048    pcimVendorConstraintEncoding    A       1.3.6.1.1.6.2.32
3049    pcimVendorActionData            A       1.3.6.1.1.6.2.33
3050    pcimVendorActionEncoding        A       1.3.6.1.1.6.2.34
3051    pcimPolicyInstanceName          A       1.3.6.1.1.6.2.35
3052    pcimRepositoryName              A       1.3.6.1.1.6.2.36
3053    pcimSubtreesAuxContainedSet     A       1.3.6.1.1.6.2.37
3054    pcimGroupsAuxContainedSet       A       1.3.6.1.1.6.2.38
3055    pcimRulesAuxContainedSet        A       1.3.6.1.1.6.2.39
3056
3057    where Type A is Attribute, Type O is ObjectClass
3058
3059    These assignments are recorded in the following registry:
3060
3061       http://www.iana.org/assignments/ldap-parameters
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082 Strassner, et al.           Standards Track                    [Page 55]
3083 \f
3084 RFC 3703                Policy Core LDAP Schema            February 2004
3085
3086
3087 9.  Acknowledgments
3088
3089    We would like to thank Kurt Zeilenga, Roland Hedburg, and Steven Legg
3090    for doing a review of this document and making many helpful
3091    suggestions and corrections.
3092
3093    Several of the policy classes in this model first appeared in early
3094    IETF drafts on IPsec policy and QoS policy.  The authors of these
3095    drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy
3096    Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael
3097    See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar.
3098
3099    This document is closely aligned with the work being done in the
3100    Distributed Management Task Force (DMTF) Policy and Networks working
3101    groups.  We would especially like to thank Lee Rafalow, Glenn Waters,
3102    David Black, Michael Richardson, Mark Stevens, David Jones, Hugh
3103    Mahon, Yoram Snir, and Yoram Ramberg for their helpful comments.
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138 Strassner, et al.           Standards Track                    [Page 56]
3139 \f
3140 RFC 3703                Policy Core LDAP Schema            February 2004
3141
3142
3143 10.  Appendix:  Constructing the Value of orderedCIMKeys
3144
3145    This appendix is non-normative, and is included in this document as a
3146    guide to implementers that wish to exchange information between CIM
3147    schemata and LDAP schemata.
3148
3149    Within a CIM name space, the naming is basically flat; all instances
3150    are identified by the values of their key properties, and each
3151    combination of key values must be unique.  A limited form of
3152    hierarchical naming is available in CIM, however, by using weak
3153    associations: since a weak association involves propagation of key
3154    properties and their values from the superior object to the
3155    subordinate one, the subordinate object can be thought of as being
3156    named "under" the superior object.  Once they have been propagated,
3157    however, propagated key properties and their values function in
3158    exactly the same way that native key properties and their values do
3159    in identifying a CIM instance.
3160
3161    The CIM mapping document [6] introduces a special attribute,
3162    orderedCIMKeys, to help map from the CIM_ManagedElement class to the
3163    LDAP class dlm1ManagedElement.  This attribute SHOULD only be used in
3164    an environment where it is necessary to map between an
3165    LDAP-accessible directory and a CIM repository.  For an LDAP
3166    environment, other LDAP naming attributes are defined (i.e., cn and a
3167    class-specific naming attribute) that SHOULD be used instead.
3168
3169    The role of orderedCIMKeys is to represent the information necessary
3170    to correlate an entry in an LDAP-accessible directory with an
3171    instance in a CIM name space.  Depending on how naming of CIM-related
3172    entries is handled in an LDAP directory, the value of orderedCIMKeys
3173    represents one of two things:
3174
3175      - If the DIT hierarchy does not mirror the "weakness hierarchy" of
3176        the CIM name space, then orderedCIMKeys represents all the
3177        keys of the CIM instance, both native and propagated.
3178      - If the DIT hierarchy does mirror the "weakness hierarchy" of the
3179        CIM name space, then orderedCIMKeys may represent either all the
3180        keys of the instance, or only the native keys.
3181
3182    Regardless of which of these alternatives is taken, the syntax of
3183    orderedCIMKeys is the same - a DirectoryString of the form
3184
3185        <className>.<key>=<value>[,<key>=<value>]*
3186
3187    where the <key>=<value> elements are ordered by the names of the key
3188    properties, according to the collating sequence for US ASCII.  The
3189    only spaces allowed in the DirectoryString are those that fall within
3190    a <value> element.  As with alphabetizing the key properties, the
3191
3192
3193
3194 Strassner, et al.           Standards Track                    [Page 57]
3195 \f
3196 RFC 3703                Policy Core LDAP Schema            February 2004
3197
3198
3199    goal of suppressing the spaces is once again to make the results of
3200    string operations predictable.
3201
3202    The values of the <value> elements are derived from the various CIM
3203    syntaxes according to a grammar specified in [5].
3204
3205 11.  References
3206
3207 11.1.  Normative References
3208
3209    [1]   Moore, B., Ellesson,E., Strassner, J. and A. Westerinen "Policy
3210          Core Information Model -- Version 1 Specification", RFC 3060,
3211          February 2001.
3212
3213    [2]   Hodges, J. and R. Morgan, "Lightweight Directory Access
3214          Protocol (v3): Technical Specification", RFC 3377, September
3215          2002.
3216
3217    [3]   Wahl, M., Coulbeck, A., Howes,T. and S. Kille, "Lightweight
3218          Directory Access Protocol (v3): Attribute Syntax Definitions",
3219          RFC 2252, December 1997.
3220
3221    [4]   The Directory: Models.  ITU-T Recommendation X.501, 2001.
3222
3223    [5]   Distributed Management Task Force, Inc., "Common Information
3224          Model (CIM) Specification", Version 2.2, June 14, 1999.  This
3225          document is available on the following DMTF web page:
3226          http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf
3227
3228    [6]   Distributed Management Task Force, Inc., "DMTF LDAP Schema for
3229          the CIM v2.5 Core Information Model", April 15, 2002.  This
3230          document is available on the following DMTF web page:
3231          http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf
3232
3233    [7]   Wahl, M., "A Summary of the X.500(96) User Schema for use with
3234          LDAPv3", RFC 2256, December 1997.
3235
3236    [8]   The Directory: Selected Attribute Types.  ITU-T Recommendation
3237          X.520, 2001.
3238
3239    [9]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
3240          (LDAP): Additional Matching Rules", RFC 3698, February 2004.
3241
3242    [10]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
3243          Levels", BCP 14, RFC 2119, March 1997.
3244
3245
3246
3247
3248
3249
3250 Strassner, et al.           Standards Track                    [Page 58]
3251 \f
3252 RFC 3703                Policy Core LDAP Schema            February 2004
3253
3254
3255 11.2.  Informative References
3256
3257    [11]  Hovey, R. and S. Bradner, "The Organizations Involved in the
3258          IETF Standards Process", BCP 11, RFC 2028, October 1996.
3259
3260    [12]  Strassner, J., policy architecture BOF presentation, 42nd IETF
3261          Meeting, Chicago, Illinois, October 1998.  Minutes of this BOF
3262          are available at the following location:
3263          http://www.ietf.org/proceedings/98aug/index.html.
3264
3265    [13]  Yavatkar, R., Guerin, R. and D. Pendarakis, "A Framework for
3266          Policy-based Admission Control", RFC 2753, January 2000.
3267
3268    [14]  Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
3269          "Authentication Methods for LDAP", RFC 2829, May 2000
3270
3271    [15]  Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
3272          Access Protocol (v3): Extension for Transport Layer Security",
3273          RFC 2830, May 2000.
3274
3275    [16]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
3276          Considerations for the Lightweight Directory Access Protocol
3277          (LDAP)", BCP 64, RFC 3383, September 2002.
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306 Strassner, et al.           Standards Track                    [Page 59]
3307 \f
3308 RFC 3703                Policy Core LDAP Schema            February 2004
3309
3310
3311 12.  Authors' Addresses
3312
3313    John Strassner
3314    Intelliden Corporation
3315    90 South Cascade Avenue
3316    Colorado Springs, CO  80903
3317
3318    Phone: +1.719.785.0648
3319    Fax:   +1.719.785.0644
3320    EMail: john.strassner@intelliden.com
3321
3322
3323    Bob Moore
3324    IBM Corporation
3325    P. O. Box 12195, BRQA/B501/G206
3326    3039 Cornwallis Rd.
3327    Research Triangle Park, NC  27709-2195
3328
3329    Phone: +1 919-254-4436
3330    Fax:   +1 919-254-6243
3331    EMail: remoore@us.ibm.com
3332
3333
3334    Ryan Moats
3335    Lemur Networks, Inc.
3336    15621 Drexel Circle
3337    Omaha, NE 68135
3338
3339    Phone: +1-402-894-9456
3340    EMail: rmoats@lemurnetworks.net
3341
3342
3343    Ed Ellesson
3344    3026 Carriage Trail
3345    Hillsborough, NC 27278
3346
3347    Phone: +1 919-644-3977
3348    EMail: ellesson@mindspring.com
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362 Strassner, et al.           Standards Track                    [Page 60]
3363 \f
3364 RFC 3703                Policy Core LDAP Schema            February 2004
3365
3366
3367 13.  Full Copyright Statement
3368
3369    Copyright (C) The Internet Society (2004).  This document is subject
3370    to the rights, licenses and restrictions contained in BCP 78 and
3371    except as set forth therein, the authors retain all their rights.
3372
3373    This document and the information contained herein are provided on an
3374    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
3375    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
3376    INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
3377    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
3378    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
3379    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3380
3381 Intellectual Property
3382
3383    The IETF takes no position regarding the validity or scope of any
3384    Intellectual Property Rights or other rights that might be claimed
3385    to pertain to the implementation or use of the technology
3386    described in this document or the extent to which any license
3387    under such rights might or might not be available; nor does it
3388    represent that it has made any independent effort to identify any
3389    such rights.  Information on the procedures with respect to
3390    rights in RFC documents can be found in BCP 78 and BCP 79.
3391
3392    Copies of IPR disclosures made to the IETF Secretariat and any
3393    assurances of licenses to be made available, or the result of an
3394    attempt made to obtain a general license or permission for the use
3395    of such proprietary rights by implementers or users of this
3396    specification can be obtained from the IETF on-line IPR repository
3397    at http://www.ietf.org/ipr.
3398
3399    The IETF invites any interested party to bring to its attention
3400    any copyrights, patents or patent applications, or other
3401    proprietary rights that may cover technology that may be required
3402    to implement this standard.  Please address the information to the
3403    IETF at ietf-ipr@ietf.org.
3404
3405 Acknowledgement
3406
3407    Funding for the RFC Editor function is currently provided by the
3408    Internet Society.
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418 Strassner, et al.           Standards Track                    [Page 61]
3419 \f