idnits 2.17.1 draft-ietf-policy-core-schema-10.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 31) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 205 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([Policy], [10], [11], [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 -- 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 (March 2001) is 8442 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) -- Looks like a reference, but probably isn't: 'Policy' on line 96 == Unused Reference: '4' is defined on line 2380, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2387, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2392, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2394, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2252 (ref. '2') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2028 (ref. '4') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2256 (ref. '11') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 8 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 A. Westerinen 3 Category: Standards Track Cisco Systems 4 E. Ellesson 5 LongBoard, Inc. 6 B. Moore 7 IBM Corporation 8 R. Moats 9 Coreon, Inc. 10 March 2001 12 Policy Core LDAP Schema 13 draft-ietf-policy-core-schema-10.txt 14 March 29, 2001 09:23 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society (2001). All Rights Reserved. 40 Abstract 42 This document takes as its starting point the object-oriented 43 information model for representing policy information currently under 44 joint development in the Service Level Agreements (SLA) Policy working 45 group of the Distributed Management Task Force (DMTF) and in the 46 IETF's Policy Framework working group. The IETF document defining 47 this information model is the "Policy Core Information Model -- 48 Version 1 Specification" [1]. This model defines two hierarchies of 49 object classes: structural classes representing policy information and 50 control of policies, and relationship classes that indicate how 51 instances of the structural classes are related to each other. In 52 general, both of these class hierarchies will need to be mapped to a 53 particular data store. 55 This draft defines the mapping of these information model classes to a 56 directory that uses LDAPv3 as its access protocol. When mapping to an 57 LDAP schema, the structural classes can be mapped more or less 58 directly. The relationship hierarchy, however, must be mapped to a 59 form suitable for directory implementation. Since this mapping of the 60 relationship classes could be done in a number of different ways, 61 there is the risk of non-interoperable implementations. To avoid this 62 possibility, this document provides a single mapping that all 63 implementations using an LDAP directory as their policy repository 64 SHALL use. 66 Classes are also added to the LDAP schema to improve the performance 67 of a client's interactions with an LDAP server when the client is 68 retrieving large amounts of policy-related information. These classes 69 exist only to optimize LDAP retrievals: there are no classes in the 70 information model that correspond to them. 72 The LDAP schema described in this document consists of ten very 73 general classes: policy (an abstract class), three policyGroup 74 classes, three policyRule classes, policyConditionAuxClass, 75 ptpConditionAuxClass, and policyActionAuxClass. (Note that the 76 PolicyTimePeriodCondition auxiliary class would normally have been 77 named policyTimePeriodConditionAuxClass, but this name is too long for 78 some directories. Therefore, we have abbreviated this name as 79 ptpConditionAuxClass). The mapping for the PCIM classes PolicyGroup 80 and PolicyRule is similar to the mapping in [10] for several CIM 81 concrete classes: an abstract superclass, with an auxiliary class and 82 a structural class derived from it. See [10] for more details on this 83 mapping approach. The schema also contains two less general classes: 84 vendorPolicyConditionAuxClass and vendorPolicyActionAuxClass. To 85 achieve the mapping of the information model's relationships, the 86 schema contains two auxiliary classes: policyGroupContainmentAuxClass 87 and policyRuleContainmentAuxClass. Capturing the distinction between 88 rule-specific and reusable policy conditions and policy actions 89 introduces seven other classes: policyRuleConditionAssociation, 90 policyRuleValidityAssociation, policyRuleActionAssociation, 91 policyInstance, and three policyRepository classes. Finally, the 92 schema includes two classes policySubtreesPtrAuxClass and 93 policyElementAuxClass for optimizing LDAP retrievals. In all, 94 therefore, the schema contains 23 classes. 96 Within the context of this document, the term "Core [Policy] Schema" 97 is used to refer to the LDAP class definitions it contains. 99 Table of Contents 100 1. Introduction......................................................3 101 2. The Policy Core Information Model.................................4 102 3. Inheritance Hierarchy for the LDAP Core Policy Schema.............5 103 4. General Discussion of Mapping the Information Model to LDAP.......7 104 4.1. Summary of Class and Association Mappings....................7 105 4.2. Naming Attributes in the Core Schema........................10 106 4.3. Rule-Specific and Reusable Conditions and Actions...........11 107 4.4. Location and Retrieval of Policy Objects in the Directory...14 108 4.4.1. Aliases and Other DIT-Optimization Techniques.............17 109 5. Class Definitions................................................18 110 5.1. The Abstract Class "policy".................................18 111 5.2. The Three policyGroup Classes...............................19 112 5.3. The Three policyRule Classes................................21 113 5.4. The Class policyRuleConditionAssociation....................27 114 5.5. The Class policyRuleValidityAssociation.....................29 115 5.6. The Class policyRuleActionAssociation.......................31 116 5.7. The Auxiliary Class policyConditionAuxClass.................34 117 5.8. The Auxiliary Class ptpConditionAuxClass....................34 118 5.9. The Auxiliary Class vendorPolicyConditionAuxClass...........36 119 5.10. The Auxiliary Class policyActionAuxClass...................37 120 5.11. The Auxiliary Class vendorPolicyActionAuxClass.............38 121 5.12. The Class policyInstance...................................38 122 5.13. The Auxiliary Class policyElementAuxClass..................40 123 5.14. The Three policyRepository Classes.........................41 124 5.15. The Auxiliary Class policySubtreesPtrAuxClass..............43 125 5.15.1. The Attribute policySubtreesAuxContainedSet..............44 126 5.16. The Auxiliary Class policyGroupContainmentAuxClass.........44 127 5.16.1. The Attribute policyGroupsAuxContainedSet................45 128 5.17. The Auxiliary Class policyRuleContainmentAuxClass..........45 129 5.17.1. The Attribute policyRulesAuxContainedSet.................46 130 6. Extending the Core Schema........................................46 131 6.1. Subclassing policyConditionAuxClass and policyActionAuxClass46 132 6.2. Using the Vendor Policy Encoding Attributes.................46 133 6.3. Using Time Validity Periods.................................47 134 7. Security Considerations..........................................47 135 8. Intellectual Property............................................49 136 9. Acknowledgments..................................................49 137 10. References......................................................49 138 11. Authors' Addresses..............................................50 139 12. Full Copyright Statement........................................51 140 13. Appendix: Constructing the Value of orderedCimKeys.............52 142 1. Introduction 144 This document takes as its starting point the object-oriented 145 information model for representing policy information currently under 146 joint development in the Service Level Agreements working group of the 147 Distributed Management Task Force (DMTF) and in the IETF's Policy 148 Framework working group. The IETF document defining this information 149 model is the "Policy Core Information Model -- Version 1 150 Specification" [1]. This model defines two hierarchies of object 151 classes: structural classes representing policy information and 152 control of policies, and relationship classes that indicate how 153 instances of the structural classes are related to each other. In 154 general, both of these class hierarchies will need to be mapped to a 155 particular data store. 157 This draft defines the mapping of these information model classes to a 158 directory that uses LDAPv3 as its access protocol. Two types of 159 mappings are involved: 161 o For the structural classes in the information model, the mapping is 162 basically one-for-one: information model classes map to LDAP 163 classes, information model properties map to LDAP attributes. 165 o For the relationship classes in the information model, different 166 mappings are possible. In this document the information model's 167 relationship classes and their properties are mapped in three ways: 168 to LDAP auxiliary classes, to attributes representing DN pointers, 169 and to containment in the Directory Information Tree (DIT). 171 Implementations that use an LDAP directory as their policy repository 172 SHALL use the LDAP policy schema defined in this document. The use of 173 the information model defined in reference [1] as the starting point 174 enables the schema and the relationship class hierarchy to be 175 extensible, such that other types of policy repositories, such as 176 relational databases, can also use this information. 178 This document fits into the overall framework for representing, 179 deploying, and managing policies being developed by the Policy 180 Framework Working Group. It traces its origins to work that was 181 originally done for the Directory-enabled Networks (DEN) 182 specification, reference [5]. Work on the DEN specification by the 183 DEN Ad-Hoc Working Group itself has been completed. Further work to 184 standardize the models contained in it will be the responsibility of 185 selected working groups of the Common Information Model (CIM) effort 186 in the Distributed Management Task Force (DMTF). DMTF standardization 187 of the core policy model is the responsibility of the SLA Policy 188 working group in the DMTF. 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC 2119 [3]. 194 2. The Policy Core Information Model 196 This document contains an LDAP schema representing the Policy Core 197 Information Model (abbreviated "PCIM"), which is defined in the 198 companion document "Policy Core Information Model -- Version 1 199 Specification" [1]. Other documents may subsequently be produced, 200 with mappings of this same PCIM to other storage technologies. Since 201 the detailed semantics of the Core Policy classes appear only in 202 reference [1], that document is a prerequisite for reading and 203 understanding this document. 205 3. Inheritance Hierarchy for the LDAP Core Policy Schema 207 The following diagram illustrates the class hierarchy for the LDAP 208 Core Policy Schema classes: 210 top 211 | 212 +--dlm1ManagedElement (abstract) 213 | | 214 | +--policy (abstract) 215 | | | 216 | | +--policyGroup (abstract) 217 | | | | 218 | | | +--policyGroupAuxClass (auxiliary) 219 | | | | 220 | | | +--policyGroupInstance (structural) 221 | | | 222 | | +--policyRule (abstract) 223 | | | | 224 | | | +--policyRuleAuxClass (auxiliary) 225 | | | | 226 | | | +--policyRuleInstance (structural) 227 | | | 228 | | +--policyRuleConditionAssociation (structural) 229 | | | 230 | | +--policyRuleValidityAssociation (structural) 231 | | | 232 | | +--policyRuleActionAssociation (structural) 233 | | | 234 | | +--policyInstance (structural) 235 | | | 236 | | +--policyElementAuxClass (auxiliary) 237 | | 238 | +--dlm1ManagedSystemElement (abstract) 239 | | 240 | +--dlm1LogicalElement (abstract) 241 | | 242 | +--dlm1System (abstract) 243 | | 244 | +--dlm1AdminDomain (abstract) 245 | | 246 | +--policyRepository (abstract) 247 | | 248 | +--policyRepositoryAuxClass (auxiliary) 249 | | 250 | +--policyRepositoryInstance (structural) 252 (continued on following page) 253 (continued from previous page) 255 top 256 | 257 +--policyConditionAuxClass (auxiliary) 258 | | 259 | +---ptpConditionAuxClass (auxiliary) 260 | | 261 | +---vendorPolicyConditionAuxClass (auxiliary) 262 | 263 +--policyActionAuxClass (auxiliary) 264 | | 265 | +---vendorPolicyActionAuxClass (auxiliary) 266 | 267 +--policySubtreesPtrAuxClass (auxiliary) 268 | 269 +--policyGroupContainmentAuxClass (auxiliary) 270 | 271 +--policyRuleContainmentAuxClass (auxiliary) 273 Figure 1. LDAP Class Inheritance Hierarchy for the Core Policy 274 Schema 276 4. General Discussion of Mapping the Information Model to LDAP 278 The classes described in Section 5 below contain certain optimizations 279 for a directory that uses LDAP as its access protocol. One example of 280 this is the use of auxiliary classes to represent some of the 281 associations defined in the information model. Other data stores 282 might need to implement these associations differently. A second 283 example is the introduction of classes specifically designed to 284 optimize retrieval of large amounts of policy-related data from a 285 directory. This section discusses some general topics related to the 286 mapping from the information model to LDAP. 288 The content and structure rules provided here are suggestions; they 289 may be modified as needed to support a particular directory structure. 290 Directory administrators do not need to subclass/instantiate all of 291 the classes in this schema. They are free to choose the subset that 292 meets their particular needs. 294 4.1. Summary of Class and Association Mappings 296 Fifteen of the classes in the LDAP Core Policy Schema come directly 297 from the nine corresponding classes in the information model. Note 298 that names of classes begin with an upper case character in the 299 information model (although for CIM in particular, case is not 300 significant in class and property names), but with a lower case 301 character in LDAP. 303 +---------------------------+-----------------------------------+ 304 | Information Model | LDAP Class | 305 +---------------------------+-----------------------------------+ 306 +---------------------------+-----------------------------------+ 307 | Policy | policy | 308 +---------------------------+-----------------------------------+ 309 | PolicyGroup | policyGroup | 310 | | policyGroupAuxClass | 311 | | policyGroupInstance | 312 +---------------------------+-----------------------------------+ 313 | PolicyRule | policyRule | 314 | | policyRuleAuxClass | 315 | | policyRuleInstance | 316 +---------------------------+-----------------------------------+ 317 | PolicyCondition | policyConditionAuxClass | 318 +---------------------------+-----------------------------------+ 319 | PolicyAction | policyActionAuxClass | 320 +---------------------------+-----------------------------------+ 321 | VendorPolicyCondition | vendorPolicyConditionAuxClass | 322 +---------------------------+-----------------------------------+ 323 | VendorPolicyAction | vendorPolicyActionAuxClass | 324 +---------------------------+-----------------------------------+ 325 | PolicyTimePeriodCondition | ptpConditionAuxClass | 326 +---------------------------+-----------------------------------+ 327 | PolicyRepository | policyRepository | 328 | | policyRepositoryAuxClass | 329 | | policyRepositoryInstance | 330 +---------------------------+-----------------------------------+ 331 Figure 2. Mapping of Information Model Classes to LDAP 333 The associations in the information model map to DN-pointer attributes 334 or to Directory Information Tree (DIT) containment in LDAP. Two of 335 the DN-pointer attributes appear in auxiliary classes, which allow 336 each of them to represent several relationships from the information 337 model. 339 +-----------------------------------+--------------------------------+ 340 | Information Model Association | LDAP Attribute / Class | 341 +-----------------------------------+--------------------------------+ 342 +-----------------------------------+--------------------------------+ 343 | PolicyGroupInPolicyGroup | policyGroupsAuxContainedSet in | 344 | | policyGroupContainmentAuxClass| 345 +-----------------------------------+--------------------------------+ 346 | PolicyRuleInPolicyGroup | policyRulesAuxContainedSet in | 347 | | policyRuleContainmentAuxClass | 348 +-----------------------------------+--------------------------------+ 349 | PolicyConditionInPolicyRule | DIT containment + | 350 | | policyRuleConditionList in | 351 | | policyRule + | 352 | | policyConditionDN in | 353 | | policyRuleConditionAssociation| 354 +-----------------------------------+--------------------------------+ 355 | PolicyActionInPolicyRule | DIT containment + | 356 | | policyRuleActionList in | 357 | | policyRule + | 358 | | policyActionDN in | 359 | | policyRuleActionAssociation | 360 +-----------------------------------+--------------------------------+ 361 | PolicyRuleValidityPeriod | policyRuleValidityAssociation | 362 | | + ptpConditionAuxClass or | 363 | | referenced through the | 364 | | policyTimePeriodConditionDN | 365 +-----------------------------------+--------------------------------+ 366 | PolicyConditionInPolicyRepository | DIT containment | 367 +-----------------------------------+--------------------------------+ 368 | PolicyActionInPolicyRepository | DIT containment | 369 +-----------------------------------+--------------------------------+ 370 | PolicyRepositoryInPolicyRepository| DIT containment | 371 +-----------------------------------+--------------------------------+ 372 Figure 3. Mapping of Information Model Associations to LDAP 374 Of the remaining classes in the LDAP Core Schema, two 375 (policyElementAuxClass and policySubtreesPtrAuxClass) are included to 376 make navigation through the DIT and retrieval of the entries found 377 there more efficient. This topic is discussed in Section 4.4 below. 379 The remaining four classes in the LDAP Core Schema, 380 policyRuleConditionAssociation, policyRuleValidityAssociation, 381 policyRuleActionAssociation, and policyInstance are all involved with 382 the representation of policy conditions and policy actions in an LDAP 383 directory. This topic is discussed in Section 4.3 below. 385 4.2. Naming Attributes in the Core Schema 387 Instances in a directory are identified by distinguished names (DNs), 388 which provide the same type of hierarchical organization that a file 389 system provides in a computer system. A distinguished name is a 390 sequence of relative distinguished names (RDNs), where an RDN provides 391 a unique identifier for an instance within the context of its 392 immediate superior, in the same way that a filename provides a unique 393 identifier for a file within the context of the folder in which it 394 resides. 396 To preserve maximum naming flexibility for policy administrators, each 397 of the structural classes defined in this schema has its own optional 398 ("MAY") naming attribute. Since the naming attributes are different, a 399 policy administrator can, by using these attributes, guarantee that 400 there will be no name collisions between instances of different 401 classes, even if the same value is assigned to the instances' 402 respective naming attributes. 404 The LDAP attribute cn (corresponding to X.500's commonName) is 405 included as a MAY attribute in the abstract class policy, and thus by 406 inheritance in all of its subclasses. In X.500, commonName typically 407 functions as an RDN attribute, for naming instances of such classes as 408 X.500's person. 410 Finally, for implementations that expect to map between native CIM and 411 LDAP representations of policy information, a second MAY attribute, 412 orderedCimKeys, is inherited from the class dlm1ManagedElement, 413 defined in reference [10], into the abstract class "policy". The 414 value of this attribute is derived algorithmically from values that 415 are already present in a CIM policy instance. See the appendix of 416 this document for a complete description of the algorithm. 418 Each of the Core Schema classes thus has three attributes suitable for 419 naming: cn, its own class-specific attribute, and orderedCimKeys. Any 420 of these attributes MAY be used for naming an instance of a Core 421 Schema class. Consequently, implementations MUST be able to 422 accommodate instances named in any of these ways. 424 Note that cn, the class-specific naming attribute, and orderedCimKeys 425 SHOULD NOT be used together to form a multi-part RDN, since support 426 for multi-part RDNs is limited among existing directory 427 implementations. 429 4.3. Rule-Specific and Reusable Conditions and Actions 431 The PCIM [1] distinguishes between two types of policy conditions and 432 policy actions: ones associated with a single policy rule, and ones 433 that are reusable, in the sense that they may be associated with more 434 than one policy rule. There is no inherent difference between a rule- 435 specific condition or action and a reusable one. There are, however, 436 differences in how they are treated in a policy repository. For 437 example, it's natural to make the access permissions for a rule- 438 specific condition or action identical to those for the rule itself. 439 It's also natural for a rule-specific condition or action to be 440 removed from the policy repository at the same time the rule is. With 441 reusable conditions and actions, on the other hand, access permissions 442 and existence criteria must be expressible without reference to a 443 policy rule. 445 The preceding paragraph does not contain an exhaustive list of the 446 ways in which reusable and rule-specific conditions should be treated 447 differently. Its purpose is merely to justify making a semantic 448 distinction between rule-specific and reusable, and then reflecting 449 this distinction in the policy repository itself. 451 When the policy repository is realized in an LDAP-accessible 452 directory, the distinction between rule-specific and reusable 453 conditions and actions is realized via placement of auxiliary classes 454 and via DIT containment. Figure 4 illustrates a policy rule Rule1 455 with one rule-specific condition CA and one rule-specific action AB. 456 Because the condition and action are specific to Rule1, the auxiliary 457 classes ca and ab that represent them are attached, respectively, to 458 the structural classes CA and AB. These structural classes represent 459 not the condition ca and action ab themselves, but rather the 460 associations between Rule1 and ca, and between Rule1 and ab. 462 As Figure 4 illustrates, Rule1 contains DN pointers to the structural 463 classes CA and AB that appear below it in the DIT. At first glance it 464 might appear that these DN pointers are unnecessary, since a subtree 465 search below Rule1 would find all of the structural classes 466 representing the associations between Rule1 and its conditions and 467 actions. Relying only on a subtree search, though, runs the risk of 468 missing conditions or actions that should have appeared in the 469 subtree, but for some reason did not, or of finding conditions or 470 actions that were inadvertently placed in the subtree, or that should 471 have been removed from the subtree, but for some reason were not. 472 With the use of DN pointers, many (but not all) of these risks are 473 eliminated. 475 Note that the existence dependency of a rule-specific condition or 476 action on its policy rule follows in this case from the semantics of 477 DNs. Note also that for directory implementations supporting subtree- 478 based access permissions, it's easy to indicate that parties with 479 access to Rule1 also have access to its condition and action. 481 +-----+ 482 |Rule1| 483 | | 484 +-----|- -|-----+ 485 | +-----+ | 486 | * * | 487 | * * | 488 | **** **** | 489 | * * | 490 v * * v 491 +--------+ +--------+ 492 | CA+ca | | AB+ab | 493 +--------+ +--------+ 495 +------------------------------+ 496 |LEGEND: | 497 | ***** DIT containment | 498 | + auxiliary attachment | 499 | ----> DN pointer | 500 +------------------------------+ 502 Figure 4. Rule-Specific Policy Conditions and Actions 504 Figure 5 illustrates a second way of representing rule-specific 505 conditions and actions in an LDAP-accessible directory: attachment of 506 the auxiliary classes directly to the instance representing the policy 507 rule. When all of the conditions and actions are attached to a policy 508 rule in this way, the rule is termed a "simple" policy rule. When 509 conditions and actions are not attached directly to a policy rule, the 510 rule is termed "complex". 512 The simple/complex distinction for a policy rule is not all or 513 nothing. A policy rule may have its conditions attached to itself and 514 its actions attached to other entries, or it may have its actions 515 attached to itself and its conditions attached to other entries. 516 However, it SHALL NOT have either its conditions or its actions 517 attached both to itself and to other entries, with one exception: a 518 policy rule may point to its validity periods with the 519 policyRuleValidityPeriodList attribute, but have its other conditions 520 attached to itself. 522 The tradeoffs between simple and complex policy rules are between the 523 efficiency of simple rules and the flexibility and greater potential 524 for reuse of complex rules. With a simple policy rule, the semantic 525 options are limited: 527 o All conditions are ANDed together. This combination can be 528 represented in two ways in the DNF / CNF expressions 529 characteristic of policy conditions: as a DNF expression with a 530 single AND group, or as a CNF expression with multiple single- 531 condition OR groups. The first of these is arbitrarily chosen as 532 the representation for the ANDed conditions in a simple policy 533 rule. 535 o If multiple actions are included, no order can be specified for 536 them. 538 If a policy administrator needs to combine conditions in some other 539 way, or if there is a set of actions that must be ordered, then the 540 only option is to use a complex policy rule. 542 +-----------+ 543 |Rule1+ca+ab| 544 | | 545 +-----------+ 547 +------------------------------+ 548 |LEGEND: | 549 | + auxiliary attachment | 550 +------------------------------+ 552 Figure 5. A Simple Policy Rule 554 Finally, Figure 6 illustrates the same policy rule Rule1, but this 555 time its condition and action are reusable. The association classes 556 CA and AB are still present, and they are still DIT contained under 557 Rule1. But rather than having the auxiliary classes ca and ab 558 attached to themselves, CA and AB now contain DN pointers to other 559 entries to which these auxiliary classes are attached. These other 560 entries, CIA and AIB, are DIT contained under RepositoryX, which is an 561 instance of the class policyRepository. Because they are named under 562 an instance of policyRepository, ca and ab are clearly identified as 563 reusable. 565 The structural classes CIA and AIB in Figure 6 may either be instances 566 of the generic class policyInstance (defined in Section 5.11). 568 +-----+ +-------------+ 569 |Rule1| | RepositoryX | 570 +-|- -|--+ | | 571 | +-----+ | +-------------+ 572 | * * | * * 573 | * * | * * 574 | *** **** | * * 575 | * * v * * 576 | * +---+ * * 577 | * |AB | +------+ * 578 v * | -|-------->|AIB+ab| * 579 +---+ +---+ +------+ * 580 |CA | +------+ 581 | -|------------------------>|CIA+ca| 582 +---+ +------+ 584 +------------------------------+ 585 |LEGEND: | 586 | ***** DIT containment | 587 | + auxiliary attachment | 588 | ----> DN pointer | 589 +------------------------------+ 591 Figure 6. Reusable Policy Conditions and Actions 593 The classes policyConditionAuxClass and policyActionAuxClass do not 594 themselves represent actual conditions and actions: these are 595 introduced in their subclasses. What policyConditionAuxClass and 596 policyActionAuxClass do introduce are the semantics of being a policy 597 condition or a policy action. These are the semantics that all the 598 subclasses of policyConditionAuxClass and policyActionAuxClass 599 inherit. Among these semantics are those of representing either a 600 rule-specific or a reusable policy condition or policy action. 602 In order to preserve the ability to represent a rule-specific or a 603 reusable condition or action, as well as a simple policy rule, all the 604 subclasses of policyConditionAuxClass and policyActionAuxClass MUST 605 also be auxiliary classes. 607 4.4. Location and Retrieval of Policy Objects in the Directory 609 When a PDP goes to an LDAP directory to retrieve the policy object 610 instances relevant to the PEPs it serves, it is faced with two related 611 problems: 613 o How does it locate and retrieve the directory entries that apply to 614 its PEPs? These entries may include instances of the Core Schema 615 classes, instances of domain-specific subclasses of these classes, 616 and instances of other classes modeling such resources as user 617 groups, interfaces, and address ranges. 619 o How does it retrieve the directory entries it needs in an efficient 620 manner, so that retrieval of policy information from the directory 621 does not become a roadblock to scalability? There are two facets 622 to this efficiency: retrieving only the relevant directory 623 entries, and retrieving these entries using as few LDAP calls as 624 possible. 626 The placement of objects in the Directory Information Tree (DIT) 627 involves considerations other than how the policy-related objects will 628 be retrieved by a PDP. Consequently, all that the Core Schema can do 629 is to provide a "toolkit" of classes to assist the policy 630 administrator as the DIT is being designed and built. A PDP SHOULD be 631 able to take advantage of any tools that the policy administrator is 632 able to build into the DIT, but it MUST be able to use a less 633 efficient means of retrieval if that is all it has available to it. 635 The basic idea behind the LDAP optimization classes is a simple one: 636 make it possible for a PDP to retrieve all the policy-related objects 637 it needs, and only those objects, using as few LDAP calls as possible. 638 An important assumption underlying this approach is that the policy 639 administrator has sufficient control over the underlying DIT structure 640 to define subtrees for storing policy information. If the policy 641 administrator does not have this level of control over DIT structure, 642 a PDP can still retrieve the policy-related objects it needs 643 individually. But it will require more LDAP access operations to do 644 the retrieval in this way. 646 Figure 7 illustrates how LDAP optimization is accomplished. 648 +-----+ 649 ---------------->| A | 650 DN pointer to | | DN pointers to subtrees +---+ 651 starting object +-----+ +------------------------->| C | 652 | o--+----+ +---+ +---+ 653 | o--+------------->| B | / \ 654 +-----+ +---+ / \ 655 / \ / \ / ... \ 656 / \ / \ 657 / \ / ... \ 659 Figure 7. Using policySubtreesPtrAuxClass to Locate Policies 661 The PDP is configured initially with a DN pointer to some entry in the 662 DIT. The structural class of this entry is not important; the PDP is 663 interested only in the policySubtreesPtrAuxClass attached to it. This 664 auxiliary class contains a multi-valued attribute with DN pointers to 665 objects that anchor subtrees containing policy-related objects of 666 interest to the PDP. Since policySubtreesPtrAuxClass is an auxiliary 667 class, it can be attached to an entry that the PDP would need to 668 access anyway - perhaps an entry containing initial configuration 669 settings for the PDP, or for a PEP that uses the PDP. 671 Once it has retrieved the DN pointers, the PDP will direct to each of 672 the objects identified by them an LDAP request that all entries in its 673 subtree be evaluated against the selection criteria specified in the 674 request. The LDAP-enabled directory then returns all entries in that 675 subtree that satisfy the specified criteria. 677 The selection criteria always specify that object class = "policy". 678 Since all classes representing policy rules, policy conditions, and 679 policy actions, both in the Core Schema and in any domain-specific 680 schema derived from it, are subclasses of the abstract class policy, 681 this criterion evaluates to TRUE for all instances of these classes. 682 To accommodate special cases where a PDP needs to retrieve objects 683 that are not inherently policy-related (for example, an IP address 684 range object pointed to by a subclass of policyActionAuxClass 685 representing the DHCP action "assign from this address range), the 686 auxiliary class policyElementAuxClass can be used to "tag" an entry, 687 so that it will be found by the selection criterion "object class = 688 policy". 690 The approach described in the preceding paragraph will not work for 691 certain directory implementations, because these implementations do 692 not support matching of auxiliary classes in the objectClass 693 attribute. For environments where these implementations are expected 694 to be present, the "tagging" of entries as relevant to policy can be 695 accomplished by inserting the special value "POLICY" into the list of 696 values contained in the policyKeywords attribute. 698 If a PDP needs only a subset of the policy-related objects in the 699 indicated subtrees, then it can be configured with additional 700 selection criteria based on the policyKeywords attribute defined in 701 the policy class. This attribute supports both standardized and 702 administrator-defined values. Thus a PDP could be configured to 703 request only those policy-related objects containing the keywords 704 "DHCP" and "Eastern US". 706 To optimize what is expected to be a typical case, the initial request 707 from the client includes not only the object to which its "seed" DN 708 pointer points, but also the subtree contained under this object. The 709 filter for searching this subtree is whatever the client is going to 710 use later to search the other subtrees: "object class = policy", 711 presence of the keyword "POLICY", or presence of a more specific 712 policyKeyword. 714 Returning to the example in Figure 7, we see that in the best case, a 715 PDP can get all the policy-related objects it needs, and only these 716 objects, with exactly three LDAP requests: one to its starting object 717 A to get the pointers to B and C, as well as the policy-related 718 objects it needs from the subtree under A, and then one each to B and 719 C to get all the policy-related objects that pass the selection 720 criteria with which it was configured. Once it has retrieved all of 721 these objects, the PDP can then traverse their various DN pointers 722 locally to understand the semantic relationships among them. The PDP 723 should also be prepared to find a pointer to another subtree attached 724 to any of the objects it retrieves, and to follow this pointer first, 725 before it follows any of the semantically significant pointers it has 726 received. This recursion permits a structured approach to identifying 727 related policies. In Figure 7, for example, if the subtree under B 728 includes departmental policies and the one under C includes divisional 729 policies, then there might be a pointer from the subtree under C to an 730 object D that roots the subtree of corporate-level policies. 732 Since a PDP has no guarantee that the entity that populates the 733 directory won't use the policySubtreesPtrAuxClass, a PDP SHOULD 734 understand this class, SHOULD be capable of retrieving and processing 735 the entries in the subtrees it points to, and SHOULD be capable of 736 doing all of this recursively. The same requirements apply to any 737 other entity needing to retrieve policy information from the 738 directory. Thus a Policy Management Tool that retrieves policy 739 entries from the directory in order to perform validation and conflict 740 detection SHOULD also understand and be capable of using the 741 policySubtreesPtrAuxClass. All of these requirements are "SHOULD"s 742 rather than "MUST"s because an LDAP client that doesn't implement them 743 can still access and retrieve the directory entries it needs . The 744 process of doing so will just be less efficient than it would have 745 been if the client had implemented these optimizations. 747 When it is serving as a tool for creating policy entries in the 748 directory, a Policy Management Tool SHOULD support creation of 749 policySubtreesPtrAuxClass entries and their DN pointers. 751 4.4.1. Aliases and Other DIT-Optimization Techniques 753 Additional flexibility in DIT structure is available to the policy 754 administrator via LDAP aliasing. Figure 8 illustrates this 755 flexibility. 757 +-----+ 758 ---------------->| A | 759 DN pointer to | | DN pointers to subtrees +---+ 760 starting object +-----+ +------------------------->| C | 761 | o--+----+ +---+ +---+ 762 | o--+------------->| B | / \ 763 +-----+ +---+ / \ 764 / \ / \ / ... \ 765 / \ / \ 766 / \ / \ 767 +---+ / +------+ \ 768 | X |<***************************|aliasX| 769 +---+ +------+ 771 Figure 8. Addition of an Alias Object 773 Even if it is necessary to store a policy entry X in a directory 774 location separate from the other policy entries, batch retrieval using 775 policy subtrees can still be done. The administrator simply inserts 776 into one of the subtrees of policy entries an alias entry aliasX 777 pointing to the outlying entry X. When the PDP requests all entries 778 in the subtree under B, a response will be returned for entry X, just 779 as responses are returned for all the (non-alias) entries that 780 actually are in the subtree. 782 Since resolution of an alias to its true entry is handled entirely by 783 the LDAP directory, and is invisible to directory clients, PDPs need 784 not do anything extra to support aliases. A Policy Management Tool 785 MAY make available to a policy administrator the ability to create 786 alias entries like the one in Figure 7. 788 In addition to aliases, there are several other techniques for 789 managing the placement of entries in the DIT and their retrieval by 790 directory clients. Among these other techniques are referrals, LDAP 791 URLs, and attributes like seeAlso. Discussion of how these other 792 techniques might be applied to policy-related entries in a directory 793 is outside the scope of this document. 795 5. Class Definitions 797 The semantics for the LDAP classes mapped directly from the 798 information model are detailed in reference [1]. Consequently, all 799 that this document presents for these classes is a bare specification 800 of the LDAP classes and attributes. More details are provided for the 801 attributes listed above in Figure 3, which realize in LDAP the 802 relationships defined in the information model. Finally, the classes 803 that exist only in the LDAP Core Schema are documented fully in this 804 document. 806 The formal language for specifying the classes, attributes, and DIT 807 structure and content rules is that defined in reference [2]. 809 Note: all attribute, object class, and name form OIDs, and all 810 structure rule integers, are place holders, and syntax OIDs in 811 definitions have been replaced by names for clarity. 813 5.1. The Abstract Class "policy" 815 The abstract class "policy" is a direct mapping of the abstract class 816 Policy from the Core Information Model. The five properties in 817 Policy, three of which are inherited from the class 818 dlm1ManagedElement, map directly to attributes in the class "policy". 819 See reference [10] for the definition of the LDAP class 820 dlm1ManagedElement. 822 The class value "policy" is also used as the mechanism for identifying 823 policy-related instances in the Directory Information Tree. An 824 instance of any class may be "tagged" with this class value by 825 attaching to it the auxiliary class policyElementAuxClass. 827 The class definition is as follows: 829 ( NAME 'policy' 830 DESC 'An abstract class with five attributes for describing 831 a policy-related instance. The attributes dlmCaption, 832 dlmDescription, and orderedCimKeys are inherited from 833 dlm1ManagedElement.' 834 SUP dlm1ManagedElement 835 ABSTRACT 836 MAY ( cn $ policyKeywords ) 837 ) 839 The three attributes dlmCaption, dlmDescription, and orderedCimKeys 840 are defined in reference [10]. The attribute cn is defined in RFC 841 2256 [11]. The remaining attribute, policyKeywords, is defined as 842 follows: 844 ( NAME 'policyKeywords' 845 DESC 'A set of keywords to assist directory clients in 846 locating the policy objects applicable to them. Each 847 value of the multi-valued attribute contains a single 848 keyword. Standard keyword values are listed in the 849 Policy Core Information Model document. 851 This value is a Directory String.' 852 EQUALITY caseIgnoreMatch 853 SUBSTR caseIgnoreSubstringsMatch 854 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 855 ) 857 5.2. The Three policyGroup Classes 859 The information model defines a policyGroup class to serve as a 860 generalized aggregation container. It enables policyRules and 861 policyGroups to be aggregated in the same container. The LDAP schema 862 maps this class into three LDAP classes. The class definitions for the 863 three policyGroup classes are as follows. Note that these class 864 definitions do not include attributes to realize the 865 PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from 866 the object model, since a policyGroup object points to instances of 867 policyGroup and policyRule via, respectively, the pointer in 868 policyGroupContainmentAuxClass and the pointer in 869 policyRuleContainmentAuxClass. 871 To maximize flexibility, the policyGroup class is defined as abstract. 872 A subclass policyGroupAuxClass provides for auxiliary attachment to 873 another entry, while a structural subclass policyGroupInstance is 874 available to represent a policy group as a standalone entry. 876 ( NAME 'policyGroup' 877 DESC 'A container for either a set of related policyRules or 878 a set of related policyGroups. A policyGroup may also 879 contain a mixture of policyRules and other 880 policyGroups.' 881 SUP policy 882 ABSTRACT 883 MAY ( policyGroupName ) 884 ) 886 ( NAME 'policyGroupAuxClass' 887 DESC 'A container for either a set of related policyRules or 888 a set of related policyGroups. A policyGroup may also 889 contain a mixture of policyRules and other 890 policyGroups.' 891 SUP policyGroup 892 AUXILIARY 893 ) 894 ( NAME 'policyGroupInstance' 895 DESC 'A container for either a set of related policyRules or 896 a set of related policyGroups. A policyGroup may also 897 contain a mixture of policyRules and other 898 policyGroups.' 899 SUP policyGroup 900 STRUCTURAL 901 ) 903 The following DIT content rule indicates that an instance of 904 policyGroupInstance may have attached to it either DN pointers to one 905 or more other policyGroups, or DN pointers to one or more policyRules. 907 ( 908 NAME 'policyGroupContentRule' 909 DESC 'shows what auxiliary classes go with this object' 910 AUX ( policyGroupContainmentAuxClass $ 911 policyRuleContainmentAuxClass ) 912 ) 914 The following DIT structure rules indicate that an instance of 915 policyGroupInstance may be named under any superior, using any of its 916 three naming attributes. 918 NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule 919 are named within the scope of ("are weak to" in the CIM jargon) an 920 instance of the CIM class System, or one of its subclasses. The most 921 natural way to map a weak relationship of this type is to map it to 922 DIT structure rules specifying that an instance of policyGroupInstance 923 or policyRuleInstance is subordinate to an object representing a CIM 924 System. Since, however, the mapping of CIM's System class to an LDAP 925 class falls outside the scope of this document, the DIT structure 926 rules that follow do not constrain the superiors under which an 927 instance of policyGroupInstance may be named. 929 ( NAME 'policyGroupNameForm1' 930 OC policyGroupInstance 931 MUST ( cn ) 932 ) 934 ( NAME 'policyGroupStructuralRule1' 935 FORM policyGroupNameForm1 936 ) 938 ( NAME 'policyGroupNameForm2' 939 OC policyGroupInstance 940 MUST ( policyGroupName ) 941 ) 943 ( NAME 'policyGroupStructuralRule2' 944 FORM policyGroupNameForm2 945 ) 947 ( NAME 'policyGroupNameForm3' 948 OC policyGroupInstance 949 MUST ( orderedCimKeys ) 950 ) 952 ( NAME 'policyGroupStructuralRule3' 953 FORM policyGroupNameForm3 954 ) 956 The one attribute of policyGroup is defined as: 958 ( NAME 'policyGroupName' 959 DESC 'The user-friendly name of this policy group. 961 This value is a Directory String.' 962 EQUALITY caseIgnoreMatch 963 SUBSTR caseIgnoreSubstringsMatch 964 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 965 SINGLE-VALUE 966 ) 968 5.3. The Three policyRule Classes 970 The information model defines a policyRule class to represent the "If 971 Condition then Action" semantics associated with a policy. For 972 maximum flexibility, the LDAP schema maps this class into three LDAP 973 classes. 975 The conditions and actions associated with a policy rule are modeled, 976 respectively, with auxiliary subclasses of the auxiliary classes 977 policyConditionAuxClass and policyActionAuxClass. Each of these 978 auxiliary subclasses is attached to an instance of one of two 979 structural classes. A subclass of policyConditionAuxClass is attached 980 either to an instance of policyRuleConditionAssociation or to an 981 instance of policyInstance. Similarly, a subclass of 982 policyActionAuxClass is attached either to an instance of 983 policyRuleActionAssociation or to an instance of policyInstance.Of the 984 nine attributes in the policyRule class, eight are mapped directly 985 from corresponding properties in the information model. The ninth 986 attribute, policyRuleValidityPeriodList, realizes the 987 PolicyRuleValidityPeriod association from the information model. 988 Since this association has no additional properties besides those that 989 tie the association to its associated objects, the attribute 990 policyRuleValidityPeriodList is simply a multi-valued DN pointer. 991 (Relationships in the information model can have additional properties 992 because CIM represents relationships as classes. See Sections 5.4 and 993 5.5 for examples of additional properties and how they are mapped to 994 LDAP.) This attribute provides an unordered set of DN pointers to one 995 or more instances of the ptpConditionAuxClass, indicating when the 996 policy rule is scheduled to be active and when it is scheduled to be 997 inactive. A policy rule is scheduled to be active if it is active 998 according to AT LEAST ONE of the ptpConditionAuxClass instances 999 pointed to by this attribute. 1001 The PolicyConditionInPolicyRule and PolicyActionInPolicyRule 1002 associations, however, have additional properties: 1003 PolicyActionInPolicyRule has an integer to sequence the actions, and 1004 PolicyConditionInPolicyRule has an integer to group the conditions, 1005 and a Boolean to specify whether a condition is to be negated. In the 1006 Core Schema, these additional association properties are represented 1007 as attributes of two classes introduced specifically to model the 1008 associations: policyRuleConditionAssociation and 1009 policyRuleActionAssociation, defined, respectively, in Sections 5.4 1010 and 5.5. Thus they do not appear as attributes of the class 1011 policyRule. 1013 To maximize flexibility, the policyRule class is defined as abstract. 1014 A subclass policyRuleAuxClass provides for auxiliary attachment to 1015 another entry, while a structural subclass policyRuleInstance is 1016 available to represent a policy rule as a standalone entry. 1018 The class definitions for the three policyRule classes are as follows: 1020 ( NAME 'policyRule' 1021 DESC 'The central class for representing the "If Condition 1022 then Action" semantics associated with a policy rule.' 1023 SUP policy 1024 ABSTRACT 1025 MAY ( policyRuleName $ policyRuleEnabled $ 1026 policyRuleConditionListType $ 1027 policyRuleConditionList $ policyRuleActionList $ 1028 policyRuleValidityPeriodList $ policyRuleUsage $ 1029 policyRulePriority $ policyRuleMandatory $ 1030 policyRuleSequencedActions $ policyRoles ) 1031 ) 1033 ( NAME 'policyRuleAuxClass' 1034 DESC 'The central class for representing the "If Condition 1035 then Action" semantics associated with a policy rule.' 1036 SUP policyRule 1037 AUXILIARY 1038 ) 1040 ( NAME 'policyRuleInstance' 1041 DESC 'The central class for representing the "If Condition 1042 then Action" semantics associated with a policy rule.' 1043 SUP policyRule 1044 STRUCTURAL 1045 ) 1047 The following DIT content rule indicates that an instance of 1048 policyRuleInstance may have attached to it the auxiliary classes 1049 policyConditionAuxClass and policyActionAuxClass, or one of their 1050 subclasses. This combination represents a simple policy rule. 1052 ( 1053 NAME 'policyRuleContentRule' 1054 DESC 'shows what auxiliary classes go with this object' 1055 AUX ( policyConditionAuxClass $ policyActionAuxClass ) 1056 ) 1058 The following DIT structure rules indicate that an instance of 1059 policyRuleInstance may be named under any superior, using any of its 1060 three naming attributes. 1062 NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule 1063 are named within the scope of ("are weak to" in the CIM jargon) an 1064 instance of the CIM class System, or one of its subclasses. The most 1065 natural way to map a weak relationship of this type is to DIT 1066 structure rules specifying that an instance of policyGroupInstance or 1067 policyRuleInstance is subordinate to an object representing a CIM 1068 System. Since, however, the mapping of CIM's System class to an LDAP 1069 class falls outside the scope of this document, the DIT structure 1070 rules that follow do not constrain the superiors under which an 1071 instance of policyRuleInstance may be named. 1073 ( NAME 'policyRuleNameForm1' 1074 OC policyRuleInstance 1075 MUST ( cn ) 1076 ) 1078 ( NAME 'policyRuleStructuralRule1' 1079 FORM policyRuleNameForm1 1080 ) 1082 ( NAME 'policyRuleNameForm2' 1083 OC policyRuleInstance 1084 MUST ( policyRuleName ) 1085 ) 1087 ( NAME 'policyRuleStructuralRule2' 1088 FORM policyRuleNameForm2 1089 ) 1090 ( NAME 'policyRuleNameForm3' 1091 OC policyRuleInstance 1092 MUST ( orderedCimKeys ) 1093 ) 1095 ( NAME 'policyRuleStructuralRule3' 1096 FORM policyRuleNameForm3 1097 ) 1099 The attributes of policyRule are defined as follows: 1101 ( NAME 'policyRuleName' 1102 DESC 'The user-friendly name of this policy rule. 1103 This value is a Directory String' 1104 EQUALITY caseIgnoreMatch 1105 SUBSTR caseIgnoreSubstringsMatch 1106 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1107 SINGLE-VALUE 1108 ) 1110 ( NAME 'policyRuleEnabled' 1111 DESC 'An enumeration indicating whether a policy rule is 1112 administratively enabled, administratively disabled, or 1113 enabled for debug mode. The defined values for this 1114 attribute are enabled(1), disabled(2), and 1115 enabledForDebug(3). 1117 This value is an INTEGER enumeration.' 1118 EQUALITY integerMatch 1119 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1120 SINGLE-VALUE 1121 ) 1123 ( NAME 'policyRuleConditionListType' 1124 DESC 'Indicates whether the list of policy conditions 1125 associated with this policy rule is in disjunctive 1126 normal form (DNF) or conjunctive normal form (CNF). 1127 Defined values are DNF(1) and CNF(2). 1129 This value is an INTEGER enumeration.' 1130 EQUALITY integerMatch 1131 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1132 SINGLE-VALUE 1133 ) 1135 ( NAME 'policyRuleConditionList' 1136 DESC 'Distinguished names of policyRuleConditionAssociation 1137 entries representing associations between this policy 1138 rule and its conditions. No order is implied. 1140 These values are Distinguished Names (DNs).' 1141 EQUALITY distinguishedNameMatch 1142 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1143 ) 1145 ( NAME 'policyRuleActionList' 1146 DESC 'Distinguished names of policyRuleActionAssociation 1147 entries representing associations between this policy 1148 rule and its actions. No order is implied. 1150 These values are Distinguished Names (DNs).' 1151 EQUALITY distinguishedNameMatch 1152 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1153 ) 1155 ( NAME 'policyRuleValidityPeriodList' 1156 DESC 'Distinguished names of policyRuleValidityAssociation 1157 entries that 1158 determine when the policyRule is scheduled to be active 1159 / inactive. No order is implied. 1161 These values are Distinguished Names (DNs).' 1162 EQUALITY distinguishedNameMatch 1163 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1164 ) 1166 ( NAME 'policyRuleUsage' 1167 DESC 'This attribute is a free-form string providing 1168 guidelines on how 1169 this policy should be used. 1171 This value is a Directory String.' 1172 EQUALITY caseIgnoreMatch 1173 SUBSTR caseIgnoreSubstringsMatch 1174 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1175 SINGLE-VALUE 1176 ) 1178 ( NAME 'policyRulePriority' 1179 DESC 'A non-negative integer for prioritizing this policyRule 1180 relative to other policyRules. A larger value indicates 1181 a higher priority. 1183 This value is an INTEGER.' 1184 EQUALITY integerMatch 1185 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1186 SINGLE-VALUE 1187 ) 1188 ( NAME 'policyRuleMandatory' 1189 DESC 'A flag indicating that the evaluation of the 1190 policyConditions and execution of policyActions (if the 1191 condition list evaluates to True) is required. 1193 This value is a Boolean.' 1194 EQUALITY booleanMatch 1195 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1196 SINGLE-VALUE 1197 ) 1199 ( NAME 'policyRuleSequencedActions' 1200 DESC 'An enumeration indicating how to interpret the action 1201 ordering indicated via the policyActionOrder 1202 attribute. The defined values for this attribute are 1203 mandatory(1), recommended(2), and dontCare(3). 1205 This value is an INTEGER enumeration.' 1206 EQUALITY integerMatch 1207 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1208 SINGLE-VALUE 1209 ) 1211 ( NAME 'policyRoles' 1212 DESC 'Each value of this attribute represents a role 1213 combination, including the special case of a 1214 "combination" containing only one role. Since this 1215 is a multi-valued attribute, more than one role 1216 combination can be associated with a single policy 1217 rule. Each value is a string of the form 1219 [&&]* 1221 where the individual role names appear in alphabetical 1222 order according to the collating sequence for UCS-2. 1224 These values are Directory Strings.' 1225 EQUALITY caseIgnoreMatch 1226 SUBSTR caseIgnoreSubstringsMatch 1227 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1228 ) 1230 The two matching rules for policyRoles support two different 1231 approaches that a PDP might take to the task of retrieving policyRules 1232 for its PEPs based on the roles they have reported to it. Suppose, 1233 for example, that a PEP has reported that it is interested in 1234 policyRules for three roles R1, R2, and R3. If the goal is to 1235 minimize queries, then the PDP can supply three substring filters 1236 containing the three role names. These queries will get all of the 1237 policyRules that apply to the PEP, but they may also get some that do 1238 not apply, for example, ones for the role combination "R1&&R4". 1240 Another strategy would be for the PDP to use only equality filters. 1241 This approach eliminates the extraneous replies, but it requires the 1242 PDP to build the role combinations ("R1&&R2", "R1&&R3", etc.) itself, 1243 and it requires extra queries. Note that this approach is practical 1244 only because the role names in a role combination are required to 1245 appear in alphabetical order. 1247 By having the two matching rules for policyRoles, the PCLS leaves to 1248 each PDP the choice of which of these approaches use. 1250 5.4. The Class policyRuleConditionAssociation 1252 This class contains attributes to represent the properties of the 1253 information model's PolicyConditionInPolicyRule association. 1254 Instances of this class are related to an instance of policyRule via 1255 DIT containment. The policy conditions themselves are represented by 1256 auxiliary subclasses of the auxiliary class policyConditionAuxClass. 1257 These auxiliary classes are attached directly to instances of 1258 policyRuleConditionAssociation for rule-specific policy conditions. 1259 For a reusable policy condition, the auxiliary class is attached to an 1260 instance of the class policyInstance, and there is a DN pointer to 1261 this instance from the instance of policyRuleConditionAssociation. 1263 The class definition is as follows: 1265 ( NAME 'policyRuleConditionAssociation' 1266 DESC 'The class contains attributes characterizing the 1267 relationship between a policy rule and one of its 1268 policy conditions.' 1269 SUP policy 1270 MUST ( policyConditionGroupNumber $ policyConditionNegated ) 1271 MAY ( policyConditionName $ policyConditionDN ) 1272 ) 1274 The following DIT content rule indicates that an instance of 1275 policyRuleConditionAssociation may have attached to it the auxiliary 1276 class policyConditionAuxClass, or one of its subclasses. This 1277 combination represents a rule-specific policy condition. 1279 ( 1280 NAME 1281 'prcAssociationContentRule' 1282 DESC 'shows what auxiliary classes go with this object' 1283 AUX ( policyConditionAuxClass ) 1284 ) 1286 The following DIT structure rules indicate that an instance of 1287 policyRuleConditionAssociation may be named under an instance of 1288 policyRule, where each of these instances may be named using any of 1289 their three naming attributes. 1291 ( NAME 1292 'prcAssociationNameForm1' 1293 OC policyRuleConditionAssociation 1294 MUST ( cn ) 1296 ( NAME 1297 'prcAssociationStructureRule1' 1298 FORM prcAssociationNameForm1 1299 SUP 1300 ) 1302 ( NAME 1303 'prcAssociationNameForm2' 1304 OC policyRuleConditionAssociation 1305 MUST ( policyConditionName ) 1306 ) 1308 ( NAME 1309 'prcAssociationStructureRule2' 1310 FORM prcAssociationNameForm2 1311 SUP 1312 ) 1313 ( NAME 1314 'prcAssociationNameForm3' 1315 OC policyRuleConditionAssociation 1316 MUST ( orderedCimKeys ) 1317 ) 1319 ( NAME 1320 'prcAssociationStructureRule3' 1321 FORM prcAssociationNameForm3 1322 SUP 1323 ) 1325 The attributes of policyRuleConditionAssociation are defined as 1326 follows. 1328 ( 1329 NAME 'policyConditionName' 1330 DESC 'A user-friendly name for a policy condition. 1332 This value is a Directory String.' 1333 EQUALITY caseIgnoreMatch 1334 SUBSTR caseIgnoreSubstringsMatch 1335 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1336 SINGLE-VALUE 1337 ) 1339 ( 1340 NAME 'policyConditionGroupNumber' 1341 DESC 'The number of the group to which a policy condition 1342 belongs. These groups are used to form the DNF or 1343 CNF expression associated with a policy rule. 1345 This value is an INTEGER.' 1346 EQUALITY integerMatch 1347 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1348 SINGLE-VALUE 1349 ) 1351 ( 1352 NAME 'policyConditionNegated' 1353 DESC 'Indicates whether a policy condition is negated in 1354 the DNF or CNF expression associated with a policy 1355 rule. The value TRUE indicates that a condition is 1356 negated 1358 This value is a Boolean.' 1359 EQUALITY booleanMatch 1360 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1361 SINGLE-VALUE 1362 ) 1364 ( 1365 NAME 'policyConditionDN' 1366 DESC 'A DN pointer to a reusable policy condition. 1368 This value is a Distinguished Name (DN).' 1369 EQUALITY distinguishedNameMatch 1370 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1371 SINGLE-VALUE 1372 ) 1374 5.5. The Class policyRuleValidityAssociation 1376 The policyRuleValidityPeriod aggregation is mapped to the 1377 policyRuleValidityAssociation class, which is defined below: 1379 ( NAME 'policyRuleValidityAssociation' 1380 DESC 'This class represents the scheduled activation and 1381 deactivation of a policy rule by binding the 1382 definition of times that the policy is active to 1383 the policy rule itself. The "scheduled" times 1384 are either identified through an attached auxiliary 1385 class, ptpConditionAuxClass, or are referenced through 1386 the policyTimePeriodConditionDN attribute.' 1387 SUP policy 1388 STRUCTURAL 1389 MAY (policyValidityConditionName $ 1390 policyTimePeriodConditionDN) 1391 ) 1393 The following DIT content rule indicates that an instance of 1394 policyRuleValidityAssociation may have attached to it the auxiliary 1395 class ptpConditionAuxClass, or one of its subclasses. This 1396 combination represents a policy validity period. 1398 ( 1399 NAME 'prvAssociationContentRule' 1400 DESC 'shows what auxiliary classes go with this object' 1401 AUX ( ptpConditionAuxClass ) 1402 ) 1404 The following DIT structure rules indicate that an instance of 1405 policyRuleValidityAssociation may be named under an instance of 1406 policyRule, where each of these instances may be named using any of 1407 their three naming attributes. 1409 ( NAME 'prvAssociationNameForm1' 1410 OC policyRuleValidityAssociation 1411 MUST ( cn ) 1413 ( NAME 'prvAssociationStructureRule1' 1414 FORM prvAssociationNameForm1 1415 SUP 1416 ) 1418 ( NAME 'prvAssociationNameForm2' 1419 OC policyRuleValidityAssociation 1420 MUST ( policyConditionName ) 1421 ) 1423 ( NAME 'prvAssociationStructureRule2' 1424 FORM prvAssociationNameForm2 1425 SUP 1426 ) 1428 ( NAME 'prvAssociationNameForm3' 1429 OC policyRuleValidityAssociation 1430 MUST ( orderedCimKeys ) 1431 ) 1433 ( NAME 'prvAssociationStructureRule3' 1434 FORM prvAssociationNameForm3 1435 SUP 1436 ) 1438 The attributes of policyRuleValidityAssociation are defined as 1439 follows. 1441 ( 1442 NAME 'policyValidityConditionName' 1443 DESC 'A user-friendly name for expressing the times that a 1444 policy rule is active. 1446 This value is a Directory String.' 1447 EQUALITY caseIgnoreMatch 1448 SUBSTR caseIgnoreSubstringsMatch 1449 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1450 SINGLE-VALUE 1451 ) 1453 ( 1454 NAME 'policyTimePeriodConditionDN' 1455 DESC 'A DN pointer to a reusable policy time period 1456 condition. 1458 This value is a Distinguised Name (DN). 1460 EQUALITY distinguishedNameMatch 1461 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1462 SINGLE-VALUE 1463 ) 1465 5.6. The Class policyRuleActionAssociation 1467 This class contains an attribute to represent the one property of the 1468 information model's PolicyActionInPolicyRule association, which makes 1469 it possible to specify an order for executing the actions associated 1470 with a policy rule. Instances of this class are related to an 1471 instance of policyRule via DIT containment. The actions themselves 1472 are represented by auxiliary subclasses of the auxiliary class 1473 policyActionAuxClass. These auxiliary classes are attached directly 1474 to instances of policyRuleActionAssociation for rule-specific policy 1475 actions. For a reusable policy action, the auxiliary class is 1476 attached to an instance of the class policyInstance, and there is a DN 1477 pointer to this instance from the instance of 1478 policyRuleActionAssociation. 1480 The class definition is as follows: 1482 ( NAME 'policyRuleActionAssociation' 1483 DESC 'The class contains an attribute that represents an 1484 execution order for an action in the context of a 1485 policy rule.' 1486 SUP policy 1487 MUST ( policyActionOrder ) 1488 MAY ( policyActionName $ policyActionDN ) 1489 ) 1491 The following DIT content rule indicates that an instance of 1492 policyRuleActionAssociation may have attached to it the auxiliary 1493 class policyActionAuxClass, or one of its subclasses. This 1494 combination represents a rule-specific policy action. 1496 ( 1497 NAME 1498 'praAssociationContentRule' 1499 DESC 'shows what auxiliary classes go with this object' 1500 AUX ( policyActionAuxClass ) 1501 ) 1503 The following DIT structure rules indicate that an instance of 1504 policyRuleActionAssociation may be named under an instance of 1505 policyRule, where each of these instances may be named using any of 1506 their three naming attributes. 1508 ( NAME 1509 'praAssociationNameForm1' 1510 OC policyRuleActionAssociation 1511 MUST ( cn ) 1512 ) 1514 ( NAME 1515 'praAssociationStructuralRule1' 1516 FORM praAssociationNameForm1 1517 SUP 1518 ) 1520 ( NAME 1521 'praAssociationNameForm2' 1522 OC policyRuleActionAssociation 1523 MUST ( policyActionName ) 1524 ) 1526 ( NAME 1527 'praAssociationStructuralRule2' 1528 FORM praAssociationNameForm2 1529 SUP 1530 ) 1532 ( NAME 1533 'praAssociationNameForm3' 1534 OC policyRuleActionAssociation 1535 MUST ( orderedCimKeys ) 1536 ) 1538 ( NAME 1539 'praAssociationStructuralRule3' 1540 FORM praAssociationNameForm3 1541 SUP 1542 ) 1544 The attributes of policyRuleActionAssociation are defined as follows. 1546 ( 1547 NAME 'policyActionName' 1548 DESC 'A user-friendly name for a policy action. 1550 This value is a Directory String.' 1551 EQUALITY caseIgnoreMatch 1552 SUBSTR caseIgnoreSubstringsMatch 1553 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1554 SINGLE-VALUE 1555 ) 1557 ( 1558 NAME 'policyActionOrder' 1559 DESC 'An integer indicating the relative order of an action 1560 in the context of a policy rule. 1562 This value is an INTEGER.' 1563 EQUALITY integerMatch 1564 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1565 SINGLE-VALUE 1566 ) 1568 ( 1569 NAME 'policyActionDN' 1570 DESC 'A DN pointer to a reusable policy action. 1572 This value is a Distinguished Name (DN).' 1573 EQUALITY distinguishedNameMatch 1574 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1575 SINGLE-VALUE 1576 ) 1578 5.7. The Auxiliary Class policyConditionAuxClass 1580 The purpose of a policy condition is to determine whether or not the 1581 set of actions (contained in the policyRule that the condition applies 1582 to) should be executed or not. This auxiliary class can be attached 1583 to instances of three other classes in the Core Policy Schema. When 1584 it is attached to an instance of policyRuleConditionAssociation, or to 1585 an instance of policyRule, it represents a rule-specific policy 1586 condition. When it is attached to an instance of policyInstance, it 1587 represents a reusable policy condition. 1589 Since all of the classes to which this auxiliary class may be attached 1590 are derived from "policy", the attributes of "policy" will already be 1591 defined for the entries to which this class attaches. Thus this class 1592 is derived directly from "top". 1594 The class definition is as follows: 1596 ( NAME 'policyConditionAuxClass' 1597 DESC 'A class representing a condition to be evaluated in 1598 conjunction with a policy rule.' 1599 SUP top 1600 AUXILIARY 1601 ) 1603 5.8. The Auxiliary Class ptpConditionAuxClass 1605 The information model defines a time period class, 1606 PolicyTimePeriodCondition, to provide a means of representing the time 1607 periods during which a policy rule is valid, i.e., active. It also 1608 defines an aggregation, PolicyRuleValidityPeriod, so that time periods 1609 can be associated with a PolicyRule. The LDAP mapping also provides 1610 two classes, one for the time condition itself, and one for the 1611 aggregation. 1613 In the information model, this class is named 1614 PolicyTimePeriodCondition. However, the resulting name of the 1615 auxiliary class in this mapping (policyTimePeriodConditionAuxClass) 1616 exceeds the length of a name that some directories can store. 1617 Therefore, we have shortened the name to ptpConditionAuxClass. 1619 The class definition is as follows. 1621 ( NAME 'ptpConditionAuxClass' 1622 DESC 'A class that provides the capability of enabling / 1623 disabling a policy rule according to a predetermined 1624 schedule.' 1625 SUP policyConditionAuxClass 1626 AUXILIARY 1627 MAY ( ptpConditionTime $ ptpConditionMonthOfYearMask $ 1628 ptpConditionDayOfMonthMask $ ptpConditionDayOfWeekMask $ 1629 ptpConditionTimeOfDayMask $ ptpConditionLocalOrUtcTime ) 1630 ) 1632 The attributes of ptpConditionAuxClass are defined as follows. Note 1633 that several of the attributes are defined as bit strings of various 1634 fixed lengths. These attributes correspond to CIM properties that 1635 include four-octet length fields prior to their semantically 1636 significant bits. Since these length fields are unnecessary in LDAP, 1637 they are not included in the bit string attributes defined in this 1638 document. 1640 ( 1641 NAME 'ptpConditionTime' 1642 DESC 'The range of calendar dates on which a policy rule is 1643 valid. The format of the string is 1644 yyyymmddThhmmss/yyyymmddThhmmss, where the first 1645 date/time may be replaced with the string 1646 "THISANDPRIOR" or the second date/time may be replaced 1647 with the string "THISANDFUTURE". 1649 This value is a Printable String.' 1650 EQUALITY caseIgnoreMatch 1651 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1652 SINGLE-VALUE 1653 ) 1655 ( 1656 NAME 'ptpConditionMonthOfYearMask' 1657 DESC 'A mask identifying the months of the year in which a 1658 policy rule is valid. The format is a bit string of 1659 length 12, representing the months of the 1660 year from January through December.' 1661 EQUALITY bitStringMatch 1662 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1663 SINGLE-VALUE 1664 ) 1666 ( 1667 NAME 'ptpConditionDayOfMonthMask' 1668 DESC 'A mask identifying the days of the month on which a 1669 policy rule is valid. The format is a bit string of 1670 length 62. The first 31 positions represent 1671 the days of the month in ascending order, from day 1 to 1672 day 31. The next 31 positions represent the days of 1673 the month in descending order, from the last day to the 1674 day 31 days from the end.' 1675 EQUALITY bitStringMatch 1676 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1677 SINGLE-VALUE 1678 ) 1680 ( 1681 NAME 'ptpConditionDayOfWeekMask' 1682 DESC 'A mask identifying the days of the week on which a 1683 policy rule is valid. The format is a bit string of 1684 length 7, representing the days of the week 1685 from Sunday through Saturday.' 1686 EQUALITY bitStringMatch 1687 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1688 SINGLE-VALUE 1689 ) 1691 ( 1692 NAME 'ptpConditionTimeOfDayMask' 1693 DESC 'The range of times at which a policy rule is valid. If 1694 the second time is earlier than the first, then the 1695 interval spans midnight. The format of the string is 1696 Thhmmss/Thhmmss. 1698 This value is a Printable String.' 1699 EQUALITY caseIgnoreMatch 1700 SUBSTR caseIgnoreSubstringsMatch 1701 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1702 SINGLE-VALUE 1703 ) 1705 ( 1706 NAME 'ptpConditionLocalOrUtcTime' 1707 DESC 'An indication of whether the other times in this 1708 instance represent local times or UTC times. The 1709 defined values for this attribute are localTime(1) 1710 and utcTime(2). 1712 This value is an INTEGER enumeration.' 1713 EQUALITY integerMatch 1714 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1715 SINGLE-VALUE 1716 ) 1718 5.9. The Auxiliary Class vendorPolicyConditionAuxClass 1720 The class definition is as follows: 1722 ( NAME 'vendorPolicyConditionAuxClass' 1723 DESC 'A class that defines a registered means to describe a 1724 policy condition.' 1725 SUP policyConditionAuxClass 1726 AUXILIARY 1727 MAY ( vendorPolicyConstraintData $ 1728 vendorPolicyConstraintEncoding ) 1729 ) 1731 The attribute definitions for vendorPolicyConditionAuxClass are as 1732 follows: 1734 ( 1735 NAME 'vendorPolicyConstraintData' 1736 DESC 'Escape mechanism for representing constraints that have 1737 not been modeled as specific attributes. The format of 1738 the values is identified by the OID stored in the 1739 attribute vendorPolicyConstraintEncoding. 1741 This value is an Octet String.' 1742 EQUALITY octetStringMatch 1743 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1744 ) 1746 ( 1747 NAME 'vendorPolicyConstraintEncoding' 1748 DESC 'An OID identifying the format and semantics for this 1749 Instance�s vendorPolicyConstraintData attribute.' 1750 EQUALITY objectIdentifierMatch 1751 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1752 SINGLE-VALUE 1753 ) 1754 5.10. The Auxiliary Class policyActionAuxClass 1756 The purpose of a policy action is to execute one or more operations 1757 that will affect network traffic and/or systems, devices, etc. in 1758 order to achieve a desired policy state. This auxiliary class can be 1759 attached to instances of three other classes in the Core Policy 1760 Schema. When it is attached to an instance of 1761 policyRuleActionAssociation, or to an instance of policyRule, it 1762 represents a rule-specific policy action. When it is attached to an 1763 instance of policyInstance, it represents a reusable policy action. 1765 Since all of the classes to which this auxiliary class may be attached 1766 are derived from "policy", the attributes of "policy" will already be 1767 defined for the entries to which this class attaches. Thus this class 1768 is derived directly from "top". 1770 The class definition is as follows: 1772 ( NAME 'policyActionAuxClass' 1773 DESC 'A class representing an action to be performed as a 1774 result of a policy rule.' 1775 SUP top 1776 AUXILIARY 1777 ) 1779 5.11. The Auxiliary Class vendorPolicyActionAuxClass 1781 The class definition is as follows: 1783 ( NAME 'vendorPolicyActionAuxClass' 1784 DESC 'A class that defines a registered means to describe a 1785 policy action.' 1786 SUP policyActionAuxClass 1787 AUXILIARY 1788 MAY ( vendorPolicyActionData $ vendorPolicyActionEncoding ) 1789 ) 1791 The attribute definitions for vendorPolicyActionAuxClass are as 1792 follows: 1794 ( 1795 NAME 'vendorPolicyActionData' 1796 DESC 'Escape mechanism for representing actions that have not 1797 been modeled as specific attributes. The format of the 1798 values is identified by the OID stored in the attribute 1799 vendorPolicyActionEncoding. 1801 This value is an Octet String.' 1802 EQUALITY octetStringMatch 1803 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1804 ) 1805 ( 1806 NAME 'vendorPolicyActionEncoding' 1807 DESC 'An OID identifying the format and semantics for this 1808 Instance�s vendorPolicyActionData attribute.' 1809 EQUALITY objectIdentifierMatch 1810 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1811 SINGLE-VALUE 1812 ) 1814 5.12. The Class policyInstance 1816 The role of this class in the Core Schema is to serve as a structural 1817 class to which auxiliary classes representing policy information are 1818 attached when the information is reusable. For auxiliary classes 1819 representing policy conditions and policy actions, there are 1820 alternative structural classes that may be used. See Sections 5.12 1821 and 5.13. See Section 4.3 for a complete discussion of reusable 1822 policy conditions and actions, and of the role that this class plays 1823 in how they are represented. 1825 In addition to the cn attribute it inherits from "policy", this class 1826 uses the class-specific naming attribute policyInstanceName. 1828 The class definition is as follows: 1830 ( NAME 'policyInstance' 1831 DESC 'A structural class that contains reusable policy 1832 information.' 1833 SUP policy 1834 MAY ( policyInstanceName ) 1835 ) 1837 The following DIT content rule indicates that an instance of 1838 policyInstance may have attached to it instances of the auxiliary 1839 classes policyConditionAuxClass and policyActionAuxClass. Additional 1840 DIT content rules may be defined later, for attachment of other 1841 policy-related auxiliary classes to policyInstance. 1843 ( 1844 NAME 'policyInstanceContentRule' 1845 DESC 'shows what auxiliary classes go with this class' 1846 AUX ( policyConditionAuxClass $ policyActionAuxClass) 1847 ) 1849 The following DIT structure rules indicate that an instance of 1850 policyInstance may be named under an instance of policyRepository, 1851 using any of its three naming attributes. 1853 ( NAME 'policyInstanceNameForm1' 1854 OC policyInstance 1855 MUST ( cn ) 1856 ) 1858 ( 1861 ) 1863 ( NAME 'policyInstanceNameForm2' 1864 OC policyInstance 1865 MUST ( policyInstanceName ) 1866 ) 1868 ( NAME 'policyInstanceStructuralRule2' 1869 FORM policyInstanceNameForm2 1870 SUP 1871 ) 1873 ( NAME 'policyInstanceNameForm3' 1874 OC policyInstance 1875 MUST ( orderedCimKeys ) 1876 ) 1878 ( NAME 'policyInstanceStructuralRule3' 1879 FORM policyInstanceNameForm3 1880 SUP 1881 ) 1883 The one attribute of policyInstance is defined as: 1885 ( NAME 'policyInstanceName' 1886 DESC 'The user-friendly name of this policy instance. 1888 This value is a Directory String.' 1889 EQUALITY caseIgnoreMatch 1890 SUBSTR caseIgnoreSubstringsMatch 1891 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1892 SINGLE-VALUE 1893 ) 1895 5.13. The Auxiliary Class policyElementAuxClass 1897 This class introduces no additional attributes, beyond those defined 1898 in the class "policy" from which it is derived. Its role is to "tag" 1899 an instance of a class defined outside the realm of policy as being 1900 nevertheless relevant to a policy specification. This tagging can 1901 potentially take place at two levels: 1903 o Every instance to which policyElementAuxClass is attached becomes 1904 an instance of the class "policy", since policyElementAuxClass is a 1905 subclass of "policy". Thus a DIT search with the filter 1906 "objectClass=policy" will return the instance. (As noted earlier, 1907 this approach does not work for some directory implementations. To 1908 accommodate these implementations, policy-related entries SHOULD be 1909 tagged with the keyword "POLICY".) 1911 o With the policyKeywords attribute that it inherits from "policy", 1912 an instance to which policyElementAuxClass is attached can be 1913 tagged as being relevant to a particular type or category of 1914 policy, using standard keywords, administrator-defined keywords, or 1915 both. 1917 The class definition is as follows: 1919 ( NAME 'policyElementAuxClass' 1920 DESC 'An auxiliary class used to tag instances of classes 1921 defined outside the realm of policy as relevant to a 1922 particular policy specification.' 1923 SUP policy 1924 AUXILIARY 1925 ) 1927 5.14. The Three policyRepository Classes 1929 These classes provide a container for reusable policy information, 1930 such as reusable policy conditions and/or reusable policy actions. 1931 They are derived from several classes defined in reference [10]: 1933 top 1934 | 1935 +--dlm1ManagedElement (abstract) 1936 | 1937 +--dlm1ManagedSystemElement (abstract) 1938 | 1939 +--dlm1LogicalElement (abstract) 1940 | 1941 +--dlm1System (abstract) 1942 | 1943 +--dlm1AdminDomain (abstract) 1944 | 1945 +--policyRepository (abstract) 1946 | 1947 +--policyRepositoryAuxClass (auxiliary) 1948 | 1949 +--policyRepositoryInstance (structural) 1951 To maximize flexibility, the policyRepository class is defined as 1952 abstract. A subclass policyRepositoryAuxClass provides for auxiliary 1953 attachment to another entry, while a structural subclass 1954 policyRepositoryInstance is available to represent a policy repository 1955 as a standalone entry. 1957 The class definitions for the policyRepository classes are as follows: 1959 ( NAME 'policyRepository' 1960 DESC 'A container for reusable policy information.' 1961 SUP dlm1AdminDomain 1962 ABSTRACT 1963 MAY ( policyRepositoryName ) 1964 ) 1966 ( NAME 'policyRepositoryAuxClass' 1967 DESC 'A container for reusable policy information.' 1968 SUP policyRepository 1969 AUXILIARY 1970 ) 1972 ( NAME 'policyRepositoryInstance' 1973 DESC 'A container for reusable policy information.' 1974 SUP policyRepository 1975 STRUCTURAL 1976 ) 1978 The following DIT structure rules indicate that an instance of 1979 policyRepositoryInstance may be named under any superior, using any of 1980 its three naming attributes. These DIT structure rules cover, as 1981 special cases, a policyRepositoryInstance that is named within the 1982 scope of another policyRepositoryInstance, or within the scope of an 1983 entry to which policyRepositoryAuxClass is attached. These special 1984 cases represent the mapping for the CIM aggregation 1985 PolicyRepositoryInPolicyRepository. 1987 ( NAME 'policyRepositoryNameForm1' 1988 OC policyRepositoryInstance 1989 MUST ( cn ) 1990 ) 1992 ( NAME 'policyRepositoryStructuralRule1' 1993 FORM policyRepositoryNameForm1 1994 ) 1996 ( NAME 'policyRepositoryNameForm2' 1997 OC policyRepositoryInstance 1998 MUST ( policyRepositoryName ) 1999 ) 2001 ( NAME 'policyRepositoryStructuralRule2' 2002 FORM policyRepositoryNameForm2 2003 ) 2005 ( NAME 'policyRepositoryNameForm3' 2006 OC policyRepositoryInstance 2007 MUST ( orderedCimKeys ) 2008 ) 2010 ( NAME 'policyRepositoryStructuralRule3' 2011 FORM policyRepositoryNameForm3 2012 ) 2014 The one attribute of policyRepository is defined as follows. 2016 ( NAME 'policyRepositoryName' 2017 DESC 'The user-friendly name of this policy repository. 2019 This value is a Directory String.' 2020 EQUALITY caseIgnoreMatch 2021 SUBSTR caseIgnoreSubstringsMatch 2022 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 2023 SINGLE-VALUE 2024 ) 2026 5.15. The Auxiliary Class policySubtreesPtrAuxClass 2028 This auxiliary class provides a single, multi-valued attribute that 2029 points to a set of objects that are at the root of DIT subtrees 2030 containing policy-related information. By attaching this attribute to 2031 instances of various other classes, a policy administrator has a 2032 flexible way of providing an entry point into the directory that 2033 allows a client to locate and retrieve the policy information relevant 2034 to it. 2036 These entries may be placed in the DIT such that a well-known DN can 2037 be used by placing the structural entry (e.g. container) with the 2038 policySubtreesPtrAuxClass attached thereto in the root of the 2039 directory suffix. In this case, the subtree entry point can contain 2040 and/or point to all related policy entries for any well-known policy 2041 disciplines. Similarly, the subtree entry point may be placed in the 2042 DIT such that the PDP's starting point is a subtree with policy- 2043 related entries that are dependent on a hierarchically-related set of 2044 subtrees (e.g., region, division, corporate). In this latter case, 2045 DNs may be provided to the PDPs via SNMP or other techniques. 2047 This object does not provide the semantic linkages between individual 2048 policy objects, such as those between a policy group and the policy 2049 rules that belong to it. Its only role is to enable efficient bulk 2050 retrieval of policy-related objects, as described in Section 4.4. 2051 Once the objects have been retrieved, a directory client can determine 2052 the semantic linkages by following DN pointers such as 2053 policyRulesAuxContainedSet locally. 2055 Since policy-related objects will often be included in the DIT subtree 2056 beneath an object to which this auxiliary class is attached, a client 2057 SHOULD request the policy-related objects from the subtree under the 2058 object with these pointers at the same time that it requests the 2059 pointers themselves. 2061 Since clients are expected to behave in this way, the policy 2062 administrator SHOULD make sure that this subtree does not contain so 2063 many objects unrelated to policy that an initial search done in this 2064 way results in a performance problem. For example, 2065 policySubtreesPtrAuxClass SHOULD NOT be attached to the partition root 2066 for a large directory partition containing a relatively few policy- 2067 related objects along with a large number of objects unrelated to 2068 policy. A better approach would be to introduce a container object 2069 immediately below the partition root, attach policySubtreesPtrAuxClass 2070 to this container object, and then place the policy-related objects in 2071 the subtree under it. 2073 The class definition is as follows: 2075 ( NAME 'policySubtreesPtrAuxClass' 2076 DESC 'An auxiliary class providing DN pointers to roots of 2077 DIT subtrees containing policy-related objects.' 2078 SUP top 2079 AUXILIARY 2080 MAY ( policySubtreesAuxContainedSet ) 2081 ) 2083 5.15.1. The Attribute policySubtreesAuxContainedSet 2085 This attribute provides an unordered set of DN pointers to one or more 2086 objects under which policy-related information is present. The 2087 objects pointed to may or may not themselves contain policy-related 2088 information. 2090 The attribute definition is as follows: 2092 ( 2093 NAME 'policySubtreesAuxContainedSet' 2094 DESC 'Distinguished names of objects that serve as roots for 2095 DIT subtrees containing policy-related objects. No 2096 order is implied. 2098 This value is a Distinguished Name (DN).' 2099 EQUALITY distinguishedNameMatch 2100 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2101 ) 2103 5.16. The Auxiliary Class policyGroupContainmentAuxClass 2105 This auxiliary class provides a single, multi-valued attribute that 2106 points to a set of policyGroups. By attaching this attribute to 2107 instances of various other classes, a policy administrator has a 2108 flexible way of providing an entry point into the directory that 2109 allows a client to locate and retrieve the policyGroups relevant to 2110 it. 2112 As is the case with policyRules, a policy administrator might have 2113 several different pointers to a policyGroup in the overall directory 2114 structure. The policyGroupContainmentAuxClass is the mechanism that 2115 makes it possible for the policy administrator to define all these 2116 pointers. 2118 The class definition is as follows: 2120 ( NAME 'policyGroupContainmentAuxClass' 2121 DESC 'An auxiliary class used to bind policyGroups to an 2122 appropriate container object.' 2123 SUP top 2124 AUXILIARY 2125 MAY ( policyGroupsAuxContainedSet ) 2126 ) 2128 5.16.1. The Attribute policyGroupsAuxContainedSet 2130 This attribute provides an unordered set of DN pointers to one or more 2131 policyGroups associated with the instance of a structural class to 2132 which this attribute has been appended. The attribute definition is 2133 as follows: 2135 ( 2136 NAME 'policyGroupsAuxContainedSet' 2137 DESC 'Distinguished names of policyGroups associated in some 2138 way with the instance to which this attribute has been 2139 appended. No order is implied. 2141 This value is a Distinguished Name (DN).' 2142 EQUALITY distinguishedNameMatch 2143 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2144 ) 2146 5.17. The Auxiliary Class policyRuleContainmentAuxClass 2148 This auxiliary class provides a single, multi-valued attribute that 2149 points to a set of policyRules. By attaching this attribute to 2150 instances of various other classes, a policy administrator has a 2151 flexible way of providing an entry point into the directory that 2152 allows a client to locate and retrieve the policyRules relevant to it. 2154 A policy administrator might have several different pointers to a 2155 policyRule in the overall directory structure. For example, there 2156 might be pointers to all policyRules for traffic originating in a 2157 particular subnet from a directory entry that represents that subnet. 2158 At the same time, there might be pointers to all policyRules related 2159 to a particular DiffServ setting from an instance of a policyGroup 2160 explicitly introduced as a container for DiffServ-related policyRules. 2161 The policyRuleContainmentAuxClass is the mechanism that makes it 2162 possible for the policy administrator to define all these pointers. 2164 Note that the cn attribute does NOT need to be defined for this class. 2165 This is because an auxiliary class is used as a means to collect 2166 common attributes and treat them as properties of an object. A good 2167 analogy is a #include file, except that since an auxiliary class is a 2168 class, all the benefits of a class (e.g., inheritance) can be applied 2169 to an auxiliary class. 2171 The class definition is as follows: 2173 ( NAME 'policyRuleContainmentAuxClass' 2174 DESC 'An auxiliary class used to bind policyRules to an 2175 appropriate container object.' 2176 SUP top 2177 AUXILIARY 2178 MAY ( policyRulesAuxContainedSet ) 2179 ) 2181 5.17.1. The Attribute policyRulesAuxContainedSet 2183 This attribute provides an unordered set of DN pointers to one or more 2184 policyRules associated with the instance of a structural class to 2185 which this attribute has been appended. The attribute definition is: 2187 ( 2188 NAME 'policyRulesAuxContainedSet' 2189 DESC 'Distinguished names of policyRules associated in some 2190 way with the instance to which this attribute has been 2191 appended. No order is implied. 2193 This value is a Distinguished Name (DN).' 2194 EQUALITY distinguishedNameMatch 2195 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2196 ) 2198 6. Extending the Core Schema 2200 The following subsections provide general guidance on how to create a 2201 domain-specific schema derived from the Core Schema, discuss how the 2202 vendor classes in the Core Schema should be used, and explain how 2203 policyTimePeriodConditions are related to other policy conditions. 2205 6.1. Subclassing policyConditionAuxClass and policyActionAuxClass 2207 In Section 4.3 above, there is a discussion of how, by representing 2208 policy conditions and policy actions as auxiliary classes in a schema, 2209 the flexibility is retained to instantiate a particular condition or 2210 action as either rule-specific or reusable. This flexibility is lost 2211 if a condition or action class is defined as structural rather than 2212 auxiliary. For standardized schemata, this document specifies that 2213 domain-specific information MUST be expressed in auxiliary subclasses 2214 of policyConditionAuxClass and policyActionAuxClass. It is 2215 RECOMMENDED that non-standardized schemata follow this practice as 2216 well. 2218 6.2. Using the Vendor Policy Encoding Attributes 2220 As discussed Section 5.8 "The Class vendorPolicyConditionAuxClass", 2221 the attributes vendorPolicyConstraintData and 2222 vendorPolicyConstraintEncoding are included in 2223 vendorPolicyConditionAuxClass to provide an escape mechanism for 2224 representing "exceptional" policy conditions. The attributes 2225 vendorPolicyActionData and vendorPolicyActionEncoding in 2226 vendorPolicyActionAuxClass class play the same role with respect to 2227 actions. This enables interoperability between different vendors. 2229 For example, imagine a network composed of access devices from vendor 2230 A, edge and core devices from vendor B, and a policy server from 2231 vendor C. It is desirable for this policy server to be able to 2232 configure and manage all of the devices from vendors A and B. 2233 Unfortunately, these devices will in general have little in common 2234 (e.g., different mechanisms, different ways for controlling those 2235 mechanisms, different operating systems, different commands, and so 2236 forth). The escape conditions provide a way for vendor-specific 2237 commands to be encoded as OctetStrings, so that a single policy server 2238 can commonly manage devices from different vendors. 2240 6.3. Using Time Validity Periods 2242 Time validity periods are defined as a subclass of 2243 policyConditionAuxClass, called policyTimePeriodCondition. This is to 2244 allow their inclusion in the AND/OR condition definitions for a 2245 policyRule. Care should be taken not to subclass 2246 policyTimePeriodCondition to add domain-specific condition properties. 2247 For example, it would be incorrect to add IPSec- or QoS-specific 2248 condition properties to the policyTimePeriodCondition class, just 2249 because IPSec or QoS includes time in its condition definition. The 2250 correct subclassing would be to create IPSec or QoS-specific 2251 subclasses of policyConditionAuxClass and then combine instances of 2252 these domain-specific condition classes with the validity period 2253 criteria. This is accomplished using the AND/OR association 2254 capabilities for policyConditions in policyRules. 2256 7. Security Considerations 2258 The Policy Core LDAP Schema (PCLS), presented in this document, 2259 provides a mapping of the object-oriented model for describing policy 2260 information (PCIM), into a data model that forms the basic framework 2261 for describing the structure of policy data, in the case where the 2262 policy repository takes the form of an LDAP-accessible directory. 2264 PCLS is not intended to represent any particular system design or 2265 implementation. PCLS is not directly useable in a real world system, 2266 without the discipline-specific mappings that are works in progress in 2267 the Policy Framework Working Group of the IETF. 2269 These other derivative documents, which use PCIM and its discipline- 2270 specific extensions as a base, will need to convey more specific 2271 security considerations (refer to RFC3060 for more information.) 2273 The reason that PCLS, as defined here, is not representative of any 2274 real-world system, is that its object classes were designed to be 2275 independent of any specific discipline, or policy domain. For 2276 example, DiffServ and IPSec represent two different policy domains. 2277 Each document that extends PCIM to one of these domains will derive 2278 subclasses from the classes and relationships defined in PCIM, in 2279 order to represent extensions of a generic model to cover specific 2280 technical domains. 2282 PCIM-derived documents will thus subclass the PCIM classes into 2283 classes specific to each technical policy domain (QOS, IPsec, etc.), 2284 which will, in turn, be mapped, to directory-specific schemas 2285 consistent with the the PCLS schema documented here. 2287 Even though discipline-specific security requirements are not 2288 appropriate for PCLS, specific security requirements MUST be defined 2289 for each operational real-world application of PCIM. Just as there 2290 will be a wide range of operational, real-world systems using PCIM, 2291 there will also be a wide range of security requirements for these 2292 systems. Some operational, real-world systems that are deployed using 2293 PCLS may have extensive security requirements that impact nearly all 2294 object classes utilized by such a system, while other systems' 2295 security requirements might have very little impact. 2297 The derivative documents, discussed above, will create the context for 2298 applying operational, real-world, system-level security requirements 2299 against the various models which derive from PCIM, consistent with 2300 PCLS. 2302 In some real-world scenarios, the values associated with certain 2303 properties, within certain instantiated object classes, may represent 2304 information associated with scarce, and/or costly (and therefore 2305 valuable) resources. It may be the case that these values must not be 2306 disclosed to, or manipulated by, unauthorized parties. 2308 Since this document forms the basis for the representation of a policy 2309 data model in a specific format (an LDAP-accessible directory), it is 2310 herein appropriate to reference the data model-specific tools and 2311 mechanisms that are available for achieving the authentication and 2312 authorization implicit in a requirement that restricts read and/or 2313 read- write access to these values stored in a directory. 2315 LDAP-specific authentication and authorization tools and mechanisms 2316 are found in the following standards track documents, which are 2317 appropriate for application to the management of security applied to 2318 policy data models stored in an LDAP-accessible directory: 2320 o RFC 2829 (Authentication Methods for LDAP) 2322 o RFC 2830 (Lightweight Directory Access Protocol (v3): Extension 2323 for Transport Layer Security) 2325 Any identified security requirements that are not dealt with in the 2326 appropriate discipline-specific information model documents, or in 2327 this document, MUST be dealt with in the derivative data model 2328 documents which are specific to each discipline. 2330 8. Intellectual Property 2332 The IETF takes no position regarding the validity or scope of any 2333 intellectual property or other rights that might be claimed to pertain 2334 to the implementation or use of the technology described in this 2335 document or the extent to which any license under such rights might or 2336 might not be available; neither does it represent that it has made any 2337 effort to identify any such rights. Information on the IETF's 2338 procedures with respect to rights in standards-track and standards- 2339 related documentation can be found in BCP-11. 2341 Copies of claims of rights made available for publication and any 2342 assurances of licenses to be made available, or the result of an 2343 attempt made to obtain a general license or permission for the use of 2344 such proprietary rights by implementers or users of this specification 2345 can be obtained from the IETF Secretariat. 2347 The IETF invites any interested party to bring to its attention any 2348 copyrights, patents or patent applications, or other proprietary 2349 rights that may cover technology that may be required to practice this 2350 standard. Please address the information to the IETF Executive 2351 Director. 2353 9. Acknowledgments 2355 Several of the policy classes in this model first appeared in early 2356 IETF drafts on IPSec policy and QoS policy. The authors of these 2357 drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy 2358 Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael 2359 See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar. 2360 This document is closely aligned with the work being done in the 2361 Distributed Management Task Force (DMTF) Service Level Agreements and 2362 Networks working groups. We would especially like to thank Lee 2363 Rafalow, Glenn Waters, David Black, Michael Richardson, Mark Stevens, 2364 David Jones, Hugh Mahon, Yoram Snir, and Yoram Ramberg for their 2365 helpful comments. 2367 10. References 2369 [1] Moore, B., and E. Ellesson, J. Strassner, A. Westerinen "Policy 2370 Core Information Model -- Version 1 Specification", RFC 3060, 2371 February 2001. 2373 [2] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight 2374 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2375 2252, December 1997. 2377 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2378 Levels", BCP 14, RFC 2119, March 1997. 2380 [4] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 2381 Standards Process", BCP 11, RFC 2028, October 1996. 2383 [5] Strassner, J. and S. Judd, "Directory-Enabled Networks", version 2384 3.0c5 (August 1998). A PDF file is available at 2385 http://www.murchiso.com/den/#denspec. 2387 [6] Strassner, J., policy architecture BOF presentation, 42nd IETF 2388 Meeting, Chicago, Illinois, October 1998. Minutes of this BOF are 2389 available at the following location: 2390 http://www.ietf.org/proceedings/98aug/index.html. 2392 [7] DMTF web site, http://www.dmtf.org. 2394 [8] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for 2395 Policy-based Admission Control", RFC 2753, January 2000. 2397 [9] Distributed Management Task Force, Inc., "Guidelines for CIM-to- 2398 LDAP Directory Mapping", May 8, 2000. This document is available 2399 on the following DMTF web page: http://www.dmtf.org/spec/denh.html. 2401 [10] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the 2402 CIM v2.4 Core Information Model", November 20, 2000. This document 2403 is available on the following DMTF web page: 2404 http://www.dmtf.org/spec/denh.html. 2406 [11] Wahl, M., " A Summary of the X.500(96) User Schema for use with 2407 LDAPv3", RFC 2256, December 1997. 2409 11. Authors' Addresses 2411 John Strassner 2412 Cisco Systems 2413 Building 20 2414 725 Alder Drive 2415 Milpitas, CA 95035 2416 Phone: +1 408-527-1069 2417 Fax: +1 408-527-1722 2418 E-mail: johns@cisco.com 2420 Andrea Westerinen 2421 Cisco Systems 2422 Building 20 2423 725 Alder Drive 2424 Milpitas, CA 95035 2425 Phone: +1-408-853-8294 2426 Fax: +1-408-527-6351 2427 E-mail: andreaw@cisco.com 2429 Ed Ellesson 2430 LongBoard, Inc. 2431 2505 Meridian Pkwy, #100 2432 Durham, NC 27713 2433 Phone: +1 919-361-3230 2434 E-mail: eellesson@lboard.com 2436 Bob Moore 2437 IBM Corporation, BRQA/502 2438 4205 S. Miami Blvd. 2439 Research Triangle Park, NC 27709 2440 Phone: +1 919-254-4436 2441 Fax: +1 919-254-6243 2442 E-mail: remoore@us.ibm.com 2444 Ryan Moats 2445 Coreon, Inc. 2446 15621 Drexel Circle 2447 Omaha, NE 68135 2448 USA 2449 Phone: +1-402-894-9456 2450 E-mail: rmoats@coreon.net 2452 12. Full Copyright Statement 2454 Copyright (C) The Internet Society (2001). All Rights Reserved. 2456 This document and translations of it may be copied and furnished to 2457 others, and derivative works that comment on or otherwise explain it 2458 or assist in its implementation may be prepared, copied, published and 2459 distributed, in whole or in part, without restriction of any kind, 2460 provided that the above copyright notice and this paragraph are 2461 included on all such copies and derivative works. However, this 2462 document itself may not be modified in any way, such as by removing 2463 the copyright notice or references to the Internet Society or other 2464 Internet organizations, except as needed for the purpose of developing 2465 Internet standards in which case the procedures for copyrights defined 2466 in the Internet Standards process must be followed, or as required to 2467 translate it into languages other than English. 2469 The limited permissions granted above are perpetual and will not be 2470 revoked by the Internet Society or its successors or assigns. 2472 This document and the information contained herein is provided on an 2473 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2474 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2475 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2476 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2477 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2479 13. Appendix: Constructing the Value of orderedCimKeys 2481 Within a CIM name space, the naming is basically flat; all instances 2482 are identified by the values of their key properties, and each 2483 combination of key values must be unique. A limited form of 2484 hierarchical naming is available in CIM, however, by using weak 2485 associations: since a weak association involves propagation of key 2486 properties and their values from the superior object to the 2487 subordinate one, the subordinate object can be thought of as being 2488 named "under" the superior object. Once they have been propagated, 2489 however, propagated key properties and their values function in 2490 exactly the same way that native key properties and their values do in 2491 identifying a CIM instance. 2493 In its mapping from the CIM_ManagedElement class to the LDAP class 2494 dlm1ManagedElement, reference [10] introduces a third attribute, 2495 orderedCimKeys, alongside the two attributes that it derives from the 2496 properties in the CIM class. The orderedCimKeys attribute is used 2497 only in an environment where it is necessary to map between an LDAP- 2498 accessible directory and a CIM repository. For other environments, 2499 LDAP entries are identified via their other attributes that are 2500 suitable for naming. 2502 The role of orderedCimKeys is to represent the information necessary 2503 to correlate an entry in an LDAP-accessible directory with an instance 2504 in a CIM name space. Depending on how naming of CIM-related entries 2505 is handled in an LDAP directory, the value of orderedCimKeys 2506 represents one of two things: 2508 o If the DIT hierarchy does not mirror the "weakness hierarchy" of 2509 the CIM name space, then orderedCimKeys represents all the keys of 2510 the CIM instance, both native and propagated. 2512 o If the DIT hierarchy does mirror the "weakness hierarchy" of the 2513 CIM name space, then orderedCimKeys may represent either all the 2514 keys of the instance, or only the native keys. 2516 Regardless of which of these alternatives is taken, the syntax of 2517 orderedCimKeys is the same - a DirectoryString of the form 2519 .=[,=]* 2521 where the = elements are ordered by the names of the key 2522 properties, according to the collating sequence for US ASCII. The 2523 only spaces allowed in the DirectoryString are those that fall within 2524 a element. As with alphabetizing the key properties, the goal 2525 of suppressing the spaces is once again to make the results of string 2526 operations predictable. 2528 The values of the elements are derived from the various CIM 2529 syntaxes according to a grammar specified in reference [9].