idnits 2.17.1 draft-ietf-policy-core-schema-11.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 203 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 (May 2001) is 8382 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 2383, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2390, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2395, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2397, 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 INTELLIDEN, Inc. 3 Category: Standards Track A. Westerinen 4 Cisco Systems 5 E. Ellesson 6 LongBoard, Inc. 7 B. Moore 8 IBM Corporation 9 R. Moats 10 May 2001 12 Policy Core LDAP Schema 13 draft-ietf-policy-core-schema-11.txt 14 May 02, 2001 15:58 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.........................9 106 4.3. Rule-Specific and Reusable Conditions and Actions...........10 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.................33 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.............37 121 5.12. The Class policyInstance...................................38 122 5.13. The Auxiliary Class policyElementAuxClass..................40 123 5.14. The Three policyRepository Classes.........................40 124 5.15. The Auxiliary Class policySubtreesPtrAuxClass..............42 125 5.15.1. The Attribute policySubtreesAuxContainedSet..............44 126 5.16. The Auxiliary Class policyGroupContainmentAuxClass.........44 127 5.16.1. The Attribute policyGroupsAuxContainedSet................44 128 5.17. The Auxiliary Class policyRuleContainmentAuxClass..........45 129 5.17.1. The Attribute policyRulesAuxContainedSet.................45 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............................................48 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.............51 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]. If your 808 implementation does not support auxiliary class inheritance, but does 809 support content rules, you will have to list auxiliary classes in 810 content rules explicitly. 812 Note: all attribute, object class, and name form OIDs, and all 813 structure rule integers, are place holders, and syntax OIDs in 814 definitions have been replaced by names for clarity. 816 5.1. The Abstract Class "policy" 818 The abstract class "policy" is a direct mapping of the abstract class 819 Policy from the Core Information Model. The five properties in 820 Policy, three of which are inherited from the class 821 dlm1ManagedElement, map directly to attributes in the class "policy". 822 See reference [10] for the definition of the LDAP class 823 dlm1ManagedElement. 825 The class value "policy" is also used as the mechanism for identifying 826 policy-related instances in the Directory Information Tree. An 827 instance of any class may be "tagged" with this class value by 828 attaching to it the auxiliary class policyElementAuxClass. 830 The class definition is as follows: 832 ( NAME 'policy' 833 DESC 'An abstract class with five attributes for describing 834 a policy-related instance. The attributes dlmCaption, 835 dlmDescription, and orderedCimKeys are inherited from 836 dlm1ManagedElement.' 837 SUP dlm1ManagedElement 838 ABSTRACT 839 MAY ( cn $ policyKeywords ) 840 ) 842 The three attributes dlmCaption, dlmDescription, and orderedCimKeys 843 are defined in reference [10]. The attribute cn is defined in RFC 844 2256 [11]. The remaining attribute, policyKeywords, is defined as 845 follows: 847 ( NAME 'policyKeywords' 848 DESC 'A set of keywords to assist directory clients in 849 locating the policy objects applicable to them. Each 850 value of the multi-valued attribute contains a single 851 keyword. Standard keyword values are listed in the 852 Policy Core Information Model document. 854 This value is a Directory String.' 855 EQUALITY caseIgnoreMatch 856 SUBSTR caseIgnoreSubstringsMatch 857 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 858 ) 860 5.2. The Three policyGroup Classes 862 The information model defines a policyGroup class to serve as a 863 generalized aggregation container. It enables policyRules and 864 policyGroups to be aggregated in the same container. The LDAP schema 865 maps this class into three LDAP classes. The class definitions for the 866 three policyGroup classes are as follows. Note that these class 867 definitions do not include attributes to realize the 868 PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from 869 the object model, since a policyGroup object points to instances of 870 policyGroup and policyRule via, respectively, the pointer in 871 policyGroupContainmentAuxClass and the pointer in 872 policyRuleContainmentAuxClass. 874 To maximize flexibility, the policyGroup class is defined as abstract. 875 A subclass policyGroupAuxClass provides for auxiliary attachment to 876 another entry, while a structural subclass policyGroupInstance is 877 available to represent a policy group as a standalone entry. 879 ( NAME 'policyGroup' 880 DESC 'A container for either a set of related policyRules or 881 a set of related policyGroups. A policyGroup may also 882 contain a mixture of policyRules and other 883 policyGroups.' 884 SUP policy 885 ABSTRACT 886 MAY ( policyGroupName ) 887 ) 889 ( NAME 'policyGroupAuxClass' 890 DESC 'A container for either a set of related policyRules or 891 a set of related policyGroups. A policyGroup may also 892 contain a mixture of policyRules and other 893 policyGroups.' 894 SUP policyGroup 895 AUXILIARY 896 ) 897 ( NAME 'policyGroupInstance' 898 DESC 'A container for either a set of related policyRules or 899 a set of related policyGroups. A policyGroup may also 900 contain a mixture of policyRules and other 901 policyGroups.' 902 SUP policyGroup 903 STRUCTURAL 904 ) 906 The following DIT content rule indicates that an instance of 907 policyGroupInstance may have attached to it either DN pointers to one 908 or more other policyGroups, or DN pointers to one or more policyRules. 910 ( 911 NAME 'policyGroupContentRule' 912 DESC 'shows what auxiliary classes go with this object' 913 AUX ( policyGroupContainmentAuxClass $ 914 policyRuleContainmentAuxClass ) 915 ) 917 The following DIT structure rules indicate that an instance of 918 policyGroupInstance may be named under any superior, using any of its 919 three naming attributes. 921 NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule 922 are named within the scope of ("are weak to" in the CIM jargon) an 923 instance of the CIM class System, or one of its subclasses. The most 924 natural way to map a weak relationship of this type is to map it to 925 DIT structure rules specifying that an instance of policyGroupInstance 926 or policyRuleInstance is subordinate to an object representing a CIM 927 System. Since, however, the mapping of CIM's System class to an LDAP 928 class falls outside the scope of this document, the DIT structure 929 rules that follow do not constrain the superiors under which an 930 instance of policyGroupInstance may be named. 932 ( NAME 'policyGroupNameForm1' 933 OC policyGroupInstance 934 MUST ( cn ) 935 ) 937 ( NAME 'policyGroupStructuralRule1' 938 FORM policyGroupNameForm1 939 ) 941 ( NAME 'policyGroupNameForm2' 942 OC policyGroupInstance 943 MUST ( policyGroupName ) 944 ) 946 ( NAME 'policyGroupStructuralRule2' 947 FORM policyGroupNameForm2 948 ) 950 ( NAME 'policyGroupNameForm3' 951 OC policyGroupInstance 952 MUST ( orderedCimKeys ) 953 ) 955 ( NAME 'policyGroupStructuralRule3' 956 FORM policyGroupNameForm3 957 ) 959 The one attribute of policyGroup is defined as: 961 ( NAME 'policyGroupName' 962 DESC 'The user-friendly name of this policy group. 964 This value is a Directory String.' 965 EQUALITY caseIgnoreMatch 966 SUBSTR caseIgnoreSubstringsMatch 967 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 968 SINGLE-VALUE 969 ) 971 5.3. The Three policyRule Classes 973 The information model defines a policyRule class to represent the "If 974 Condition then Action" semantics associated with a policy. For 975 maximum flexibility, the LDAP schema maps this class into three LDAP 976 classes. 978 The conditions and actions associated with a policy rule are modeled, 979 respectively, with auxiliary subclasses of the auxiliary classes 980 policyConditionAuxClass and policyActionAuxClass. Each of these 981 auxiliary subclasses is attached to an instance of one of two 982 structural classes. A subclass of policyConditionAuxClass is attached 983 either to an instance of policyRuleConditionAssociation or to an 984 instance of policyInstance. Similarly, a subclass of 985 policyActionAuxClass is attached either to an instance of 986 policyRuleActionAssociation or to an instance of policyInstance.Of the 987 nine attributes in the policyRule class, eight are mapped directly 988 from corresponding properties in the information model. The ninth 989 attribute, policyRuleValidityPeriodList, realizes the 990 PolicyRuleValidityPeriod association from the information model. 991 Since this association has no additional properties besides those that 992 tie the association to its associated objects, the attribute 993 policyRuleValidityPeriodList is simply a multi-valued DN pointer. 994 (Relationships in the information model can have additional properties 995 because CIM represents relationships as classes. See Sections 5.4 and 996 5.5 for examples of additional properties and how they are mapped to 997 LDAP.) This attribute provides an unordered set of DN pointers to one 998 or more instances of the ptpConditionAuxClass, indicating when the 999 policy rule is scheduled to be active and when it is scheduled to be 1000 inactive. A policy rule is scheduled to be active if it is active 1001 according to AT LEAST ONE of the ptpConditionAuxClass instances 1002 pointed to by this attribute. 1004 The PolicyConditionInPolicyRule and PolicyActionInPolicyRule 1005 associations, however, have additional properties: 1006 PolicyActionInPolicyRule has an integer to sequence the actions, and 1007 PolicyConditionInPolicyRule has an integer to group the conditions, 1008 and a Boolean to specify whether a condition is to be negated. In the 1009 Core Schema, these additional association properties are represented 1010 as attributes of two classes introduced specifically to model the 1011 associations: policyRuleConditionAssociation and 1012 policyRuleActionAssociation, defined, respectively, in Sections 5.4 1013 and 5.5. Thus they do not appear as attributes of the class 1014 policyRule. 1016 To maximize flexibility, the policyRule class is defined as abstract. 1017 A subclass policyRuleAuxClass provides for auxiliary attachment to 1018 another entry, while a structural subclass policyRuleInstance is 1019 available to represent a policy rule as a standalone entry. 1021 The class definitions for the three policyRule classes are as follows: 1023 ( NAME 'policyRule' 1024 DESC 'The central class for representing the "If Condition 1025 then Action" semantics associated with a policy rule.' 1026 SUP policy 1027 ABSTRACT 1028 MAY ( policyRuleName $ policyRuleEnabled $ 1029 policyRuleConditionListType $ 1030 policyRuleConditionList $ policyRuleActionList $ 1031 policyRuleValidityPeriodList $ policyRuleUsage $ 1032 policyRulePriority $ policyRuleMandatory $ 1033 policyRuleSequencedActions $ policyRoles ) 1034 ) 1036 ( NAME 'policyRuleAuxClass' 1037 DESC 'The central class for representing the "If Condition 1038 then Action" semantics associated with a policy rule.' 1039 SUP policyRule 1040 AUXILIARY 1041 ) 1043 ( NAME 'policyRuleInstance' 1044 DESC 'The central class for representing the "If Condition 1045 then Action" semantics associated with a policy rule.' 1046 SUP policyRule 1047 STRUCTURAL 1048 ) 1050 The following DIT content rule indicates that an instance of 1051 policyRuleInstance may have attached to it the auxiliary classes 1052 policyConditionAuxClass and policyActionAuxClass, or one of their 1053 subclasses. This combination represents a simple policy rule. 1055 ( 1056 NAME 'policyRuleContentRule' 1057 DESC 'shows what auxiliary classes go with this object' 1058 AUX ( policyConditionAuxClass $ policyActionAuxClass ) 1059 ) 1061 The following DIT structure rules indicate that an instance of 1062 policyRuleInstance may be named under any superior, using any of its 1063 three naming attributes. 1065 NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule 1066 are named within the scope of ("are weak to" in the CIM jargon) an 1067 instance of the CIM class System, or one of its subclasses. The most 1068 natural way to map a weak relationship of this type is to DIT 1069 structure rules specifying that an instance of policyGroupInstance or 1070 policyRuleInstance is subordinate to an object representing a CIM 1071 System. Since, however, the mapping of CIM's System class to an LDAP 1072 class falls outside the scope of this document, the DIT structure 1073 rules that follow do not constrain the superiors under which an 1074 instance of policyRuleInstance may be named. 1076 ( NAME 'policyRuleNameForm1' 1077 OC policyRuleInstance 1078 MUST ( cn ) 1079 ) 1080 ( NAME 'policyRuleStructuralRule1' 1081 FORM policyRuleNameForm1 1082 ) 1084 ( NAME 'policyRuleNameForm2' 1085 OC policyRuleInstance 1086 MUST ( policyRuleName ) 1087 ) 1089 ( NAME 'policyRuleStructuralRule2' 1090 FORM policyRuleNameForm2 1091 ) 1092 ( NAME 'policyRuleNameForm3' 1093 OC policyRuleInstance 1094 MUST ( orderedCimKeys ) 1095 ) 1097 ( NAME 'policyRuleStructuralRule3' 1098 FORM policyRuleNameForm3 1099 ) 1101 The attributes of policyRule are defined as follows: 1103 ( NAME 'policyRuleName' 1104 DESC 'The user-friendly name of this policy rule. 1105 This value is a Directory String' 1106 EQUALITY caseIgnoreMatch 1107 SUBSTR caseIgnoreSubstringsMatch 1108 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1109 SINGLE-VALUE 1110 ) 1112 ( NAME 'policyRuleEnabled' 1113 DESC 'An enumeration indicating whether a policy rule is 1114 administratively enabled, administratively disabled, or 1115 enabled for debug mode. The defined values for this 1116 attribute are enabled(1), disabled(2), and 1117 enabledForDebug(3). 1119 This value is an INTEGER enumeration.' 1120 EQUALITY integerMatch 1121 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1122 SINGLE-VALUE 1123 ) 1125 ( NAME 'policyRuleConditionListType' 1126 DESC 'Indicates whether the list of policy conditions 1127 associated with this policy rule is in disjunctive 1128 normal form (DNF) or conjunctive normal form (CNF). 1129 Defined values are DNF(1) and CNF(2). 1131 This value is an INTEGER enumeration.' 1132 EQUALITY integerMatch 1133 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1134 SINGLE-VALUE 1135 ) 1137 ( NAME 'policyRuleConditionList' 1138 DESC 'Distinguished names of policyRuleConditionAssociation 1139 entries representing associations between this policy 1140 rule and its conditions. No order is implied. 1142 These values are Distinguished Names (DNs).' 1143 EQUALITY distinguishedNameMatch 1144 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1145 ) 1147 ( NAME 'policyRuleActionList' 1148 DESC 'Distinguished names of policyRuleActionAssociation 1149 entries representing associations between this policy 1150 rule and its actions. No order is implied. 1152 These values are Distinguished Names (DNs).' 1153 EQUALITY distinguishedNameMatch 1154 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1155 ) 1157 ( NAME 'policyRuleValidityPeriodList' 1158 DESC 'Distinguished names of policyRuleValidityAssociation 1159 entries that 1160 determine when the policyRule is scheduled to be active 1161 / inactive. No order is implied. 1163 These values are Distinguished Names (DNs).' 1164 EQUALITY distinguishedNameMatch 1165 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1166 ) 1168 ( NAME 'policyRuleUsage' 1169 DESC 'This attribute is a free-form string providing 1170 guidelines on how 1171 this policy should be used. 1173 This value is a Directory String.' 1174 EQUALITY caseIgnoreMatch 1175 SUBSTR caseIgnoreSubstringsMatch 1176 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1177 SINGLE-VALUE 1178 ) 1180 ( NAME 'policyRulePriority' 1181 DESC 'A non-negative integer for prioritizing this policyRule 1182 relative to other policyRules. A larger value indicates 1183 a higher priority. 1185 This value is an INTEGER.' 1186 EQUALITY integerMatch 1187 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1188 SINGLE-VALUE 1189 ) 1191 ( NAME 'policyRuleMandatory' 1192 DESC 'A flag indicating that the evaluation of the 1193 policyConditions and execution of policyActions (if the 1194 condition list evaluates to True) is required. 1196 This value is a Boolean.' 1197 EQUALITY booleanMatch 1198 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1199 SINGLE-VALUE 1200 ) 1202 ( NAME 'policyRuleSequencedActions' 1203 DESC 'An enumeration indicating how to interpret the action 1204 ordering indicated via the policyActionOrder 1205 attribute. The defined values for this attribute are 1206 mandatory(1), recommended(2), and dontCare(3). 1208 This value is an INTEGER enumeration.' 1209 EQUALITY integerMatch 1210 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1211 SINGLE-VALUE 1212 ) 1214 ( NAME 'policyRoles' 1215 DESC 'Each value of this attribute represents a role 1216 combination, including the special case of a 1217 "combination" containing only one role. Since this 1218 is a multi-valued attribute, more than one role 1219 combination can be associated with a single policy 1220 rule. Each value is a string of the form 1222 [&&]* 1224 where the individual role names appear in alphabetical 1225 order according to the collating sequence for UCS-2. 1227 These values are Directory Strings.' 1228 EQUALITY caseIgnoreMatch 1229 SUBSTR caseIgnoreSubstringsMatch 1230 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1231 ) 1233 The two matching rules for policyRoles support two different 1234 approaches that a PDP might take to the task of retrieving policyRules 1235 for its PEPs based on the roles they have reported to it. Suppose, 1236 for example, that a PEP has reported that it is interested in 1237 policyRules for three roles R1, R2, and R3. If the goal is to 1238 minimize queries, then the PDP can supply three substring filters 1239 containing the three role names. These queries will get all of the 1240 policyRules that apply to the PEP, but they may also get some that do 1241 not apply, for example, ones for the role combination "R1&&R4". 1243 Another strategy would be for the PDP to use only equality filters. 1244 This approach eliminates the extraneous replies, but it requires the 1245 PDP to build the role combinations ("R1&&R2", "R1&&R3", etc.) itself, 1246 and it requires extra queries. Note that this approach is practical 1247 only because the role names in a role combination are required to 1248 appear in alphabetical order. 1250 By having the two matching rules for policyRoles, the PCLS leaves to 1251 each PDP the choice of which of these approaches use. 1253 5.4. The Class policyRuleConditionAssociation 1255 This class contains attributes to represent the properties of the 1256 information model's PolicyConditionInPolicyRule association. 1257 Instances of this class are related to an instance of policyRule via 1258 DIT containment. The policy conditions themselves are represented by 1259 auxiliary subclasses of the auxiliary class policyConditionAuxClass. 1260 These auxiliary classes are attached directly to instances of 1261 policyRuleConditionAssociation for rule-specific policy conditions. 1262 For a reusable policy condition, the auxiliary class is attached to an 1263 instance of the class policyInstance, and there is a DN pointer to 1264 this instance from the instance of policyRuleConditionAssociation. 1266 The class definition is as follows: 1268 ( NAME 'policyRuleConditionAssociation' 1269 DESC 'The class contains attributes characterizing the 1270 relationship between a policy rule and one of its 1271 policy conditions.' 1272 SUP policy 1273 MUST ( policyConditionGroupNumber $ policyConditionNegated ) 1274 MAY ( policyConditionName $ policyConditionDN ) 1275 ) 1277 The following DIT content rule indicates that an instance of 1278 policyRuleConditionAssociation may have attached to it the auxiliary 1279 class policyConditionAuxClass, or one of its subclasses. This 1280 combination represents a rule-specific policy condition. 1282 ( 1283 NAME 1284 'prcAssociationContentRule' 1285 DESC 'shows what auxiliary classes go with this object' 1286 AUX ( policyConditionAuxClass ) 1287 ) 1289 The following DIT structure rules indicate that an instance of 1290 policyRuleConditionAssociation may be named under an instance of 1291 policyRule, where each of these instances may be named using any of 1292 their three naming attributes. 1294 ( NAME 1295 'prcAssociationNameForm1' 1296 OC policyRuleConditionAssociation 1297 MUST ( cn ) 1299 ( NAME 1300 'prcAssociationStructureRule1' 1301 FORM prcAssociationNameForm1 1302 SUP 1303 ) 1305 ( NAME 1306 'prcAssociationNameForm2' 1307 OC policyRuleConditionAssociation 1308 MUST ( policyConditionName ) 1309 ) 1311 ( NAME 1312 'prcAssociationStructureRule2' 1313 FORM prcAssociationNameForm2 1314 SUP 1315 ) 1316 ( NAME 1317 'prcAssociationNameForm3' 1318 OC policyRuleConditionAssociation 1319 MUST ( orderedCimKeys ) 1320 ) 1322 ( NAME 1323 'prcAssociationStructureRule3' 1324 FORM prcAssociationNameForm3 1325 SUP 1326 ) 1328 The attributes of policyRuleConditionAssociation are defined as 1329 follows. 1331 ( 1332 NAME 'policyConditionName' 1333 DESC 'A user-friendly name for a policy condition. 1335 This value is a Directory String.' 1336 EQUALITY caseIgnoreMatch 1337 SUBSTR caseIgnoreSubstringsMatch 1338 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1339 SINGLE-VALUE 1340 ) 1342 ( 1343 NAME 'policyConditionGroupNumber' 1344 DESC 'The number of the group to which a policy condition 1345 belongs. These groups are used to form the DNF or 1346 CNF expression associated with a policy rule. 1348 This value is an INTEGER.' 1349 EQUALITY integerMatch 1350 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1351 SINGLE-VALUE 1352 ) 1354 ( 1355 NAME 'policyConditionNegated' 1356 DESC 'Indicates whether a policy condition is negated in 1357 the DNF or CNF expression associated with a policy 1358 rule. The value TRUE indicates that a condition is 1359 negated 1361 This value is a Boolean.' 1362 EQUALITY booleanMatch 1363 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1364 SINGLE-VALUE 1365 ) 1367 ( 1368 NAME 'policyConditionDN' 1369 DESC 'A DN pointer to a reusable policy condition. 1371 This value is a Distinguished Name (DN).' 1372 EQUALITY distinguishedNameMatch 1373 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1374 SINGLE-VALUE 1375 ) 1377 5.5. The Class policyRuleValidityAssociation 1379 The policyRuleValidityPeriod aggregation is mapped to the 1380 policyRuleValidityAssociation class, which is defined below: 1382 ( NAME 'policyRuleValidityAssociation' 1383 DESC 'This class represents the scheduled activation and 1384 deactivation of a policy rule by binding the 1385 definition of times that the policy is active to 1386 the policy rule itself. The "scheduled" times 1387 are either identified through an attached auxiliary 1388 class, ptpConditionAuxClass, or are referenced through 1389 the policyTimePeriodConditionDN attribute.' 1390 SUP policy 1391 STRUCTURAL 1392 MAY (policyValidityConditionName $ 1393 policyTimePeriodConditionDN) 1394 ) 1396 The following DIT content rule indicates that an instance of 1397 policyRuleValidityAssociation may have attached to it the auxiliary 1398 class ptpConditionAuxClass, or one of its subclasses. This 1399 combination represents a policy validity period. 1401 ( 1402 NAME 'prvAssociationContentRule' 1403 DESC 'shows what auxiliary classes go with this object' 1404 AUX ( ptpConditionAuxClass ) 1405 ) 1407 The following DIT structure rules indicate that an instance of 1408 policyRuleValidityAssociation may be named under an instance of 1409 policyRule, where each of these instances may be named using any of 1410 their three naming attributes. 1412 ( NAME 'prvAssociationNameForm1' 1413 OC policyRuleValidityAssociation 1414 MUST ( cn ) 1416 ( NAME 'prvAssociationStructureRule1' 1417 FORM prvAssociationNameForm1 1418 SUP 1419 ) 1421 ( NAME 'prvAssociationNameForm2' 1422 OC policyRuleValidityAssociation 1423 MUST ( policyValidityConditionName ) 1424 ) 1426 ( NAME 'prvAssociationStructureRule2' 1427 FORM prvAssociationNameForm2 1428 SUP 1429 ) 1431 ( NAME 'prvAssociationNameForm3' 1432 OC policyRuleValidityAssociation 1433 MUST ( orderedCimKeys ) 1434 ) 1436 ( NAME 'prvAssociationStructureRule3' 1437 FORM prvAssociationNameForm3 1438 SUP 1439 ) 1441 The attributes of policyRuleValidityAssociation are defined as 1442 follows. 1444 ( 1445 NAME 'policyValidityConditionName' 1446 DESC 'A user-friendly name for expressing the times that a 1447 policy rule is active. 1449 This value is a Directory String.' 1450 EQUALITY caseIgnoreMatch 1451 SUBSTR caseIgnoreSubstringsMatch 1452 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1453 SINGLE-VALUE 1454 ) 1456 ( 1457 NAME 'policyTimePeriodConditionDN' 1458 DESC 'A DN pointer to a reusable policy time period 1459 condition. 1461 This value is a Distinguised Name (DN). 1463 EQUALITY distinguishedNameMatch 1464 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1465 SINGLE-VALUE 1466 ) 1468 5.6. The Class policyRuleActionAssociation 1470 This class contains an attribute to represent the one property of the 1471 information model's PolicyActionInPolicyRule association, which makes 1472 it possible to specify an order for executing the actions associated 1473 with a policy rule. Instances of this class are related to an 1474 instance of policyRule via DIT containment. The actions themselves 1475 are represented by auxiliary subclasses of the auxiliary class 1476 policyActionAuxClass. These auxiliary classes are attached directly 1477 to instances of policyRuleActionAssociation for rule-specific policy 1478 actions. For a reusable policy action, the auxiliary class is 1479 attached to an instance of the class policyInstance, and there is a DN 1480 pointer to this instance from the instance of 1481 policyRuleActionAssociation. 1483 The class definition is as follows: 1485 ( NAME 'policyRuleActionAssociation' 1486 DESC 'The class contains an attribute that represents an 1487 execution order for an action in the context of a 1488 policy rule.' 1489 SUP policy 1490 MUST ( policyActionOrder ) 1491 MAY ( policyActionName $ policyActionDN ) 1492 ) 1493 The following DIT content rule indicates that an instance of 1494 policyRuleActionAssociation may have attached to it the auxiliary 1495 class policyActionAuxClass, or one of its subclasses. This 1496 combination represents a rule-specific policy action. 1498 ( 1499 NAME 1500 'praAssociationContentRule' 1501 DESC 'shows what auxiliary classes go with this object' 1502 AUX ( policyActionAuxClass ) 1503 ) 1505 The following DIT structure rules indicate that an instance of 1506 policyRuleActionAssociation may be named under an instance of 1507 policyRule, where each of these instances may be named using any of 1508 their three naming attributes. 1510 ( NAME 1511 'praAssociationNameForm1' 1512 OC policyRuleActionAssociation 1513 MUST ( cn ) 1514 ) 1516 ( NAME 1517 'praAssociationStructuralRule1' 1518 FORM praAssociationNameForm1 1519 SUP 1520 ) 1522 ( NAME 1523 'praAssociationNameForm2' 1524 OC policyRuleActionAssociation 1525 MUST ( policyActionName ) 1526 ) 1528 ( NAME 1529 'praAssociationStructuralRule2' 1530 FORM praAssociationNameForm2 1531 SUP 1532 ) 1534 ( NAME 1535 'praAssociationNameForm3' 1536 OC policyRuleActionAssociation 1537 MUST ( orderedCimKeys ) 1538 ) 1540 ( NAME 1541 'praAssociationStructuralRule3' 1542 FORM praAssociationNameForm3 1543 SUP 1544 ) 1545 The attributes of policyRuleActionAssociation are defined as follows. 1547 ( 1548 NAME 'policyActionName' 1549 DESC 'A user-friendly name for a policy action. 1551 This value is a Directory String.' 1552 EQUALITY caseIgnoreMatch 1553 SUBSTR caseIgnoreSubstringsMatch 1554 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1555 SINGLE-VALUE 1556 ) 1558 ( 1559 NAME 'policyActionOrder' 1560 DESC 'An integer indicating the relative order of an action 1561 in the context of a policy rule. 1563 This value is an INTEGER.' 1564 EQUALITY integerMatch 1565 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1566 SINGLE-VALUE 1567 ) 1569 ( 1570 NAME 'policyActionDN' 1571 DESC 'A DN pointer to a reusable policy action. 1573 This value is a Distinguished Name (DN).' 1574 EQUALITY distinguishedNameMatch 1575 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1576 SINGLE-VALUE 1577 ) 1579 5.7. The Auxiliary Class policyConditionAuxClass 1581 The purpose of a policy condition is to determine whether or not the 1582 set of actions (contained in the policyRule that the condition applies 1583 to) should be executed or not. Subclasses of this auxiliary class can 1584 be attached to instances of three other classes in the Core Policy 1585 Schema. When a subclass of this class is attached to an instance of 1586 policyRuleConditionAssociation, or to an instance of policyRule, it 1587 represents a rule-specific policy condition. When a subclass of this 1588 class is attached to an instance of policyInstance, it represents a 1589 reusable policy condition. 1591 Since all of the classes to which subclasses of this auxiliary class 1592 may be attached are derived from "policy", the attributes of "policy" 1593 will already be defined for the entries to which these subclasses 1594 attach. Thus, this class is derived directly from "top". 1596 The class definition is as follows: 1598 ( NAME 'policyConditionAuxClass' 1599 DESC 'A class representing a condition to be evaluated in 1600 conjunction with a policy rule.' 1601 SUP top 1602 AUXILIARY 1603 ) 1605 5.8. The Auxiliary Class ptpConditionAuxClass 1607 The information model defines a time period class, 1608 PolicyTimePeriodCondition, to provide a means of representing the time 1609 periods during which a policy rule is valid, i.e., active. It also 1610 defines an aggregation, PolicyRuleValidityPeriod, so that time periods 1611 can be associated with a PolicyRule. The LDAP mapping also provides 1612 two classes, one for the time condition itself, and one for the 1613 aggregation. 1615 In the information model, this class is named 1616 PolicyTimePeriodCondition. However, the resulting name of the 1617 auxiliary class in this mapping (policyTimePeriodConditionAuxClass) 1618 exceeds the length of a name that some directories can store. 1619 Therefore, we have shortened the name to ptpConditionAuxClass. 1621 The class definition is as follows. 1623 ( NAME 'ptpConditionAuxClass' 1624 DESC 'A class that provides the capability of enabling / 1625 disabling a policy rule according to a predetermined 1626 schedule.' 1627 SUP policyConditionAuxClass 1628 AUXILIARY 1629 MAY ( ptpConditionTime $ ptpConditionMonthOfYearMask $ 1630 ptpConditionDayOfMonthMask $ ptpConditionDayOfWeekMask $ 1631 ptpConditionTimeOfDayMask $ ptpConditionLocalOrUtcTime ) 1632 ) 1634 The attributes of ptpConditionAuxClass are defined as follows. Note 1635 that several of the attributes are defined as bit strings of various 1636 fixed lengths. These attributes correspond to CIM properties that 1637 include four-octet length fields prior to their semantically 1638 significant bits. Since these length fields are unnecessary in LDAP, 1639 they are not included in the bit string attributes defined in this 1640 document. 1642 ( 1643 NAME 'ptpConditionTime' 1644 DESC 'The range of calendar dates on which a policy rule is 1645 valid. The format of the string is 1646 yyyymmddThhmmss/yyyymmddThhmmss, where the first 1647 date/time may be replaced with the string 1648 "THISANDPRIOR" or the second date/time may be replaced 1649 with the string "THISANDFUTURE". 1651 This value is a Printable String.' 1652 EQUALITY caseIgnoreMatch 1653 SUBSTR caseIgnoreSubstringsMatch 1654 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1655 SINGLE-VALUE 1656 ) 1658 ( 1659 NAME 'ptpConditionMonthOfYearMask' 1660 DESC 'A mask identifying the months of the year in which a 1661 policy rule is valid. The format is a bit string of 1662 length 12, representing the months of the 1663 year from January through December.' 1664 EQUALITY bitStringMatch 1665 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1666 SINGLE-VALUE 1667 ) 1669 ( 1670 NAME 'ptpConditionDayOfMonthMask' 1671 DESC 'A mask identifying the days of the month on which a 1672 policy rule is valid. The format is a bit string of 1673 length 62. The first 31 positions represent 1674 the days of the month in ascending order, from day 1 to 1675 day 31. The next 31 positions represent the days of 1676 the month in descending order, from the last day to the 1677 day 31 days from the end.' 1678 EQUALITY bitStringMatch 1679 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1680 SINGLE-VALUE 1681 ) 1683 ( 1684 NAME 'ptpConditionDayOfWeekMask' 1685 DESC 'A mask identifying the days of the week on which a 1686 policy rule is valid. The format is a bit string of 1687 length 7, representing the days of the week 1688 from Sunday through Saturday.' 1689 EQUALITY bitStringMatch 1690 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1691 SINGLE-VALUE 1692 ) 1694 ( 1695 NAME 'ptpConditionTimeOfDayMask' 1696 DESC 'The range of times at which a policy rule is valid. If 1697 the second time is earlier than the first, then the 1698 interval spans midnight. The format of the string is 1699 Thhmmss/Thhmmss. 1701 This value is a Printable String.' 1702 EQUALITY caseIgnoreMatch 1703 SUBSTR caseIgnoreSubstringsMatch 1704 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1705 SINGLE-VALUE 1706 ) 1708 ( 1709 NAME 'ptpConditionLocalOrUtcTime' 1710 DESC 'An indication of whether the other times in this 1711 instance represent local times or UTC times. The 1712 defined values for this attribute are localTime(1) 1713 and utcTime(2). 1715 This value is an INTEGER enumeration.' 1716 EQUALITY integerMatch 1717 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1718 SINGLE-VALUE 1719 ) 1721 5.9. The Auxiliary Class vendorPolicyConditionAuxClass 1723 The class definition is as follows: 1725 ( NAME 'vendorPolicyConditionAuxClass' 1726 DESC 'A class that defines a registered means to describe a 1727 policy condition.' 1728 SUP policyConditionAuxClass 1729 AUXILIARY 1730 MAY ( vendorPolicyConstraintData $ 1731 vendorPolicyConstraintEncoding ) 1732 ) 1734 The attribute definitions for vendorPolicyConditionAuxClass are as 1735 follows: 1737 ( 1738 NAME 'vendorPolicyConstraintData' 1739 DESC 'Escape mechanism for representing constraints that have 1740 not been modeled as specific attributes. The format of 1741 the values is identified by the OID stored in the 1742 attribute vendorPolicyConstraintEncoding. 1744 This value is an Octet String.' 1745 EQUALITY octetStringMatch 1746 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1747 ) 1749 ( 1750 NAME 'vendorPolicyConstraintEncoding' 1751 DESC 'An OID identifying the format and semantics for this 1752 Instance�s vendorPolicyConstraintData attribute.' 1753 EQUALITY objectIdentifierMatch 1754 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1755 SINGLE-VALUE 1756 ) 1758 5.10. The Auxiliary Class policyActionAuxClass 1760 The purpose of a policy action is to execute one or more operations 1761 that will affect network traffic and/or systems, devices, etc. in 1762 order to achieve a desired policy state. Subclasses of this auxiliary 1763 class can be attached to instances of three other classes in the Core 1764 Policy Schema. When a subclass of this class is attached to an 1765 instance of policyRuleActionAssociation, or to an instance of 1766 policyRule, it represents a rule-specific policy action. When a 1767 subclass of this class is attached to an instance of policyInstance, 1768 it represents a reusable policy action. 1770 Since all of the classes to which subclasses of this auxiliary class 1771 may be attached are derived from "policy", the attributes of "policy" 1772 will already be defined for the entries to which these subclasses 1773 attach. Thus, this class is derived directly from "top". 1775 The class definition is as follows: 1777 ( NAME 'policyActionAuxClass' 1778 DESC 'A class representing an action to be performed as a 1779 result of a policy rule.' 1780 SUP top 1781 AUXILIARY 1782 ) 1784 5.11. The Auxiliary Class vendorPolicyActionAuxClass 1786 The class definition is as follows: 1788 ( NAME 'vendorPolicyActionAuxClass' 1789 DESC 'A class that defines a registered means to describe a 1790 policy action.' 1791 SUP policyActionAuxClass 1792 AUXILIARY 1793 MAY ( vendorPolicyActionData $ vendorPolicyActionEncoding ) 1794 ) 1796 The attribute definitions for vendorPolicyActionAuxClass are as 1797 follows: 1799 ( 1800 NAME 'vendorPolicyActionData' 1801 DESC 'Escape mechanism for representing actions that have not 1802 been modeled as specific attributes. The format of the 1803 values is identified by the OID stored in the attribute 1804 vendorPolicyActionEncoding. 1806 This value is an Octet String.' 1807 EQUALITY octetStringMatch 1808 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1809 ) 1811 ( 1812 NAME 'vendorPolicyActionEncoding' 1813 DESC 'An OID identifying the format and semantics for this 1814 Instance�s vendorPolicyActionData attribute.' 1815 EQUALITY objectIdentifierMatch 1816 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1817 SINGLE-VALUE 1818 ) 1820 5.12. The Class policyInstance 1822 The role of this class in the Core Schema is to serve as a structural 1823 class to which auxiliary classes representing policy information are 1824 attached when the information is reusable. For auxiliary classes 1825 representing policy conditions and policy actions, there are 1826 alternative structural classes that may be used. See Sections 5.12 1827 and 5.13. See Section 4.3 for a complete discussion of reusable 1828 policy conditions and actions, and of the role that this class plays 1829 in how they are represented. 1831 In addition to the cn attribute it inherits from "policy", this class 1832 uses the class-specific naming attribute policyInstanceName. 1834 The class definition is as follows: 1836 ( NAME 'policyInstance' 1837 DESC 'A structural class that contains reusable policy 1838 information.' 1839 SUP policy 1840 MAY ( policyInstanceName ) 1841 ) 1843 The following DIT content rule indicates that an instance of 1844 policyInstance may have attached to it instances of the auxiliary 1845 classes policyConditionAuxClass and policyActionAuxClass. Additional 1846 DIT content rules may be defined later, for attachment of other 1847 policy-related auxiliary classes to policyInstance. 1849 ( 1850 NAME 'policyInstanceContentRule' 1851 DESC 'shows what auxiliary classes go with this class' 1852 AUX ( policyConditionAuxClass $ policyActionAuxClass) 1853 ) 1854 The following DIT structure rules indicate that an instance of 1855 policyInstance may be named under an instance of policyRepository, 1856 using any of its three naming attributes. 1858 ( NAME 'policyInstanceNameForm1' 1859 OC policyInstance 1860 MUST ( cn ) 1861 ) 1863 ( 1866 ) 1868 ( NAME 'policyInstanceNameForm2' 1869 OC policyInstance 1870 MUST ( policyInstanceName ) 1871 ) 1873 ( NAME 'policyInstanceStructuralRule2' 1874 FORM policyInstanceNameForm2 1875 SUP 1876 ) 1878 ( NAME 'policyInstanceNameForm3' 1879 OC policyInstance 1880 MUST ( orderedCimKeys ) 1881 ) 1883 ( NAME 'policyInstanceStructuralRule3' 1884 FORM policyInstanceNameForm3 1885 SUP 1886 ) 1888 The one attribute of policyInstance is defined as: 1890 ( NAME 'policyInstanceName' 1891 DESC 'The user-friendly name of this policy instance. 1893 This value is a Directory String.' 1894 EQUALITY caseIgnoreMatch 1895 SUBSTR caseIgnoreSubstringsMatch 1896 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1897 SINGLE-VALUE 1898 ) 1899 5.13. The Auxiliary Class policyElementAuxClass 1901 This class introduces no additional attributes, beyond those defined 1902 in the class "policy" from which it is derived. Its role is to "tag" 1903 an instance of a class defined outside the realm of policy as being 1904 nevertheless relevant to a policy specification. This tagging can 1905 potentially take place at two levels: 1907 o Every instance to which policyElementAuxClass is attached becomes 1908 an instance of the class "policy", since policyElementAuxClass is a 1909 subclass of "policy". Thus a DIT search with the filter 1910 "objectClass=policy" will return the instance. (As noted earlier, 1911 this approach does not work for some directory implementations. To 1912 accommodate these implementations, policy-related entries SHOULD be 1913 tagged with the keyword "POLICY".) 1915 o With the policyKeywords attribute that it inherits from "policy", 1916 an instance to which policyElementAuxClass is attached can be 1917 tagged as being relevant to a particular type or category of 1918 policy, using standard keywords, administrator-defined keywords, or 1919 both. 1921 The class definition is as follows: 1923 ( NAME 'policyElementAuxClass' 1924 DESC 'An auxiliary class used to tag instances of classes 1925 defined outside the realm of policy as relevant to a 1926 particular policy specification.' 1927 SUP policy 1928 AUXILIARY 1929 ) 1931 5.14. The Three policyRepository Classes 1933 These classes provide a container for reusable policy information, 1934 such as reusable policy conditions and/or reusable policy actions. 1935 They are derived from several classes defined in reference [10]: 1937 top 1938 | 1939 +--dlm1ManagedElement (abstract) 1940 | 1941 +--dlm1ManagedSystemElement (abstract) 1942 | 1943 +--dlm1LogicalElement (abstract) 1944 | 1945 +--dlm1System (abstract) 1946 | 1947 +--dlm1AdminDomain (abstract) 1948 | 1949 +--policyRepository (abstract) 1950 | 1951 +--policyRepositoryAuxClass (auxiliary) 1952 | 1953 +--policyRepositoryInstance (structural) 1955 To maximize flexibility, the policyRepository class is defined as 1956 abstract. A subclass policyRepositoryAuxClass provides for auxiliary 1957 attachment to another entry, while a structural subclass 1958 policyRepositoryInstance is available to represent a policy repository 1959 as a standalone entry. 1961 The class definitions for the policyRepository classes are as follows: 1963 ( NAME 'policyRepository' 1964 DESC 'A container for reusable policy information.' 1965 SUP dlm1AdminDomain 1966 ABSTRACT 1967 MAY ( policyRepositoryName ) 1968 ) 1970 ( NAME 'policyRepositoryAuxClass' 1971 DESC 'A container for reusable policy information.' 1972 SUP policyRepository 1973 AUXILIARY 1974 ) 1976 ( NAME 'policyRepositoryInstance' 1977 DESC 'A container for reusable policy information.' 1978 SUP policyRepository 1979 STRUCTURAL 1980 ) 1982 The following DIT structure rules indicate that an instance of 1983 policyRepositoryInstance may be named under any superior, using any of 1984 its three naming attributes. These DIT structure rules cover, as 1985 special cases, a policyRepositoryInstance that is named within the 1986 scope of another policyRepositoryInstance, or within the scope of an 1987 entry to which policyRepositoryAuxClass is attached. These special 1988 cases represent the mapping for the CIM aggregation 1989 PolicyRepositoryInPolicyRepository. 1991 ( NAME 'policyRepositoryNameForm1' 1992 OC policyRepositoryInstance 1993 MUST ( cn ) 1994 ) 1996 ( NAME 'policyRepositoryStructuralRule1' 1997 FORM policyRepositoryNameForm1 1998 ) 2000 ( NAME 'policyRepositoryNameForm2' 2001 OC policyRepositoryInstance 2002 MUST ( policyRepositoryName ) 2003 ) 2005 ( NAME 'policyRepositoryStructuralRule2' 2006 FORM policyRepositoryNameForm2 2007 ) 2009 ( NAME 'policyRepositoryNameForm3' 2010 OC policyRepositoryInstance 2011 MUST ( orderedCimKeys ) 2012 ) 2014 ( NAME 'policyRepositoryStructuralRule3' 2015 FORM policyRepositoryNameForm3 2016 ) 2018 The one attribute of policyRepository is defined as follows. 2020 ( NAME 'policyRepositoryName' 2021 DESC 'The user-friendly name of this policy repository. 2023 This value is a Directory String.' 2024 EQUALITY caseIgnoreMatch 2025 SUBSTR caseIgnoreSubstringsMatch 2026 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 2027 SINGLE-VALUE 2028 ) 2030 5.15. The Auxiliary Class policySubtreesPtrAuxClass 2032 This auxiliary class provides a single, multi-valued attribute that 2033 points to a set of objects that are at the root of DIT subtrees 2034 containing policy-related information. By attaching this attribute to 2035 instances of various other classes, a policy administrator has a 2036 flexible way of providing an entry point into the directory that 2037 allows a client to locate and retrieve the policy information relevant 2038 to it. 2040 These entries may be placed in the DIT such that a well-known DN can 2041 be used by placing the structural entry (e.g. container) with the 2042 policySubtreesPtrAuxClass attached thereto in the root of the 2043 directory suffix. In this case, the subtree entry point can contain 2044 and/or point to all related policy entries for any well-known policy 2045 disciplines. Similarly, the subtree entry point may be placed in the 2046 DIT such that the PDP's starting point is a subtree with policy- 2047 related entries that are dependent on a hierarchically-related set of 2048 subtrees (e.g., region, division, corporate). In this latter case, 2049 DNs may be provided to the PDPs via SNMP or other techniques. 2051 This object does not provide the semantic linkages between individual 2052 policy objects, such as those between a policy group and the policy 2053 rules that belong to it. Its only role is to enable efficient bulk 2054 retrieval of policy-related objects, as described in Section 4.4. 2055 Once the objects have been retrieved, a directory client can determine 2056 the semantic linkages by following DN pointers such as 2057 policyRulesAuxContainedSet locally. 2059 Since policy-related objects will often be included in the DIT subtree 2060 beneath an object to which this auxiliary class is attached, a client 2061 SHOULD request the policy-related objects from the subtree under the 2062 object with these pointers at the same time that it requests the 2063 pointers themselves. 2065 Since clients are expected to behave in this way, the policy 2066 administrator SHOULD make sure that this subtree does not contain so 2067 many objects unrelated to policy that an initial search done in this 2068 way results in a performance problem. For example, 2069 policySubtreesPtrAuxClass SHOULD NOT be attached to the partition root 2070 for a large directory partition containing a relatively few policy- 2071 related objects along with a large number of objects unrelated to 2072 policy. A better approach would be to introduce a container object 2073 immediately below the partition root, attach policySubtreesPtrAuxClass 2074 to this container object, and then place the policy-related objects in 2075 the subtree under it. 2077 The class definition is as follows: 2079 ( NAME 'policySubtreesPtrAuxClass' 2080 DESC 'An auxiliary class providing DN pointers to roots of 2081 DIT subtrees containing policy-related objects.' 2082 SUP top 2083 AUXILIARY 2084 MAY ( policySubtreesAuxContainedSet ) 2085 ) 2086 5.15.1. The Attribute policySubtreesAuxContainedSet 2088 This attribute provides an unordered set of DN pointers to one or more 2089 objects under which policy-related information is present. The 2090 objects pointed to may or may not themselves contain policy-related 2091 information. 2093 The attribute definition is as follows: 2095 ( 2096 NAME 'policySubtreesAuxContainedSet' 2097 DESC 'Distinguished names of objects that serve as roots for 2098 DIT subtrees containing policy-related objects. No 2099 order is implied. 2101 This value is a Distinguished Name (DN).' 2102 EQUALITY distinguishedNameMatch 2103 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2104 ) 2106 5.16. The Auxiliary Class policyGroupContainmentAuxClass 2108 This auxiliary class provides a single, multi-valued attribute that 2109 points to a set of policyGroups. By attaching this attribute to 2110 instances of various other classes, a policy administrator has a 2111 flexible way of providing an entry point into the directory that 2112 allows a client to locate and retrieve the policyGroups relevant to 2113 it. 2115 As is the case with policyRules, a policy administrator might have 2116 several different pointers to a policyGroup in the overall directory 2117 structure. The policyGroupContainmentAuxClass is the mechanism that 2118 makes it possible for the policy administrator to define all these 2119 pointers. 2121 The class definition is as follows: 2123 ( NAME 'policyGroupContainmentAuxClass' 2124 DESC 'An auxiliary class used to bind policyGroups to an 2125 appropriate container object.' 2126 SUP top 2127 AUXILIARY 2128 MAY ( policyGroupsAuxContainedSet ) 2129 ) 2131 5.16.1. The Attribute policyGroupsAuxContainedSet 2133 This attribute provides an unordered set of DN pointers to one or more 2134 policyGroups associated with the instance of a structural class to 2135 which this attribute has been appended. The attribute definition is 2136 as follows: 2138 ( 2139 NAME 'policyGroupsAuxContainedSet' 2140 DESC 'Distinguished names of policyGroups associated in some 2141 way with the instance to which this attribute has been 2142 appended. No order is implied. 2144 This value is a Distinguished Name (DN).' 2145 EQUALITY distinguishedNameMatch 2146 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2147 ) 2149 5.17. The Auxiliary Class policyRuleContainmentAuxClass 2151 This auxiliary class provides a single, multi-valued attribute that 2152 points to a set of policyRules. By attaching this attribute to 2153 instances of various other classes, a policy administrator has a 2154 flexible way of providing an entry point into the directory that 2155 allows a client to locate and retrieve the policyRules relevant to it. 2157 A policy administrator might have several different pointers to a 2158 policyRule in the overall directory structure. For example, there 2159 might be pointers to all policyRules for traffic originating in a 2160 particular subnet from a directory entry that represents that subnet. 2161 At the same time, there might be pointers to all policyRules related 2162 to a particular DiffServ setting from an instance of a policyGroup 2163 explicitly introduced as a container for DiffServ-related policyRules. 2164 The policyRuleContainmentAuxClass is the mechanism that makes it 2165 possible for the policy administrator to define all these pointers. 2167 Note that the cn attribute does NOT need to be defined for this class. 2168 This is because an auxiliary class is used as a means to collect 2169 common attributes and treat them as properties of an object. A good 2170 analogy is a #include file, except that since an auxiliary class is a 2171 class, all the benefits of a class (e.g., inheritance) can be applied 2172 to an auxiliary class. 2174 The class definition is as follows: 2176 ( NAME 'policyRuleContainmentAuxClass' 2177 DESC 'An auxiliary class used to bind policyRules to an 2178 appropriate container object.' 2179 SUP top 2180 AUXILIARY 2181 MAY ( policyRulesAuxContainedSet ) 2182 ) 2184 5.17.1. The Attribute policyRulesAuxContainedSet 2186 This attribute provides an unordered set of DN pointers to one or more 2187 policyRules associated with the instance of a structural class to 2188 which this attribute has been appended. The attribute definition is: 2190 ( 2191 NAME 'policyRulesAuxContainedSet' 2192 DESC 'Distinguished names of policyRules associated in some 2193 way with the instance to which this attribute has been 2194 appended. No order is implied. 2196 This value is a Distinguished Name (DN).' 2197 EQUALITY distinguishedNameMatch 2198 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2199 ) 2201 6. Extending the Core Schema 2203 The following subsections provide general guidance on how to create a 2204 domain-specific schema derived from the Core Schema, discuss how the 2205 vendor classes in the Core Schema should be used, and explain how 2206 policyTimePeriodConditions are related to other policy conditions. 2208 6.1. Subclassing policyConditionAuxClass and policyActionAuxClass 2210 In Section 4.3 above, there is a discussion of how, by representing 2211 policy conditions and policy actions as auxiliary classes in a schema, 2212 the flexibility is retained to instantiate a particular condition or 2213 action as either rule-specific or reusable. This flexibility is lost 2214 if a condition or action class is defined as structural rather than 2215 auxiliary. For standardized schemata, this document specifies that 2216 domain-specific information MUST be expressed in auxiliary subclasses 2217 of policyConditionAuxClass and policyActionAuxClass. It is 2218 RECOMMENDED that non-standardized schemata follow this practice as 2219 well. 2221 6.2. Using the Vendor Policy Encoding Attributes 2223 As discussed Section 5.8 "The Class vendorPolicyConditionAuxClass", 2224 the attributes vendorPolicyConstraintData and 2225 vendorPolicyConstraintEncoding are included in 2226 vendorPolicyConditionAuxClass to provide an escape mechanism for 2227 representing "exceptional" policy conditions. The attributes 2228 vendorPolicyActionData and vendorPolicyActionEncoding in 2229 vendorPolicyActionAuxClass class play the same role with respect to 2230 actions. This enables interoperability between different vendors. 2232 For example, imagine a network composed of access devices from vendor 2233 A, edge and core devices from vendor B, and a policy server from 2234 vendor C. It is desirable for this policy server to be able to 2235 configure and manage all of the devices from vendors A and B. 2236 Unfortunately, these devices will in general have little in common 2237 (e.g., different mechanisms, different ways for controlling those 2238 mechanisms, different operating systems, different commands, and so 2239 forth). The escape conditions provide a way for vendor-specific 2240 commands to be encoded as OctetStrings, so that a single policy server 2241 can commonly manage devices from different vendors. 2243 6.3. Using Time Validity Periods 2245 Time validity periods are defined as a subclass of 2246 policyConditionAuxClass, called policyTimePeriodCondition. This is to 2247 allow their inclusion in the AND/OR condition definitions for a 2248 policyRule. Care should be taken not to subclass 2249 policyTimePeriodCondition to add domain-specific condition properties. 2250 For example, it would be incorrect to add IPSec- or QoS-specific 2251 condition properties to the policyTimePeriodCondition class, just 2252 because IPSec or QoS includes time in its condition definition. The 2253 correct subclassing would be to create IPSec or QoS-specific 2254 subclasses of policyConditionAuxClass and then combine instances of 2255 these domain-specific condition classes with the validity period 2256 criteria. This is accomplished using the AND/OR association 2257 capabilities for policyConditions in policyRules. 2259 7. Security Considerations 2261 The Policy Core LDAP Schema (PCLS), presented in this document, 2262 provides a mapping of the object-oriented model for describing policy 2263 information (PCIM), into a data model that forms the basic framework 2264 for describing the structure of policy data, in the case where the 2265 policy repository takes the form of an LDAP-accessible directory. 2267 PCLS is not intended to represent any particular system design or 2268 implementation. PCLS is not directly useable in a real world system, 2269 without the discipline-specific mappings that are works in progress in 2270 the Policy Framework Working Group of the IETF. 2272 These other derivative documents, which use PCIM and its discipline- 2273 specific extensions as a base, will need to convey more specific 2274 security considerations (refer to RFC3060 for more information.) 2276 The reason that PCLS, as defined here, is not representative of any 2277 real-world system, is that its object classes were designed to be 2278 independent of any specific discipline, or policy domain. For 2279 example, DiffServ and IPSec represent two different policy domains. 2280 Each document that extends PCIM to one of these domains will derive 2281 subclasses from the classes and relationships defined in PCIM, in 2282 order to represent extensions of a generic model to cover specific 2283 technical domains. 2285 PCIM-derived documents will thus subclass the PCIM classes into 2286 classes specific to each technical policy domain (QOS, IPsec, etc.), 2287 which will, in turn, be mapped, to directory-specific schemas 2288 consistent with the the PCLS schema documented here. 2290 Even though discipline-specific security requirements are not 2291 appropriate for PCLS, specific security requirements MUST be defined 2292 for each operational real-world application of PCIM. Just as there 2293 will be a wide range of operational, real-world systems using PCIM, 2294 there will also be a wide range of security requirements for these 2295 systems. Some operational, real-world systems that are deployed using 2296 PCLS may have extensive security requirements that impact nearly all 2297 object classes utilized by such a system, while other systems' 2298 security requirements might have very little impact. 2300 The derivative documents, discussed above, will create the context for 2301 applying operational, real-world, system-level security requirements 2302 against the various models which derive from PCIM, consistent with 2303 PCLS. 2305 In some real-world scenarios, the values associated with certain 2306 properties, within certain instantiated object classes, may represent 2307 information associated with scarce, and/or costly (and therefore 2308 valuable) resources. It may be the case that these values must not be 2309 disclosed to, or manipulated by, unauthorized parties. 2311 Since this document forms the basis for the representation of a policy 2312 data model in a specific format (an LDAP-accessible directory), it is 2313 herein appropriate to reference the data model-specific tools and 2314 mechanisms that are available for achieving the authentication and 2315 authorization implicit in a requirement that restricts read and/or 2316 read- write access to these values stored in a directory. 2318 LDAP-specific authentication and authorization tools and mechanisms 2319 are found in the following standards track documents, which are 2320 appropriate for application to the management of security applied to 2321 policy data models stored in an LDAP-accessible directory: 2323 o RFC 2829 (Authentication Methods for LDAP) 2325 o RFC 2830 (Lightweight Directory Access Protocol (v3): Extension 2326 for Transport Layer Security) 2328 Any identified security requirements that are not dealt with in the 2329 appropriate discipline-specific information model documents, or in 2330 this document, MUST be dealt with in the derivative data model 2331 documents which are specific to each discipline. 2333 8. Intellectual Property 2335 The IETF takes no position regarding the validity or scope of any 2336 intellectual property or other rights that might be claimed to pertain 2337 to the implementation or use of the technology described in this 2338 document or the extent to which any license under such rights might or 2339 might not be available; neither does it represent that it has made any 2340 effort to identify any such rights. Information on the IETF's 2341 procedures with respect to rights in standards-track and standards- 2342 related documentation can be found in BCP-11. 2344 Copies of claims of rights made available for publication and any 2345 assurances of licenses to be made available, or the result of an 2346 attempt made to obtain a general license or permission for the use of 2347 such proprietary rights by implementers or users of this specification 2348 can be obtained from the IETF Secretariat. 2350 The IETF invites any interested party to bring to its attention any 2351 copyrights, patents or patent applications, or other proprietary 2352 rights that may cover technology that may be required to practice this 2353 standard. Please address the information to the IETF Executive 2354 Director. 2356 9. Acknowledgments 2358 Several of the policy classes in this model first appeared in early 2359 IETF drafts on IPSec policy and QoS policy. The authors of these 2360 drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy 2361 Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael 2362 See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar. 2363 This document is closely aligned with the work being done in the 2364 Distributed Management Task Force (DMTF) Service Level Agreements and 2365 Networks working groups. We would especially like to thank Lee 2366 Rafalow, Glenn Waters, David Black, Michael Richardson, Mark Stevens, 2367 David Jones, Hugh Mahon, Yoram Snir, and Yoram Ramberg for their 2368 helpful comments. 2370 10. References 2372 [1] Moore, B., and E. Ellesson, J. Strassner, A. Westerinen "Policy 2373 Core Information Model -- Version 1 Specification", RFC 3060, 2374 February 2001. 2376 [2] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight 2377 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2378 2252, December 1997. 2380 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2381 Levels", BCP 14, RFC 2119, March 1997. 2383 [4] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 2384 Standards Process", BCP 11, RFC 2028, October 1996. 2386 [5] Strassner, J. and S. Judd, "Directory-Enabled Networks", version 2387 3.0c5 (August 1998). A PDF file is available at 2388 http://www.murchiso.com/den/#denspec. 2390 [6] Strassner, J., policy architecture BOF presentation, 42nd IETF 2391 Meeting, Chicago, Illinois, October 1998. Minutes of this BOF are 2392 available at the following location: 2393 http://www.ietf.org/proceedings/98aug/index.html. 2395 [7] DMTF web site, http://www.dmtf.org. 2397 [8] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for 2398 Policy-based Admission Control", RFC 2753, January 2000. 2400 [9] Distributed Management Task Force, Inc., "Guidelines for CIM-to- 2401 LDAP Directory Mapping", May 8, 2000. This document is available 2402 on the following DMTF web page: http://www.dmtf.org/spec/denh.html. 2404 [10] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the 2405 CIM v2.4 Core Information Model", November 20, 2000. This document 2406 is available on the following DMTF web page: 2407 http://www.dmtf.org/spec/denh.html. 2409 [11] Wahl, M., " A Summary of the X.500(96) User Schema for use with 2410 LDAPv3", RFC 2256, December 1997. 2412 11. Authors' Addresses 2414 John Strassner 2415 INTELLIDEN, Inc. 2416 90 South Cascade Avenue 2417 Colorado Springs, CO 80903 2418 Phone: +1.719.785.0648 2419 Fax: +1.719.785.0644 2420 E-mail: john.strassner@intelliden.com 2422 Andrea Westerinen 2423 Cisco Systems 2424 Building 20 2425 725 Alder Drive 2426 Milpitas, CA 95035 2427 Phone: +1-408-853-8294 2428 Fax: +1-408-527-6351 2429 E-mail: andreaw@cisco.com 2431 Ed Ellesson 2432 LongBoard, Inc. 2433 2505 Meridian Pkwy, #100 2434 Durham, NC 27713 2435 Phone: +1 919-361-3230 2436 E-mail: eellesson@lboard.com 2438 Bob Moore 2439 IBM Corporation, BRQA/502 2440 4205 S. Miami Blvd. 2442 Research Triangle Park, NC 27709 2443 Phone: +1 919-254-4436 2444 Fax: +1 919-254-6243 2445 E-mail: remoore@us.ibm.com 2447 Ryan Moats 2448 15621 Drexel Circle 2449 Omaha, NE 68135 2450 USA 2451 Phone: +1-402-894-9456 2452 E-mail: moats@tconl.com 2454 12. Full Copyright Statement 2456 Copyright (C) The Internet Society (2001). All Rights Reserved. 2458 This document and translations of it may be copied and furnished to 2459 others, and derivative works that comment on or otherwise explain it 2460 or assist in its implementation may be prepared, copied, published and 2461 distributed, in whole or in part, without restriction of any kind, 2462 provided that the above copyright notice and this paragraph are 2463 included on all such copies and derivative works. However, this 2464 document itself may not be modified in any way, such as by removing 2465 the copyright notice or references to the Internet Society or other 2466 Internet organizations, except as needed for the purpose of developing 2467 Internet standards in which case the procedures for copyrights defined 2468 in the Internet Standards process must be followed, or as required to 2469 translate it into languages other than English. 2471 The limited permissions granted above are perpetual and will not be 2472 revoked by the Internet Society or its successors or assigns. 2474 This document and the information contained herein is provided on an 2475 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2476 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2477 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2478 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2479 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2481 13. Appendix: Constructing the Value of orderedCimKeys 2483 Within a CIM name space, the naming is basically flat; all instances 2484 are identified by the values of their key properties, and each 2485 combination of key values must be unique. A limited form of 2486 hierarchical naming is available in CIM, however, by using weak 2487 associations: since a weak association involves propagation of key 2488 properties and their values from the superior object to the 2489 subordinate one, the subordinate object can be thought of as being 2490 named "under" the superior object. Once they have been propagated, 2491 however, propagated key properties and their values function in 2492 exactly the same way that native key properties and their values do in 2493 identifying a CIM instance. 2495 In its mapping from the CIM_ManagedElement class to the LDAP class 2496 dlm1ManagedElement, reference [10] introduces a third attribute, 2497 orderedCimKeys, alongside the two attributes that it derives from the 2498 properties in the CIM class. The orderedCimKeys attribute is used 2499 only in an environment where it is necessary to map between an LDAP- 2500 accessible directory and a CIM repository. For other environments, 2501 LDAP entries are identified via their other attributes that are 2502 suitable for naming. 2504 The role of orderedCimKeys is to represent the information necessary 2505 to correlate an entry in an LDAP-accessible directory with an instance 2506 in a CIM name space. Depending on how naming of CIM-related entries 2507 is handled in an LDAP directory, the value of orderedCimKeys 2508 represents one of two things: 2510 o If the DIT hierarchy does not mirror the "weakness hierarchy" of 2511 the CIM name space, then orderedCimKeys represents all the keys of 2512 the CIM instance, both native and propagated. 2514 o If the DIT hierarchy does mirror the "weakness hierarchy" of the 2515 CIM name space, then orderedCimKeys may represent either all the 2516 keys of the instance, or only the native keys. 2518 Regardless of which of these alternatives is taken, the syntax of 2519 orderedCimKeys is the same - a DirectoryString of the form 2521 .=[,=]* 2523 where the = elements are ordered by the names of the key 2524 properties, according to the collating sequence for US ASCII. The 2525 only spaces allowed in the DirectoryString are those that fall within 2526 a element. As with alphabetizing the key properties, the goal 2527 of suppressing the spaces is once again to make the results of string 2528 operations predictable. 2530 The values of the elements are derived from the various CIM 2531 syntaxes according to a grammar specified in reference [9].