idnits 2.17.1 draft-ietf-policy-core-schema-08.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 192 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 (November 2000) is 8563 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 86 == Unused Reference: '4' is defined on line 2311, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2318, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2323, 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 (~~), 4 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 B. Moore 5 IBM Corporation 6 Ryan Moats 7 Coreon 8 November 2000 10 Policy Core LDAP Schema 11 draft-ietf-policy-core-schema-08.txt 12 November 22, 2000 13:08 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (2000). All Rights Reserved. 38 Abstract 40 This document takes as its starting point the object-oriented 41 information model for representing policy information currently under 42 joint development in the Service Level Agreements (SLA) Policy working 43 group of the Distributed Management Task Force (DMTF) and in the 44 IETF's Policy Framework working group. The IETF document defining 45 this information model is the "Policy Core Information Model -- 46 Version 1 Specification" [1]. This model defines two hierarchies of 47 object classes: structural classes representing policy information and 48 control of policies, and relationship classes that indicate how 49 instances of the structural classes are related to each other. In 50 general, both of these class hierarchies will need to be mapped to a 51 particular data store. 53 This draft defines the mapping of these information model classes to a 54 directory that uses LDAPv3 as its access protocol. When mapping to an 55 LDAP schema, the structural classes can be mapped more or less 56 directly. The relationship hierarchy, however, must be mapped to a 57 form suitable for directory implementation. Since this mapping of the 58 relationship classes could be done in a number of different ways, 59 there is the risk of non-interoperable implementations. To avoid this 60 possibility, this document provides a single mapping that all 61 implementations using an LDAP directory as their policy repository 62 SHALL use. 64 Classes are also added to the LDAP schema to improve the performance 65 of a client's interactions with an LDAP server when the client is 66 retrieving large amounts of policy-related information. These classes 67 exist only to optimize LDAP retrievals: there are no classes in the 68 information model that correspond to them. 70 The LDAP schema described in this document consists of six very 71 general classes: policy (an abstract class), policyGroup, policyRule, 72 policyConditionAuxClass, policyTimePeriodConditionAuxClass, and 73 policyActionAuxClass. The schema also contains two less general 74 classes: vendorPolicyConditionAuxClass and vendorPolicyActionAuxClass. 75 To achieve the mapping of the information model's relationships, the 76 schema contains two auxiliary classes: policyGroupContainmentAuxClass 77 and policyRuleContainmentAuxClass. Capturing the distinction between 78 rule-specific and reusable policy conditions and policy actions 79 introduces six other classes: policyRuleConditionAssociation, 80 policyRuleActionAssociation, policyInstance, policyConditionInstance, 81 policyActionInstance, and policyRepository. Finally, the schema 82 includes two classes policySubtreesPtrAuxClass and 83 policyElementAuxClass for optimizing LDAP retrievals. In all, 84 therefore, the schema contains 18 classes. 86 Within the context of this document, the term "Core [Policy] Schema" 87 is used to refer to the LDAP class definitions it contains. 89 Table of Contents 90 1. Introduction......................................................3 91 2. The Policy Core Information Model.................................4 92 3. Inheritance Hierarchy for the LDAP Core Policy Schema.............5 93 4. General Discussion of Mapping the Information Model to LDAP.......7 94 4.1. Summary of Class and Association Mappings....................7 95 4.2. Naming Attributes in the Core Schema.........................8 96 4.3. Rule-Specific and Reusable Conditions and Actions............9 97 4.4. Location and Retrieval of Policy Objects in the Directory...13 98 4.4.1. Aliases and Other DIT-Optimization Techniques.............16 99 5. Class Definitions................................................17 100 5.1. The Abstract Class "policy".................................17 101 5.2. The Class policyGroup.......................................18 102 5.3. The Class policyRule........................................20 103 5.4. The Class policyRuleConditionAssociation....................24 104 5.5. The Class policyRuleActionAssociation.......................27 105 5.6. The Auxiliary Class policyConditionAuxClass.................29 106 5.7. The Auxiliary Class policyTimePeriodConditionAuxClass.......29 107 5.8. The Auxiliary Class vendorPolicyConditionAuxClass...........31 108 5.9. The Auxiliary Class policyActionAuxClass....................32 109 5.10. The Auxiliary Class vendorPolicyActionAuxClass.............32 110 5.11. The Class policyInstance...................................33 111 5.12. The Class policyConditionInstance..........................35 112 5.13. The Class policyActionInstance.............................36 113 5.14. The Auxiliary Class policyElementAuxClass..................38 114 5.15. The Class policyRepository.................................38 115 5.16. The Auxiliary Class policySubtreesPtrAuxClass..............40 116 5.16.1. The Attribute policySubtreesAuxContainedSet..............41 117 5.17. The Auxiliary Class policyGroupContainmentAuxClass.........41 118 5.17.1. The Attribute policyGroupsAuxContainedSet................42 119 5.18. The Auxiliary Class policyRuleContainmentAuxClass..........42 120 5.18.1. The Attribute policyRulesAuxContainedSet.................43 121 6. Extending the Core Schema........................................43 122 6.1. Subclassing policyConditionAuxClass and policyActionAuxClass43 123 6.2. Using the Vendor Policy Encoding Attributes.................44 124 6.3. Using Time Validity Periods.................................44 125 7. Security Considerations..........................................44 126 8. Intellectual Property............................................46 127 9. Acknowledgments..................................................47 128 10. References......................................................47 129 11. Authors' Addresses..............................................48 130 12. Full Copyright Statement........................................49 131 13. Appendix: Constructing the Value of orderedCimKeys.............49 133 1. Introduction 135 This document takes as its starting point the object-oriented 136 information model for representing policy information currently under 137 joint development in the Service Level Agreements working group of the 138 Distributed Management Task Force (DMTF) and in the IETF's Policy 139 Framework working group. The IETF document defining this information 140 model is the "Policy Core Information Model -- Version 1 141 Specification" [1]. This model defines two hierarchies of object 142 classes: structural classes representing policy information and 143 control of policies, and relationship classes that indicate how 144 instances of the structural classes are related to each other. In 145 general, both of these class hierarchies will need to be mapped to a 146 particular data store. 148 This draft defines the mapping of these information model classes to a 149 directory that uses LDAPv3 as its access protocol. Two types of 150 mappings are involved: 152 o For the structural classes in the information model, the mapping is 153 basically one-for-one: information model classes map to LDAP 154 classes, information model properties map to LDAP attributes. 156 o For the relationship classes in the information model, different 157 mappings are possible. In this document the information model's 158 relationship classes and their properties are mapped in three ways: 159 to LDAP auxiliary classes, to attributes representing DN pointers, 160 and to containment in the Directory Information Tree (DIT). 162 Implementations that use an LDAP directory as their policy repository 163 SHALL use the LDAP policy schema defined in this document. The use of 164 the information model defined in reference [1] as the starting point 165 enables the schema and the relationship class hierarchy to be 166 extensible, such that other types of policy repositories, such as 167 relational databases, can also use this information. 169 This document fits into the overall framework for representing, 170 deploying, and managing policies being developed by the Policy 171 Framework Working Group. It traces its origins to work that was 172 originally done for the Directory-enabled Networks (DEN) 173 specification, reference [5]. Work on the DEN specification by the 174 DEN Ad-Hoc Working Group itself has been completed. Further work to 175 standardize the models contained in it will be the responsibility of 176 selected working groups of the Common Information Model (CIM) effort 177 in the Distributed Management Task Force (DMTF). DMTF standardization 178 of the core policy model is the responsibility of the SLA Policy 179 working group in the DMTF. 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in RFC 2119, reference 184 [3]. 186 2. The Policy Core Information Model 188 This document contains an LDAP schema representing the Policy Core 189 Information Model (abbreviated "PCIM"), which is defined in the 190 companion document "Policy Core Information Model -- Version 1 191 Specification" [1]. Other documents may subsequently be produced, 192 with mappings of this same PCIM to other storage technologies. Since 193 the detailed semantics of the Core Policy classes appear only in 194 reference [1], that document is a prerequisite for reading and 195 understanding this document. 197 3. Inheritance Hierarchy for the LDAP Core Policy Schema 199 The following diagram illustrates the class hierarchy for the LDAP 200 Core Policy Schema classes: 202 top 203 | 204 +--dlm1ManagedElement (abstract) 205 | | 206 | +--policy (abstract) 207 | | | 208 | | +--policyGroup (structural) 209 | | | 210 | | +--policyRule (structural) 211 | | | 212 | | +--policyRuleConditionAssociation (structural) 213 | | | 214 | | +--policyRuleActionAssociation (structural) 215 | | | 216 | | +--policyInstance (structural) 217 | | | | 218 | | | +--policyConditionInstance (structural) 219 | | | | 220 | | | +--policyActionInstance (structural) 221 | | | 222 | | +--policyElementAuxClass (auxiliary) 223 | | 224 | +--dlm1ManagedSystemElement (abstract) 225 | | 226 | +--dlm1LogicalElement (abstract) 227 | | 228 | +--dlm1System (abstract) 229 | | 230 | +--dlm1AdminDomain (abstract) 231 | | 232 | +--policyRepository (structural) 233 | 234 +--policyConditionAuxClass (auxiliary) 235 | | 236 | +---policyTimePeriodConditionAuxClass (auxiliary) 237 | | 238 | +---vendorPolicyConditionAuxClass (auxiliary) 239 | 240 +--policyActionAuxClass (auxiliary) 241 | | 242 | +---vendorPolicyActionAuxClass (auxiliary) 243 | 244 +--policySubtreesPtrAuxClass (auxiliary) 245 | 246 +--policyGroupContainmentAuxClass (auxiliary) 247 | 248 +--policyRuleContainmentAuxClass (auxiliary) 250 Figure 1. LDAP Class Inheritance Hierarchy for the Core Policy 251 Schema 252 4. General Discussion of Mapping the Information Model to LDAP 254 The classes described in Section 5 below contain certain optimizations 255 for a directory that uses LDAP as its access protocol. One example of 256 this is the use of auxiliary classes to represent some of the 257 associations defined in the information model. Other data stores 258 might need to implement these associations differently. A second 259 example is the introduction of classes specifically designed to 260 optimize retrieval of large amounts of policy-related data from a 261 directory. This section discusses some general topics related to the 262 mapping from the information model to LDAP. 264 4.1. Summary of Class and Association Mappings 266 Nine of the classes in the LDAP Core Policy Schema come directly from 267 corresponding classes in the information model. Note that names of 268 classes begin with an upper case character in the information model 269 (although for CIM in particular, case is not significant in class and 270 property names), but with a lower case character in LDAP. 272 +---------------------------+-----------------------------------+ 273 | Information Model | LDAP Class | 274 +---------------------------+-----------------------------------+ 275 +---------------------------+-----------------------------------+ 276 | Policy | policy | 277 +---------------------------+-----------------------------------+ 278 | PolicyGroup | policyGroup | 279 +---------------------------+-----------------------------------+ 280 | PolicyRule | policyRule | 281 +---------------------------+-----------------------------------+ 282 | PolicyCondition | policyConditionAuxClass | 283 +---------------------------+-----------------------------------+ 284 | PolicyAction | policyActionAuxClass | 285 +---------------------------+-----------------------------------+ 286 | VendorPolicyCondition | vendorPolicyConditionAuxClass | 287 +---------------------------+-----------------------------------+ 288 | VendorPolicyAction | vendorPolicyActionAuxClass | 289 +---------------------------+-----------------------------------+ 290 | PolicyTimePeriodCondition | policyTimePeriodConditionAuxClass | 291 +---------------------------+-----------------------------------+ 292 | PolicyRepository | policyRepository | 293 +---------------------------+-----------------------------------+ 294 Figure 2. Mapping of Information Model Classes to LDAP 296 The associations in the information model map to DN-pointer attributes 297 or to Directory Information Tree (DIT) containment in LDAP. Two of 298 the DN-pointer attributes appear in auxiliary classes, which allow 299 each of them to represent several relationships from the information 300 model. 302 +-----------------------------------+--------------------------------+ 303 | Information Model Association | LDAP Attribute / Class | 304 +-----------------------------------+--------------------------------+ 305 +-----------------------------------+--------------------------------+ 306 | PolicyGroupInPolicyGroup | policyGroupsAuxContainedSet in | 307 | | policyGroupContainmentAuxClass| 308 +-----------------------------------+--------------------------------+ 309 | PolicyRuleInPolicyGroup | policyRulesAuxContainedSet in | 310 | | policyRuleContainmentAuxClass | 311 +-----------------------------------+--------------------------------+ 312 | PolicyConditionInPolicyRule | DIT containment + | 313 | | policyRuleConditionList in | 314 | | policyRule + | 315 | | policyConditionDN in | 316 | | policyRuleConditionAssociation| 317 +-----------------------------------+--------------------------------+ 318 | PolicyActionInPolicyRule | DIT containment + | 319 | | policyRuleActionList in | 320 | | policyRule + | 321 | | policyActionDN in | 322 | | policyRuleActionAssociation | 323 +-----------------------------------+--------------------------------+ 324 | PolicyRuleValidityPeriod | policyRuleValidityPeriodList in| 325 | | policyRule | 326 +-----------------------------------+--------------------------------+ 327 | PolicyConditionInPolicyRepository | DIT containment | 328 +-----------------------------------+--------------------------------+ 329 | PolicyActionInPolicyRepository | DIT containment | 330 +-----------------------------------+--------------------------------+ 331 | PolicyRepositoryInPolicyRepository| DIT containment | 332 +-----------------------------------+--------------------------------+ 333 Figure 3. Mapping of Information Model Associations to LDAP 335 Of the remaining classes in the LDAP Core Schema, two 336 (policyElementAuxClass and policySubtreesPtrAuxClass) are included to 337 make navigation through the DIT and retrieval of the entries found 338 there more efficient. This topic is discussed in Section 4.4 below. 340 The remaining five classes in the LDAP Core Schema, 341 policyRuleConditionAssociation, policyRuleActionAssociation, 342 policyInstance, policyConditionInstance, and policyActionInstance are 343 all involved with the representation of policy conditions and policy 344 actions in an LDAP directory. This topic is discussed in Section 4.3 345 below. 347 4.2. Naming Attributes in the Core Schema 349 Instances in a directory are identified by distinguished names (DNs), 350 which provide the same type of hierarchical organization that a file 351 system provides in a computer system. A distinguished name is a 352 sequence of relative distinguished names (RDNs), where an RDN provides 353 a unique identifier for an instance within the context of its 354 immediate superior, in the same way that a filename provides a unique 355 identifier for a file within the context of the folder in which it 356 resides. 358 To preserve maximum naming flexibility for policy administrators, each 359 of the structural classes defined in this schema has its own naming 360 attribute. (The naming attribute policyConditionName is used in two 361 structural class: policyRuleConditionAssociation and 362 policyConditionInstance. As discussed below in Section 4.3, these are 363 two of the structural classes to which the auxiliary class 364 policyConditionAuxClass may be attached. The naming attribute 365 policyActionName is similarly associated with two structural classes.) 366 Since the naming attributes are different, a policy administrator can, 367 by using these attributes, guarantee that there will be no name 368 collisions between instances of different classes, even if the same 369 value is assigned to the instances' respective naming attributes. 371 The X.500 attribute commonName (cn) is included as a MAY attribute in 372 the abstract class policy, and thus by inheritance in all of its 373 subclasses. In X.500, commonName typically functions as an RDN 374 attribute, for naming instances of such classes as X.500's person. 376 Finally, for implementations that expect to map between native CIM and 377 LDAP representations of policy information, a second MAY attribute, 378 orderedCimKeys, is inherited from the class dlm1ManagedElement, 379 defined in reference [10], into the abstract class "policy". The 380 value of this attribute is derived algorithmically from values that 381 are already present in a CIM policy instance. See the appendix of 382 this document for a complete description of the algorithm. 384 Each of the Core Schema classes thus has three attributes suitable for 385 naming: cn, its own class-specific attribute, and orderedCimKeys. 386 Any of these attributes MAY be used for naming an instance of a Core 387 Schema class. Consequently, implementations MUST be able to 388 accommodate instances named in any of these ways. 390 Note that since they are required ("MUST") attributes, the class- 391 specific naming attributes are always present in instances of their 392 respective classes, even if they are not being used for naming the 393 instances. In these cases the class-specific naming attributes may be 394 used for other purposes. Note also that "cn", the class-specific 395 naming attribute, and orderedCimKeys SHOULD NOT be used together to 396 form a multi-part RDN, since support for multi-part RDNs is limited 397 among existing directory implementations. 399 4.3. Rule-Specific and Reusable Conditions and Actions 401 The PCIM [1] distinguishes between two types of policy conditions and 402 policy actions: ones associated with a single policy rule, and ones 403 that are reusable, in the sense that they may be associated with more 404 than one policy rule. There is no inherent difference between a rule- 405 specific condition or action and a reusable one. There are, however, 406 differences in how they are treated in a policy repository. For 407 example, it's natural to make the access permissions for a rule- 408 specific condition or action identical to those for the rule itself. 409 It's also natural for a rule-specific condition or action to be 410 removed from the policy repository at the same time the rule is. With 411 reusable conditions and actions, on the other hand, access permissions 412 and existence criteria must be expressible without reference to a 413 policy rule. 415 The preceding paragraph does not contain an exhaustive list of the 416 ways in which reusable and rule-specific conditions should be treated 417 differently. Its purpose is merely to justify making a semantic 418 distinction between rule-specific and reusable, and then reflecting 419 this distinction in the policy repository itself. 421 When the policy repository is realized in an LDAP-accessible 422 directory, the distinction between rule-specific and reusable 423 conditions and actions is realized via placement of auxiliary classes 424 and via DIT containment. Figure 4 illustrates a policy rule Rule1 425 with one rule-specific condition CA and one rule-specific action AB. 426 Because the condition and action are specific to Rule1, the auxiliary 427 classes ca and ab that represent them are attached, respectively, to 428 the structural classes CA and AB. These structural classes represent 429 not the condition ca and action ab themselves, but rather the 430 associations between Rule1 and ca, and between Rule1 and ab. 432 As Figure 4 illustrates, Rule1 contains DN pointers to the structural 433 classes CA and AB that appear below it in the DIT. At first glance it 434 might appear that these DN pointers are unnecessary, since a subtree 435 search below Rule1 would find all of the structural classes 436 representing the associations between Rule1 and its conditions and 437 actions. Relying only on a subtree search, though, runs the risk of 438 missing conditions or actions that should have appeared in the 439 subtree, but for some reason did not, or of finding conditions or 440 actions that were inadvertently placed in the subtree, or that should 441 have been removed from the subtree, but for some reason were not. 442 With the use of DN pointers, many (but not all) of these risks are 443 eliminated. 445 Note that the existence dependency of a rule-specific condition or 446 action on its policy rule follows in this case from the semantics of 447 DNs. Note also that for directory implementations supporting subtree- 448 based access permissions, it's easy to indicate that parties with 449 access to Rule1 also have access to its condition and action. 451 +-----+ 452 |Rule1| 453 | | 454 +-----|- -|-----+ 455 | +-----+ | 456 | * * | 457 | * * | 458 | **** **** | 459 | * * | 460 v * * v 461 +--------+ +--------+ 462 | CA+ca | | AB+ab | 463 +--------+ +--------+ 465 +------------------------------+ 466 |LEGEND: | 467 | ***** DIT containment | 468 | + auxiliary attachment | 469 | ----> DN pointer | 470 +------------------------------+ 472 Figure 4. Rule-Specific Policy Conditions and Actions 474 Figure 5 illustrates a second way of representing rule-specific 475 conditions and actions in an LDAP-accessible directory: attachment of 476 the auxiliary classes directly to the instance representing the policy 477 rule. When conditions and actions are attached to a policy rule in 478 this way, the rule is termed a "simple" policy rule. When conditions 479 and actions are not attached directly to a policy rule, the rule is 480 termed "complex". 482 The simple/complex distinction for a policy rule is not all or 483 nothing. A policy rule may have its conditions attached to itself and 484 its actions attached to other entries, or it may have its actions 485 attached to itself and its conditions attached to other entries. 486 However, it SHALL NOT have either its conditions or its actions 487 attached both to itself and to other entries, with one exception: a 488 policy rule may point to its validity periods with the 489 policyRuleValidityPeriodList attribute, but have its other conditions 490 attached to itself. 492 The tradeoffs between simple and complex policy rules are between the 493 efficiency of simple rules and the flexibility and greater potential 494 for reuse of complex rules. With a simple policy rule, the semantic 495 options are limited: 497 o All conditions are ANDed together. This combination can be 498 represented in two ways in the DNF / CNF expressions 499 characteristic of policy conditions: as a DNF expression with a 500 single AND group, or as a CNF expression with multiple single- 501 condition OR groups. The first of these is arbitrarily chosen as 502 the representation for the ANDed conditions in a simple policy 503 rule. 505 o If multiple actions are included, no order can be specified for 506 them. 508 If a policy administrator needs to combine conditions in some other 509 way, or if there is a set of actions that must be ordered, then the 510 only option is to use a complex policy rule. 512 +-----------+ 513 |Rule1+ca+ab| 514 | | 515 +-----------+ 517 +------------------------------+ 518 |LEGEND: | 519 | + auxiliary attachment | 520 +------------------------------+ 522 Figure 5. A Simple Policy Rule 524 Finally, Figure 6 illustrates the same policy rule Rule1, but this 525 time its condition and action are reusable. The association classes 526 CA and AB are still present, and they are still DIT contained under 527 Rule1. But rather than having the auxiliary classes ca and ab 528 attached to themselves, CA and AB now contain DN pointers to other 529 entries to which these auxiliary classes are attached. These other 530 entries, CIA and AIB, are DIT contained under RepositoryX, which is an 531 instance of the class policyRepository. Because they are named under 532 an instance of policyRepository, ca and ab are clearly identified as 533 reusable. 535 The structural classes CIA and AIB in Figure 6 may either be instances 536 of the generic class policyInstance (defined in Section 5.11), or, 537 respectively, instances of the classes policyConditionInstance 538 (Section 5.12) and policyActionInstance (Section 5.13). 540 +-----+ +-------------+ 541 |Rule1| | RepositoryX | 542 +-|- -|--+ | | 543 | +-----+ | +-------------+ 544 | * * | * * 545 | * * | * * 546 | *** **** | * * 547 | * * v * * 548 | * +---+ * * 549 | * |AB | +------+ * 550 v * | -|-------->|AIB+ab| * 551 +---+ +---+ +------+ * 552 |CA | +------+ 553 | -|------------------------>|CIA+ca| 554 +---+ +------+ 556 +------------------------------+ 557 |LEGEND: | 558 | ***** DIT containment | 559 | + auxiliary attachment | 560 | ----> DN pointer | 561 +------------------------------+ 563 Figure 6. Reusable Policy Conditions and Actions 565 The classes policyConditionAuxClass and policyActionAuxClass do not 566 themselves represent actual conditions and actions: these are 567 introduced in their subclasses. What policyConditionAuxClass and 568 policyActionAuxClass do introduce are the semantics of being a policy 569 condition or a policy action. These are the semantics that all the 570 subclasses of policyConditionAuxClass and policyActionAuxClass 571 inherit. Among these semantics are those of representing either a 572 rule-specific or a reusable policy condition or policy action. 574 In order to preserve the ability to represent a rule-specific or a 575 reusable condition or action, as well as a simple policy rule, all the 576 subclasses of policyConditionAuxClass and policyActionAuxClass MUST 577 also be auxiliary classes. 579 4.4. Location and Retrieval of Policy Objects in the Directory 581 When a PDP goes to an LDAP directory to retrieve the policy object 582 instances relevant to the PEPs it serves, it is faced with two related 583 problems: 585 o How does it locate and retrieve the directory entries that apply to 586 its PEPs? These entries may include instances of the Core Schema 587 classes, instances of domain-specific subclasses of these classes, 588 and instances of other classes modeling such resources as user 589 groups, interfaces, and address ranges. 591 o How does it retrieve the directory entries it needs in an efficient 592 manner, so that retrieval of policy information from the directory 593 does not become a roadblock to scalability? There are two facets 594 to this efficiency: retrieving only the relevant directory 595 entries, and retrieving these entries using as few LDAP calls as 596 possible. 598 The placement of objects in the Directory Information Tree (DIT) 599 involves considerations other than how the policy-related objects will 600 be retrieved by a PDP. Consequently, all that the Core Schema can do 601 is to provide a "toolkit" of classes to assist the policy 602 administrator as the DIT is being designed and built. A PDP SHOULD be 603 able to take advantage of any tools that the policy administrator is 604 able to build into the DIT, but it MUST be able to use a less 605 efficient means of retrieval if that is all it has available to it. 607 The basic idea behind the LDAP optimization classes is a simple one: 608 make it possible for a PDP to retrieve all the policy-related objects 609 it needs, and only those objects, using as few LDAP calls as possible. 610 An important assumption underlying this approach is that the policy 611 administrator has sufficient control over the underlying DIT structure 612 to define subtrees for storing policy information. If the policy 613 administrator does not have this level of control over DIT structure, 614 a PDP can still retrieve the policy-related objects it needs 615 individually. But it will require more LDAP access operations to do 616 the retrieval in this way. 618 Figure 7 illustrates how LDAP optimization is accomplished. 620 +-----+ 621 ---------------->| A | 622 DN pointer to | | DN pointers to subtrees +---+ 623 starting object +-----+ +------------------------->| C | 624 | o--+----+ +---+ +---+ 625 | o--+------------->| B | / \ 626 +-----+ +---+ / \ 627 / \ / \ / ... \ 628 / \ / \ 629 / \ / ... \ 631 Figure 7. Using policySubtreesPtrAuxClass to Locate Policies 633 The PDP is configured initially with a DN pointer to some entry in the 634 DIT. The structural class of this entry is not important; the PDP is 635 interested only in the policySubtreesPtrAuxClass attached to it. This 636 auxiliary class contains a multi-valued attribute with DN pointers to 637 objects that anchor subtrees containing policy-related objects of 638 interest to the PDP. Since policySubtreesPtrAuxClass is an auxiliary 639 class, it can be attached to an entry that the PDP would need to 640 access anyway - perhaps an entry containing initial configuration 641 settings for the PDP, or for a PEP that uses the PDP. 643 Once it has retrieved the DN pointers, the PDP will direct to each of 644 the objects identified by them an LDAP request that all entries in its 645 subtree be evaluated against the selection criteria specified in the 646 request. The LDAP-enabled directory then returns all entries in that 647 subtree that satisfy the specified criteria. 649 The selection criteria always specify that object class = "policy". 650 Since all classes representing policy rules, policy conditions, and 651 policy actions, both in the Core Schema and in any domain-specific 652 schema derived from it, are subclasses of the abstract class policy, 653 this criterion evaluates to TRUE for all instances of these classes. 654 To accommodate special cases where a PDP needs to retrieve objects 655 that are not inherently policy-related (for example, an IP address 656 range object pointed to by a subclass of policyActionAuxClass 657 representing the DHCP action "assign from this address range), the 658 auxiliary class policyElementAuxClass can be used to "tag" an entry, 659 so that it will be found by the selection criterion "object class = 660 policy". 662 The approach described in the preceding paragraph will not work for 663 certain directory implementations, because these implementations do 664 not support matching of auxiliary classes in the objectClass 665 attribute. For environments where these implementations are expected 666 to be present, the "tagging" of entries as relevant to policy can be 667 accomplished by inserting the special value "POLICY" into the list of 668 values contained in the policyKeywords attribute. 670 If a PDP needs only a subset of the policy-related objects in the 671 indicated subtrees, then it can be configured with additional 672 selection criteria based on the policyKeywords attribute defined in 673 the policy class. This attribute supports both standardized and 674 administrator-defined values. Thus a PDP could be configured to 675 request only those policy-related objects containing the keywords 676 "DHCP" and "Eastern US". 678 To optimize what is expected to be a typical case, the initial request 679 from the client includes not only the object to which its "seed" DN 680 pointer points, but also the subtree contained under this object. The 681 filter for searching this subtree is whatever the client is going to 682 use later to search the other subtrees: "object class = policy", 683 presence of the keyword "POLICY", or presence of a more specific 684 policyKeyword. 686 Returning to the example in Figure 7, we see that in the best case, a 687 PDP can get all the policy-related objects it needs, and only these 688 objects, with exactly three LDAP requests: one to its starting object 689 A to get the pointers to B and C, as well as the policy-related 690 objects it needs from the subtree under A, and then one each to B and 691 C to get all the policy-related objects that pass the selection 692 criteria with which it was configured. Once it has retrieved all of 693 these objects, the PDP can then traverse their various DN pointers 694 locally to understand the semantic relationships among them. The PDP 695 should also be prepared to find a pointer to another subtree attached 696 to any of the objects it retrieves, and to follow this pointer first, 697 before it follows any of the semantically significant pointers it has 698 received. This recursion permits a structured approach to identifying 699 related policies. In Figure 7, for example, if the subtree under B 700 includes departmental policies and the one under C includes divisional 701 policies, then there might be a pointer from the subtree under C to an 702 object D that roots the subtree of corporate-level policies. 704 Since a PDP has no guarantee that the entity that populates the 705 directory won't use the policySubtreesPtrAuxClass, a PDP SHOULD 706 understand this class, SHOULD be capable of retrieving and processing 707 the entries in the subtrees it points to, and SHOULD be capable of 708 doing all of this recursively. The same requirements apply to any 709 other entity needing to retrieve policy information from the 710 directory. Thus a Policy Management Tool that retrieves policy 711 entries from the directory in order to perform validation and conflict 712 detection SHOULD also understand and be capable of using the 713 policySubtreesPtrAuxClass. All of these requirements are "SHOULD"s 714 rather than "MUST"s because an LDAP client that doesn't implement them 715 can still access and retrieve the directory entries it needs . The 716 process of doing so will just be less efficient than it would have 717 been if the client had implemented these optimizations. 719 When it is serving as a tool for creating policy entries in the 720 directory, a Policy Management Tool SHOULD support creation of 721 policySubtreesPtrAuxClass entries and their DN pointers. 723 4.4.1. Aliases and Other DIT-Optimization Techniques 725 Additional flexibility in DIT structure is available to the policy 726 administrator via LDAP aliasing. Figure 8 illustrates this 727 flexibility. 729 +-----+ 730 ---------------->| A | 731 DN pointer to | | DN pointers to subtrees +---+ 732 starting object +-----+ +------------------------->| C | 733 | o--+----+ +---+ +---+ 734 | o--+------------->| B | / \ 735 +-----+ +---+ / \ 736 / \ / \ / ... \ 737 / \ / \ 738 / \ / \ 739 +---+ / +------+ \ 740 | X |<***************************|aliasX| 741 +---+ +------+ 743 Figure 8. Addition of an Alias Object 745 Even if it is necessary to store a policy entry X in a directory 746 location separate from the other policy entries, batch retrieval using 747 policy subtrees can still be done. The administrator simply inserts 748 into one of the subtrees of policy entries an alias entry aliasX 749 pointing to the outlying entry X. When the PDP requests all entries 750 in the subtree under B, a response will be returned for entry X, just 751 as responses are returned for all the (non-alias) entries that 752 actually are in the subtree. 754 Since resolution of an alias to its true entry is handled entirely by 755 the LDAP directory, and is invisible to directory clients, PDPs need 756 not do anything extra to support aliases. A Policy Management Tool 757 MAY make available to a policy administrator the ability to create 758 alias entries like the one in Figure 7. 760 In addition to aliases, there are several other techniques for 761 managing the placement of entries in the DIT and their retrieval by 762 directory clients. Among these other techniques are referrals, LDAP 763 URLs, and attributes like seeAlso. Discussion of how these other 764 techniques might be applied to policy-related entries in a directory 765 is outside the scope of this document. 767 5. Class Definitions 769 The semantics for the LDAP classes mapped directly from the 770 information model are detailed in reference [1]. Consequently, all 771 that this document presents for these classes is a bare specification 772 of the LDAP classes and attributes. More details are provided for the 773 attributes listed above in Figure 3, which realize in LDAP the 774 relationships defined in the information model. Finally, the classes 775 that exist only in the LDAP Core Schema are documented fully in this 776 document. 778 The formal language for specifying the classes, attributes, and DIT 779 structure and content rules is that defined in reference [2]. 781 Note: all attribute, object class, and name form OIDs, and all 782 structure rule integers, are place holders, and syntax OIDs in 783 definitions have been replaced by names for clarity. 785 5.1. The Abstract Class "policy" 787 The abstract class "policy" is a direct mapping of the abstract class 788 Policy from the Core Information Model. The five properties in 789 Policy, three of which are inherited from the class 790 dlm1ManagedElement, map directly to attributes in the class "policy". 791 See reference [10] for the definition of the LDAP class 792 dlm1ManagedElement. 794 The class value "policy" is also used as the mechanism for identifying 795 policy-related instances in the Directory Information Tree. An 796 instance of any class may be "tagged" with this class value by 797 attaching to it the auxiliary class policyElementAuxClass. 799 The class definition is as follows: 801 ( NAME 'policy' 802 DESC 'An abstract class with five attributes for describing 803 a policy-related instance. The attributes cimCaption, 804 cimDescription, and orderedCimKeys are inherited from 805 dlm1ManagedElement.' 806 SUP dlm1ManagedElement 807 ABSTRACT 808 MAY ( cn $ policyKeywords ) 809 ) 811 The three attributes cimCaption, cimDescription, and orderedCimKeys 812 are defined in reference [10]. The attribute "cn" is defined in 813 X.520. The remaining attribute, policyKeywords, is defined as 814 follows: 816 ( NAME 'policyKeywords' 817 DESC 'A set of keywords to assist directory clients in 818 locating the policy objects applicable to them. Each 819 value of the multi-valued attribute contains a single 820 keyword. Standard keyword values are listed in the 821 Policy Core Information Model document. 823 This value is a Directory String.' 824 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 825 EQUALITY caseIgnoreMatch 826 ) 828 5.2. The Class policyGroup 830 The class definition for policyGroup is as follows. Note that this 831 class definition does not include attributes to realize the 832 PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from 833 the object model, since a policyGroup object points to instances of 834 policyGroup and policyRule via, respectively, the pointer in 835 policyGroupContainmentAuxClass and the pointer in 836 policyRuleContainmentAuxClass. 838 ( NAME 'policyGroup' 839 DESC 'A container for either a set of related policyRules or 840 a set of related policyGroups.' 841 SUP policy 842 MUST ( policyGroupName ) 843 ) 845 The following DIT content rule indicates that an instance of 846 policyGroup may have attached to it either DN pointers to one or more 847 other policyGroups, or DN pointers to one or more policyRules. 849 ( 850 NAME 'policyGroupContentRule' 851 DESC 'shows what auxiliary classes go with this object' 852 AUX ( policyGroupContainmentAuxClass $ 853 policyRuleContainmentAuxClass ) 854 ) 856 The following DIT structure rules indicate that an instance of 857 policyGroup may be named under any superior, using any of its three 858 naming attributes. 860 NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule 861 are named within the scope of ("are weak to" in the CIM jargon) an 862 instance of the CIM class System, or one of its subclasses. The most 863 natural way to map a weak relationship of this type is to map it to 864 DIT structure rules specifying that an instance of policyGroup or 865 policyRule is subordinate to an object representing a CIM System. 866 Since, however, the mapping of CIM's System class to an LDAP class 867 falls outside the scope of this document, the DIT structure rules that 868 follow do not constrain the superiors under which an instance of 869 PolicyGroup may be named. 871 ( NAME 'policyGroupNameForm1' 872 OC policyGroup 873 MUST ( cn ) 874 ) 876 ( NAME 'policyGroupStructuralRule1' 877 FORM policyGroupNameForm1 878 ) 880 ( NAME 'policyGroupNameForm2' 881 OC policyGroup 882 MUST ( policyGroupName ) 883 ) 885 ( NAME 'policyGroupStructuralRule2' 886 FORM policyGroupNameForm2 887 ) 889 ( NAME 'policyGroupNameForm3' 890 OC policyGroup 891 MUST ( orderedCimKeys ) 892 ) 894 ( NAME 'policyGroupStructuralRule3' 895 FORM policyGroupNameForm3 896 ) 898 The one attribute of policyGroup is defined as: 900 ( NAME 'policyGroupName' 901 DESC 'The user-friendly name of this policy group. 903 This value is a Directory String.' 904 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 905 EQUALITY caseIgnoreMatch 906 SINGLE-VALUE 907 ) 909 5.3. The Class policyRule 911 This class represents the "If Condition then Action" semantics 912 associated with a policy. The conditions and actions associated with 913 a policy rule are modeled, respectively, with auxiliary subclasses of 914 the auxiliary classes policyConditionAuxClass and 915 policyActionAuxClass. Each of these auxiliary subclasses is attached 916 to an instance of one of two structural classes. A subclass of 917 policyConditionAuxClass is attached either to an instance of 918 policyRuleConditionAssociation or to an instance of 919 policyConditionInstance. Similarly, a subclass of 920 policyActionAuxClass is attached either to an instance of 921 policyRuleActionAssociation or to an instance of policyActionInstance. 923 Of the nine attributes in the policyRule class, eight are mapped 924 directly from corresponding properties in the information model. The 925 ninth attribute, policyRuleValidityPeriodList, realizes the 926 PolicyRuleValidityPeriod association from the information model. 927 Since this association has no "extra" properties (besides those that 928 tie the association to its associated objects), the attribute 929 policyRuleValidityPeriodList is simply a multi-valued DN pointer. 930 (Relationships in the information model can have "extra" properties 931 because CIM represents relationships as classes. See Sections 5.4 and 932 5.5 for examples of "extra" properties and how they are mapped to 933 LDAP.) This attribute provides an unordered set of DN pointers to one 934 or more instances of the policyTimePeriodConditionAuxClass, indicating 935 when the policy rule is scheduled to be active and when it is 936 scheduled to be inactive. A policy rule is scheduled to be active if 937 it is active according to AT LEAST ONE of the 938 policyTimePeriodConditionAuxClass instances pointed to by this 939 attribute. 941 The PolicyConditionInPolicyRule and PolicyActionInPolicyRule 942 associations, however, have additional properties: 943 PolicyActionInPolicyRule has an integer to sequence the actions, and 944 PolicyConditionInPolicyRule has an integer to group the conditions, 945 and a Boolean to specify whether a condition is to be negated. In the 946 Core Schema, these extra association properties are represented as 947 attributes of two classes introduced specifically to model the 948 associations: policyRuleConditionAssociation and 949 policyRuleActionAssociation, defined, respectively, in Sections 5.4 950 and 5.5. Thus they do not appear as attributes of the class 951 policyRule. 953 The class definition of policyRule is as follows: 955 ( NAME 'policyRule' 956 DESC 'The central class for representing the "If Condition 957 then Action" semantics associated with a policy rule.' 958 SUP policy 959 MUST ( policyRuleName ) 960 MAY ( policyRuleEnabled $ policyRuleConditionListType $ 961 policyRuleConditionList $ policyRuleActionList $ 962 policyRuleValidityPeriodList $ policyRuleUsage $ 963 policyRulePriority $ policyRuleMandatory $ 964 policyRuleSequencedActions $ policyRoles ) 965 ) 967 The following DIT content rule indicates that an instance of 968 policyRule may have attached to it the auxiliary classes 969 policyConditionAuxClass and policyActionAuxClass, or one of their 970 subclasses. This combination represents a simple policy rule. 972 ( 973 NAME 'policyRuleContentRule' 974 DESC 'shows what auxiliary classes go with this object' 975 AUX ( policyConditionAuxClass $ policyActionAuxClass ) 976 ) 978 The following DIT structure rules indicate that an instance of 979 policyRule may be named under any superior, using any of its three 980 naming attributes. 982 NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule 983 are named within the scope of ("are weak to" in the CIM jargon) an 984 instance of the CIM class System, or one of its subclasses. The most 985 natural way to map a weak relationship of this type is to DIT 986 structure rules specifying that an instance of policyGroup or 987 policyRule is subordinate to an object representing a CIM System. 988 Since, however, the mapping of CIM's System class to an LDAP class 989 falls outside the scope of this document, the DIT structure rules that 990 follow do not constrain the superiors under which an instance of 991 PolicyRule may be named. 993 ( NAME 'policyRuleNameForm1' 994 OC policyRule 995 MUST ( cn ) 996 ) 998 ( NAME 'policyRuleStructuralRule1' 999 FORM policyRuleNameForm1 1000 ) 1002 ( NAME 'policyRuleNameForm2' 1003 OC policyRule 1004 MUST ( policyRuleName ) 1005 ) 1006 ( NAME 'policyRuleStructuralRule2' 1007 FORM policyRuleNameForm2 1008 ) 1009 ( NAME 'policyRuleNameForm3' 1010 OC policyRule 1011 MUST ( orderedCimKeys ) 1012 ) 1014 ( NAME 'policyRuleStructuralRule3' 1015 FORM policyRuleNameForm3 1016 ) 1018 The attributes of policyRule are defined as follows: 1020 ( NAME 'policyRuleName' 1021 DESC 'The user-friendly name of this policy rule. 1023 This value is a Directory String' 1024 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1025 EQUALITY caseIgnoreMatch 1026 SINGLE-VALUE 1027 ) 1029 ( NAME 'policyRuleEnabled' 1030 DESC 'An enumeration indicating whether a policy rule is 1031 administratively enabled, administratively disabled, or 1032 enabled for debug mode. The defined values for this 1033 attribute are enabled(1), disabled(2), and 1034 enabledForDebug(3). 1036 This value is an INTEGER enumeration.' 1037 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1038 EQUALITY integerMatch 1039 SINGLE-VALUE 1040 ) 1042 ( NAME 'policyRuleConditionListType' 1043 DESC 'Indicates whether the list of policy conditions 1044 associated with this policy rule is in disjunctive 1045 normal form (DNF) or conjunctive normal form (CNF). 1046 Defined values are DNF(1) and CNF(2). 1048 This value is an INTEGER enumeration.' 1049 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1050 EQUALITY integerMatch 1051 SINGLE-VALUE 1052 ) 1054 ( NAME 'policyRuleConditionList' 1055 DESC 'Distinguished names of policyRuleConditionAssociation 1056 entries representing associations between this policy 1057 rule and its conditions. No order is implied. 1059 This value is a Distinguished Name (DN).' 1060 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1061 EQUALITY distinguishedNameMatch 1062 ) 1064 ( NAME 'policyRuleActionList' 1065 DESC 'Distinguished names of policyRuleActionAssociation 1066 entries representing associations between this policy 1067 rule and its actions. No order is implied. 1069 This value is a Distinguished Name (DN).' 1070 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1071 EQUALITY distinguishedNameMatch 1072 ) 1074 ( NAME 'policyRuleValidityPeriodList' 1075 DESC 'Distinguished names of policyTimePeriodConditions that 1076 determine when the policyRule is scheduled to be active 1077 / inactive. No order is implied. 1079 This value is a Distinguished Name (DN).' 1080 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1081 EQUALITY distinguishedNameMatch 1082 ) 1084 ( NAME 'policyRuleUsage' 1085 DESC 'This attribute is used to provide guidelines on how 1086 this policy should be used. 1088 This value is a Directory String.' 1089 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1090 EQUALITY caseIgnoreMatch 1091 SINGLE-VALUE 1092 ) 1094 ( NAME 'policyRulePriority' 1095 DESC 'A non-negative integer for prioritizing this policyRule 1096 relative to other policyRules. A larger value indicates 1097 a higher priority. 1099 This value is an INTEGER.' 1100 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1101 EQUALITY integerMatch 1102 SINGLE-VALUE 1103 ) 1105 ( NAME 'policyRuleMandatory' 1106 DESC 'A flag indicating that the evaluation of the 1107 policyConditions and execution of policyActions (if the 1108 condition list evaluates to True) is required. 1110 This value is a Boolean.' 1111 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1112 EQUALITY booleanMatch 1113 SINGLE-VALUE 1114 ) 1116 ( NAME 'policyRuleSequencedActions' 1117 DESC 'An enumeration indicating how to interpret the action 1118 ordering indicated via the policyRuleActionList 1119 attribute. The defined values for this attribute are 1120 mandatory(1), recommended(2), and dontCare(3). 1122 This value is an INTEGER enumeration.' 1123 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1124 EQUALITY integerMatch 1125 ) 1127 ( NAME 'policyRoles' 1128 DESC 'Each value of this attribute represents a role 1129 combination, including the special case of a 1130 "combination" containing only one role. Since this 1131 is a multi-valued attribute, more than one role 1132 combination can be associated with a single policy 1133 rule. Each value is a string of the form 1135 [&&]* 1137 where the individual role names appear in alphabetical 1138 order according to the collating sequence for UCS-2. 1140 This value is a Directory String.' 1141 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1142 EQUALITY caseIgnoreMatch 1143 ) 1145 5.4. The Class policyRuleConditionAssociation 1147 This class contains attributes to represent the "extra" properties of 1148 the information model's PolicyConditionInPolicyRule association. 1149 Instances of this class are related to an instance of policyRule via 1150 DIT containment. The policy conditions themselves are represented by 1151 auxiliary subclasses of the auxiliary class policyConditionAuxClass. 1152 These auxiliary classes are attached directly to instances of 1153 policyRuleConditionAssociation for rule-specific policy conditions. 1154 For a reusable policy condition, the auxiliary class is attached to an 1155 instance of the class policyConditionInstance, and there is a DN 1156 pointer to this instance from the instance of 1157 policyRuleConditionAssociation. 1159 The class definition is as follows: 1161 ( NAME 'policyRuleConditionAssociation' 1162 DESC 'The class contains attributes characterizing the 1163 relationship between a policy rule and one of its 1164 policy conditions.' 1165 SUP policy 1166 MUST ( policyConditionGroupNumber $ policyConditionNegated $ 1167 policyConditionName ) 1168 MAY ( policyConditionDN ) 1169 ) 1171 The following DIT content rule indicates that an instance of 1172 policyRuleConditionAssociation may have attached to it the auxiliary 1173 class policyConditionAuxClass, or one of its subclasses. This 1174 combination represents a rule-specific policy condition. 1176 ( 1177 NAME 'policyRuleConditionAssociationContentRule' 1178 DESC 'shows what auxiliary classes go with this object' 1179 AUX ( policyConditionAuxClass ) 1180 ) 1182 The following DIT structure rules indicate that an instance of 1183 policyRuleConditionAssociation may be named under an instance of 1184 policyRule, where each of these instances may be named using any of 1185 their three naming attributes. 1187 ( NAME 'policyRuleConditionAssociationNameForm1' 1188 OC policyRuleConditionAssociation 1189 MUST ( cn ) 1191 ( NAME 'policyRuleConditionAssociationStructuralRule1' 1192 FORM policyRuleConditionAssociationNameForm1 1193 SUP 1194 ) 1196 ( NAME 'policyRuleConditionAssociationNameForm2' 1197 OC policyRuleConditionAssociation 1198 MUST ( policyConditionName ) 1199 ) 1201 ( NAME 'policyRuleConditionAssociationStructuralRule2' 1202 FORM policyRuleConditionAssociationNameForm2 1203 SUP 1204 ) 1205 ( NAME 'policyRuleConditionAssociationNameForm3' 1206 OC policyRuleConditionAssociation 1207 MUST ( orderedCimKeys ) 1208 ) 1210 ( NAME 'policyRuleConditionAssociationStructuralRule3' 1211 FORM policyRuleConditionAssociationNameForm3 1212 SUP 1213 ) 1215 The attributes of policyRuleConditionAssociation are defined as 1216 follows. Note that the class-specific naming attribute 1217 policyConditionName is also used in the class policyConditionInstance, 1218 where it identifies a reusable policy condition. 1220 ( 1221 NAME 'policyConditionName' 1222 DESC 'A user-friendly name for a policy condition. 1224 This value is a Directory String.' 1225 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1226 EQUALITY caseIgnoreMatch 1227 SINGLE-VALUE 1228 ) 1230 ( 1231 NAME 'policyConditionGroupNumber' 1232 DESC 'The number of the group to which a policy condition 1233 belongs. These groups are used to form the DNF or 1234 CNF expression associated with a policy rule. 1236 This value is an INTEGER.' 1237 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1238 EQUALITY integerMatch 1239 SINGLE-VALUE 1240 ) 1242 ( 1243 NAME 'policyConditionNegated' 1244 DESC 'Indicates whether a policy condition is negated in 1245 the DNF or CNF expression associated with a policy 1246 rule. The value TRUE indicates that a condition is 1247 negated 1249 This value is a Boolean.' 1250 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1251 EQUALITY booleanMatch 1252 SINGLE-VALUE 1253 ) 1255 ( 1256 NAME 'policyConditionDN' 1257 DESC 'A DN pointer to a reusable policy condition. 1259 This value is a Distinguised Name (DN).' 1260 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1261 EQUALITY distinguishedNameMatch 1262 SINGLE-VALUE 1263 ) 1264 5.5. The Class policyRuleActionAssociation 1266 This class contains an attribute to represent the one "extra" property 1267 of the information model's PolicyActionInPolicyRule association, which 1268 makes it possible to specify an order for executing the actions 1269 associated with a policy rule. Instances of this class are related to 1270 an instance of policyRule via DIT containment. The actions themselves 1271 are represented by auxiliary subclasses of the auxiliary class 1272 policyActionAuxClass. These auxiliary classes are attached directly 1273 to instances of policyRuleActionAssociation for rule-specific policy 1274 actions. For a reusable policy action, the auxiliary class is 1275 attached to an instance of the class policyActionInstance, and there 1276 is a DN pointer to this instance from the instance of 1277 policyRuleActionAssociation. 1279 The class definition is as follows: 1281 ( NAME 'policyRuleActionAssociation' 1282 DESC 'The class contains an attribute that represents an 1283 execution order for an action in the context of a 1284 policy rule.' 1285 SUP policy 1286 MUST ( policyActionOrder $ 1287 policyActionName ) 1288 MAY ( policyActionDN ) 1289 ) 1291 The following DIT content rule indicates that an instance of 1292 policyRuleActionAssociation may have attached to it the auxiliary 1293 class policyActionAuxClass, or one of its subclasses. This 1294 combination represents a rule-specific policy action. 1296 ( 1297 NAME 'policyRuleActionAssociationContentRule' 1298 DESC 'shows what auxiliary classes go with this object' 1299 AUX ( policyActionAuxClass ) 1300 ) 1302 The following DIT structure rules indicate that an instance of 1303 policyRuleActionAssociation may be named under an instance of 1304 policyRule, where each of these instances may be named using any of 1305 their three naming attributes. 1307 ( NAME 'policyRuleActionAssociationNameForm1' 1308 OC policyRuleActionAssociation 1309 MUST ( cn ) 1310 ) 1312 ( NAME 'policyRuleActionAssociationStructuralRule1' 1313 FORM policyRuleActionAssociationNameForm1 1314 SUP 1315 ) 1316 ( NAME 'policyRuleActionAssociationNameForm2' 1317 OC policyRuleActionAssociation 1318 MUST ( policyActionName ) 1319 ) 1321 ( NAME 'policyRuleActionAssociationStructuralRule2' 1322 FORM policyRuleActionAssociationNameForm2 1323 SUP 1324 ) 1326 ( NAME 'policyRuleActionAssociationNameForm3' 1327 OC policyRuleActionAssociation 1328 MUST ( orderedCimKeys ) 1329 ) 1331 ( NAME 'policyRuleActionAssociationStructuralRule3' 1332 FORM policyRuleActionAssociationNameForm3 1333 SUP 1334 ) 1336 The attributes of policyRuleActionAssociation are defined as follows. 1337 Note that the class-specific naming attribute policyActionName is also 1338 used in the class policyActionInstance, where it identifies a reusable 1339 policy action. 1341 ( 1342 NAME 'policyActionName' 1343 DESC 'A user-friendly name for a policy action. 1345 This value is a Directory String.' 1346 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1347 EQUALITY caseIgnoreMatch 1348 SINGLE-VALUE 1349 ) 1351 ( 1352 NAME 'policyActionOrder' 1353 DESC 'An integer indicating the relative order of an action 1354 in the context of a policy rule. 1356 This value is an INTEGER.' 1357 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1358 EQUALITY integerMatch 1359 SINGLE-VALUE 1360 ) 1362 ( 1363 NAME 'policyActionDN' 1364 DESC 'A DN pointer to a reusable policy action. 1366 This value is a Distinguished Name (DN).' 1367 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1368 EQUALITY distinguishedNameMatch 1369 SINGLE-VALUE 1370 ) 1372 5.6. The Auxiliary Class policyConditionAuxClass 1374 The purpose of a policy condition is to determine whether or not the 1375 set of actions (contained in the policyRule that the condition applies 1376 to) should be executed or not. This auxiliary class can be attached 1377 to instances of three other classes in the Core Policy Schema. When 1378 it is attached to an instance of policyRuleConditionAssociation, or to 1379 an instance of policyRule, it represents a rule-specific policy 1380 condition. When it is attached to an instance of 1381 policyConditionInstance, it represents a reusable policy condition. 1383 Since all of the classes to which this auxiliary class may be attached 1384 are derived from "policy", the attributes of "policy" will already be 1385 defined for the entries to which this class attaches. Thus this class 1386 is derived directly from "top". 1388 The class definition is as follows: 1390 ( NAME 'policyConditionAuxClass' 1391 DESC 'A class representing a condition to be evaluated in 1392 conjunction with a policy rule.' 1393 SUP top 1394 AUXILIARY 1395 ) 1397 5.7. The Auxiliary Class policyTimePeriodConditionAuxClass 1399 This class provides a means of representing the time periods during 1400 which a policy rule is valid, i.e., active. The class definition is 1401 as follows. 1403 ( NAME 'policyTimePeriodConditionAuxClass' 1404 DESC 'A class that provides the capability of enabling / 1405 disabling a policy rule according to a predetermined 1406 schedule.' 1407 SUP policyConditionAuxClass 1408 AUXILIARY 1409 MAY ( ptpConditionTime $ ptpConditionMonthOfYearMask $ 1410 ptpConditionDayOfMonthMask $ ptpConditionDayOfWeekMask $ 1411 ptpConditionTimeOfDayMask $ ptpConditionLocalOrUtcTime ) 1412 ) 1414 The attributes of policyTimePeriodConditionAuxClass are defined as 1415 follows. Note that several of the attributes are defined as bit 1416 strings of various fixed lengths. These attributes correspond to CIM 1417 properties that include four-octet length fields prior to their 1418 semantically significant bits. Since these length fields are 1419 unnecessary in LDAP, they are not included in the bit string 1420 attributes defined in this document. 1422 ( 1423 NAME 'ptpConditionTime' 1424 DESC 'The range of calendar dates on which a policy rule is 1425 valid. The format of the string is 1426 yyyymmddThhmmss/yyyymmddThhmmss, where the first 1427 date/time may be replaced with the string 1428 "THISANDPRIOR" or the second date/time may be replaced 1429 with the string "THISANDFUTURE". 1431 This value is a Printable String.' 1432 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1433 EQUALITY caseIgnoreMatch 1434 SINGLE-VALUE 1435 ) 1437 ( 1438 NAME 'ptpConditionMonthOfYearMask' 1439 DESC 'A mask identifying the months of the year in which a 1440 policy rule is valid. The format is a bit string of 1441 length 12, representing the months of the 1442 year from January through December.' 1443 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1444 EQUALITY bitStringMatch 1445 SINGLE-VALUE 1446 ) 1448 ( 1449 NAME 'ptpConditionDayOfMonthMask' 1450 DESC 'A mask identifying the days of the month on which a 1451 policy rule is valid. The format is a bit string of 1452 length 62. The first 31 positions represent 1453 the days of the month in ascending order, from day 1 to 1454 day 31. The next 31 positions represent the days of 1455 the month in descending order, from the last day to the 1456 day 31 days from the end.' 1457 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1458 EQUALITY bitStringMatch 1459 SINGLE-VALUE 1460 ) 1462 ( 1463 NAME 'ptpConditionDayOfWeekMask' 1464 DESC 'A mask identifying the days of the week on which a 1465 policy rule is valid. The format is a bit string of 1466 length 7, representing the days of the week 1467 from Sunday through Saturday.' 1468 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1469 EQUALITY bitStringMatch 1470 SINGLE-VALUE 1471 ) 1473 ( 1474 NAME 'ptpConditionTimeOfDayMask' 1475 DESC 'The range of times at which a policy rule is valid. If 1476 the second time is earlier than the first, then the 1477 interval spans midnight. The format of the string is 1478 Thhmmss/Thhmmss. 1480 This value is a Printable String.' 1481 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1482 EQUALITY caseIgnoreMatch 1483 ) 1485 ( 1486 NAME 'ptpConditionLocalOrUtcTime' 1487 DESC 'An indication of whether the other times in this 1488 instance represent local times or UTC times. The 1489 defined values for this attribute are localTime(1) 1490 and utcTime(2). 1492 This value is an INTEGER enumeration.' 1493 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1494 EQUALITY integerMatch 1495 SINGLE-VALUE 1496 ) 1498 5.8. The Auxiliary Class vendorPolicyConditionAuxClass 1500 The class definition is as follows: 1502 ( NAME 'vendorPolicyConditionAuxClass' 1503 DESC 'A class that defines a registered means to describe a 1504 policy condition.' 1505 SUP policyConditionAuxClass 1506 AUXILIARY 1507 MAY ( vendorPolicyConstraintData $ 1508 vendorPolicyConstraintEncoding ) 1509 ) 1511 The attribute definitions for vendorPolicyConditionAuxClass are as 1512 follows: 1514 ( 1515 NAME 'vendorPolicyConstraintData' 1516 DESC 'Escape mechanism for representing constraints that have 1517 not been modeled as specific attributes. The format of 1518 the values is identified by the OID stored in the 1519 attribute vendorPolicyConstraintEncoding. 1521 This value is an Octet String.' 1522 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1523 EQUALITY octetStringMatch 1524 ) 1526 ( 1527 NAME 'vendorPolicyConstraintEncoding' 1528 DESC 'An OID identifying the format and semantics for this 1529 instance"s vendorPolicyConstraintData attribute.' 1530 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1531 EQUALITY objectIdentifierMatch 1532 SINGLE-VALUE 1533 ) 1535 5.9. The Auxiliary Class policyActionAuxClass 1537 The purpose of a policy action is to execute one or more operations 1538 that will affect network traffic and/or systems, devices, etc. in 1539 order to achieve a desired policy state. This auxiliary class can be 1540 attached to instances of three other classes in the Core Policy 1541 Schema. When it is attached to an instance of 1542 policyRuleActionAssociation, or to an instance of policyRule, it 1543 represents a rule-specific policy action. When it is attached to an 1544 instance of policyActionInstance, it represents a reusable policy 1545 action. 1547 Since all of the classes to which this auxiliary class may be attached 1548 are derived from "policy", the attributes of "policy" will already be 1549 defined for the entries to which this class attaches. Thus this class 1550 is derived directly from "top". 1552 The class definition is as follows: 1554 ( NAME 'policyActionAuxClass' 1555 DESC 'A class representing an action to be performed as a 1556 result of a policy rule.' 1557 SUP top 1558 AUXILIARY 1559 ) 1561 5.10. The Auxiliary Class vendorPolicyActionAuxClass 1563 The class definition is as follows: 1565 ( NAME 'vendorPolicyActionAuxClass' 1566 DESC 'A class that defines a registered means to describe a 1567 policy action.' 1568 SUP policyActionAuxClass 1569 AUXILIARY 1570 MAY ( vendorPolicyActionData $ vendorPolicyActionEncoding ) 1571 ) 1572 The attribute definitions for vendorPolicyActionAuxClass are as 1573 follows: 1575 ( 1576 NAME 'vendorPolicyActionData' 1577 DESC 'Escape mechanism for representing actions that have not 1578 been modeled as specific attributes. The format of the 1579 values is identified by the OID stored in the attribute 1580 vendorPolicyActionEncoding. 1582 This value is an Octet String.' 1583 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1584 EQUALITY octetStringMatch 1585 ) 1587 ( 1588 NAME 'vendorPolicyActionEncoding' 1589 DESC 'An OID identifying the format and semantics for this 1590 instance"s vendorPolicyActionData attribute.' 1591 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 EQUALITY 1592 objectIdentifierMatch 1593 SINGLE-VALUE 1594 ) 1596 5.11. The Class policyInstance 1598 The role of this class in the Core Schema is to serve as a structural 1599 class to which auxiliary classes representing policy information are 1600 attached when the information is reusable. For auxiliary classes 1601 representing policy conditions and policy actions, there are 1602 alternative structural classes that may be used. See Sections 5.12 1603 and 5.13. See Section 4.3 for a complete discussion of reusable 1604 policy conditions and actions, and of the role that this class plays 1605 in how they are represented. 1607 In addition to the cn attribute it inherits from "policy", this class 1608 uses the class-specific naming attribute policyInstanceName. 1610 The class definition is as follows: 1612 ( NAME 'policyInstance' 1613 DESC 'A structural class that contains reusable policy 1614 information.' 1615 SUP policy 1616 MAY ( policyInstanceName ) 1617 ) 1619 The following DIT content rule indicates that an instance of 1620 policyInstance may have attached to it instances of the auxiliary 1621 classes policyConditionAuxClass and policyActionAuxClass. Additional 1622 DIT content rules may be defined later, for attachment of other 1623 policy-related auxiliary classes to policyInstance. 1625 ( 1626 NAME 'policyInstanceContentRule' 1627 DESC 'shows what auxiliary classes go with this class' 1628 AUX ( policyConditionAuxClass $ policyActionAuxClass) 1629 ) 1631 The following DIT structure rules indicate that an instance of 1632 policyInstance may be named under an instance of policyRepository, 1633 using any of its three naming attributes. 1635 ( NAME 'policyInstanceNameForm1' 1636 OC policyInstance 1637 MUST ( cn ) 1638 ) 1640 ( 1643 ) 1645 ( NAME 'policyInstanceNameForm2' 1646 OC policyInstance 1647 MUST ( policyInstanceName ) 1648 ) 1650 ( NAME 'policyInstanceStructuralRule2' 1651 FORM policyInstanceNameForm2 1652 SUP 1653 ) 1655 ( NAME 'policyInstanceNameForm3' 1656 OC policyInstance 1657 MUST ( orderedCimKeys ) 1658 ) 1660 ( NAME 'policyInstanceStructuralRule3' 1661 FORM policyInstanceNameForm3 1662 SUP 1663 ) 1665 The one attribute of policyInstance is defined as: 1667 ( NAME 'policyInstanceName' 1668 DESC 'The user-friendly name of this policy instance. 1670 This value is a Directory String.' 1671 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1672 EQUALITY caseIgnoreMatch 1673 SINGLE-VALUE 1674 ) 1676 5.12. The Class policyConditionInstance 1678 The role of this class in the Core Schema is to serve as a structural 1679 class to which the auxiliary class policyConditionAuxClass may be 1680 attached to form a reusable policy condition. Alternatively, a 1681 reusable policyConditionAuxClass may be attached to the more generic 1682 structural class policyInstance, defined in Section 5.11. See Section 1683 4.3 for a complete discussion of reusable policy conditions and the 1684 role that this class plays in how they are represented. 1686 In addition to the cn attribute it inherits from "policy" and the 1687 policyInstanceName attribute it inherits from policyInstance, this 1688 class uses the naming attribute policyConditionName, which was defined 1689 above in Section 5.4. 1691 The class definition is as follows: 1693 ( NAME 'policyConditionInstance' 1694 DESC 'A structural class that contains a reusable policy 1695 condition.' 1696 SUP policyInstance 1697 MAY ( policyConditionName ) 1698 ) 1700 The following DIT content rule indicates that an instance of 1701 policyConditionInstance may have attached to it an instance of the 1702 auxiliary class policyConditionAuxClass. 1704 ( 1705 NAME 'policyConditionInstanceContentRule' 1706 DESC 'shows what auxiliary classes go with this class' 1707 AUX ( policyConditionAuxClass ) 1708 ) 1710 The following DIT structure rules indicate that an instance of 1711 policyConditionInstance may be named under an instance of 1712 policyRepository, using any of its four naming attributes. 1714 ( NAME 'policyConditionInstanceNameForm1' 1715 OC policyConditionInstance 1716 MUST ( cn ) 1717 ) 1719 ( NAME 'policyConditionInstanceStructuralRule1' 1720 FORM policyConditionInstanceNameForm1 1721 SUP 1722 ) 1723 ( NAME 'policyConditionInstanceNameForm2' 1724 OC policyConditionInstance 1725 MUST ( policyConditionName ) 1726 ) 1728 ( NAME 'policyConditionInstanceStructuralRule2' 1729 FORM policyConditionInstanceNameForm2 1730 SUP 1731 ) 1733 ( NAME 'policyConditionInstanceNameForm3' 1734 OC policyConditionInstance 1735 MUST ( orderedCimKeys ) 1736 ) 1738 ( NAME 'policyConditionInstanceStructuralRule3' 1739 FORM policyConditionInstanceNameForm3 1740 SUP 1741 ) 1743 ( NAME 'policyConditionInstanceNameForm4' 1744 OC policyConditionInstance 1745 MUST ( policyInstanceName ) 1746 ) 1748 ( NAME 'policyConditionInstanceStructuralRule4' 1749 FORM policyConditionInstanceNameForm4 1750 SUP 1751 ) 1753 5.13. The Class policyActionInstance 1755 The role of this class in the Core Schema is to serve as a structural 1756 class to which the auxiliary class policyActionAuxClass may be 1757 attached to form a reusable policy action. Alternatively, a reusable 1758 policyActionAuxClass may be attached to the more generic structural 1759 class policyInstance, defined in Section 5.11. See Section 4.3 for a 1760 complete discussion of reusable policy actions and the role that this 1761 class plays in how they are represented. 1763 In addition to the cn attribute it inherits from "policy" and the 1764 policyInstanceName attribute it inherits from policyInstance, this 1765 class uses the naming attribute policyActionName, which was defined 1766 above in Section 5.5. 1768 The class definition is as follows: 1770 ( NAME 'policyActionInstance' 1771 DESC 'A structural class that contains a reusable policy 1772 action.' 1773 SUP policyInstance 1774 MAY ( policyActionName ) 1776 The following DIT content rule indicates that an instance of 1777 policyActionInstance may have attached to it an instance of the 1778 auxiliary class policyActionAuxClass. 1780 ( 1781 NAME 'policyActionInstanceContentRule' 1782 DESC 'shows what auxiliary classes go with this class' 1783 AUX ( policyActionAuxClass ) 1784 ) 1786 The following DIT structure rules indicate that an instance of 1787 policyActionInstance may be named under an instance of 1788 policyRepository, using any of its three naming attributes. 1790 ( NAME 'policyActionInstanceNameForm1' 1791 OC policyActionInstance 1792 MUST ( cn ) 1793 ) 1795 ( NAME 'policyActionInstanceStructuralRule1' 1796 FORM policyActionInstanceNameForm1 1797 SUP 1798 ) 1800 ( NAME 'policyActionInstanceNameForm2' 1801 OC policyActionInstance 1802 MUST ( policyActionName ) 1803 ) 1805 ( NAME 'policyActionInstanceStructuralRule2' 1806 FORM policyActionInstanceNameForm2 1807 SUP 1808 ) 1810 ( NAME 'policyActionInstanceNameForm3' 1811 OC policyActionInstance 1812 MUST ( orderedCimKeys ) 1813 ) 1815 ( NAME 'policyActionInstanceStructuralRule3' 1816 FORM policyActionInstanceNameForm3 1817 SUP 1818 ) 1820 ( NAME 'policyActionInstanceNameForm4' 1821 OC policyActionInstance 1822 MUST ( policyInstanceName ) 1823 ) 1825 ( NAME 'policyActionInstanceStructuralRule4' 1826 FORM policyActionInstanceNameForm4 1827 SUP 1828 ) 1830 5.14. The Auxiliary Class policyElementAuxClass 1832 This class introduces no additional attributes, beyond those defined 1833 in the class "policy" from which it is derived. Its role is to "tag" 1834 an instance of a class defined outside the realm of policy as being 1835 nevertheless relevant to a policy specification. This tagging can 1836 potentially take place at two levels: 1838 o Every instance to which policyElementAuxClass is attached becomes 1839 an instance of the class "policy", since policyElementAuxClass is a 1840 subclass of "policy". Thus a DIT search with the filter 1841 "objectClass=policy" will return the instance. (As noted earlier, 1842 this approach does not work for some directory implementations. To 1843 accommodate these implementations, policy-related entries SHOULD be 1844 tagged with the keyword "POLICY".) 1846 o With the policyKeywords attribute that it inherits from "policy", 1847 an instance to which policyElementAuxClass is attached can be 1848 tagged as being relevant to a particular type or category of 1849 policy, using standard keywords, administrator-defined keywords, or 1850 both. 1852 The class definition is as follows: 1854 ( NAME 'policyElementAuxClass' 1855 DESC 'An auxiliary class used to tag instances of classes 1856 defined outside the realm of policy as relevant to a 1857 particular policy specification.' 1858 SUP policy 1859 AUXILIARY 1860 ) 1862 5.15. The Class policyRepository 1864 This class provides a container for reusable policy information, such 1865 as reusable policy conditions and/or reusable policy actions. It is 1866 derived from several classes defined in reference [10]: 1868 top 1869 | 1870 +--dlm1ManagedElement (abstract) 1871 | 1872 +--dlm1ManagedSystemElement (abstract) 1873 | 1874 +--dlm1LogicalElement (abstract) 1875 | 1876 +--dlm1System (abstract) 1877 | 1878 +--dlm1AdminDomain (abstract) 1879 | 1880 +--policyRepository (structural) 1882 The class definition is as follows: 1884 ( NAME 'policyRepository' 1885 DESC 'A container for reusable information.' 1886 SUP dlm1AdminDomain 1887 MUST ( policyRepositoryName ) 1888 ) 1890 The following DIT structure rules indicate that an instance of 1891 policyRepository may be named under any superior, using any of its 1892 three naming attributes. These DIT structure rules cover, as a 1893 special case, a policyRepository that is named within the scope of 1894 another policyRepository. This special case is the mapping for the 1895 CIM aggregation PolicyRepositoryInPolicyRepository. 1897 ( NAME 'policyRepositoryNameForm1' 1898 OC policyRepository 1899 MUST ( cn ) 1900 ) 1902 ( NAME 'policyRepositoryStructuralRule1' 1903 FORM policyRepositoryNameForm1 1904 ) 1906 ( NAME 'policyRepositoryNameForm2' 1907 OC policyRepository 1908 MUST ( policyRepositoryName ) 1909 ) 1911 ( NAME 'policyRepositoryStructuralRule2' 1912 FORM policyRepositoryNameForm2 1913 ) 1915 ( NAME 'policyRepositoryNameForm3' 1916 OC policyRepository 1917 MUST ( orderedCimKeys ) 1918 ) 1919 ( NAME 'policyRepositoryStructuralRule3' 1920 FORM policyRepositoryNameForm3 1921 ) 1923 The one attribute of policyRepository is defined as follows. 1925 ( NAME 'policyRepositoryName' 1926 DESC 'The user-friendly name of this policy repository. 1928 This value is a Directory String.' 1929 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1930 EQUALITY caseIgnoreMatch 1931 SINGLE-VALUE 1932 ) 1934 5.16. The Auxiliary Class policySubtreesPtrAuxClass 1936 This auxiliary class provides a single, multi-valued attribute that 1937 points to a set of objects that are at the root of DIT subtrees 1938 containing policy-related information. By attaching this attribute to 1939 instances of various other classes, a policy administrator has a 1940 flexible way of providing an entry point into the directory that 1941 allows a client to locate and retrieve the policy information relevant 1942 to it. 1944 These entries may be placed in the DIT such that a well-known DN can 1945 be used by placing the structural entry (e.g. container) with the 1946 policySubtreesPtrAuxClass attached thereto in the root of the 1947 directory suffix. In this case, the subtree entry point can contain 1948 and/or point to all related policy entries for any well-known policy 1949 disciplines. Similarly, the subtree entry point may be placed in the 1950 DIT such that the PDP's starting point is a subtree with policy- 1951 related entries that are dependent on a hierarchically-related set of 1952 subtrees (e.g., region, division, corporate). In this latter case, 1953 DNs may be provided to the PDPs via SNMP or other techniques. 1955 This object does not provide the semantic linkages between individual 1956 policy objects, such as those between a policy group and the policy 1957 rules that belong to it. Its only role is to enable efficient bulk 1958 retrieval of policy-related objects, as described in Section 4.4. 1959 Once the objects have been retrieved, a directory client can determine 1960 the semantic linkages by following DN pointers such as 1961 policyRulesAuxContainedSet locally. 1963 Since policy-related objects will often be included in the DIT subtree 1964 beneath an object to which this auxiliary class is attached, a client 1965 SHOULD request the policy-related objects from the subtree under the 1966 object with these pointers at the same time that it requests the 1967 pointers themselves. 1969 Since clients are expected to behave in this way, the policy 1970 administrator SHOULD make sure that this subtree does not contain so 1971 many objects unrelated to policy that an initial search done in this 1972 way results in a performance problem. For example, 1973 policySubtreesPtrAuxClass SHOULD NOT be attached to the partition root 1974 for a large directory partition containing a relatively few policy- 1975 related objects along with a large number of objects unrelated to 1976 policy. A better approach would be to introduce a container object 1977 immediately below the partition root, attach policySubtreesPtrAuxClass 1978 to this container object, and then place the policy-related objects in 1979 the subtree under it. 1981 The class definition is as follows: 1983 ( NAME 'policySubtreesPtrAuxClass' 1984 DESC 'An auxiliary class providing DN pointers to roots of 1985 DIT subtrees containing policy-related objects.' 1986 SUP top 1987 AUXILIARY 1988 MAY ( policySubtreesAuxContainedSet ) 1989 ) 1991 5.16.1. The Attribute policySubtreesAuxContainedSet 1993 This attribute provides an unordered set of DN pointers to one or more 1994 objects under which policy-related information is present. The 1995 objects pointed to may or may not themselves contain policy-related 1996 information. 1998 The attribute definition is as follows: 2000 ( 2001 NAME 'policySubtreesAuxContainedSet' 2002 DESC 'Distinguished names of objects that serve as roots for 2003 DIT subtrees containing policy-related objects. No 2004 order is implied. 2006 This value is a Distinguished Name (DN).' 2007 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2008 EQUALITY distinguishedNameMatch 2009 ) 2011 5.17. The Auxiliary Class policyGroupContainmentAuxClass 2013 This auxiliary class provides a single, multi-valued attribute that 2014 points to a set of policyGroups. By attaching this attribute to 2015 instances of various other classes, a policy administrator has a 2016 flexible way of providing an entry point into the directory that 2017 allows a client to locate and retrieve the policyGroups relevant to 2018 it. 2020 As is the case with policyRules, a policy administrator might have 2021 several different pointers to a policyGroup in the overall directory 2022 structure. The policyGroupContainmentAuxClass is the mechanism that 2023 makes it possible for the policy administrator to define all these 2024 pointers. 2026 The class definition is as follows: 2028 ( NAME 'policyGroupContainmentAuxClass' 2029 DESC 'An auxiliary class used to bind policyGroups to an 2030 appropriate container object.' 2031 SUP top 2032 AUXILIARY 2033 MAY ( policyGroupsAuxContainedSet ) 2034 ) 2036 5.17.1. The Attribute policyGroupsAuxContainedSet 2038 This attribute provides an unordered set of DN pointers to one or more 2039 policyGroups associated with the instance of a structural class to 2040 which this attribute has been appended. The attribute definition is 2041 as follows: 2043 ( 2044 NAME 'policyGroupsAuxContainedSet' 2045 DESC 'Distinguished names of policyGroups associated in some 2046 way with the instance to which this attribute has been 2047 appended. No order is implied. 2049 This value is a Distinguished Name (DN).' 2050 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2051 EQUALITY distinguishedNameMatch 2052 ) 2054 5.18. The Auxiliary Class policyRuleContainmentAuxClass 2056 This auxiliary class provides a single, multi-valued attribute that 2057 points to a set of policyRules. By attaching this attribute to 2058 instances of various other classes, a policy administrator has a 2059 flexible way of providing an entry point into the directory that 2060 allows a client to locate and retrieve the policyRules relevant to it. 2062 A policy administrator might have several different pointers to a 2063 policyRule in the overall directory structure. For example, there 2064 might be pointers to all policyRules for traffic originating in a 2065 particular subnet from a directory entry that represents that subnet. 2066 At the same time, there might be pointers to all policyRules related 2067 to a particular DiffServ setting from an instance of a policyGroup 2068 explicitly introduced as a container for DiffServ-related policyRules. 2070 The policyRuleContainmentAuxClass is the mechanism that makes it 2071 possible for the policy administrator to define all these pointers. 2073 Note that the cn attribute does NOT need to be defined for this class. 2074 This is because an auxiliary class is used as a means to collect 2075 common attributes and treat them as properties of an object. A good 2076 analogy is a #include file, except that since an auxiliary class is a 2077 class, all the benefits of a class (e.g., inheritance) can be applied 2078 to an auxiliary class. 2080 The class definition is as follows: 2082 ( NAME 'policyRuleContainmentAuxClass' 2083 DESC 'An auxiliary class used to bind policyRules to an 2084 appropriate container object.' 2085 SUP top 2086 AUXILIARY 2087 MAY ( policyRulesAuxContainedSet ) 2088 ) 2090 5.18.1. The Attribute policyRulesAuxContainedSet 2092 This attribute provides an unordered set of DN pointers to one or more 2093 policyRules associated with the instance of a structural class to 2094 which this attribute has been appended. The attribute definition is: 2096 ( 2097 NAME 'policyRulesAuxContainedSet' 2098 DESC 'Distinguished names of policyRules associated in some 2099 way with the instance to which this attribute has been 2100 appended. No order is implied. 2102 This value is a Distinguished Name (DN).' 2103 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2104 EQUALITY distinguishedNameMatch 2105 ) 2107 6. Extending the Core Schema 2109 The following subsections provide general guidance on how to create a 2110 domain-specific schema derived from the Core Schema, discuss how the 2111 vendor classes in the Core Schema should be used, and explain how 2112 policyTimePeriodConditions are related to other policy conditions. 2114 6.1. Subclassing policyConditionAuxClass and policyActionAuxClass 2116 In Section 4.3 above, there is a discussion of how, by representing 2117 policy conditions and policy actions as auxiliary classes in a schema, 2118 the flexibility is retained to instantiate a particular condition or 2119 action as either rule-specific or reusable. This flexibility is lost 2120 if a condition or action class is defined as structural rather than 2121 auxiliary. For standardized schemata, this document specifies that 2122 domain-specific information MUST be expressed in auxiliary subclasses 2123 of policyConditionAuxClass and policyActionAuxClass. It is 2124 RECOMMENDED that non-standardized schemata follow this practice as 2125 well. 2127 6.2. Using the Vendor Policy Encoding Attributes 2129 As discussed Section 5.8 "The Class vendorPolicyConditionAuxClass", 2130 the attributes vendorPolicyConstraintData and 2131 vendorPolicyConstraintEncoding are included in 2132 vendorPolicyConditionAuxClass to provide an escape mechanism for 2133 representing "exceptional" policy conditions. The attributes 2134 vendorPolicyActionData and vendorPolicyActionEncoding in 2135 vendorPolicyActionAuxClass class play the same role with respect to 2136 actions. This enables interoperability between different vendors. 2138 For example, imagine a network composed of access devices from vendor 2139 A, edge and core devices from vendor B, and a policy server from 2140 vendor C. It is desirable for this policy server to be able to 2141 configure and manage all of the devices from vendors A and B. 2142 Unfortunately, these devices will in general have little in common 2143 (e.g., different mechanisms, different ways for controlling those 2144 mechanisms, different operating systems, different commands, and so 2145 forth). The escape conditions provide a way for vendor-specific 2146 commands to be encoded as OctetStrings, so that a single policy server 2147 can commonly manage devices from different vendors. 2149 6.3. Using Time Validity Periods 2151 Time validity periods are defined as a subclass of 2152 policyConditionAuxClass, called policyTimePeriodCondition. This is to 2153 allow their inclusion in the AND/OR condition definitions for a 2154 policyRule. Care should be taken not to subclass 2155 policyTimePeriodCondition to add domain-specific condition properties. 2156 For example, it would be incorrect to add IPSec- or QoS-specific 2157 condition properties to the policyTimePeriodCondition class, just 2158 because IPSec or QoS includes time in its condition definition. The 2159 correct subclassing would be to create IPSec or QoS-specific 2160 subclasses of policyConditionAuxClass and then combine instances of 2161 these domain-specific condition classes with the validity period 2162 criteria. This is accomplished using the AND/OR association 2163 capabilities for policyConditions in policyRules. 2165 7. Security Considerations 2167 o General: See reference [1]. 2169 o Users: See reference [1]. 2171 o Administrators of Schema: In general, most LDAP-accessible 2172 directories do not permit old or out-of-date schemas, or schema 2173 elements to be deleted. Instead, they are rendered inactive. 2174 This makes it that much more important to get it right the first 2175 time on an operational system, in order to avoid complex inactive 2176 schema artifacts from lying about in the operational directory. 2177 The good news is that it is expected that large network operators 2178 will change schema design infrequently, and, when they do, the 2179 schema creation changes will be tested on an off-line copy of the 2180 directory before the operational directory is updated. 2181 Typically, a small group of directory schema administrators will 2182 be authorized to make these changes in a service provider or 2183 enterprise environment. The ability to maintain audit trails is 2184 also required here. 2186 o Administrators of Schema Content (Directory Entries): This group 2187 requires authorization to load values (entries) into a policy 2188 repository directory schema, i.e. read/write access. An audit 2189 trail capability is also required here. 2191 o Applications and PDPs: These entities must be authorized for 2192 read-only access to the policy repository directory, so that they 2193 may acquire policy for the purposes of passing it to their 2194 respective enforcement entities. 2196 o Security Disciplines: 2198 o Audit Trail (Non-repudiation): In general, standardizing 2199 mechanisms for non-repudiation is outside the scope of the 2200 IETF; however, we can certainly document the need for this 2201 function in systems that maintain and distribute policy. The 2202 dependency for support of this function is on the implementers 2203 of these systems, and not on any specific standards for 2204 implementation. The requirement for a policy system is that a 2205 minimum level of auditing via an auditing facility must be 2206 provided. Logging should be enabled. This working group will 2207 not specify what this minimal auditing function consists of. 2209 o Access Control/Authorization: Access Control List (ACL) 2210 functionality must be provided. Standards for directories that 2211 use LDAPv3 as an access mechanism are still being worked on in 2212 the LDAPext working group, as of this writing. The two 2213 administrative sets of users documented above will form the 2214 basis for two administrative use cases that require support. 2216 o Authentication: In the LDAP-accessible directory case, both TLS 2217 and Kerberos are acceptable for authentication. Existing LDAP 2218 implementations provide these functions within the context of 2219 the BIND request, which is adequate. We advise against using 2220 weaker mechanisms, such as clear text and HTTP Digest. Mutual 2221 authentication is recommended. The LDAPv3 protocol supports 2222 this, but implementations vary in the functionality that they 2223 support. 2225 o Integrity/Privacy: In the LDAP-accessible directory case, TLS 2226 is acceptable for encryption and data integrity on the wire. 2227 If physical or virtual access to the policy repository is in 2228 question, it may also be necessary to encrypt the policy data 2229 as it is stored on the file system; however, specification of 2230 mechanisms for this purpose are outside the scope of this 2231 working group. In any case, we recommend that the physical 2232 server be located in a physically secure environment. 2234 In the case of PDP-to-PEP communications, the use of IPSEC is 2235 recommended for providing confidentiality, data origin 2236 authentication, integrity, and replay prevention. See reference 2237 [8]. 2239 o Denial of Service: We recommend the use of multiple policy 2240 repository directories, such that a denial of service attack on 2241 any one directory server will not make all policy data 2242 inaccessible to legitimate users. However, this still leaves a 2243 denial of service attack exposure. Our belief is that the use of 2244 a policy schema, in a centrally administered but physically 2245 distributed policy directory, does not increase the risk of 2246 denial of service attacks; however, such attacks are still 2247 possible. If executed successfully, such an attack could prevent 2248 PDPs from accessing a policy repository, and thus prevent them 2249 from acquiring new policy. In such a case, the PDPs, and 2250 associated PEPs would continue operating under the policies in 2251 force before the denial of service attack was launched. Note 2252 that exposure of policy systems to denial of service attacks is 2253 not any greater than the exposure of DNS with DNSSEC in place. 2255 o Other LDAP-accessible Directory Schema Considerations: 2257 o Replication: Replication among directory copies across servers 2258 should also be protected. Replicating over connections secured 2259 by SSL or IPSEC is recommended. 2261 8. Intellectual Property 2263 The IETF takes no position regarding the validity or scope of any 2264 intellectual property or other rights that might be claimed to pertain 2265 to the implementation or use of the technology described in this 2266 document or the extent to which any license under such rights might or 2267 might not be available; neither does it represent that it has made any 2268 effort to identify any such rights. Information on the IETF's 2269 procedures with respect to rights in standards-track and standards- 2270 related documentation can be found in BCP-11. 2272 Copies of claims of rights made available for publication and any 2273 assurances of licenses to be made available, or the result of an 2274 attempt made to obtain a general license or permission for the use of 2275 such proprietary rights by implementers or users of this specification 2276 can be obtained from the IETF Secretariat. 2278 The IETF invites any interested party to bring to its attention any 2279 copyrights, patents or patent applications, or other proprietary 2280 rights that may cover technology that may be required to practice this 2281 standard. Please address the information to the IETF Executive 2282 Director. 2284 9. Acknowledgments 2286 Several of the policy classes in this model first appeared in early 2287 IETF drafts on IPSec policy and QoS policy. The authors of these 2288 drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy 2289 Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael 2290 See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar. 2291 This document is closely aligned with the work being done in the 2292 Distributed Management Task Force (DMTF) Service Level Agreements and 2293 Networks working groups. We would especially like to thank Andrea 2294 Westerinen, Lee Rafalow, Glenn Waters, David Black, Michael 2295 Richardson, Mark Stevens, David Jones, Hugh Mahon, Yoram Snir, and 2296 Yoram Ramberg for their helpful comments. 2298 10. References 2300 [1] Moore, B., and E. Ellesson, J. Strassner,, A. Westerinen "Policy 2301 Core Information Model -- Version 1 Specification", draft-ietf- 2302 policy-core-info-model-08.txt, October 2000. 2304 [2] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight 2305 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2306 2252, December 1997. 2308 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2309 Levels", BCP 14, RFC 2119, March 1997. 2311 [4] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 2312 Standards Process", BCP 11, RFC 2028, October 1996. 2314 [5] Strassner, J. and S. Judd, "Directory-Enabled Networks", version 2315 3.0c5 (August 1998). A PDF file is available at 2316 http://www.murchiso.com/den/#denspec. 2318 [6] Strassner, J., policy architecture BOF presentation, 42nd IETF 2319 Meeting, Chicago, Illinois, October 1998. Minutes of this BOF are 2320 available at the following location: 2321 http://www.ietf.org/proceedings/98aug/index.html. 2323 [7] DMTF web site, http://www.dmtf.org. 2325 [8] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for 2326 Policy-based Admission Control", RFC 2753, January 2000. 2328 [9] Distributed Management Task Force, Inc., "Guidelines for CIM-to- 2329 LDAP Directory Mapping", May 8, 2000. . This document is available 2330 on the following DMTF web page: http://www.dmtf.org/spec/denh.html. 2332 [10] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the 2333 CIM v2.4 Core Information Model", November 20, 2000. This document 2334 is available on the following DMTF web page: 2335 http://www.dmtf.org/spec/denh.html. 2337 11. Authors' Addresses 2339 John Strassner 2340 Cisco Systems, Bldg 15 2341 170 West Tasman Drive 2342 San Jose, CA 95134 2343 Phone: +1 408-527-1069 2344 Fax: +1 408-527-1722 2345 E-mail: johns@cisco.com 2347 Ed Ellesson 2348 Tivoli Systems 2349 Building 10, Office R2D39 2350 3901 Miami Blvd. 2351 Durham, NC 27703 2352 Phone: +1 919-224-2111 2353 Fax: +1 919-224-2540 2354 E-mail: ed_ellesson@tivoli.com 2356 Bob Moore 2357 IBM Corporation, BRQA/502 2358 4205 S. Miami Blvd. 2359 Research Triangle Park, NC 27709 2360 Phone: +1 919-254-4436 2361 Fax: +1 919-254-6243 2362 E-mail: remoore@us.ibm.com 2364 Ryan Moats 2365 15621 Drexel Circle 2366 Omaha, NE 68135 2367 USA 2368 Phone: +1-402-894-9456 2369 E-mail: rmoats@coreon.net 2371 12. Full Copyright Statement 2373 Copyright (C) The Internet Society (2000). All Rights Reserved. 2375 This document and translations of it may be copied and furnished to 2376 others, and derivative works that comment on or otherwise explain it 2377 or assist in its implementation may be prepared, copied, published and 2378 distributed, in whole or in part, without restriction of any kind, 2379 provided that the above copyright notice and this paragraph are 2380 included on all such copies and derivative works. However, this 2381 document itself may not be modified in any way, such as by removing 2382 the copyright notice or references to the Internet Society or other 2383 Internet organizations, except as needed for the purpose of developing 2384 Internet standards in which case the procedures for copyrights defined 2385 in the Internet Standards process must be followed, or as required to 2386 translate it into languages other than English. 2388 The limited permissions granted above are perpetual and will not be 2389 revoked by the Internet Society or its successors or assigns. 2391 This document and the information contained herein is provided on an 2392 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2393 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2394 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2395 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2396 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2398 13. Appendix: Constructing the Value of orderedCimKeys 2400 Within a CIM name space, the naming is basically flat; all instances 2401 are identified by the values of their key properties, and each 2402 combination of key values must be unique. A limited form of 2403 hierarchical naming is available in CIM, however, by using weak 2404 associations: since a weak association involves propagation of key 2405 properties and their values from the superior object to the 2406 subordinate one, the subordinate object can be thought of as being 2407 named "under" the superior object. Once they have been propagated, 2408 however, propagated key properties and their values function in 2409 exactly the same way that native key properties and their values do in 2410 identifying a CIM instance. 2412 In its mapping from the CIM_ManagedElement class to the LDAP class 2413 dlm1ManagedElement, reference [10] introduces a third attribute, 2414 orderedCimKeys, alongside the two attributes that it derives from the 2415 properties in the CIM class. The orderedCimKeys attribute is used 2416 only in an environment where it is necessary to map between an LDAP- 2417 accessible directory and a CIM repository. For other environments, 2418 LDAP entries are identified via their other attributes that are 2419 suitable for naming. 2421 The role of orderedCimKeys is to represent the information necessary 2422 to correlate an entry in an LDAP-accessible directory with an instance 2423 in a CIM name space. Depending on how naming of CIM-related entries 2424 is handled in an LDAP directory, the value of orderedCimKeys 2425 represents one of two things: 2427 o If the DIT hierarchy does not mirror the "weakness hierarchy" of 2428 the CIM name space, then orderedCimKeys represents all the keys of 2429 the CIM instance, both native and propagated. 2431 o If the DIT hierarchy does mirror the "weakness hierarchy" of the 2432 CIM name space, then orderedCimKeys may represent either all the 2433 keys of the instance, or only the native keys. 2435 Regardless of which of these alternatives is taken, the syntax of 2436 orderedCimKeys is the same - a DirectoryString of the form 2438 .=[,=]* 2440 where the = elements are ordered by the names of the key 2441 properties, according to the collating sequence for US ASCII. The 2442 only spaces allowed in the DirectoryString are those that fall within 2443 a element. As with alphabetizing the key properties, the goal 2444 of suppressing the spaces is once again to make the results of string 2445 operations predictable. 2447 The values of the elements are derived from the various CIM 2448 syntaxes according to a grammar specified in reference [9].