idnits 2.17.1 draft-ietf-policy-core-schema-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 60 instances of lines with control characters in the document. ** The abstract seems to contain references ([6], [7], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1048 has weird spacing: '...ment to anot...' == Line 1259 has weird spacing: '... either manda...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '11' is defined on line 2563, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 2566, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2571, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2574, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2577, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 2581, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3377 (ref. '2') (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 2252 (ref. '3') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2256 (ref. '7') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Obsolete informational reference (is this intentional?): RFC 2028 (ref. '11') (Obsoleted by RFC 9281) -- Obsolete informational reference (is this intentional?): RFC 2829 (ref. '14') (Obsoleted by RFC 4510, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 2830 (ref. '15') (Obsoleted by RFC 4510, RFC 4511, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 3383 (ref. '16') (Obsoleted by RFC 4520) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Policy Framework Working Group J. Strassner 2 Internet-draft Intelliden Corporation 3 Category: Standards Track B. Moore 4 IBM Corporation 5 R. Moats 6 Lemur Networks, Inc. 7 E. Ellesson 8 October 2002 9 Policy Core LDAP Schema 10 draft-ietf-policy-core-schema-16.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document defines a mapping of the Policy Core Information Model 39 to a form that can be implemented in a directory that uses Lightweight 40 Directory Access Protocol (LDAP) as its access protocol. This model 41 defines two hierarchies of object classes: structural classes 42 representing information for representing and controlling policy data 43 as specified in RFC3060, and relationship classes that indicate how 44 instances of the structural classes are related to each other. Classes 45 are also added to the LDAP schema to improve the performance of a 46 client's interactions with an LDAP server when the client is retrieving 47 large amounts of policy-related information. These classes exist only 48 to optimize LDAP retrievals: there are no classes in the information 49 model that correspond to them. 51 Table of Contents 53 1. Introduction 3 54 2. The Policy Core Information Model 4 55 3. Inheritance Hierarchy for the PCLS 5 56 4. General Discussion of Mapping the Information Model to LDAP 6 57 4.1. Summary of Class and Association Mappings 7 58 4.2. Usage of DIT Content and Structure Rules and Name Forms 9 59 4.3. Naming Attributes in the PCLS 10 60 4.4. Rule-Specific and Reusable Conditions and Actions 11 61 4.5. Location and Retrieval of Policy Objects in the Directory 15 62 4.5.1. Aliases and Other DIT-Optimization Techniques 17 63 5. Class Definitions 18 64 5.1. The Abstract Class "pcimPolicy" 19 65 5.2. The Three Policy Group Classes 20 66 5.3. The Three Policy Rule Classes 22 67 5.4. The Class pcimRuleConditionAssociation 28 68 5.5. The Class pcimRuleValidityAssociation 30 69 5.6. The Class pcimRuleActionAssociation 31 70 5.7. The Auxiliary Class pcimConditionAuxClass 33 71 5.8. The Auxiliary Class pcimTPCAuxClass 34 72 5.9. The Auxiliary Class pcimConditionVendorAuxClass 37 73 5.10. The Auxiliary Class pcimActionAuxClass 38 74 5.11. The Auxiliary Class pcimActionVendorAuxClass 38 75 5.12. The Class pcimPolicyInstance 40 76 5.13. The Auxiliary Class pcimElementAuxClass 41 77 5.14. The Three Policy Repository Classes 41 78 5.15. The Auxiliary Class pcimSubtreesPtrAuxClass 43 79 5.16. The Auxiliary Class pcimGroupContainmentAuxClass 44 80 5.17. The Auxiliary Class pcimRuleContainmentAuxClass 45 81 6. Extending the Classes Defined in This Document 47 82 6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 47 83 6.2. Using the Vendor Policy Attributes 47 84 6.3. Using Time Validity Periods 47 85 7. Security Considerations 48 86 8. IANA Considerations 49 87 8.1. Object Identifiers 49 88 8.2. Object Identifier Descriptors 50 89 9. Intellectual Property 51 90 10. Acknowledgments 52 91 11. Normative References 53 92 12. Informative References 54 93 13. Authors' Addresses 55 94 14. Full Copyright Statement 56 95 15. Appendix: Constructing the Value of orderedCIMKeys 57 96 PLEASE NOTE: 97 OIDs for the schema elements in this document have not been assigned. 98 This note to be removed by the RFC editor before publication. All uses 99 of OIDs are indicated symbolically: for example, IANA-ASSIGNED-OID.1.1 100 is a placeholder that will be replaced by a real OID that is assigned by 101 IANA before publication. 103 1. Introduction 105 This document takes as its starting point the object-oriented 106 information model for representing information for representing and 107 controlling policy data as specified in [1]. Lightweight Directory Access 108 Protocol (LDAP) [2] implementers, please note that the use of the term 109 "policy" in this document does not refer to the use of the term "policy" 110 as defined in X.501 [4]. Rather, the use of the term "policy" throughout 111 this document is defined as follows: 113 Policy is defined as a set of rules to administer, manage, and 114 control access to network resources. 116 This work is currently under joint development in the IETF's Policy 117 Framework working group and in the Policy working group of the 118 Distributed Management Task Force (DMTF). This model defines two 119 hierarchies of object classes: structural classes representing policy 120 information and control of policies, and relationship classes that 121 indicate how instances of the structural classes are related to each 122 other. In general, both of these class hierarchies will need to be 123 mapped to a particular data store. 125 This draft defines the mapping of these information model classes to a 126 directory that uses LDAP as its access protocol. Two types of 127 mappings are involved: 129 - For the structural classes in the information model, the mapping is 130 basically one-for-one: information model classes map to LDAP 131 classes, information model properties map to LDAP attributes. 133 - For the relationship classes in the information model, different 134 mappings are possible. In this document, the Policy Core Information 135 Model's (PCIM's) relationship classes and their properties are mapped 136 in three ways: to LDAP auxiliary classes, to attributes representing 137 distinguished name (DN) references, and to superior-subordinate 138 relationships in the Directory Information Tree (DIT). 140 Implementations that use an LDAP directory as their policy repository 141 and want to implement policy information according to RFC3060 [1] SHALL 142 use the LDAP schema defined in this document, or a schema that 143 subclasses from the schema defined in this document. The use of the 144 information model defined in reference [1] as the starting point 145 enables the inheritance and the relationship class hierarchies to be 146 extensible, such that other types of policy repositories, such as 147 relational databases, can also use this information. 149 This document fits into the overall framework for representing, 150 deploying, and managing policies being developed by the Policy 151 Framework Working Group. 153 The LDAP schema described in this document uses the prefix "pcim" to 154 identify its classes and attributes. It consists of ten very general 155 classes: pcimPolicy (an abstract class), three policy group classes 156 (pcimGroup, pcimGroupAuxClass, and pcimGroupInstance), three policy rule 157 classes (pcimRule, pcimRuleAuxClass, and pcimRuleInstance), and three 158 special auxiliary classes (pcimConditionAuxClass, pcimTPCAuxClass, and 159 pcimActionAuxClass). (Note that the PolicyTimePeriodCondition auxiliary 160 class defined in [1] would normally have been named 161 pcimTimePeriodConditionAuxClass, but this name is too long for some 162 directories. Therefore, we have abbreviated this name to be 163 pcimTPCAuxClass). 165 The mapping for the PCIM classes pcimGroup and pcimRule is designed to 166 be as flexible as possible. An abstract superclass is defined that 167 contains all required properties, and then both an auxiliary class as 168 well as a structural class are derived from it. This provides maximum 169 flexibility for the developer. 171 The schema also contains two less general classes: 172 pcimConditionVendorAuxClass and pcimActionVendorAuxClass. To achieve 173 the mapping of the information model's relationships, the schema also 174 contains two auxiliary classes: pcimGroupContainmentAuxClass and 175 pcimRuleContainmentAuxClass. Capturing the distinction between rule- 176 specific and reusable policy conditions and policy actions introduces 177 seven other classes: pcimRuleConditionAssociation, 178 pcimRuleValidityAssociation, pcimRuleActionAssociation, 179 pcimPolicyInstance, and three policy repository classes (pcimRepository, 180 pcimRepositoryAuxClass, and pcimRepositoryInstance). Finally, the 181 schema includes two classes (pcimSubtreesPtrAuxClass and 182 pcimElementAuxClass) for optimizing LDAP retrievals. In all, the schema 183 contains 23 classes. 185 Within the context of this document, the term "PCLS" (Policy Core LDAP 186 Schema) is used to refer to the LDAP class definitions that this 187 document contains. The term "PCIM" refers to classes defined in [1]. 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [10]. 193 2. The Policy Core Information Model 195 This document contains an LDAP schema representing the classes defined 196 in the companion document "Policy Core Information Model -- Version 1 197 Specification" [1]. Other documents may subsequently be produced, with 198 mappings of this same PCIM to other storage technologies. Since the 199 detailed semantics of the PCIM classes appear only in [1], that document 200 is a prerequisite for reading and understanding this document. 202 3. Inheritance Hierarchy for the PCLS 204 The following diagram illustrates the class hierarchy for the LDAP 205 Classes defined in this document: 207 top 208 | 209 +--dlm1ManagedElement (abstract) 210 | | 211 | +--pcimPolicy (abstract) 212 | | | 213 | | +--pcimGroup (abstract) 214 | | | | 215 | | | +--pcimGroupAuxClass (auxiliary) 216 | | | | 217 | | | +--pcimGroupInstance (structural) 218 | | | 219 | | +--pcimRule (abstract) 220 | | | | 221 | | | +--pcimRuleAuxClass (auxiliary) 222 | | | | 223 | | | +--pcimRuleInstance (structural) 224 | | | 225 | | +--pcimRuleConditionAssociation (structural) 226 | | | 227 | | +--pcimRuleValidityAssociation (structural) 228 | | | 229 | | +--pcimRuleActionAssociation (structural) 230 | | | 231 | | +--pcimPolicyInstance (structural) 232 | | | 233 | | +--pcimElementAuxClass (auxiliary) 234 | | 235 | +--dlm1ManagedSystemElement (abstract) 236 | | 237 | +--dlm1LogicalElement (abstract) 238 | | 239 | +--dlm1System (abstract) 240 | | 241 | +--dlm1AdminDomain (abstract) 242 | | 243 | +--pcimRepository (abstract) 244 | | 245 | +--pcimRepositoryAuxClass (auxiliary) 246 | | 247 | +--pcimRepositoryInstance 248 | (structural) 250 (continued on following page) 251 (continued from previous page) 253 top 254 | 255 +--pcimConditionAuxClass (auxiliary) 256 | | 257 | +---pcimTPCAuxClass (auxiliary) 258 | | 259 | +---pcimConditionVendorAuxClass (auxiliary) 260 | 261 +--pcimActionAuxClass (auxiliary) 262 | | 263 | +---pcimActionVendorAuxClass (auxiliary) 264 | 265 +--pcimSubtreesPtrAuxClass (auxiliary) 266 | 267 +--pcimGroupContainmentAuxClass (auxiliary) 268 | 269 +--pcimRuleContainmentAuxClass (auxiliary) 271 Figure 1. LDAP Class Inheritance Hierarchy for the PCLS 273 4. General Discussion of Mapping the Information Model to LDAP 275 The classes described in Section 5 below contain certain optimizations 276 for a directory that uses LDAP as its access protocol. One example of 277 this is the use of auxiliary classes to represent some of the 278 associations defined in the information model. Other data stores might 279 need to implement these associations differently. A second example is 280 the introduction of classes specifically designed to optimize retrieval 281 of large amounts of policy-related data from a directory. This section 282 discusses some general topics related to the mapping from the 283 information model to LDAP. 285 The remainder of this section will discuss the following topics. Section 286 4.1 will discuss the strategy used in mapping the classes and 287 associations defined in [1] to a form that can be represented in a 288 directory that uses LDAP as its access protocol. Section 4.2 discusses 289 DIT content and structure rules, as well as name forms. Section 4.3 290 describes the strategy used in defining naming attributes for the schema 291 described in Section 5 of this document. Section 4.4 defines the 292 strategy recommended for locating and retrieving PCIM-derived objects in 293 the directory. 295 4.1. Summary of Class and Association Mappings 297 Fifteen of the classes in the PCLS come directly from the nine 298 corresponding classes in the information model. Note that names of 299 classes begin with an upper case character in the information model 300 (although for CIM in particular, case is not significant in class and 301 property names), but with a lower case character in LDAP. This is 302 because although LDAP doesn't care, X.500 doesn't allow class names to 303 begin with an uppercase character. Note also that the prefix "pcim" is 304 used to identify these LDAP classes. 306 +---------------------------+-------------------------------+ 307 | Information Model | LDAP Class(es) | 308 +---------------------------+-------------------------------+ 309 +---------------------------+-------------------------------+ 310 | Policy | pcimPolicy | 311 +---------------------------+-------------------------------+ 312 | PolicyGroup | pcimGroup | 313 | | pcimGroupAuxClass | 314 | | pcimGroupInstance | 315 +---------------------------+-------------------------------+ 316 | PolicyRule | pcimRule | 317 | | pcimRuleAuxClass | 318 | | pcimRuleInstance | 319 +---------------------------+-------------------------------+ 320 | PolicyCondition | pcimConditionAuxClass | 321 +---------------------------+-------------------------------+ 322 | PolicyAction | pcimActionAuxClass | 323 +---------------------------+-------------------------------+ 324 | VendorPolicyCondition | pcimConditionVendorAuxClass | 325 +---------------------------+-------------------------------+ 326 | VendorPolicyAction | pcimActionVendorAuxClass | 327 +---------------------------+-------------------------------+ 328 | PolicyTimePeriodCondition | pcimTPCAuxClass | 329 +---------------------------+-------------------------------+ 330 | PolicyRepository | pcimRepository | 331 | | pcimRepositoryAuxClass | 332 | | pcimRepositoryInstance | 333 +---------------------------+-------------------------------+ 335 Figure 2. Mapping of Information Model Classes to LDAP 337 The associations in the information model map to attributes that 338 reference DNs (Distinguished Names) or to Directory Information Tree 339 (DIT) containment (i.e., superior-subordinate relationships) in LDAP. 340 Two of the attributes that reference DNs appear in auxiliary classes, 341 which allow each of them to represent several relationships from the 342 information model. 344 +----------------------------------+----------------------------------+ 345 | Information Model Association | LDAP Attribute / Class | 346 +-----------------------------------+---------------------------------+ 347 +-----------------------------------+---------------------------------+ 348 | PolicyGroupInPolicyGroup | pcimGroupsAuxContainedSet in | 349 | | pcimGroupContainmentAuxClass | 350 +-----------------------------------+---------------------------------+ 351 | PolicyRuleInPolicyGroup | pcimRulesAuxContainedSet in | 352 | | pcimRuleContainmentAuxClass | 353 +-----------------------------------+---------------------------------+ 354 | PolicyConditionInPolicyRule | DIT containment or | 355 | | pcimRuleConditionList in | 356 | | pcimRule or | 357 | | pcimConditionDN in | 358 | | pcimRuleConditionAssociation | 359 +-----------------------------------+---------------------------------+ 360 | PolicyActionInPolicyRule | DIT containment or | 361 | | pcimRuleActionList in | 362 | | pcimRule or | 363 | | pcimActionDN in | 364 | | pcimRuleActionAssociation | 365 +-----------------------------------+---------------------------------+ 366 | PolicyRuleValidityPeriod | pcimRuleValidityPeriodList | 367 | | in pcimRule or (if reusable) | 368 | | referenced through the | 369 | | pcimTimePeriodConditionDN in | 370 | | pcimRuleValidityAssociation | 371 +-----------------------------------+---------------------------------+ 372 | PolicyConditionInPolicyRepository | DIT containment | 373 +-----------------------------------+---------------------------------+ 374 | PolicyActionInPolicyRepository | DIT containment | 375 +-----------------------------------+---------------------------------+ 376 | PolicyRepositoryInPolicyRepository| DIT containment | 377 +-----------------------------------+---------------------------------+ 379 Figure 3. Mapping of Information Model Associations to LDAP 381 Of the remaining classes in the PCLS, two (pcimElementAuxClass and 382 pcimSubtreesPtrAuxClass) are included to make navigation through the DIT 383 and retrieval of the entries found there more efficient. This topic is 384 discussed in Section 4.5 below. 386 The remaining four classes in the PCLS, pcimRuleConditionAssociation, 387 pcimRuleValidityAssociation, pcimRuleActionAssociation, and 388 pcimPolicyInstance, are all involved with the representation of policy 389 conditions and policy actions in an LDAP directory. This topic is 390 discussed in Section 4.4 below. 392 4.2 Usage of DIT Content and Structure Rules and Name Forms 394 There are three powerful tools that can be used to help define schemata. 395 The first, DIT content rules, is a way of defining the content of an 396 entry for a structural object class. It can be used to specify the 397 following characteristics of the entry: 399 - additional mandatory attributes that the entries are required to 400 contain 401 - additional optional attributes the entries are allowed to contain 402 - the set of additional auxiliary object classes that these entries 403 are allowed to be members of 404 - any optional attributes from the structural and auxiliary object 405 class definitions that the entries are required to preclude 407 DIT content rules are NOT mandatory for any structural object class. 409 A DIT structure rule, together with a name form, controls the placement 410 and naming of an entry within the scope of a subschema. Name forms 411 define which attribute type(s) are required and are allowed to be used in 412 forming the Relative Distinguished Names (RDNs) of entries. DIT structure 413 rules specify which entries are allowed to be superior to other entries, 414 and hence control the way that RDNs are added together to make DNs. 416 A name form specifies the following: 417 - the structural object class of the entries named by this name form 418 - attributes that are required to be used in forming the RDNs of these 419 entries 420 - attributes that are allowed to be used in forming the RDNs of these 421 entries 422 - an object identifier to uniquely identify this name form 424 Note that name forms can only be specified for structural object 425 classes. However, every entry in the DIT must have a name form 426 controlling it. 428 Unfortunately, current LDAP servers vary quite a lot in their support of 429 these features. There are also three crucial implementation points that 430 must be followed. First, X.500 use of structure rules requires that a 431 structural object class with no superior structure rule be a subschema 432 administrative point. This is exactly NOT what we want for policy 433 information. Second, when an auxiliary class is subclassed, if a content 434 rule exists for the structural class that the auxiliary class refers to, 435 then that content rule needs to be augmented. Finally, most LDAP servers 436 unfortunately do not support inheritance of structure and content rules. 438 Given these concerns, DIT structure and content rules have been removed 439 from the PCLS. This is because, if included, they would be normative 440 references and would require OIDs. However, we don't want to lose the 441 insight gained in building the structure and content rules of the 442 previous version of the schema. Therefore, we describe where such rules 443 could be used in this schema, what they would control, and what their 444 effect would be. 446 4.3. Naming Attributes in the PCLS 448 Instances in a directory are identified by distinguished names (DNs), 449 which provide the same type of hierarchical organization that a file 450 system provides in a computer system. A distinguished name is a 451 sequence of RDNs. An RDN provides a unique identifier for an instance 452 within the context of its immediate superior, in the same way that a 453 filename provides a unique identifier for a file within the context of 454 the folder in which it resides. 456 To preserve maximum naming flexibility for policy administrators, three 457 optional (i.e., "MAY") naming attributes have been defined. They are: 459 - Each of the structural classes defined in this schema has its own 460 unique ("MAY") naming attribute. Since the naming attributes are 461 different, a policy administrator can, by using these attributes, 462 guarantee that there will be no name collisions between instances of 463 different classes, even if the same value is assigned to the 464 instances' respective naming attributes. 466 - The LDAP attribute cn (corresponding to X.500's commonName) is 467 included as a MAY attribute in the abstract class pcimPolicy, and 468 thus by inheritance in all of its subclasses. In X.500, commonName 469 typically functions as an RDN attribute, for naming instances of 470 many classes (e.g., X.500's person class). 472 - A special attribute is provided for implementations that expect to 473 map between native CIM and LDAP representations of policy 474 information. This attribute, called orderedCimKeys, is defined in 475 the class dlm1ManagedElement [6]. The value of this attribute is 476 derived algorithmically from values that are already present in a 477 CIM policy instance. The normative reference for this algorithm is 478 contained in [6]. See the appendix of this document for a 479 description of the algorithm. 481 Since any of these naming attributes MAY be used for naming an instance 482 of a PCLS class, implementations MUST be able to accommodate instances 483 named in any of these ways. 485 Note that it is recommended that two or more of these attributes SHOULD 486 NOT be used together to form a multi-part RDN, since support for multi- 487 part RDNs is limited among existing directory implementations. 489 4.4. Rule-Specific and Reusable Conditions and Actions 491 The PCIM [1] distinguishes between two types of policy conditions and 492 policy actions: ones associated with a single policy rule, and ones 493 that are reusable, in the sense that they may be associated with more 494 than one policy rule. While there is no inherent functional difference 495 between a rule-specific condition or action and a reusable one, there is 496 both a usage as well as an implementation difference between them. 498 Defining a condition or action as reusable vs. rule-specific reflects a 499 conscious decision on the part of the administrator in defining how they 500 are used. In addition, there are differences that reflect the difference 501 in implementing rule-specific vs. reusable policy conditions and actions 502 in how they are treated in a policy repository. The major implementation 503 differences between a rule-specific and a reusable condition or 504 actionare delineated below: 506 1. It is natural for a rule-specific condition or action to be removed 507 from the policy repository at the same time the rule is. It is just 508 the opposite for reusable conditions and actions. This is because 509 the condition or action is conceptually attached to the rule in the 510 rule-specific case, whereas it is referenced (e.g., pointed at) in 511 the reusable case. The persistence of a pcimRepository instance is 512 independent of the persistence of a pcimRule instance. 513 2. Access permissions for a rule-specific condition or action are 514 usually identical to those for the rule itself. On the other hand, 515 access permissions of reusable conditions and actions must be 516 expressible without reference to a policy rule. 517 3. Rule-specific conditions and actions require fewer accesses, 518 because the conditions and actions are "attached" to the rule. In 519 contrast, reusable conditions and actions require more accesses, 520 because each condition or action that is reusable requires a 521 separate access. 522 4. Rule-specific conditions and actions are designed for use by a 523 single rule. As the number of rules that use the same rule-specific 524 condition increase, subtle problems are created (the most obvious 525 being how to keep the rule-specific conditions and actions updated 526 to reflect the same value). Reusable conditions and actions lend 527 themselves for use by multiple independent rules. 528 5. Reusable conditions and actions offer an optimization when multiple 529 rules are using the same condition or action. This is because the 530 reusable condition or action only needs be updated once, and by 531 virtue of DN reference, the policy rules will be automatically 532 updated. 534 The preceding paragraph does not contain an exhaustive list of the ways 535 in which reusable and rule-specific conditions should be treated 536 differently. Its purpose is merely to justify making a semantic 537 distinction between rule-specific and reusable, and then reflecting this 538 distinction in the policy repository itself. 540 When the policy repository is realized in an LDAP-accessible directory, 541 the distinction between rule-specific and reusable conditions and 542 actions is realized via placement of auxiliary classes and via DIT 543 containment. Figure 4 illustrates a policy rule Rule1 with one rule- 544 specific condition CA and one rule-specific action AB. 546 +-----+ 547 |Rule1| 548 | | 549 +-----|- -|-----+ 550 | +-----+ | 551 | * * | 552 | * * | 553 | **** **** | 554 | * * | 555 v * * v 556 +--------+ +--------+ 557 | CA+ca | | AB+ab | 558 +--------+ +--------+ 560 +------------------------------+ 561 |LEGEND: | 562 | ***** DIT containment | 563 | + auxiliary attachment | 564 | ----> DN reference | 565 +------------------------------+ 567 Figure 4. Rule-Specific Policy Conditions and Actions 569 Because the condition and action are specific to Rule1, the auxiliary 570 classes ca and ab that represent them are attached, respectively, to the 571 structural classes CA and AB. These structural classes represent not 572 the condition ca and action ab themselves, but rather the associations 573 between Rule1 and ca, and between Rule1 and ab. 575 As Figure 4 illustrates, Rule1 contains DN references to the structural 576 classes CA and AB that appear below it in the DIT. At first glance it 577 might appear that these DN references are unnecessary, since a subtree 578 search below Rule1 would find all of the structural classes representing 579 the associations between Rule1 and its conditions and actions. Relying 580 only on a subtree search, though, runs the risk of missing conditions or 581 actions that should have appeared in the subtree, but for some reason 582 did not, or of finding conditions or actions that were inadvertently 583 placed in the subtree, or that should have been removed from the 584 subtree, but for some reason were not. Implementation experience has 585 suggested that many (but not all) of these risks are eliminated. 587 However, it must be noted that this comes at a price. The use of DN 588 references, as shown in Figure 4 above, thwarts inheritance of access 589 control information as well as existence dependency information. It also 590 is subject to referential integrity considerations. Therefore, it is 591 being included as an option for the designer. 593 Figure 5 illustrates a second way of representing rule-specific 594 conditions and actions in an LDAP-accessible directory: attachment of 595 the auxiliary classes directly to the instance representing the policy 596 rule. When all of the conditions and actions are attached to a policy 597 rule in this way, the rule is termed a "simple" policy rule. When 598 conditions and actions are not attached directly to a policy rule, the 599 rule is termed a "complex" policy rule. 601 +-----------+ 602 |Rule1+ca+ab| 603 | | 604 +-----------+ 606 +------------------------------+ 607 |LEGEND: | 608 | + auxiliary attachment | 609 +------------------------------+ 611 Figure 5. A Simple Policy Rule 613 The simple/complex distinction for a policy rule is not all or nothing. 614 A policy rule may have its conditions attached to itself and its actions 615 attached to other entries, or it may have its actions attached to itself 616 and its conditions attached to other entries. However, it SHALL NOT have 617 either its conditions or its actions attached both to itself and to 618 other entries, with one exception: a policy rule may reference its 619 validity periods with the pcimRuleValidityPeriodList attribute, but have 620 its other conditions attached to itself. 622 The tradeoffs between simple and complex policy rules are between the 623 efficiency of simple rules and the flexibility and greater potential for 624 reuse of complex rules. With a simple policy rule, the semantic options 625 are limited: 627 - All conditions are ANDed together. This combination can be 628 represented in two ways in the Disjunctive Normal Form (DNF)/ 629 Conjunctive Normal Form (CNF) (please see [1] for definitions of 630 these terms) expressions characteristic of policy conditions: as a 631 DNF expression with a single AND group, or as a CNF expression with 632 multiple single-condition OR groups. The first of these is 633 arbitrarily chosen as the representation for the ANDed conditions 634 in a simple policy rule. 636 - If multiple actions are included, no order can be specified for 637 them. 639 If a policy administrator needs to combine conditions in some other way, 640 or if there is a set of actions that must be ordered, then the only 641 option is to use a complex policy rule. 643 Finally, Figure 6 illustrates the same policy rule Rule1, but this time 644 its condition and action are reusable. The association classes CA and 645 AB are still present, and they are still DIT contained under Rule1. But 646 rather than having the auxiliary classes ca and ab attached directly to 647 the association classes CA and AB, each now contains DN references to 648 other entries to which these auxiliary classes are attached. These 649 other entries, CIA and AIB, are DIT contained under RepositoryX, which 650 is an instance of the class pcimRepository. Because they are named 651 under an instance of pcimRepository, ca and ab are clearly identified as 652 reusable. 654 +-----+ +-------------+ 655 |Rule1| | RepositoryX | 656 +-|- -|--+ | | 657 | +-----+ | +-------------+ 658 | * * | * * 659 | * * | * * 660 | *** **** | * * 661 | * * v * * 662 | * +---+ * * 663 | * |AB | +------+ * 664 v * | -|-------->|AIB+ab| * 665 +---+ +---+ +------+ * 666 |CA | +------+ 667 | -|------------------------>|CIA+ca| 668 +---+ +------+ 670 +------------------------------+ 671 |LEGEND: | 672 | ***** DIT containment | 673 | + auxiliary attachment | 674 | ----> DN reference | 675 +------------------------------+ 677 Figure 6. Reusable Policy Conditions and Actions 679 The classes pcimConditionAuxClass and pcimActionAuxClass do not 680 themselves represent actual conditions and actions: these are 681 introduced in their subclasses. What pcimConditionAuxClass and 682 pcimActionAuxClass do introduce are the semantics of being a policy 683 condition or a policy action. These are the semantics that all the 684 subclasses of pcimConditionAuxClass and pcimActionAuxClass inherit. 685 Among these semantics are those of representing either a rule-specific 686 or a reusable policy condition or policy action. 688 In order to preserve the ability to represent a rule-specific or a 689 reusable condition or action, as well as a simple policy rule, all the 690 subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST also be 691 auxiliary classes. 693 4.5. Location and Retrieval of Policy Objects in the Directory 695 When a Policy Decision Point (PDP) goes to an LDAP directory to retrieve 696 the policy object instances relevant to the Policy Enforcement Points 697 (PEPs) it serves, it is faced with two related problems: 699 - How does it locate and retrieve the directory entries that apply to 700 its PEPs? These entries may include instances of the PCLS classes, 701 instances of domain-specific subclasses of these classes, and 702 instances of other classes modeling such resources as user groups, 703 interfaces, and address ranges. 705 - How does it retrieve the directory entries it needs in an efficient 706 manner, so that retrieval of policy information from the directory 707 does not become a roadblock to scalability? There are two facets to 708 this efficiency: retrieving only the relevant directory entries, 709 and retrieving these entries using as few LDAP calls as possible. 711 The placement of objects in the Directory Information Tree (DIT) 712 involves considerations other than how the policy-related objects will 713 be retrieved by a PDP. Consequently, all that the PCLS can do is to 714 provide a "toolkit" of classes to assist the policy administrator as the 715 DIT is being designed and built. A PDP SHOULD be able to take advantage 716 of any tools that the policy administrator is able to build into the 717 DIT, but it MUST be able to use a less efficient means of retrieval if 718 that is all it has available to it. 720 The basic idea behind the LDAP optimization classes is a simple one: 721 make it possible for a PDP to retrieve all the policy-related objects it 722 needs, and only those objects, using as few LDAP calls as possible. An 723 important assumption underlying this approach is that the policy 724 administrator has sufficient control over the underlying DIT structure 725 to define subtrees for storing policy information. If the policy 726 administrator does not have this level of control over DIT structure, a 727 PDP can still retrieve the policy-related objects it needs individually. 728 But it will require more LDAP access operations to do the retrieval in 729 this way. Figure 7 illustrates how LDAP optimization is accomplished. 731 +-----+ 732 ---------------->| A | 733 DN reference to | | DN references to subtrees +---+ 734 starting object +-----+ +-------------------------->| C | 735 | o--+----+ +---+ +---+ 736 | o--+------------->| B | / \ 737 +-----+ +---+ / \ 738 / \ / \ / ... \ 739 / \ / \ 740 / \ / ... \ 742 Figure 7. Using the pcimSubtreesPtrAuxClass to Locate Policies 743 The PDP is configured initially with a DN reference to some entry in the 744 DIT. The structural class of this entry is not important; the PDP is 745 interested only in the pcimSubtreesPtrAuxClass attached to it. This 746 auxiliary class contains a multi-valued attribute with DN references to 747 objects that anchor subtrees containing policy-related objects of 748 interest to the PDP. Since pcimSubtreesPtrAuxClass is an auxiliary 749 class, it can be attached to an entry that the PDP would need to access 750 anyway - perhaps an entry containing initial configuration settings for 751 the PDP, or for a PEP that uses the PDP. 753 Once it has retrieved the DN references, the PDP will direct to each of 754 the objects identified by them an LDAP request that all entries in its 755 subtree be evaluated against the selection criteria specified in the 756 request. The LDAP-enabled directory then returns all entries in that 757 subtree that satisfy the specified criteria. 759 The selection criteria always specify that object class="pcimPolicy". 760 Since all classes representing policy rules, policy conditions, and 761 policy actions, both in the PCLS and in any domain-specific schema 762 derived from it, are subclasses of the abstract class policy, this 763 criterion evaluates to TRUE for all instances of these classes. To 764 accommodate special cases where a PDP needs to retrieve objects that are 765 not inherently policy-related (for example, an IP address range object 766 referenced by a subclass of pcimActionAuxClass representing the DHCP 767 action "assign from this address range"), the auxiliary class 768 pcimElementAuxClass can be used to "tag" an entry, so that it will be 769 found by the selection criterion "object class=pcimPolicy". 771 The approach described in the preceding paragraph will not work for 772 certain directory implementations, because these implementations do not 773 support matching of auxiliary classes in the objectClass attribute. For 774 environments where these implementations are expected to be present, the 775 "tagging" of entries as relevant to policy can be accomplished by 776 inserting the special value "POLICY" into the list of values contained 777 in the pcimKeywords attribute (provided by the pcimPolicy class). 779 If a PDP needs only a subset of the policy-related objects in the 780 indicated subtrees, then it can be configured with additional selection 781 criteria based on the pcimKeywords attribute defined in the pcimPolicy 782 class. This attribute supports both standardized and administrator- 783 defined values. For example, a PDP could be configured to request only 784 those policy-related objects containing the keywords "DHCP" and "Eastern 785 US". 787 To optimize what is expected to be a typical case, the initial request 788 from the client includes not only the object to which its "seed" DN 789 references, but also the subtree contained under this object. The 790 filter for searching this subtree is whatever the client is going to use 791 later to search the other subtrees: object class="pcimPolicy" or the 792 presence of the keyword "POLICY", and/or presence of a more specific 793 value of pcimKeywords (e.g., "QoS Edge Policy"). 795 Returning to the example in Figure 7, we see that in the best case, a 796 PDP can get all the policy-related objects it needs, and only those 797 objects, with exactly three LDAP requests: one to its starting object A 798 to get the references to B and C, as well as the policy-related objects 799 it needs from the subtree under A, and then one each to B and C to get 800 all the policy-related objects that pass the selection criteria with 801 which it was configured. Once it has retrieved all of these objects, 802 the PDP can then traverse their various DN references locally to 803 understand the semantic relationships among them. The PDP should also 804 be prepared to find a reference to another subtree attached to any of 805 the objects it retrieves, and to follow this reference first, before it 806 follows any of the semantically significant references it has received. 807 This recursion permits a structured approach to identifying related 808 policies. In Figure 7, for example, if the subtree under B includes 809 departmental policies and the one under C includes divisional policies, 810 then there might be a reference from the subtree under C to an object D 811 that roots the subtree of corporate-level policies. 813 A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be 814 capable of retrieving and processing the entries in the subtrees it 815 references, and SHOULD be capable of doing all of this recursively. The 816 same requirements apply to any other entity needing to retrieve policy 817 information from the directory. Thus, a Policy Management Tool that 818 retrieves policy entries from the directory in order to perform 819 validation and conflict detection SHOULD also understand and be capable 820 of using the pcimSubtreesPtrAuxClass. All of these requirements are 821 "SHOULD"s rather than "MUST"s because an LDAP client that doesn't 822 implement them can still access and retrieve the directory entries it 823 needs. The process of doing so will just be less efficient than it 824 would have been if the client had implemented these optimizations. 826 When it is serving as a tool for creating policy entries in the 827 directory, a Policy Management Tool SHOULD support creation of 828 pcimSubtreesPtrAuxClass entries and their references to object 829 instances. 831 4.5.1. Aliases and Other DIT-Optimization Techniques 833 Additional flexibility in DIT structure is available to the policy 834 administrator via LDAP aliasing and other techniques. Previous versions 835 of this document have used aliases. However, because aliases are 836 experimental, the use of aliases has been removed from this version of 837 this document. This is because the IETF has yet to produce a 838 specification on how aliases are represented in the directory or how 839 server implementations are to process aliases. 841 5. Class Definitions 843 The semantics for the policy information classes that are to be mapped 844 directly from the information model to an LDAP representation are 845 detailed in [1]. Consequently, all that this document presents for 846 these classes is the specification for how to do the mapping from the 847 information model (which is independent of repository type and access 848 protocol) to a form that can be accessed using LDAP. Remember that some 849 new classes needed to be created (that were not part of [1]) to 850 implement the LDAP mapping. These new LDAP-only classes are fully 851 documented in this document. 853 The formal language for specifying the classes, attributes, and DIT 854 structure and content rules is that defined in reference [3]. If your 855 implementation does not support auxiliary class inheritance, you will 856 have to list auxiliary classes in content rules explicitly or define 857 them in another (implementation-specific) way. 859 The following notes apply to this section in its entirety. 861 Note 1: in the following definitions, the class and attribute 862 definitions follow RFC2252 [3] but they are line-wrapped to enhance 863 human readability. 865 Note 2: where applicable, the possibilities for specifying DIT structure 866 and content rules are noted. However, care must be taken in specifying 867 DIT structure rules. This is because X.501 [4] states that an entry may 868 only exist in the DIT as a subordinate to another superior entry (the 869 superior) if a DIT structure rule exists in the governing subschema 870 which: 872 1) indicates a name form for the structural object class of the 873 subordinate entry, and 874 2) either includes the entry's superior structure rule as a possible 875 superior structure rule, or 876 3) does not specify a superior structure rule. 878 If this last case (3) applies, then the entry is defined to be a 879 subschema administrative point. This is not what is desired. Therefore, 880 care must be taken in defining structure rules, and in particular, they 881 must be locally augmented. 883 Note 3: Wherever possible, both an equality and a substring matching 884 rule are defined for a particular attribute (as well as an ordering 885 match rule to enable sorting of matching results). This provides two 886 different choices for the developer for maximum flexibility. 888 For example, consider the pcimRoles attribute (section 5.3). Suppose 889 that a PEP has reported that it is interested in pcimRules for three 890 roles R1, R2, and R3. If the goal is to minimize queries, then the PDP 891 can supply three substring filters containing the three role names. 893 These queries will return all of the pcimRules that apply to the PEP, 894 but they may also get some that do not apply (e.g., ones that contain 895 one of the roles R1, R2, or R3 and one or more other roles present in a 896 role-combination [1]). 898 Another strategy would be for the PDP to use only equality filters. This 899 approach eliminates the extraneous replies, but it requires the PDP to 900 explicitly build the desired role-combinations itself. It also requires 901 extra queries. Note that this approach is practical only because the 902 role names in a role combination are required to appear in alphabetical 903 order. 905 Note 4: in the following definitions, note that all LDAP matching rules 906 are defined in [3] and in [9]. The corresponding X.500 matching rules 907 are defined in [8]. 909 Note 5: some of the following attribute definitions specify additional 910 constraints on various data types (e.g., this integer has values that are valid 911 from 1..10). Text has been added to instruct servers and applications what to 912 do if a value outside of this range is encountered. 913 In all cases, if a constraint is violated, then the policy rule SHOULD be 914 treated as being disabled, meaning that execution of the policy rule SHOULD be 915 stopped. 917 5.1. The Abstract Class pcimPolicy 919 The abstract class pcimPolicy is a direct mapping of the abstract class 920 Policy from the PCIM. The class value "pcimPolicy" is also used as the 921 mechanism for identifying policy-related instances in the Directory 922 Information Tree. An instance of any class may be "tagged" with this 923 class value by attaching to it the auxiliary class pcimElementAuxClass. 924 Since pcimPolicy is derived from the class dlm1ManagedElement defined in 925 reference [6], this specification has a normative dependency on that 926 element of reference [6]. 928 The class definition is as follows: 930 ( IANA-ASSIGNED-OID.1.1 NAME 'pcimPolicy' 931 DESC 'An abstract class that is the base class for all classes 932 that describe policy-related instances.' 933 SUP dlm1ManagedElement 934 ABSTRACT 935 MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $ 936 pcimKeywords ) 937 ) 939 The attribute cn is defined in RFC 2256 [7]. The dlmCaption, 940 dlmDescription, and orderedCimKeys attributes are defined in [6]. 942 The pcimKeywords attribute is a multi-valued attribute that contains a 943 set of keywords to assist directory clients in locating the policy 944 objects identified by these keywords. It is defined as follows: 946 ( IANA-ASSIGNED-OID.2.3 NAME 'pcimKeywords' 947 DESC 'A set of keywords to assist directory clients in 948 locating the policy objects applicable to them.' 949 EQUALITY caseIgnoreMatch 950 ORDERING caseIgnoreOrderingMatch 951 SUBSTR caseIgnoreSubstringsMatch 952 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 953 ) 955 5.2. The Three Policy Group Classes 957 PCIM [1] defines the PolicyGroup class to serve as a generalized 958 aggregation mechanism, enabling PolicyRules and/or PolicyGroups to be 959 aggregated together. PCLS maps this class into three LDAP classes, 960 called pcimGroup, pcimGroupAuxClass, and pcimGroupInstance. This is done 961 in order to provide maximum flexibility for the DIT designer. 963 The class definitions for the three policy group classes are listed 964 below. These class definitions do not include attributes to realize the 965 PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from 966 the PCIM. This is because a pcimGroup object refers to instances of 967 pcimGroup and pcimRule via, respectively, the attribute 968 pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object 969 class and the attribute pcimRulesAuxContainedSet in the 970 pcimRuleContainmentAuxClass object class. 972 To maximize flexibility, the pcimGroup class is defined as abstract. The 973 subclass pcimGroupAuxClass provides for auxiliary attachment to 974 another entry, while the structural subclass pcimGroupInstance is 975 available to represent a policy group as a standalone entry. 977 The class definitions are as follows. First, the definition of the 978 abstract class pcimGroup: 980 ( IANA-ASSIGNED-OID.1.2 NAME 'pcimGroup' 981 DESC 'A container for a set of related pcimRules and/or 982 a set of related pcimGroups.' 983 SUP pcimPolicy 984 ABSTRACT 985 MAY ( pcimGroupName ) 986 ) 987 The one attribute of pcimGroup is pcimGroupName. This attribute is used 988 to define a user-friendly name of this policy group, and may be used as 989 a naming attribute if desired. It is defined as follows: 991 ( IANA-ASSIGNED-OID.2.4 NAME 'pcimGroupName' 992 DESC 'The user-friendly name of this policy group.' 993 EQUALITY caseIgnoreMatch 994 ORDERING caseIgnoreOrderingMatch 995 SUBSTR caseIgnoreSubstringsMatch 996 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 997 SINGLE-VALUE 998 ) 1000 The two subclasses of pcimGroup are defined as follows. The class 1001 pcimGroupAuxClass is an auxiliary class that can be used to collect a 1002 set of related pcimRule and/or pcimGroup classes. It is defined as 1003 follows: 1005 ( IANA-ASSIGNED-OID.1.3 NAME 'pcimGroupAuxClass' 1006 DESC 'An auxiliary class that collects a set of related 1007 pcimRule and/or pcimGroup entries.' 1008 SUP pcimGroup 1009 AUXILIARY 1010 ) 1012 The class pcimGroupInstance is a structural class that can be used to 1013 collect a set of related pcimRule and/or pcimGroup classes. It is 1014 defined as follows: 1016 ( IANA-ASSIGNED-OID.1.4 NAME 'pcimGroupInstance' 1017 DESC 'A structural class that collects a set of related 1018 pcimRule and/or pcimGroup entries.' 1019 SUP pcimGroup 1020 STRUCTURAL 1021 ) 1023 A DIT content rule could be written to enable an instance of 1024 pcimGroupInstance to have attached to it either references to one or 1025 more policy groups (using pcimGroupContainmentAuxClass) or references to 1026 one or more policy rules (using pcimRuleContainmentAuxClass). This would 1027 be used to formalize the semantics of the PolicyGroup class [1]. Since 1028 these semantics do not include specifying any properties of the 1029 PolicyGroup class, the content rule would not need to specify any 1030 attributes. 1032 Similarly, three separate DIT structure rules could be written, each of 1033 which would refer to a specific name form that identified one of the 1034 three possible naming attributes (i.e., pcimGroupName, cn, and 1035 orderedCIMKeys) for the pcimGroup object class. This structure rule 1036 SHOULD include a superiorStructureRule (see Note 2 at the beginning of 1037 section 5). The three name forms referenced by the three structure rules 1038 would each define one of the three naming attributes. 1040 5.3. The Three Policy Rule Classes 1042 The information model defines a PolicyRule class to represent the "If 1043 Condition then Action" semantics associated with processing policy 1044 information. For maximum flexibility, the PCLS maps this class into 1045 three LDAP classes. 1047 To maximize flexibility, the pcimRule class is defined as abstract. The 1048 subclass pcimRuleAuxClass provides for auxiliary attachment to another 1049 entry, while the structural subclass pcimRuleInstance is available to 1050 represent a policy rule as a standalone entry. 1052 The conditions and actions associated with a policy rule are modeled, 1053 respectively, with auxiliary subclasses of the auxiliary classes 1054 pcimConditionAuxClass and pcimActionAuxClass. Each of these auxiliary 1055 subclasses is attached to an instance of one of three structural 1056 classes. A subclass of pcimConditionAuxClass is attached to an instance 1057 of pcimRuleInstance, to an instance of pcimRuleConditionAssociation, or 1058 to an instance of pcimPolicyInstance. Similarly, a subclass of 1059 pcimActionAuxClass is attached to an instance of pcimRuleInstance, to an 1060 instance of pcimRuleActionAssociation, or to an instance of 1061 pcimPolicyInstance. 1063 The pcimRuleValidityPeriodList attribute (defined below) realizes the 1064 PolicyRuleValidityPeriod association defined in the PCIM. Since this 1065 association has no additional properties besides those that tie the 1066 association to its associated objects, this association can be realized 1067 by simply using an attribute. Thus, the pcimRuleValidityPeriodList 1068 attribute is simply a multi-valued attribute that provides an unordered 1069 set of DN references to one or more instances of the pcimTPCAuxClass, 1070 indicating when the policy rule is scheduled to be active and when it is 1071 scheduled to be inactive. A policy rule is scheduled to be active if it 1072 is active according to AT LEAST ONE of the pcimTPCAuxClass instances 1073 referenced by this attribute. 1075 The PolicyConditionInPolicyRule and PolicyActionInPolicyRule 1076 associations, however, do have additional attributes. The association 1077 PolicyActionInPolicyRule defines an integer attribute to sequence the 1078 actions, and the association PolicyConditionInPolicyRule has both an 1079 integer attribute to group the condition terms as well as a Boolean 1080 property to specify whether a condition is to be negated. 1082 In the PCLS, these additional association attributes are represented as 1083 attributes of two classes introduced specifically to model these 1084 associations. These classes are the pcimRuleConditionAssociation class 1085 and the pcimRuleActionAssociation class, which are defined in Sections 1086 5.4 and 5.5, respectively. Thus, they do not appear as attributes of 1087 the class pcimRule. Instead, the pcimRuleConditionList and 1088 pcimRuleActionList attributes can be used to reference these classes. 1090 The class definitions for the three pcimRule classes are as follows. 1092 The abstract class pcimRule is a base class for representing the "If 1093 Condition then Action" semantics associated with a policy rule. It is 1094 defined as follows: 1096 ( IANA-ASSIGNED-OID.1.5 NAME 'pcimRule' 1097 DESC 'The base class for representing the "If Condition 1098 then Action" semantics associated with a policy rule.' 1099 SUP pcimPolicy 1100 ABSTRACT 1101 MAY ( pcimRuleName $ pcimRuleEnabled $ 1102 pcimRuleConditionListType $ pcimRuleConditionList $ 1103 pcimRuleActionList $ pcimRuleValidityPeriodList $ 1104 pcimRuleUsage $ pcimRulePriority $ 1105 pcimRuleMandatory $ pcimRuleSequencedActions $ 1106 pcimRoles ) 1107 ) 1109 The PCIM [1] defines seven properties for the PolicyRule class. The PCLS 1110 defines eleven attributes for the pcimRule class, which is the LDAP 1111 equivalent of the PolicyRule class. Of these eleven attributes, seven 1112 are mapped directly from corresponding properties in PCIM's PolicyRule 1113 class. The remaining four attributes are a class-specific optional 1114 naming attribute, and three attributes used to realize the three 1115 associations that the pcimRule class participates in. 1117 The pcimRuleName attribute is used as a user-friendly name of this 1118 policy rule, and can also serve as the class-specific optional naming 1119 attribute. It is defined as follows: 1121 ( IANA-ASSIGNED-OID.2.5 NAME 'pcimRuleName' 1122 DESC 'The user-friendly name of this policy rule.' 1123 EQUALITY caseIgnoreMatch 1124 ORDERING caseIgnoreOrderingMatch 1125 SUBSTR caseIgnoreSubstringsMatch 1126 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1127 SINGLE-VALUE 1128 ) 1129 The pcimRuleEnabled attribute is an integer enumeration indicating 1130 whether a policy rule is administratively enabled (value=1), 1131 administratively disabled (value=2), or enabled for debug (value=3). It 1132 is defined as follows: 1134 ( IANA-ASSIGNED-OID.2.6 NAME 'pcimRuleEnabled' 1135 DESC 'An integer indicating whether a policy rule is 1136 administratively enabled (value=1), disabled 1137 (value=2), or enabled for debug (value=3).' 1138 EQUALITY integerMatch 1139 ORDERING integerOrderingMatch 1140 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1141 SINGLE-VALUE 1142 ) 1144 Note: All other values for the pcimRuleEnabled attribute are considered 1145 errors, and the administrator SHOULD treat this rule as being disabled 1146 if an invalid value is found. 1148 The pcimRuleConditionListType attribute is used to indicate whether the 1149 list of policy conditions associated with this policy rule is in 1150 disjunctive normal form (DNF, value=1) or conjunctive normal form (CNF, 1151 value=2). It is defined as follows: 1153 ( IANA-ASSIGNED-OID.2.7 NAME 'pcimRuleConditionListType' 1154 DESC 'A value of 1 means that this policy rule is in 1155 disjunctive normal form; a value of 2 means that this 1156 policy rule is in conjunctive normal form.' 1157 EQUALITY integerMatch 1158 ORDERING integerOrderingMatch 1159 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1160 SINGLE-VALUE 1161 ) 1163 Note: any value other than 1 or 2 for the pcimRuleConditionListType 1164 attribute is considered an error. Administrators SHOULD treat this rule 1165 as being disabled if an invalid value is found, since it is unclear how 1166 to structure the condition list. 1168 The pcimRuleConditionList attribute is a multi-valued attribute that is 1169 used to realize the policyRuleInPolicyCondition association defined in 1170 [1]. It contains a set of DNs of pcimRuleConditionAssociation entries 1171 representing associations between this policy rule and its conditions. 1172 No order is implied. It is defined as follows: 1174 ( IANA-ASSIGNED-OID.2.8 NAME 'pcimRuleConditionList' 1175 DESC 'Unordered set of DNs of pcimRuleConditionAssociation 1176 entries representing associations between this policy 1177 rule and its conditions.' 1178 EQUALITY distinguishedNameMatch 1179 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1180 ) 1181 The pcimRuleActionList attribute is a multi-valued attribute that is 1182 used to realize the policyRuleInPolicyAction association defined in [1]. 1183 It contains a set of DNs of pcimRuleActionAssociation entries 1184 representing associations between this policy rule and its actions. No 1185 order is implied. It is defined as follows: 1187 ( IANA-ASSIGNED-OID.2.9 NAME 'pcimRuleActionList' 1188 DESC 'Unordered set of DNs of pcimRuleActionAssociation 1189 entries representing associations between this policy 1190 rule and its actions.' 1191 EQUALITY distinguishedNameMatch 1192 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1193 ) 1195 The pcimRuleValidityPeriodList attribute is a multi-valued attribute 1196 that is used to realize the pcimRuleValidityPeriod association that is 1197 defined in [1]. It contains a set of DNs of pcimRuleValidityAssociation 1198 entries that determine when the pcimRule is scheduled to be active or 1199 inactive. No order is implied. It is defined as follows: 1201 ( IANA-ASSIGNED-OID.2.10 NAME 'pcimRuleValidityPeriodList' 1202 DESC 'Unordered set of DNs of pcimRuleValidityAssociation 1203 entries that determine when the pcimRule is scheduled 1204 to be active or inactive.' 1205 EQUALITY distinguishedNameMatch 1206 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1207 ) 1209 The pcimRuleUsage attribute is a free-form sting providing guidelines on 1210 how this policy should be used. It is defined as follows: 1212 ( IANA-ASSIGNED-OID.2.11 NAME 'pcimRuleUsage' 1213 DESC 'This attribute is a free-form sting providing 1214 guidelines on how this policy should be used.' 1215 EQUALITY caseIgnoreMatch 1216 ORDERING caseIgnoreOrderingMatch 1217 SUBSTR caseIgnoreSubstringsMatch 1218 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1219 SINGLE-VALUE 1220 ) 1222 The pcimRulePriority attribute is a non-negative integer that is used to 1223 prioritize this pcimRule relative to other pcimRules. A larger value 1224 indicates a higher priority. It is defined as follows: 1226 ( IANA-ASSIGNED-OID.2.12 NAME 'pcimRulePriority' 1227 DESC 'A non-negative integer for prioritizing this 1228 pcimRule relative to other pcimRules. A larger 1229 value indicates a higher priority.' 1230 EQUALITY integerMatch 1231 ORDERING integerOrderingMatch 1232 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1233 SINGLE-VALUE 1234 ) 1236 Note: if the value of the pcimRulePriority field is 0, then it SHOULD be 1237 treated as "don't care". On the other hand, if the value is negative, 1238 then it SHOULD be treated as an error and Administrators SHOULD treat 1239 this rule as being disabled. 1241 The pcimRuleMandatory attribute is a Boolean attribute that, if TRUE, 1242 indicates that for this policy rule, the evaluation of its conditions 1243 and execution of its actions (if the condition is satisfied) is 1244 required. If it is FALSE, then the evaluation of its conditions and 1245 execution of its actions (if the condition is satisfied) is not 1246 required. This attribute is defined as follows: 1248 ( IANA-ASSIGNED-OID.2.13 NAME 'pcimRuleMandatory' 1249 DESC 'If TRUE, indicates that for this policy rule, the 1250 evaluation of its conditions and execution of its 1251 actions (if the condition is satisfied) is required.' 1252 EQUALITY booleanMatch 1253 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1254 SINGLE-VALUE 1255 ) 1257 The pcimRuleSequencedActions attribute is an integer enumeration that is 1258 used to indicate that the ordering of actions defined by the 1259 pcimActionOrder attribute is either mandatory(value=1), 1260 recommended(value=2), or dontCare(value=3). It is defined as follows: 1262 ( IANA-ASSIGNED-OID.2.14 NAME 'pcimRuleSequencedActions' 1263 DESC 'An integer enumeration indicating that the ordering of 1264 actions defined by the pcimActionOrder attribute is 1265 mandatory(1), recommended(2), or dontCare(3).' 1266 EQUALITY integerMatch 1267 ORDERING integerOrderingMatch 1268 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1269 SINGLE-VALUE 1270 ) 1272 Note: if the value of pcimRulesSequencedActions field is not one of 1273 these three values, then Administrators SHOULD treat this rule as being 1274 disabled. 1276 The pcimRoles attribute represents the policyRoles property of [1]. Each 1277 value of this attribute represents a role-combination, which is a string 1278 of the form: 1279 [&&]* 1280 where the individual role names appear in alphabetical order according 1281 to the collating sequence for UCS-2. This attribute is defined as 1282 follows: 1284 ( IANA-ASSIGNED-OID.2.15 NAME 'pcimRoles' 1285 DESC 'Each value of this attribute represents a role- 1286 combination.' 1287 EQUALITY caseIgnoreMatch 1288 ORDERING caseIgnoreOrderingMatch 1289 SUBSTR caseIgnoreSubstringsMatch 1290 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1291 ) 1293 Note: if the value of the pcimRoles attribute does not conform to the 1294 format "[&&]*" (see Section 6.3.7 of [1]), then this 1295 attribute is malformed and its policy rule SHOULD be treated as being 1296 disabled. 1298 The two subclasses of the pcimRule class are defined as follows. First, 1299 the pcimRuleAuxClass is an auxiliary class for representing the "If 1300 Condition then Action" semantics associated with a policy rule. Its 1301 class definition is as follows: 1303 ( IANA-ASSIGNED-OID.1.6 NAME 'pcimRuleAuxClass' 1304 DESC 'An auxiliary class for representing the "If Condition 1305 then Action" semantics associated with a policy rule.' 1306 SUP pcimRule 1307 AUXILIARY 1308 ) 1310 The pcimRuleInstance is a structural class for representing the "If 1311 Condition then Action" semantics associated with a policy rule. Its 1312 class definition is as follows: 1314 ( IANA-ASSIGNED-OID.1.7 NAME 'pcimRuleInstance' 1315 DESC 'A structural class for representing the "If Condition 1316 then Action" semantics associated with a policy rule.' 1317 SUP pcimRule 1318 STRUCTURAL 1319 ) 1320 A DIT content rule could be written to enable an instance of 1321 pcimRuleInstance to have attached to it either references to one or more 1322 policy conditions (using pcimConditionAuxClass) or references to one or 1323 more policy actions (using pcimActionAuxClass). This would be used to 1324 formalize the semantics of the PolicyRule class [1]. Since these 1325 semantics do not include specifying any properties of the PolicyRule 1326 class, the content rule would not need to specify any attributes. 1328 Similarly, three separate DIT structure rules could be written, each of 1329 which would refer to a specific name form that identified one of its 1330 three possible naming attributes (i.e., pcimRuleName, cn, and 1331 orderedCIMKeys). This structure rule SHOULD include a 1332 superiorStructureRule (see Note 2 at the beginning of section 5). The 1333 three name forms referenced by the three structure rules would each 1334 define one of the three naming attributes. 1336 5.4. The Class pcimRuleConditionAssociation 1338 This class contains attributes to represent the properties of the PCIM's 1339 PolicyConditionInPolicyRule association. Instances of this class are 1340 related to an instance of pcimRule via DIT containment. The policy 1341 conditions themselves are represented by auxiliary subclasses of the 1342 auxiliary class pcimConditionAuxClass. These auxiliary classes are 1343 attached directly to instances of pcimRuleConditionAssociation for rule- 1344 specific policy conditions. For a reusable policy condition, the 1345 policyCondition auxiliary subclass is attached to an instance of the 1346 class pcimPolicyInstance (which is presumably associated with a 1347 pcimRepository by DIT containment), and the policyConditionDN attribute 1348 (of this class) is used to reference the reusable policyCondition 1349 instance. 1351 The class definition is as follows: 1353 ( IANA-ASSIGNED-OID.1.8 NAME 'pcimRuleConditionAssociation' 1354 DESC 'This class contains attributes characterizing the 1355 relationship between a policy rule and one of its 1356 policy conditions.' 1357 SUP pcimPolicy 1358 MUST ( pcimConditionGroupNumber $ pcimConditionNegated ) 1359 MAY ( pcimConditionName $ pcimConditionDN ) 1360 ) 1362 The attributes of this class are defined as follows. 1364 The pcimConditionGroupNumber attribute is a non-negative integer. It is 1365 used to identify the group to which the condition referenced by this 1366 association is assigned. This attribute is defined as follows: 1368 ( IANA-ASSIGNED-OID.2.16 1369 NAME 'pcimConditionGroupNumber' 1370 DESC 'The number of the group to which a policy condition 1371 belongs. This is used to form the DNF or CNF 1372 expression associated with a policy rule.' 1373 EQUALITY integerMatch 1374 ORDERING integerOrderingMatch 1375 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1376 SINGLE-VALUE 1377 ) 1379 Note that this number is non-negative. A negative value for this 1380 attribute is invalid, and any policy rule that refers to an invalid 1381 entry SHOULD be treated as being disabled. 1383 The pcimConditionNegated attribute is a Boolean attribute that indicates 1384 whether this policy condition is to be negated or not. If it is TRUE 1385 (FALSE), it indicates that a policy condition IS (IS NOT) negated in the 1386 DNF or CNF expression associated with a policy rule. This attribute is 1387 defined as follows: 1389 ( IANA-ASSIGNED-OID.2.17 1390 NAME 'pcimConditionNegated' 1391 DESC 'If TRUE (FALSE), it indicates that a policy condition 1392 IS (IS NOT) negated in the DNF or CNF expression 1393 associated with a policy rule.' 1394 EQUALITY booleanMatch 1395 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1396 SINGLE-VALUE 1397 ) 1399 The pcimConditionName is a user-friendly name for identifying this 1400 policy condition, and may be used as a naming attribute if desired. This 1401 attribute is defined as follows: 1403 ( IANA-ASSIGNED-OID.2.18 1404 NAME 'pcimConditionName' 1405 DESC 'A user-friendly name for a policy condition.' 1406 EQUALITY caseIgnoreMatch 1407 ORDERING caseIgnoreOrderingMatch 1408 SUBSTR caseIgnoreSubstringsMatch 1409 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1410 SINGLE-VALUE 1411 ) 1413 The pcimConditionDN attribute is a DN that references an instance of a 1414 reusable policy condition. This attribute is defined as follows: 1416 ( IANA-ASSIGNED-OID.2.19 1417 NAME 'pcimConditionDN' 1418 DESC 'A DN that references an instance of a reusable policy 1419 condition.' 1420 EQUALITY distinguishedNameMatch 1421 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1422 SINGLE-VALUE 1423 ) 1425 A DIT content rule could be written to enable an instance of 1426 pcimRuleConditionAssociation to have attached to it an instance of the 1427 auxiliary class pcimConditionAuxClass, or one of its subclasses. This 1428 would be used to formalize the semantics of the 1429 PolicyConditionInPolicyRule association. Specifically, this would be 1430 used to represent a rule-specific policy condition [1]. 1432 Similarly, three separate DIT structure rules could be written. Each of 1433 these DIT structure rules would refer to a specific name form that 1434 defined two important semantics. First, each name form would identify 1435 one of the three possible naming attributes (i.e., pcimConditionName, 1436 cn, and orderedCIMKeys) for the pcimRuleConditionAssociation object 1437 class. Second, each name form would require that an instance of the 1438 pcimRuleConditionAssociation class have as its superior an instance of 1439 the pcimRule class. This structure rule SHOULD also include a 1440 superiorStructureRule (see Note 2 at the beginning of section 5). 1442 5.5. The Class pcimRuleValidityAssociation 1444 The policyRuleValidityPeriod aggregation is mapped to the PCLS 1445 pcimRuleValidityAssociation class. This class represents the scheduled 1446 activation and deactivation of a policy rule by binding the definition 1447 of times that the policy is active to the policy rule itself. The 1448 "scheduled" times are either identified through an attached auxiliary 1449 class pcimTPCAuxClass, or are referenced through its 1450 pcimTimePeriodConditionDN attribute. 1452 This class is defined as follows: 1454 ( IANA-ASSIGNED-OID.1.9 NAME 'pcimRuleValidityAssociation' 1455 DESC 'This defines the scheduled activation or deactivation 1456 of a policy rule.' 1457 SUP pcimPolicy 1458 STRUCTURAL 1459 MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN ) 1460 ) 1462 The attributes of this class are defined as follows: 1464 The pcimValidityConditionName attribute is used to define a user- 1465 friendly name of this condition, and may be used as a naming attribute 1466 if desired. This attribute is defined as follows: 1468 ( IANA-ASSIGNED-OID.2.20 1469 NAME 'pcimValidityConditionName' 1470 DESC 'A user-friendly name for identifying an instance of 1471 a pcimRuleValidityAssociation entry.' 1472 EQUALITY caseIgnoreMatch 1473 ORDERING caseIgnoreOrderingMatch 1474 SUBSTR caseIgnoreSubstringsMatch 1475 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1476 SINGLE-VALUE 1477 ) 1479 The pcimTimePeriodConditionDN attribute is a DN that references a 1480 reusable time period condition. It is defined as follows: 1482 ( IANA-ASSIGNED-OID.2.21 1483 NAME 'pcimTimePeriodConditionDN' 1484 DESC 'A reference to a reusable policy time period 1485 condition.' 1486 EQUALITY distinguishedNameMatch 1487 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1488 SINGLE-VALUE 1489 ) 1491 A DIT content rule could be written to enable an instance of 1492 pcimRuleValidityAssociation to have attached to it an instance of the 1493 auxiliary class pcimTPCAuxClass, or one of its subclasses. This would be 1494 used to formalize the semantics of the PolicyRuleValidityPeriod 1495 aggregation [1]. 1497 Similarly, three separate DIT structure rules could be written. Each of 1498 these DIT structure rules would refer to a specific name form that 1499 defined two important semantics. First, each name form would identify 1500 one of the three possible naming attributes (i.e., 1501 pcimValidityConditionName, cn, and orderedCIMKeys) for the 1502 pcimRuleValidityAssociation object class. Second, each name form would 1503 require that an instance of the pcimRuleValidityAssociation class have 1504 as its superior an instance of the pcimRule class. This structure rule 1505 SHOULD also include a superiorStructureRule (see Note 2 at the beginning 1506 of section 5). 1508 5.6. The Class pcimRuleActionAssociation 1510 This class contains an attribute to represent the one property of the 1511 PCIM PolicyActionInPolicyRule association, ActionOrder. This property is 1512 used to specify an order for executing the actions associated with a 1513 policy rule. Instances of this class are related to an instance of 1514 pcimRule via DIT containment. The actions themselves are represented by 1515 auxiliary subclasses of the auxiliary class pcimActionAuxClass. 1517 These auxiliary classes are attached directly to instances of 1518 pcimRuleActionAssociation for rule-specific policy actions. For a 1519 reusable policy action, the pcimAction auxiliary subclass is attached to 1520 an instance of the class pcimPolicyInstance (which is presumably 1521 associated with a pcimRepository by DIT containment), and the 1522 pcimActionDN attribute (of this class) is used to reference the reusable 1523 pcimCondition instance. 1525 The class definition is as follows: 1527 ( IANA-ASSIGNED-OID.1.10 NAME 'pcimRuleActionAssociation' 1528 DESC 'This class contains attributes characterizing the 1529 relationship between a policy rule and one of its 1530 policy actions.' 1531 SUP pcimPolicy 1532 MUST ( pcimActionOrder ) 1533 MAY ( pcimActionName $ pcimActionDN ) 1534 ) 1536 The pcimActionName attribute is used to define a user-friendly name of 1537 this action, and may be used as a naming attribute if desired. This 1538 attribute is defined as follows: 1540 ( IANA-ASSIGNED-OID.2.22 1541 NAME 'pcimActionName' 1542 DESC 'A user-friendly name for a policy action.' 1543 EQUALITY caseIgnoreMatch 1544 ORDERING caseIgnoreOrderingMatch 1545 SUBSTR caseIgnoreSubstringsMatch 1546 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1547 SINGLE-VALUE 1548 ) 1550 The pcimActionOrder attribute is an unsigned integer that is used to 1551 indicate the relative position of an action in a sequence of actions 1552 that are associated with a given policy rule. When this number is 1553 positive, it indicates a place in the sequence of actions to be 1554 performed, with smaller values indicating earlier positions in the 1555 sequence. If the value is zero, then this indicates that the order is 1556 irrelevant. Note that if two or more actions have the same non-zero 1557 value, they may be performed in any order as long as they are each 1558 performed in the correct place in the overall sequence of actions. This 1559 attribute is defined as follows: 1561 ( IANA-ASSIGNED-OID.2.23 1562 NAME 'pcimActionOrder' 1563 DESC 'An integer indicating the relative order of an action 1564 in the context of a policy rule.' 1565 EQUALITY integerMatch 1566 ORDERING integerOrderingMatch 1567 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1568 SINGLE-VALUE 1569 ) 1570 Note: if the value of the pcimActionOrder field is negative, then it 1571 SHOULD be treated as an error and any policy rule that refers to such an 1572 entry SHOULD be treated as being disabled. 1574 The pcimActionDN attribute is a DN that references a reusable policy 1575 action. It is defined as follows: 1577 ( IANA-ASSIGNED-OID.2.24 1578 NAME 'pcimActionDN' 1579 DESC 'A DN that references a reusable policy action.' 1580 EQUALITY distinguishedNameMatch 1581 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1582 SINGLE-VALUE 1583 ) 1585 A DIT content rule could be written to enable an instance of 1586 pcimRuleActionAssociation to have attached to it an instance of the 1587 auxiliary class pcimActionAuxClass, or one of its subclasses. This would 1588 be used to formalize the semantics of the PolicyActionInPolicyRule 1589 association. Specifically, this would be used to represent a rule- 1590 specific policy action [1]. 1592 Similarly, three separate DIT structure rules could be written. Each of 1593 these DIT structure rules would refer to a specific name form that 1594 defined two important semantics. First, each name form would identify 1595 one of the three possible naming attributes (i.e., pcimActionName, cn, 1596 and orderedCIMKeys) for the pcimRuleActionAssociation object class. 1597 Second, each name form would require that an instance of the 1598 pcimRuleActionAssociation class have as its superior an instance of the 1599 pcimRule class. This structure rule should also include a 1600 superiorStructureRule (see Note 2 at the beginning of section 5). 1602 5.7. The Auxiliary Class pcimConditionAuxClass 1604 The purpose of a policy condition is to determine whether or not the set 1605 of actions (contained in the pcimRule that the condition applies to) 1606 should be executed or not. This class defines the basic organizational 1607 semantics of a policy condition, as specified in [1]. Subclasses of this 1608 auxiliary class can be attached to instances of three other classes in 1609 the PCLS. When a subclass of this class is attached to an instance of 1610 pcimRuleConditionAssociation, or to an instance of pcimRule, it 1611 represents a rule-specific policy condition. When a subclass of this 1612 class is attached to an instance of pcimPolicyInstance, it represents a 1613 reusable policy condition. 1615 Since all of the classes to which subclasses of this auxiliary class may 1616 be attached are derived from the pcimPolicy class, the attributes of 1617 pcimPolicy will already be defined for the entries to which these 1618 subclasses attach. Thus, this class is derived directly from "top". 1620 The class definition is as follows: 1622 ( IANA-ASSIGNED-OID.1.11 NAME 'pcimConditionAuxClass' 1623 DESC 'A class representing a condition to be evaluated in 1624 conjunction with a policy rule.' 1625 SUP top 1626 AUXILIARY 1627 ) 1629 5.8. The Auxiliary Class pcimTPCAuxClass 1631 The PCIM defines a time period class, PolicyTimePeriodCondition, to 1632 provide a means of representing the time periods during which a policy 1633 rule is valid, i.e., active. It also defines an aggregation, 1634 PolicyRuleValidityPeriod, so that time periods can be associated with a 1635 PolicyRule. The LDAP mapping also provides two classes, one for the 1636 time condition itself, and one for the aggregation. 1638 In the PCIM, the time period class is named PolicyTimePeriodCondition. 1639 However, the resulting name of the auxiliary class in this mapping 1640 (pcimTimePeriodConditionAuxClass) exceeds the length of a name that some 1641 directories can store. Therefore, the name has been shortened to 1642 pcimTPCAuxClass. 1644 The class definition is as follows: 1646 ( IANA-ASSIGNED-OID.1.12 NAME 'pcimTPCAuxClass' 1647 DESC 'This provides the capability of enabling or disabling 1648 a policy rule according to a predetermined schedule.' 1649 SUP pcimConditionAuxClass 1650 AUXILIARY 1651 MAY ( pcimTPCTime $ pcimTPCMonthOfYearMask $ 1652 pcimTPCDayOfMonthMask $ pcimTPCDayOfWeekMask $ 1653 pcimTPCTimeOfDayMask $ pcimTPCLocalOrUtcTime ) 1654 ) 1656 The attributes of the pcimTPCAuxClass are defined as follows. 1658 The pcimTPCTime attribute represents the time period that a policy rule 1659 is enabled for. This attribute is defined as a string in [1] with a 1660 special format which defines a time period with a starting date and an 1661 ending date separated by a forward slash ("/"), as follows: 1663 yyyymmddThhmmss/yyyymmddThhmmss 1665 where the first date and time may be replaced with the string 1666 "THISANDPRIOR" or the second date and time may be replaced with the 1667 string "THISANDFUTURE". This attribute is defined as follows: 1669 ( IANA-ASSIGNED-OID.2.25 1670 NAME 'pcimTPCTime' 1671 DESC 'The start and end times on which a policy rule is 1672 valid.' 1673 EQUALITY caseIgnoreMatch 1674 ORDERING caseIgnoreOrderingMatch 1675 SUBSTR caseIgnoreSubstringsMatch 1676 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1677 SINGLE-VALUE 1678 ) 1680 The value of this attribute SHOULD be checked against its defined format 1681 ("yyyymmddThhmmss/yyyymmddThhmmss", where the first and second date 1682 strings may be replaced with the strings "THISANDPRIOR" and 1683 "THISANDFUTURE"). If the value of this attribute does not conform to 1684 this syntax, then this SHOULD be considered an error and the policy rule 1685 SHOULD be treated as being disabled. 1687 The next four attributes (pcimTPCMonthOfYearMask, pcimTPCDayOfMonthMask, 1688 pcimTPCDayOfWeekMask, and pcimTPCTimeOfDayMask) are all defined as octet 1689 strings in [1]. However, the semantics of each of these attributes are 1690 contained in bit strings of various fixed lengths. Therefore, the PCLS 1691 uses a syntax of Bit String to represent each of them. The definition of 1692 these four attributes are as follows. 1694 The pcimTPCMonthOfYearMask attribute defines a 12-bit mask identifying 1695 the months of the year in which a policy rule is valid. The format is a 1696 bit string of length 12, representing the months of the year from 1697 January through December. The definition of this attribute is as 1698 follows: 1700 ( IANA-ASSIGNED-OID.2.26 1701 NAME 'pcimTPCMonthOfYearMask' 1702 DESC 'This identifies the valid months of the year for a 1703 policy rule using a 12-bit string that represents the 1704 months of the year from January through December.' 1705 EQUALITY bitStringMatch 1706 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1707 SINGLE-VALUE 1708 ) 1710 The value of this attribute SHOULD be checked against its defined 1711 format. If the value of this attribute does not conform to this syntax, 1712 then this SHOULD be considered an error and the policy rule SHOULD be 1713 treated as being disabled. 1715 The pcimTPCMonthOfDayMask attribute defines a mask identifying the days 1716 of the month on which a policy rule is valid. The format is a bit string 1717 of length 62. The first 31 positions represent the days of the month in 1718 ascending order, from day 1 to day 31. The next 31 positions represent 1719 the days of the month in descending order, from the last day to the day 1720 31 days from the end. The definition of this attribute is as follows: 1722 ( IANA-ASSIGNED-OID.2.27 1723 NAME 'pcimTPCDayOfMonthMask' 1724 DESC 'This identifies the valid days of the month for a 1725 policy rule using a 62-bit string. The first 31 1726 positions represent the days of the month in ascending 1727 order, and the next 31 positions represent the days of 1728 the month in descending order.' 1729 EQUALITY bitStringMatch 1730 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1731 SINGLE-VALUE 1732 ) 1734 The value of this attribute SHOULD be checked against its defined 1735 format. If the value of this attribute does not conform to this syntax, 1736 then this SHOULD be considered an error and the policy rule SHOULD be 1737 treated as being disabled. 1739 The pcimTPCDayOfWeekMask attribute defines a mask identifying the days 1740 of the week on which a policy rule is valid. The format is a bit string 1741 of length 7, representing the days of the week from Sunday through 1742 Saturday. The definition of this attribute is as follows: 1744 ( IANA-ASSIGNED-OID.2.28 1745 NAME 'pcimTPCDayOfWeekMask' 1746 DESC 'This identifies the valid days of the week for a 1747 policy rule using a 7-bit string. This represents 1748 the days of the week from Sunday through Saturday.' 1749 EQUALITY bitStringMatch 1750 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1751 SINGLE-VALUE 1752 ) 1754 The value of this attribute SHOULD be checked against its defined 1755 format. If the value of this attribute does not conform to this syntax, 1756 then this SHOULD be considered an error and the policy rule SHOULD be 1757 treated as being disabled. 1759 The pcimTPCTimeOfDayMask attribute defines the range of times at which a 1760 policy rule is valid. If the second time is earlier than the first, then 1761 the interval spans midnight. The format of the string is 1762 Thhmmss/Thhmmss. The definition of this attribute is as follows: 1764 ( IANA-ASSIGNED-OID.2.29 1765 NAME 'pcimTPCTimeOfDayMask' 1766 DESC 'This identifies the valid range of times for a policy 1767 using the format Thhmmss/Thhmmss.' 1768 EQUALITY caseIgnoreMatch 1769 ORDERING caseIgnoreOrderingMatch 1770 SUBSTR caseIgnoreSubstringsMatch 1771 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1772 SINGLE-VALUE 1773 ) 1774 The value of this attribute SHOULD be checked against its defined 1775 format. If the value of this attribute does not conform to this syntax, 1776 then this SHOULD be considered an error and the policy rule SHOULD be 1777 treated as being disabled. 1779 Finally, the pcimTPCLocalOrUtcTime attribute is used to choose between 1780 local or UTC time representation. This is mapped as a simple integer 1781 syntax, with the value of 1 representing local time and the value of 2 1782 representing UTC time. The definition of this attribute is as follows: 1784 ( IANA-ASSIGNED-OID.2.30 1785 NAME 'pcimTPCLocalOrUtcTime' 1786 DESC 'This defines whether the times in this instance 1787 represent local (value=1) times or UTC (value=2) 1788 times.' 1789 EQUALITY integerMatch 1790 ORDERING integerOrderingMatch 1791 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1792 SINGLE-VALUE 1793 ) 1795 Note: if the value of the pcimTPCLocalOrUtcTime is not 1 or 2, then this 1796 SHOULD be considered an error and the policy rule SHOULD be disabled. 1797 If the attribute is not present at all, then all times are interpreted 1798 as if it were present with the value 2, that is, UTC time. 1800 5.9. The Auxiliary Class pcimConditionVendorAuxClass 1802 This class provides a general extension mechanism for representing 1803 policy conditions that have not been modeled with specific properties. 1804 Instead, its two properties are used to define the content and format of 1805 the condition, as explained below. This class is intended for vendor- 1806 specific extensions that are not amenable to using pcimCondition; 1807 standardized extensions SHOULD NOT use this class. 1809 The class definition is as follows: 1811 ( IANA-ASSIGNED-OID.1.13 NAME 'pcimConditionVendorAuxClass' 1812 DESC 'A class that defines a registered means to describe a 1813 policy condition.' 1814 SUP pcimConditionAuxClass 1815 AUXILIARY 1816 MAY ( pcimVendorConstraintData $ 1817 pcimVendorConstraintEncoding ) 1818 ) 1819 The pcimVendorConstraintData attribute is a multi-valued attribute. It 1820 provides a general mechanism for representing policy conditions that 1821 have not been modeled as specific attributes. This information is 1822 encoded in a set of octet strings. The format of the octet strings is 1823 identified by the OID stored in the pcimVendorConstraintEncoding 1824 attribute. This attribute is defined as follows: 1826 ( IANA-ASSIGNED-OID.2.31 1827 NAME 'pcimVendorConstraintData' 1828 DESC 'Mechanism for representing constraints that have not 1829 been modeled as specific attributes. Their format is 1830 identified by the OID stored in the attribute 1831 pcimVendorConstraintEncoding.' 1832 EQUALITY octetStringMatch 1833 ORDERING octetStringOrderingMatch 1834 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1835 ) 1837 The pcimVendorConstraintEncoding attribute is used to identify the 1838 format and semantics for the pcimVendorConstraintData attribute. This 1839 attribute is defined as follows: 1841 ( IANA-ASSIGNED-OID.2.32 1842 NAME 'pcimVendorConstraintEncoding' 1843 DESC 'An OID identifying the format and semantics for the 1844 pcimVendorConstraintData for this instance.' 1845 EQUALITY objectIdentifierMatch 1846 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1847 SINGLE-VALUE 1848 ) 1850 5.10. The Auxiliary Class pcimActionAuxClass 1852 The purpose of a policy action is to execute one or more operations that 1853 will affect network traffic and/or systems, devices, etc. in order to 1854 achieve a desired policy state. This class is used to represent an 1855 action to be performed as a result of a policy rule whose condition 1856 clause was satisfied. 1858 Subclasses of this auxiliary class can be attached to instances of three 1859 other classes in the PCLS. When a subclass of this class is attached to 1860 an instance of pcimRuleActionAssociation, or to an instance of pcimRule, 1861 it represents a rule-specific policy action. When a subclass of this 1862 class is attached to an instance of pcimPolicyInstance, it represents a 1863 reusable policy action. 1865 Since all of the classes to which subclasses of this auxiliary class may 1866 be attached are derived from the pcimPolicy class, the attributes of the 1867 pcimPolicy class will already be defined for the entries to which these 1868 subclasses attach. Thus, this class is derived directly from "top". 1870 The class definition is as follows: 1872 ( IANA-ASSIGNED-OID.1.14 NAME 'pcimActionAuxClass' 1873 DESC 'A class representing an action to be performed as a 1874 result of a policy rule.' 1875 SUP top 1876 AUXILIARY 1877 ) 1879 5.11. The Auxiliary Class pcimActionVendorAuxClass 1881 The purpose of this class is to provide a general extension mechanism 1882 for representing policy actions that have not been modeled with specific 1883 properties. Instead, its two properties are used to define the content 1884 and format of the action, as explained below. 1886 As its name suggests, this class is intended for vendor-specific 1887 extensions that are not amenable to using the standard pcimAction class. 1888 Standardized extensions SHOULD NOT use this class. 1890 The class definition is as follows: 1892 ( IANA-ASSIGNED-OID.1.15 NAME 'pcimActionVendorAuxClass' 1893 DESC 'A class that defines a registered means to describe a 1894 policy action.' 1895 SUP pcimActionAuxClass 1896 AUXILIARY 1897 MAY ( pcimVendorActionData $ pcimVendorActionEncoding ) 1898 ) 1900 The pcimVendorActionData attribute is a multi-valued attribute. It 1901 provides a general mechanism for representing policy actions that have 1902 not been modeled as specific attributes. This information is encoded in 1903 a set of octet strings. The format of the octet strings is identified by 1904 the OID stored in the pcimVendorActionEncoding attribute. This attribute 1905 is defined as follows: 1907 ( IANA-ASSIGNED-OID.2.33 1908 NAME 'pcimVendorActionData' 1909 DESC ' Mechanism for representing policy actions that have 1910 not been modeled as specific attributes. Their format 1911 is identified by the OID stored in the attribute 1912 pcimVendorActionEncoding.' 1913 EQUALITY octetStringMatch 1914 ORDERING octetStringOrderingMatch 1915 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1916 ) 1917 The pcimVendorActionEncoding attribute is used to identify the format 1918 and semantics for the pcimVendorActionData attribute. This attribute is 1919 defined as follows: 1921 ( IANA-ASSIGNED-OID.2.34 1922 NAME 'pcimVendorActionEncoding' 1923 DESC 'An OID identifying the format and semantics for the 1924 pcimVendorActionData attribute of this instance.' 1925 EQUALITY objectIdentifierMatch 1926 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1927 SINGLE-VALUE 1928 ) 1930 5.12. The Class pcimPolicyInstance 1932 This class is not defined in the PCIM. Its role is to serve as a 1933 structural class to which auxiliary classes representing policy 1934 information are attached when the information is reusable. For 1935 auxiliary classes representing policy conditions and policy actions, 1936 there are alternative structural classes that may be used. See Section 1937 4.4 for a complete discussion of reusable policy conditions and actions, 1938 and of the role that this class plays in how they are represented. 1940 The class definition is as follows: 1942 ( IANA-ASSIGNED-OID.1.16 NAME 'pcimPolicyInstance' 1943 DESC 'A structural class to which aux classes containing 1944 reusable policy information can be attached.' 1945 SUP pcimPolicy 1946 MAY ( pcimPolicyInstanceName ) 1947 ) 1949 The pcimPolicyInstanceName attribute is used to define a user-friendly 1950 name of this class, and may be used as a naming attribute if desired. It 1951 is defined as follows: 1953 ( IANA-ASSIGNED-OID.2.35 NAME 'pcimPolicyInstanceName' 1954 DESC 'The user-friendly name of this policy instance.' 1955 EQUALITY caseIgnoreMatch 1956 ORDERING caseIgnoreOrderingMatch 1957 SUBSTR caseIgnoreSubstringsMatch 1958 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1959 SINGLE-VALUE 1960 ) 1962 A DIT content rule could be written to enable an instance of 1963 pcimPolicyInstance to have attached to it either instances of one or 1964 more of the auxiliary object classes pcimConditionAuxClass and 1965 pcimActionAuxClass. Since these semantics do not include specifying any 1966 properties, the content rule would not need to specify any attributes. 1967 Note that other content rules could be defined to enable other policy- 1968 related auxiliary classes to be attached to pcimPolicyInstance. 1970 Similarly, three separate DIT structure rules could be written. Each of 1971 these DIT structure rules would refer to a specific name form that 1972 defined two important semantics. First, each name form would identify 1973 one of the three possible naming attributes (i.e., 1974 pcimPolicyInstanceName, cn, and orderedCIMKeys) for this object class. 1975 Second, each name form would require that an instance of the 1976 pcimPolicyInstance class have as its superior an instance of the 1977 pcimRepository class. This structure rule SHOULD also include a 1978 superiorStructureRule (see Note 2 at the beginning of section 5). 1980 5.13. The Auxiliary Class pcimElementAuxClass 1982 This class introduces no additional attributes, beyond those defined in 1983 the class pcimPolicy from which it is derived. Its role is to "tag" an 1984 instance of a class defined outside the realm of policy information as 1985 represented by PCIM as being nevertheless relevant to a policy 1986 specification. This tagging can potentially take place at two levels: 1988 - Every instance to which pcimElementAuxClass is attached becomes 1989 an instance of the class pcimPolicy, since pcimElementAuxClass is a 1990 subclass of pcimPolicy. Searching for object class="pcimPolicy" 1991 will return the instance. (As noted earlier, this approach does 1992 NOT work for some directory implementations. To accommodate these 1993 implementations, policy-related entries SHOULD be tagged with the 1994 pcimKeyword "POLICY".) 1996 - With the pcimKeywords attribute that it inherits from pcimPolicy, 1997 an instance to which pcimElementAuxClass is attached can be 1998 tagged as being relevant to a particular type or category of 1999 policy information, using standard keywords, administrator-defined 2000 keywords, or both. 2002 The class definition is as follows: 2004 ( IANA-ASSIGNED-OID.1.17 NAME 'pcimElementAuxClass' 2005 DESC 'An auxiliary class used to tag instances of classes 2006 defined outside the realm of policy as relevant to a 2007 particular policy specification.' 2008 SUP pcimPolicy 2009 AUXILIARY 2010 ) 2012 5.14. The Three Policy Repository Classes 2014 These classes provide a container for reusable policy information, such 2015 as reusable policy conditions and/or reusable policy actions. This 2016 document is concerned with mapping just the properties that appear in 2017 these classes. Conceptually, this may be thought of as a special 2018 location in the DIT where policy information may reside. Since 2019 pcimRepository is derived from the class dlm1AdminDomain defined in 2020 reference [6], this specification has a normative dependency on that 2021 element of reference [6] (as well as on its entire derivation 2022 hierarchy, which also appears in reference [6]). To maximize 2023 flexibility, the pcimRepository class is defined as abstract. A 2024 subclass pcimRepositoryAuxClass provides for auxiliary attachment to 2025 another entry, while a structural subclass pcimRepositoryInstance is 2026 available to represent a policy repository as a standalone entry. 2028 The definition for the pcimRepository class is as follows: 2030 ( IANA-ASSIGNED-OID.1.18 NAME 'pcimRepository' 2031 DESC 'A container for reusable policy information.' 2032 SUP dlm1AdminDomain 2033 ABSTRACT 2034 MAY ( pcimRepositoryName ) 2035 ) 2037 The pcimRepositoryName attribute is used to define a user-friendly name 2038 of this class, and may be used as a naming attribute if desired. It is 2039 defined as follows: 2041 ( IANA-ASSIGNED-OID.2.36 NAME 'pcimRepositoryName' 2042 DESC 'The user-friendly name of this policy repository.' 2043 EQUALITY caseIgnoreMatch 2044 ORDERING caseIgnoreOrderingMatch 2045 SUBSTR caseIgnoreSubstringsMatch 2046 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 2047 SINGLE-VALUE 2048 ) 2050 The two subclasses of pcimRepository are defined as follows. First, the 2051 pcimRepositoryAuxClass is an auxiliary class that can be used to 2052 aggregate reusable policy information. It is defined as follows: 2054 ( IANA-ASSIGNED-OID.1.19 NAME 'pcimRepositoryAuxClass' 2055 DESC 'An auxiliary class that can be used to aggregate 2056 reusable policy information.' 2057 SUP pcimRepository 2058 AUXILIARY 2059 ) 2061 In cases where structural classes are needed instead of an auxiliary 2062 class, the pcimRepositoryInstance class is a structural class that can 2063 be used to aggregate reusable policy information. It is defined as 2064 follows: 2066 ( IANA-ASSIGNED-OID.1.20 NAME 'pcimRepositoryInstance' 2067 DESC 'A structural class that can be used to aggregate 2068 reusable policy information.' 2069 SUP pcimRepository 2070 STRUCTURAL 2071 ) 2072 Three separate DIT structure rules could be written for this class. Each 2073 of these DIT structure rules would refer to a specific name form that 2074 enabled an instance of the pcimRepository class to be named under any 2075 superior using one of the three possible naming attributes (i.e., 2076 pcimRepositoryName, cn, and orderedCIMKeys). This structure rule SHOULD 2077 also include a superiorStructureRule (see Note 2 at the beginning of 2078 section 5). 2080 5.15. The Auxiliary Class pcimSubtreesPtrAuxClass 2082 This auxiliary class provides a single, multi-valued attribute that 2083 references a set of objects that are at the root of DIT subtrees 2084 containing policy-related information. By attaching this attribute to 2085 instances of various other classes, a policy administrator has a 2086 flexible way of providing an entry point into the directory that allows 2087 a client to locate and retrieve the policy information relevant to it. 2089 It is intended that these entries are placed in the DIT such that well- 2090 known DNs can be used to reference a well-known structural entry that 2091 has the pcimSubtreesPtrAuxClass attached to it. In effect, this defines 2092 a set of entry points. Each of these entry points can contain and/or 2093 reference all related policy entries for any well-known policy domains. 2094 The pcimSubtreesPtrAuxClass functions as a tag to identify portions of 2095 the DIT that contain policy information. 2097 This object does not provide the semantic linkages between individual 2098 policy objects, such as those between a policy group and the policy 2099 rules that belong to it. Its only role is to enable efficient bulk 2100 retrieval of policy-related objects, as described in Section 4.5. 2102 Once the objects have been retrieved, a directory client can determine 2103 the semantic linkages by following references contained in multi-valued 2104 attributes, such as pcimRulesAuxContainedSet. 2106 Since policy-related objects will often be included in the DIT subtree 2107 beneath an object to which this auxiliary class is attached, a client 2108 SHOULD request the policy-related objects from the subtree under the 2109 object with these references at the same time that it requests the 2110 references themselves. 2112 Since clients are expected to behave in this way, the policy 2113 administrator SHOULD make sure that this subtree does not contain so 2114 many objects unrelated to policy that an initial search done in this way 2115 results in a performance problem. The pcimSubtreesPtrAuxClass SHOULD 2116 NOT be attached to the partition root for a large directory partition 2117 containing a relatively few number of policy-related objects along with 2118 a large number of objects unrelated to policy (again, "policy" here 2119 refers to the PCIM, not the X.501, definition and use of "policy"). A 2120 better approach would be to introduce a container object immediately 2121 below the partition root, attach pcimSubtreesPtrAuxClass to this 2122 container object, and then place all of the policy-related objects in 2123 that subtree. 2125 The class definition is as follows: 2127 ( IANA-ASSIGNED-OID.1.21 NAME 'pcimSubtreesPtrAuxClass' 2128 DESC 'An auxiliary class providing DN references to roots of 2129 DIT subtrees containing policy-related objects.' 2130 SUP top 2131 AUXILIARY 2132 MAY ( pcimSubtreesAuxContainedSet ) 2133 ) 2135 The attribute pcimSubtreesAuxContainedSet provides an unordered set of 2136 DN references to instances of one or more objects under which policy- 2137 related information is present. The objects referenced may or may not 2138 themselves contain policy-related information. The attribute definition 2139 is as follows: 2141 ( IANA-ASSIGNED-OID.2.37 2142 NAME 'pcimSubtreesAuxContainedSet' 2143 DESC 'DNs of objects that serve as roots for DIT subtrees 2144 containing policy-related objects.' 2145 EQUALITY distinguishedNameMatch 2146 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2147 ) 2149 Note that the cn attribute does NOT need to be defined for this class. 2150 This is because an auxiliary class is used as a means to collect common 2151 attributes and treat them as properties of an object. A good analogy is 2152 a #include file, except that since an auxiliary class is a class, all 2153 the benefits of a class (e.g., inheritance) can be applied to an 2154 auxiliary class. 2156 5.16. The Auxiliary Class pcimGroupContainmentAuxClass 2158 This auxiliary class provides a single, multi-valued attribute that 2159 references a set of pcimGroups. By attaching this attribute to 2160 instances of various other classes, a policy administrator has a 2161 flexible way of providing an entry point into the directory that allows 2162 a client to locate and retrieve the pcimGroups relevant to it. 2164 As is the case with pcimRules, a policy administrator might have several 2165 different references to a pcimGroup in the overall directory structure. 2166 The pcimGroupContainmentAuxClass is the mechanism that makes it possible 2167 for the policy administrator to define all these different references. 2169 The class definition is as follows: 2171 ( IANA-ASSIGNED-OID.1.22 NAME 'pcimGroupContainmentAuxClass' 2172 DESC 'An auxiliary class used to bind pcimGroups to an 2173 appropriate container object.' 2174 SUP top 2175 AUXILIARY 2176 MAY ( pcimGroupsAuxContainedSet ) 2177 ) 2179 The attribute pcimGroupsAuxContainedSet provides an unordered set of 2180 references to instances of one or more pcimGroups associated with the 2181 instance of a structural class to which this attribute has been 2182 appended. 2184 The attribute definition is as follows: 2186 ( IANA-ASSIGNED-OID.2.38 2187 NAME 'pcimGroupsAuxContainedSet' 2188 DESC 'DNs of pcimGroups associated in some way with the 2189 instance to which this attribute has been appended.' 2190 EQUALITY distinguishedNameMatch 2191 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2192 ) 2194 Note that the cn attribute does NOT have to be defined for this class 2195 for the same reasons as those given for the pcimSubtreesPtrAuxClass in 2196 section 5.15. 2198 5.17. The Auxiliary Class pcimRuleContainmentAuxClass 2200 This auxiliary class provides a single, multi-valued attribute that 2201 references a set of pcimRules. By attaching this attribute to instances 2202 of various other classes, a policy administrator has a flexible way of 2203 providing an entry point into the directory that allows a client to 2204 locate and retrieve the pcimRules relevant to it. 2206 A policy administrator might have several different references to a 2207 pcimRule in the overall directory structure. For example, there might 2208 be references to all pcimRules for traffic originating in a particular 2209 subnet from a directory entry that represents that subnet. At the same 2210 time, there might be references to all pcimRules related to a particular 2211 DiffServ setting from an instance of a pcimGroup explicitly introduced 2212 as a container for DiffServ-related pcimRules. The 2213 pcimRuleContainmentAuxClass is the mechanism that makes it possible for 2214 the policy administrator to define all these separate references. 2216 The class definition is as follows: 2218 ( IANA-ASSIGNED-OID.1.23 NAME 'pcimRuleContainmentAuxClass' 2219 DESC 'An auxiliary class used to bind pcimRules to an 2220 appropriate container object.' 2221 SUP top 2222 AUXILIARY 2223 MAY ( pcimRulesAuxContainedSet ) 2224 ) 2226 The attribute pcimRulesAuxContainedSet provides an unordered set of 2227 references to one or more instances of pcimRules associated with the 2228 instance of a structural class to which this attribute has been 2229 appended. The attribute definition is as follows: 2231 ( IANA-ASSIGNED-OID.2.39 2232 NAME 'pcimRulesAuxContainedSet' 2233 DESC 'DNs of pcimRules associated in some way with the 2234 instance to which this attribute has been appended.' 2235 EQUALITY distinguishedNameMatch 2236 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2237 ) 2239 The cn attribute does NOT have to be defined for this class for the same 2240 reasons as those given for the pcimSubtreesPtrAuxClass in section 5.15. 2242 6. Extending the Classes Defined in This Document 2244 The following subsections provide general guidance on how to create a 2245 domain-specific schema derived from this document, discuss how the 2246 vendor classes in the PCLS should be used, and explain how 2247 policyTimePeriodConditions are related to other policy conditions. 2249 6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 2251 In Section 4.4, there is a discussion of how, by representing policy 2252 conditions and policy actions as auxiliary classes in a schema, the 2253 flexibility is retained to instantiate a particular condition or action 2254 as either rule-specific or reusable. This flexibility is lost if a 2255 condition or action class is defined as structural rather than 2256 auxiliary. For standardized schemata, this document specifies that 2257 domain-specific information MUST be expressed in auxiliary subclasses of 2258 pcimConditionAuxClass and pcimActionAuxClass. It is RECOMMENDED that 2259 non-standardized schemata follow this practice as well. 2261 6.2. Using the Vendor Policy Attributes 2263 As discussed Section 5.9, the attributes pcimVendorConstraintData and 2264 pcimVendorConstraintEncoding are included in the 2265 pcimConditionVendorAuxClass to provide a mechanism for representing 2266 vendor-specific policy conditions that are not amenable to being 2267 represented with the pcimCondition class (or its subclasses). The 2268 attributes pcimVendorActionData and pcimVendorActionEncoding in the 2269 pcimActionVendorAuxClass class play the same role with respect to 2270 actions. This enables interoperability between different vendors who 2271 could not otherwise interoperate. 2273 For example, imagine a network composed of access devices from vendor A, 2274 edge and core devices from vendor B, and a policy server from vendor C. 2275 It is desirable for this policy server to be able to configure and 2276 manage all of the devices from vendors A and B. Unfortunately, these 2277 devices will in general have little in common (e.g., different 2278 mechanisms, different ways for controlling those mechanisms, different 2279 operating systems, different commands, and so forth). The extension 2280 conditions provide a way for vendor-specific commands to be encoded as 2281 octet strings, so that a single policy server can commonly manage 2282 devices from different vendors. 2284 6.3. Using Time Validity Periods 2286 Time validity periods are defined as an auxiliary subclass of 2287 pcimConditionAuxClass, called pcimTPCAuxClass. This is to allow their 2288 inclusion in the AND/OR condition definitions for a pcimRule. Care 2289 should be taken not to subclass pcimTPCAuxClass to add domain-specific 2290 condition properties. 2292 For example, it would be incorrect to add IPsec- or QoS-specific 2293 condition properties to the pcimTPCAuxClass class, just because IPsec or 2294 QoS includes time in its condition definition. The correct subclassing 2295 would be to create IPsec or QoS-specific subclasses of 2296 pcimConditionAuxClass and then combine instances of these domain- 2297 specific condition classes with the appropriate validity period 2298 criteria. This is accomplished using the AND/OR association capabilities 2299 for policy conditions in pcimRules. 2301 7. Security Considerations 2303 The PCLS, presented in this document, provides a mapping of the object- 2304 oriented model for describing policy information (PCIM) into a data 2305 model that forms the basic framework for describing the structure of 2306 policy data, in the case where the policy repository takes the form of 2307 an LDAP-accessible directory. 2309 PCLS is not intended to represent any particular system design or 2310 implementation. PCLS is not directly useable in a real world system, 2311 without the discipline-specific mappings that are works in progress in 2312 the Policy Framework Working Group of the IETF. 2314 These other derivative documents, which use PCIM and its discipline- 2315 specific extensions as a base, will need to convey more specific 2316 security considerations (refer to RFC3060 for more information.) 2318 The reason that PCLS, as defined here, is not representative of any 2319 real-world system, is that its object classes were designed to be 2320 independent of any specific discipline, or policy domain. For example, 2321 DiffServ and IPsec represent two different policy domains. Each document 2322 that extends PCIM to one of these domains will derive subclasses from 2323 the classes and relationships defined in PCIM, in order to represent 2324 extensions of a generic model to cover specific technical domains. 2326 PCIM-derived documents will thus subclass the PCIM classes into classes 2327 specific to each technical policy domain (QOS, IPsec, etc.), which will, 2328 in turn, be mapped, to directory-specific schemata consistent with the 2329 PCLS documented here. 2331 Even though discipline-specific security requirements are not 2332 appropriate for PCLS, specific security requirements MUST be defined for 2333 each operational real-world application of PCIM. Just as there will be 2334 a wide range of operational, real-world systems using PCIM, there will 2335 also be a wide range of security requirements for these systems. Some 2336 operational, real-world systems that are deployed using PCLS may have 2337 extensive security requirements that impact nearly all object classes 2338 utilized by such a system, while other systems' security requirements 2339 might have very little impact. 2341 The derivative documents, discussed above, will create the context for 2342 applying operational, real-world, system-level security requirements 2343 against the various models that derive from PCIM, consistent with PCLS. 2345 In some real-world scenarios, the values associated with certain 2346 properties, within certain instantiated object classes, may represent 2347 information associated with scarce, and/or costly (and therefore 2348 valuable) resources. It may be the case that these values must not be 2349 disclosed to, or manipulated by, unauthorized parties. 2351 Since this document forms the basis for the representation of a policy 2352 data model in a specific format (an LDAP-accessible directory), it is 2353 herein appropriate to reference the data model-specific tools and 2354 mechanisms that are available for achieving the authentication and 2355 authorization implicit in a requirement that restricts read and/or read- 2356 write access to these values stored in a directory. 2358 General LDAP security considerations apply, as documented in RFC3377 [2]. 2359 LDAP-specific authentication and authorization tools and mechanisms are 2360 found in the following standards track documents, which are appropriate 2361 for application to the management of security applied to policy data 2362 models stored in an LDAP-accessible directory: 2364 - RFC 2829 (Authentication Methods for LDAP) 2365 - RFC 2830 (Lightweight Directory Access Protocol (v3): Extension 2366 for Transport Layer Security) 2368 Any identified security requirements that are not dealt with in the 2369 appropriate discipline-specific information model documents, or in this 2370 document, MUST be dealt with in the derivative data model documents 2371 which are specific to each discipline. 2373 8. IANA Considerations 2375 Reference RFC 3383 "Internet Assigned Numbers Authority (IANA) 2376 Considerations for the Lightweight Directory Access Protocol (LDAP)"[16]. 2378 8.1. Object Identifiers 2380 It is requested that IANA register an LDAP Object Identifer 2381 for use in this technical specification according to the 2382 following template: 2384 Subject: Request for LDAP OID Registration 2385 Person & email address to contact for further information: 2386 Bob Moore (remoore@us.ibm.com) 2387 Specification: RFC XXXX 2388 Author/Change Controller: IESG 2389 Comments: 2390 The assigned OID will be used as a base for identifying 2391 a number of schema elements defined in this document. 2393 8.2. Object Identifier Descriptors 2395 It is requested that IANA register the LDAP Descriptors used 2396 in this technical specification as detailed in the following 2397 template: 2399 Subject: Request for LDAP Descriptor Registration Update 2400 Descriptor (short name): see comment 2401 Object Identifier: see comment 2402 Person & email address to contact for further information: 2403 Bob Moore (remoore@us.ibm.com) 2404 Usage: see comment 2405 Specification: RFC XXXX 2406 Author/Change Controller: IESG 2407 Comments: 2409 The following descriptors should be added: 2411 NAME Type OID 2412 -------------- ---- ------------ 2413 pcimPolicy O IANA-ASSIGNED-OID.1.1 2414 pcimGroup O IANA-ASSIGNED-OID.1.2 2415 pcimGroupAuxClass O IANA-ASSIGNED-OID.1.3 2416 pcimGroupInstance O IANA-ASSIGNED-OID.1.4 2417 pcimRule O IANA-ASSIGNED-OID.1.5 2418 pcimRuleAuxClass O IANA-ASSIGNED-OID.1.6 2419 pcimRuleInstance O IANA-ASSIGNED-OID.1.7 2420 pcimRuleConditionAssociation O IANA-ASSIGNED-OID.1.8 2421 pcimRuleValidityAssociation O IANA-ASSIGNED-OID.1.9 2422 pcimRuleActionAssociation O IANA-ASSIGNED-OID.1.10 2423 pcimConditionAuxClass O IANA-ASSIGNED-OID.1.11 2424 pcimTPCAuxClass O IANA-ASSIGNED-OID.1.12 2425 pcimConditionVendorAuxClass O IANA-ASSIGNED-OID.1.13 2426 pcimActionAuxClass O IANA-ASSIGNED-OID.1.14 2427 pcimActionVendorAuxClass O IANA-ASSIGNED-OID.1.15 2428 pcimPolicyInstance O IANA-ASSIGNED-OID.1.16 2429 pcimElementAuxClass O IANA-ASSIGNED-OID.1.17 2430 pcimRepository O IANA-ASSIGNED-OID.1.18 2431 pcimRepositoryAuxClass O IANA-ASSIGNED-OID.1.19 2432 pcimRepositoryInstance O IANA-ASSIGNED-OID.1.20 2433 pcimSubtreesPtrAuxClass O IANA-ASSIGNED-OID.1.21 2434 pcimGroupContainmentAuxClass O IANA-ASSIGNED-OID.1.22 2435 pcimRuleContainmentAuxClass O IANA-ASSIGNED-OID.1.23 2436 pcimKeywords A IANA-ASSIGNED-OID.2.3 2437 pcimGroupName A IANA-ASSIGNED-OID.2.4 2438 pcimRuleName A IANA-ASSIGNED-OID.2.5 2439 pcimRuleEnabled A IANA-ASSIGNED-OID.2.6 2440 pcimRuleConditionListType A IANA-ASSIGNED-OID.2.7 2441 pcimRuleConditionList A IANA-ASSIGNED-OID.2.8 2442 pcimRuleActionList A IANA-ASSIGNED-OID.2.9 2444 (descriptors continued on next page) 2445 (descriptors continued from previous page) 2447 NAME Type OID 2448 -------------- ---- ------------ 2450 pcimRuleValidityPeriodList A IANA-ASSIGNED-OID.2.10 2451 pcimRuleUsage A IANA-ASSIGNED-OID.2.11 2452 pcimRulePriority A IANA-ASSIGNED-OID.2.12 2453 pcimRuleMandatory A IANA-ASSIGNED-OID.2.13 2454 pcimRuleSequencedActions A IANA-ASSIGNED-OID.2.14 2455 pcimRoles A IANA-ASSIGNED-OID.2.15 2456 pcimConditionGroupNumber A IANA-ASSIGNED-OID.2.16 2457 pcimConditionNegated A IANA-ASSIGNED-OID.2.17 2458 pcimConditionName A IANA-ASSIGNED-OID.2.18 2459 pcimConditionDN A IANA-ASSIGNED-OID.2.19 2460 pcimValidityConditionName A IANA-ASSIGNED-OID.2.20 2461 pcimTimePeriodConditionDN A IANA-ASSIGNED-OID.2.21 2462 pcimActionName A IANA-ASSIGNED-OID.2.22 2463 pcimActionOrder A IANA-ASSIGNED-OID.2.23 2464 pcimActionDN A IANA-ASSIGNED-OID.2.24 2465 pcimTPCTime A IANA-ASSIGNED-OID.2.25 2466 pcimTPCMonthOfYearMask A IANA-ASSIGNED-OID.2.26 2467 pcimTPCDayOfMonthMask A IANA-ASSIGNED-OID.2.27 2468 pcimTPCDayOfWeekMask A IANA-ASSIGNED-OID.2.28 2469 pcimTPCTimeOfDayMask A IANA-ASSIGNED-OID.2.29 2470 pcimTPCLocalOrUtcTime A IANA-ASSIGNED-OID.2.30 2471 pcimVendorConstraintData A IANA-ASSIGNED-OID.2.31 2472 pcimVendorConstraintEncoding A IANA-ASSIGNED-OID.2.32 2473 pcimVendorActionData A IANA-ASSIGNED-OID.2.33 2474 pcimVendorActionEncoding A IANA-ASSIGNED-OID.2.34 2475 pcimPolicyInstanceName A IANA-ASSIGNED-OID.2.35 2476 pcimRepositoryName A IANA-ASSIGNED-OID.2.36 2477 pcimSubtreesAuxContainedSet A IANA-ASSIGNED-OID.2.37 2478 pcimGroupsAuxContainedSet A IANA-ASSIGNED-OID.2.38 2479 pcimRulesAuxContainedSet A IANA-ASSIGNED-OID.2.39 2481 where Type A is Attribute, Type O is ObjectClass 2483 9. Intellectual Property 2485 The IETF takes no position regarding the validity or scope of any 2486 intellectual property or other rights that might be claimed to pertain 2487 to the implementation or use of the technology described in this 2488 document or the extent to which any license under such rights might or 2489 might not be available; neither does it represent that it has made any 2490 effort to identify any such rights. Information on the IETF's 2491 procedures with respect to rights in standards-track and standards- 2492 related documentation can be found in BCP-11. 2494 Copies of claims of rights made available for publication and any 2495 assurances of licenses to be made available, or the result of an attempt 2496 made to obtain a general license or permission for the use of such 2497 proprietary rights by implementers or users of this specification can be 2498 obtained from the IETF Secretariat. 2500 The IETF invites any interested party to bring to its attention any 2501 copyrights, patents or patent applications, or other proprietary rights 2502 that may cover technology that may be required to practice this 2503 standard. Please address the information to the IETF Executive 2504 Director. 2506 10. Acknowledgments 2508 We would like to thank Kurt Zeilenga, Roland Hedburg, and Steven Legg 2509 for doing a review of this document and making many helpful suggestions 2510 and corrections. 2512 Several of the policy classes in this model first appeared in early IETF 2513 drafts on IPsec policy and QoS policy. The authors of these drafts were 2514 Partha Bhattacharya, Rob Adams, William Dixon, Roy Pereira, Raju Rajan, 2515 Jean-Christophe Martin, Sanjay Kamat, Michael See, Rajiv Chaudhury, 2516 Dinesh Verma, George Powers, and Raj Yavatkar. 2518 This document is closely aligned with the work being done in the 2519 Distributed Management Task Force (DMTF) Policy and Networks working 2520 groups. We would especially like to thank Lee Rafalow, Glenn Waters, 2521 David Black, Michael Richardson, Mark Stevens, David Jones, Hugh Mahon, 2522 Yoram Snir, and Yoram Ramberg for their helpful comments. 2524 11. Normative References 2526 [1] Moore, B., and E. Ellesson, J. Strassner, A. Westerinen "Policy 2527 Core Information Model -- Version 1 Specification", RFC 3060, 2528 February 2001. 2530 [2] Hodges, J., and Morgan R., "Lightweight Directory Access Protocol 2531 (v3): Technical Specification", RFC3377, September 2002. 2533 [3] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight 2534 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2535 2252, December 1997. 2537 [4] The Directory: Models. ITU-T Recommendation X.501, 2001. 2539 [5] Distributed Management Task Force, Inc., "Common Information 2540 Model (CIM) Specification", Version 2.2, June 14, 1999. This 2541 document is available on the following DMTF web page: 2542 http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf 2544 [6] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the 2545 CIM v2.5 Core Information Model", April 15, 2002. This document 2546 is available on the following DMTF web page: 2547 http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf 2549 [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with 2550 LDAPv3", RFC 2256, December 1997. 2552 [8] The Directory: Selected Attribute Types. ITU-T Recommendation 2553 X.520, 2001. 2555 [9] K. Zeilenga, ed., "LDAPv3: A Collection of User Schema", 2556 , May 2002. 2558 12. Informative References 2560 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2561 Levels", BCP 14, RFC 2119, March 1997. 2563 [11] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 2564 Standards Process", BCP 11, RFC 2028, October 1996. 2566 [12] Strassner, J., policy architecture BOF presentation, 42nd IETF 2567 Meeting, Chicago, Illinois, October 1998. Minutes of this BOF are 2568 available at the following location: 2569 http://www.ietf.org/proceedings/98aug/index.html. 2571 [13] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for 2572 Policy-based Admission Control", RFC 2753, January 2000. 2574 [14] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication 2575 Methods for LDAP", RFC 2829, May 2000 2577 [15] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access 2578 Protocol (v3): Extension for Transport Layer Security", RFC 2830, 2579 May 2000. 2581 [16] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 2582 Considerations for the Lightweight Directory Access Protocol 2583 (LDAP)", BCP 64, RFC 3383, September 2002. 2585 13. Authors' Addresses 2587 John Strassner 2588 Intelliden Corporation 2589 90 South Cascade Avenue 2590 Colorado Springs, CO 80903 2591 Phone: +1.719.785.0648 2592 Fax: +1.719.785.0644 2593 E-mail: john.strassner@intelliden.com 2595 Bob Moore 2596 IBM Corporation 2597 P. O. Box 12195, BRQA/B501/E116 2598 3039 Cornwallis Rd. 2599 Research Triangle Park, NC 27709-2195 2600 Phone: +1 919-254-4436 2601 Fax: +1 919-254-6243 2602 E-mail: remoore@us.ibm.com 2604 Ryan Moats 2605 Lemur Networks, Inc. 2606 15621 Drexel Circle 2607 Omaha, NE 68135 2608 Phone: +1-402-894-9456 2609 E-mail: rmoats@lemurnetworks.net 2611 Ed Ellesson 2612 3026 Carriage Trail 2613 Hillsborough, NC 27278 2614 Phone: +1 919-644-3977 2615 E-mail: ellesson@mindspring.com 2616 14. Full Copyright Statement 2618 Copyright (C) The Internet Society (2002). All Rights Reserved. 2620 This document and translations of it may be copied and furnished to 2621 others, and derivative works that comment on or otherwise explain it or 2622 assist in its implementation may be prepared, copied, published and 2623 distributed, in whole or in part, without restriction of any kind, 2624 provided that the above copyright notice and this paragraph are included 2625 on all such copies and derivative works. However, this document itself 2626 may not be modified in any way, such as by removing the copyright notice 2627 or references to the Internet Society or other Internet organizations, 2628 except as needed for the purpose of developing Internet standards in 2629 which case the procedures for copyrights defined in the Internet 2630 Standards process must be followed, or as required to translate it into 2631 languages other than English. 2633 The limited permissions granted above are perpetual and will not be 2634 revoked by the Internet Society or its successors or assigns. 2636 This document and the information contained herein is provided on an "AS 2637 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2638 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2639 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2640 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2641 FITNESS FOR A PARTICULAR PURPOSE. 2643 15. Appendix: Constructing the Value of orderedCIMKeys 2645 This appendix is non-normative, and is included in this document as a 2646 guide to implementers that wish to exchange information between CIM 2647 schemata and LDAP schemata. 2649 Within a CIM name space, the naming is basically flat; all instances are 2650 identified by the values of their key properties, and each combination 2651 of key values must be unique. A limited form of hierarchical naming is 2652 available in CIM, however, by using weak associations: since a weak 2653 association involves propagation of key properties and their values from 2654 the superior object to the subordinate one, the subordinate object can 2655 be thought of as being named "under" the superior object. Once they 2656 have been propagated, however, propagated key properties and their 2657 values function in exactly the same way that native key properties and 2658 their values do in identifying a CIM instance. 2660 The CIM mapping document [6] introduces a special attribute, 2661 orderedCIMKeys, to help map from the CIM_ManagedElement class to the 2662 LDAP class dlm1ManagedElement. This attribute SHOULD only be used in an 2663 environment where it is necessary to map between an LDAP-accessible 2664 directory and a CIM repository. For an LDAP environment, other LDAP 2665 naming attributes are defined (i.e., cn and a class-specific naming 2666 attribute) that SHOULD be used instead. 2668 The role of orderedCIMKeys is to represent the information necessary to 2669 correlate an entry in an LDAP-accessible directory with an instance in a 2670 CIM name space. Depending on how naming of CIM-related entries is 2671 handled in an LDAP directory, the value of orderedCIMKeys represents one 2672 of two things: 2674 - If the DIT hierarchy does not mirror the "weakness hierarchy" of 2675 the CIM name space, then orderedCIMKeys represents all the 2676 keys of the CIM instance, both native and propagated. 2677 - If the DIT hierarchy does mirror the "weakness hierarchy" of the 2678 CIM name space, then orderedCIMKeys may represent either all the 2679 keys of the instance, or only the native keys. 2681 Regardless of which of these alternatives is taken, the syntax of 2682 orderedCIMKeys is the same - a DirectoryString of the form 2684 .=[,=]* 2686 where the = elements are ordered by the names of the key 2687 properties, according to the collating sequence for US ASCII. The only 2688 spaces allowed in the DirectoryString are those that fall within a 2689 element. As with alphabetizing the key properties, the goal of 2690 suppressing the spaces is once again to make the results of string 2691 operations predictable. 2693 The values of the elements are derived from the various CIM 2694 syntaxes according to a grammar specified in [5].