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