idnits 2.17.1 draft-ietf-policy-core-schema-07.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 47 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 48 pages 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 200 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], [11], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 270 has weird spacing: '...case is not s...' == Line 2139 has weird spacing: '...ository direc...' == Line 2192 has weird spacing: '... server will ...' -- 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 (July 2000) is 8658 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 2262, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2269, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2274, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-policy-core-info-model-07 ** 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' -- Possible downref: Normative reference to a draft: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 9 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 July 2000 10 Policy Core LDAP Schema 11 draft-ietf-policy-core-schema-07.txt 12 July 14, 2000 14:26 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 48 and 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 75 vendorPolicyActionAuxClass. To achieve the mapping of the information 76 model's relationships, the schema contains two auxiliary classes: 77 policyGroupContainmentAuxClass and policyRuleContainmentAuxClass. 78 Capturing the distinction between rule-specific and reusable policy 79 conditions and policy actions introduces six other classes: 80 policyRuleConditionAssociation, policyRuleActionAssociation, 81 policyInstance, policyConditionInstance, policyActionInstance, and 82 policyRepository. Finally, the schema includes two classes 83 policySubtreesPtrAuxClass and policyElementAuxClass for optimizing 84 LDAP retrievals. In all, 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.......................26 105 5.6. The Auxiliary Class policyConditionAuxClass.................28 106 5.7. The Auxiliary Class policyTimePeriodConditionAuxClass.......28 107 5.8. The Auxiliary Class vendorPolicyConditionAuxClass...........30 108 5.9. The Auxiliary Class policyActionAuxClass....................31 109 5.10. The Auxiliary Class vendorPolicyActionAuxClass.............31 110 5.11. The Class policyInstance...................................32 111 5.12. The Class policyConditionInstance..........................33 112 5.13. The Class policyActionInstance.............................35 113 5.14. The Auxiliary Class policyElementAuxClass..................36 114 5.15. The Class policyRepository.................................37 115 5.16. The Auxiliary Class policySubtreesPtrAuxClass..............38 116 5.16.1. The Attribute policySubtreesAuxContainedSet..............39 117 5.17. The Auxiliary Class policyGroupContainmentAuxClass.........40 118 5.17.1. The Attribute policyGroupsAuxContainedSet................40 119 5.18. The Auxiliary Class policyRuleContainmentAuxClass..........41 120 5.18.1. The Attribute policyRulesAuxContainedSet.................41 121 6. Extending the Core Schema........................................42 122 6.1. Subclassing policyConditionAuxClass and policyActionAuxClass42 123 6.2. Using the Vendor Policy Encoding Attributes.................42 124 6.3. Using Time Validity Periods.................................42 125 7. Security Considerations..........................................43 126 8. Intellectual Property............................................45 127 9. Acknowledgments..................................................45 128 10. References......................................................45 129 11. Authors' Addresses..............................................46 130 12. Full Copyright Statement........................................47 131 13. Appendix: Constructing the Value of orderedCimKeys.............47 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 +--cim23ManagedElement (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 | +--cim23ManagedSystemElement (abstract) 225 | | 226 | +--cim23LogicalElement (abstract) 227 | | 228 | +--cim23System (abstract) 229 | | 230 | +--cim23AdminDomain (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 253 4. General Discussion of Mapping the Information Model to LDAP 255 The classes described in Section 5 below contain certain optimizations 256 for a directory that uses LDAP as its access protocol. One example of 257 this is the use of auxiliary classes to represent some of the 258 associations defined in the information model. Other data stores 259 might need to implement these associations differently. A second 260 example is the introduction of classes specifically designed to 261 optimize retrieval of large amounts of policy-related data from a 262 directory. This section discusses some general topics related to the 263 mapping from the information model to LDAP. 265 4.1. Summary of Class and Association Mappings 267 Nine of the classes in the LDAP Core Policy Schema come directly from 268 corresponding classes in the information model. Note that names of 269 classes begin with an upper case character in the information model 270 (although for CIM in particular, case is not significant in class and 271 property names), but with a lower case character in LDAP. 273 +---------------------------+-----------------------------------+ 274 | Information Model | LDAP Class | 275 +---------------------------+-----------------------------------+ 276 +---------------------------+-----------------------------------+ 277 | Policy | policy | 278 +---------------------------+-----------------------------------+ 279 | PolicyGroup | policyGroup | 280 +---------------------------+-----------------------------------+ 281 | PolicyRule | policyRule | 282 +---------------------------+-----------------------------------+ 283 | PolicyCondition | policyConditionAuxClass | 284 +---------------------------+-----------------------------------+ 285 | PolicyAction | policyActionAuxClass | 286 +---------------------------+-----------------------------------+ 287 | VendorPolicyCondition | vendorPolicyConditionAuxClass | 288 +---------------------------+-----------------------------------+ 289 | VendorPolicyAction | vendorPolicyActionAuxClass | 290 +---------------------------+-----------------------------------+ 291 | PolicyTimePeriodCondition | policyTimePeriodConditionAuxClass | 292 +---------------------------+-----------------------------------+ 293 | PolicyRepository | policyRepository | 294 +---------------------------+-----------------------------------+ 295 Figure 2. Mapping of Information Model Classes to LDAP 297 The associations in the information model map to DN-pointer attributes 298 or to Directory Information Tree (DIT) containment in LDAP. Two of 299 the DN-pointer attributes appear in auxiliary classes, which allow 300 each of them to represent several relationships from the information 301 model. 303 +-----------------------------------+--------------------------------+ 304 | Information Model Association | LDAP Attribute / Class | 305 +-----------------------------------+--------------------------------+ 306 +-----------------------------------+--------------------------------+ 307 | PolicyGroupInPolicyGroup | policyGroupsAuxContainedSet in | 308 | | policyGroupContainmentAuxClass| 309 +-----------------------------------+--------------------------------+ 310 | PolicyRuleInPolicyGroup | policyRulesAuxContainedSet in | 311 | | policyRuleContainmentAuxClass | 312 +-----------------------------------+--------------------------------+ 313 | PolicyConditionInPolicyRule | DIT containment + | 314 | | containedConditionAssocSet in | 315 | | policyRule + | 316 | | policyConditionDN in | 317 | | policyRuleConditionAssociation| 318 +-----------------------------------+--------------------------------+ 319 | PolicyActionInPolicyRule | DIT containment + | 320 | | containedActionAssocSet in | 321 | | policyRule + | 322 | | policyActionDN in | 323 | | policyRuleActionAssociation | 324 +-----------------------------------+--------------------------------+ 325 | PolicyRuleValidityPeriod | policyRuleValidityPeriodList in| 326 | | policyRule | 327 +-----------------------------------+--------------------------------+ 328 | PolicyConditionInPolicyRepository | DIT containment | 329 +-----------------------------------+--------------------------------+ 330 | PolicyActionInPolicyRepository | DIT containment | 331 +-----------------------------------+--------------------------------+ 332 | PolicyRepositoryInPolicyRepository| DIT containment | 333 +-----------------------------------+--------------------------------+ 334 Figure 3. Mapping of Information Model Associations to LDAP 336 Of the remaining classes in the LDAP Core Schema, two 337 (policyElementAuxClass and policySubtreesPtrAuxClass) are included to 338 make navigation through the DIT and retrieval of the entries found 339 there more efficient. This topic is discussed in Section 4.4 below. 341 The remaining five classes in the LDAP Core Schema, 342 policyRuleConditionAssociation, policyRuleActionAssociation, 343 policyInstance, policyConditionInstance, and policyActionInstance are 344 all involved with the representation of policy conditions and policy 345 actions in an LDAP directory. This topic is discussed in Section 4.3 346 below. 348 4.2. Naming Attributes in the Core Schema 350 Instances in a directory are identified by distinguished names (DNs), 351 which provide the same type of hierarchical organization that a file 352 system provides in a computer system. A distinguished name is a 353 sequence of relative distinguished names (RDNs), where an RDN provides 354 a unique identifier for an instance within the context of its 355 immediate superior, in the same way that a filename provides a unique 356 identifier for a file within the context of the folder in which it 357 resides. 359 To preserve maximum naming flexibility for policy administrators, each 360 of the structural classes defined in this schema has its own naming 361 attribute. (The naming attribute policyConditionName is used in two 362 structural class: policyRuleConditionAssociation and 363 policyConditionInstance. As discussed below in Section 4.3, these are 364 two of the structural classes to which the auxiliary class 365 policyConditionAuxClass may be attached. The naming attribute 366 policyActionName is similarly associated with two structural classes.) 367 Since the naming attributes are different, a policy administrator can, 368 by using these attributes, guarantee that there will be no name 369 collisions between instances of different classes, even if the same 370 value is assigned to the instances' respective naming attributes. 372 The X.500 attribute commonName (cn) is included as a MAY attribute in 373 the abstract class policy, and thus by inheritance in all of its 374 subclasses. In X.500, commonName typically functions as an RDN 375 attribute, for naming instances of such classes as X.500's person. 377 Finally, for implementations that expect to map between native CIM and 378 LDAP representations of policy information, a second MAY attribute, 379 orderedCimKeys, is inherited from the class cim23ManagedElement, 380 defined in reference [11], into the abstract class "policy". The 381 value of this attribute is derived algorithmically from values that 382 are already present in a CIM policy instance. See the appendix of 383 this document for a complete description of the algorithm. 385 Each of the Core Schema classes thus has three attributes suitable for 386 naming: cn, its own class-specific attribute, and orderedCimKeys. 387 Any of these attributes MAY be used for naming an instance of a Core 388 Schema class. Consequently, implementations MUST be able to 389 accommodate instances named in any of these ways. 391 Note that since they are required ("MUST") attributes, the class- 392 specific naming attributes are always present in instances of their 393 respective classes, even if they are not being used for naming the 394 instances. In these cases the class-specific naming attributes may be 395 used for other purposes. Note also that "cn", the class-specific 396 naming attribute, and orderedCimKeys SHOULD NOT be used together to 397 form a multi-part RDN, since support for multi-part RDNs is limited 398 among existing directory implementations. 400 4.3. Rule-Specific and Reusable Conditions and Actions 402 The PCIM [1] distinguishes between two types of policy conditions and 403 policy actions: ones associated with a single policy rule, and ones 404 that are reusable, in the sense that they may be associated with more 405 than one policy rule. There is no inherent difference between a rule- 406 specific condition or action and a reusable one. There are, however, 407 differences in how they are treated in a policy repository. For 408 example, it's natural to make the access permissions for a rule- 409 specific condition or action identical to those for the rule itself. 410 It's also natural for a rule-specific condition or action to be 411 removed from the policy repository at the same time the rule is. With 412 reusable conditions and actions, on the other hand, access permissions 413 and existence criteria must be expressible without reference to a 414 policy rule. 416 The preceding paragraph does not contain an exhaustive list of the 417 ways in which reusable and rule-specific conditions should be treated 418 differently. Its purpose is merely to justify making a semantic 419 distinction between rule-specific and reusable, and then reflecting 420 this distinction in the policy repository itself. 422 When the policy repository is realized in an LDAP-accessible 423 directory, the distinction between rule-specific and reusable 424 conditions and actions is realized via placement of auxiliary classes 425 and via DIT containment. Figure 4 illustrates a policy rule Rule1 426 with one rule-specific condition CA and one rule-specific action AB. 427 Because the condition and action are specific to Rule1, the auxiliary 428 classes ca and ab that represent them are attached, respectively, to 429 the structural classes CA and AB. These structural classes represent 430 not the condition ca and action ab themselves, but rather the 431 associations between Rule1 and ca, and between Rule1 and ab. 433 As Figure 4 illustrates, Rule1 contains DN pointers to the structural 434 classes CA and AB that appear below it in the DIT. At first glance it 435 might appear that these DN pointers are unnecessary, since a subtree 436 search below Rule1 would find all of the structural classes 437 representing the associations between Rule1 and its conditions and 438 actions. Relying only on a subtree search, though, runs the risk of 439 missing conditions or actions that should have appeared in the 440 subtree, but for some reason did not, or of finding conditions or 441 actions that were inadvertently placed in the subtree, or that should 442 have been removed from the subtree, but for some reason were not. 443 With the use of DN pointers, many (but not all) of these risks are 444 eliminated. 446 Note that the existence dependency of a rule-specific condition or 447 action on its policy rule follows in this case from the semantics of 448 DNs. Note also that for directory implementations supporting subtree- 449 based access permissions, it's easy to indicate that parties with 450 access to Rule1 also have access to its condition and action. 452 +-----+ 453 |Rule1| 454 | | 455 +-----|- -|-----+ 456 | +-----+ | 457 | * * | 458 | * * | 459 | **** **** | 460 | * * | 461 v * * v 462 +--------+ +--------+ 463 | CA+ca | | AB+ab | 464 +--------+ +--------+ 466 +------------------------------+ 467 |LEGEND: | 468 | ***** DIT containment | 469 | + auxiliary attachment | 470 | ----> DN pointer | 471 +------------------------------+ 473 Figure 4. Rule-Specific Policy Conditions and Actions 475 Figure 5 illustrates a second way of representing rule-specific 476 conditions and actions in an LDAP-accessible directory: attachment of 477 the auxiliary classes directly to the instance representing the policy 478 rule. When conditions and actions are attached to a policy rule in 479 this way, the rule is termed a "simple" policy rule. When conditions 480 and actions are not attached directly to a policy rule, the rule is 481 termed "complex". 483 The simple/complex distinction for a policy rule is not all or 484 nothing. A policy rule may have its conditions attached to itself and 485 its actions attached to other entries, or it may have its actions 486 attached to itself and its conditions attached to other entries. 487 However, it SHALL NOT have either its conditions or its actions 488 attached both to itself and to other entries, with one exception: a 489 policy rule may point to its validity periods with the 490 policyRuleValidityPeriodList attribute, but have its other conditions 491 attached to itself. 493 The tradeoffs between simple and complex policy rules are between the 494 efficiency of simple rules and the flexibility and greater potential 495 for reuse of complex rules. With a simple policy rule, the semantic 496 options are limited: 498 o All conditions are ANDed together. This combination can be 499 represented in two ways in the DNF / CNF expressions 500 characteristic of policy conditions: as a DNF expression with a 501 single AND group, or as a CNF expression with multiple single- 502 condition OR groups. The first of these is arbitrarily chosen as 503 the representation for the ANDed conditions in a simple policy 504 rule. 506 o If multiple actions are included, no order can be specified for 507 them. 509 If a policy administrator needs to combine conditions in some other 510 way, or if there is a set of actions that must be ordered, then the 511 only option is to use a complex policy rule. 513 +-----------+ 514 |Rule1+ca+ab| 515 | | 516 +-----------+ 518 +------------------------------+ 519 |LEGEND: | 520 | + auxiliary attachment | 521 +------------------------------+ 523 Figure 5. A Simple Policy Rule 525 Finally, Figure 6 illustrates the same policy rule Rule1, but this 526 time its condition and action are reusable. The association classes 527 CA and AB are still present, and they are still DIT contained under 528 Rule1. But rather than having the auxiliary classes ca and ab 529 attached to themselves, CA and AB now contain DN pointers to other 530 entries to which these auxiliary classes are attached. These other 531 entries, CIA and AIB, are DIT contained under RepositoryX, which is an 532 instance of the class policyRepository. Because they are named under 533 an instance of policyRepository, ca and ab are clearly identified as 534 reusable. 536 The structural classes CIA and AIB in Figure 6 may either be instances 537 of the generic class policyInstance (defined in Section 5.11), or, 538 respectively, instances of the classes policyConditionInstance 539 (Section 5.12) and policyActionInstance (Section 5.13). 541 +-----+ +-------------+ 542 |Rule1| | RepositoryX | 543 +-|- -|--+ | | 544 | +-----+ | +-------------+ 545 | * * | * * 546 | * * | * * 547 | *** **** | * * 548 | * * v * * 549 | * +---+ * * 550 | * |AB | +------+ * 551 v * | -|-------->|AIB+ab| * 552 +---+ +---+ +------+ * 553 |CA | +------+ 554 | -|------------------------>|CIA+ca| 555 +---+ +------+ 557 +------------------------------+ 558 |LEGEND: | 559 | ***** DIT containment | 560 | + auxiliary attachment | 561 | ----> DN pointer | 562 +------------------------------+ 564 Figure 6. Reusable Policy Conditions and Actions 566 The classes policyConditionAuxClass and policyActionAuxClass do not 567 themselves represent actual conditions and actions: these are 568 introduced in their subclasses. What policyConditionAuxClass and 569 policyActionAuxClass do introduce are the semantics of being a policy 570 condition or a policy action. These are the semantics that all the 571 subclasses of policyConditionAuxClass and policyActionAuxClass 572 inherit. Among these semantics are those of representing either a 573 rule-specific or a reusable policy condition or policy action. 575 In order to preserve the ability to represent a rule-specific or a 576 reusable condition or action, as well as a simple policy rule, all the 577 subclasses of policyConditionAuxClass and policyActionAuxClass MUST 578 also be auxiliary classes. 580 4.4. Location and Retrieval of Policy Objects in the Directory 582 When a PDP goes to an LDAP directory to retrieve the policy object 583 instances relevant to the PEPs it serves, it is faced with two related 584 problems: 586 o How does it locate and retrieve the directory entries that apply to 587 its PEPs? These entries may include instances of the Core Schema 588 classes, instances of domain-specific subclasses of these classes, 589 and instances of other classes modeling such resources as user 590 groups, interfaces, and address ranges. 592 o How does it retrieve the directory entries it needs in an efficient 593 manner, so that retrieval of policy information from the directory 594 does not become a roadblock to scalability? There are two facets 595 to this efficiency: retrieving only the relevant directory 596 entries, and retrieving these entries using as few LDAP calls as 597 possible. 599 The placement of objects in the Directory Information Tree (DIT) 600 involves considerations other than how the policy-related objects will 601 be retrieved by a PDP. Consequently, all that the Core Schema can do 602 is to provide a "toolkit" of classes to assist the policy 603 administrator as the DIT is being designed and built. A PDP SHOULD be 604 able to take advantage of any tools that the policy administrator is 605 able to build into the DIT, but it MUST be able to use a less 606 efficient means of retrieval if that is all it has available to it. 608 The basic idea behind the LDAP optimization classes is a simple one: 609 make it possible for a PDP to retrieve all the policy-related objects 610 it needs, and only those objects, using as few LDAP calls as possible. 611 An important assumption underlying this approach is that the policy 612 administrator has sufficient control over the underlying DIT structure 613 to define subtrees for storing policy information. If the policy 614 administrator does not have this level of control over DIT structure, 615 a PDP can still retrieve the policy-related objects it needs 616 individually. But it will require more LDAP access operations to do 617 the retrieval in this way. 619 Figure 7 illustrates how LDAP optimization is accomplished. 621 +-----+ 622 ---------------->| A | 623 DN pointer to | | DN pointers to subtrees +---+ 624 starting object +-----+ +------------------------->| C | 625 | o--+----+ +---+ +---+ 626 | o--+------------->| B | / \ 627 +-----+ +---+ / \ 628 / \ / \ / ... \ 629 / \ / \ 630 / \ / ... \ 632 Figure 7. Using policySubtreesPtrAuxClass to Locate Policies 634 The PDP is configured initially with a DN pointer to some entry in the 635 DIT. The structural class of this entry is not important; the PDP is 636 interested only in the policySubtreesPtrAuxClass attached to it. This 637 auxiliary class contains a multi-valued attribute with DN pointers to 638 objects that anchor subtrees containing policy-related objects of 639 interest to the PDP. Since policySubtreesPtrAuxClass is an auxiliary 640 class, it can be attached to an entry that the PDP would need to 641 access anyway - perhaps an entry containing initial configuration 642 settings for the PDP, or for a PEP that uses the PDP. 644 Once it has retrieved the DN pointers, the PDP will direct to each of 645 the objects identified by them an LDAP request that all entries in its 646 subtree be evaluated against the selection criteria specified in the 647 request. The LDAP-enabled directory then returns all entries in that 648 subtree that satisfy the specified criteria. 650 The selection criteria always specify that object class = "policy". 651 Since all classes representing policy rules, policy conditions, and 652 policy actions, both in the Core Schema and in any domain-specific 653 schema derived from it, are subclasses of the abstract class policy, 654 this criterion evaluates to TRUE for all instances of these classes. 655 To accommodate special cases where a PDP needs to retrieve objects 656 that are not inherently policy-related (for example, an IP address 657 range object pointed to by a subclass of policyActionAuxClass 658 representing the DHCP action "assign from this address range), the 659 auxiliary class policyElementAuxClass can be used to "tag" an entry, 660 so that it will be found by the selection criterion "object class = 661 policy". 663 The approach described in the preceding paragraph will not work for 664 certain directory implementations, because these implementations do 665 not support matching of auxiliary classes in the objectClass 666 attribute. For environments where these implementations are expected 667 to be present, the "tagging" of entries as relevant to policy can be 668 accomplished by inserting the special value "POLICY" into the list of 669 values contained in the policyKeywords attribute. 671 If a PDP needs only a subset of the policy-related objects in the 672 indicated subtrees, then it can be configured with additional 673 selection criteria based on the policyKeywords attribute defined in 674 the policy class. This attribute supports both standardized and 675 administrator-defined values. Thus a PDP could be configured to 676 request only those policy-related objects containing the keywords 677 "DHCP" and "Eastern US". 679 To optimize what is expected to be a typical case, the initial request 680 from the client includes not only the object to which its "seed" DN 681 pointer points, but also the subtree contained under this object. The 682 filter for searching this subtree is whatever the client is going to 683 use later to search the other subtrees: "object class = policy", 684 presence of the keyword "POLICY", or presence of a more specific 685 policyKeyword. 687 Returning to the example in Figure 7, we see that in the best case, a 688 PDP can get all the policy-related objects it needs, and only these 689 objects, with exactly three LDAP requests: one to its starting object 690 A to get the pointers to B and C, as well as the policy-related 691 objects it needs from the subtree under A, and then one each to B and 692 C to get all the policy-related objects that pass the selection 693 criteria with which it was configured. Once it has retrieved all of 694 these objects, the PDP can then traverse their various DN pointers 695 locally to understand the semantic relationships among them. The PDP 696 should also be prepared to find a pointer to another subtree attached 697 to any of the objects it retrieves, and to follow this pointer first, 698 before it follows any of the semantically significant pointers it has 699 received. This recursion permits a structured approach to identifying 700 related policies. In Figure 7, for example, if the subtree under B 701 includes departmental policies and the one under C includes divisional 702 policies, then there might be a pointer from the subtree under C to an 703 object D that roots the subtree of corporate-level policies. 705 Since a PDP has no guarantee that the entity that populates the 706 directory won't use the policySubtreesPtrAuxClass, a PDP SHOULD 707 understand this class, SHOULD be capable of retrieving and processing 708 the entries in the subtrees it points to, and SHOULD be capable of 709 doing all of this recursively. The same requirements apply to any 710 other entity needing to retrieve policy information from the 711 directory. Thus a Policy Management Tool that retrieves policy 712 entries from the directory in order to perform validation and conflict 713 detection SHOULD also understand and be capable of using the 714 policySubtreesPtrAuxClass. All of these requirements are "SHOULD"s 715 rather than "MUST"s because an LDAP client that doesn't implement them 716 can still access and retrieve the directory entries it needs . The 717 process of doing so will just be less efficient than it would have 718 been if the client had implemented these optimizations. 720 When it is serving as a tool for creating policy entries in the 721 directory, a Policy Management Tool SHOULD support creation of 722 policySubtreesPtrAuxClass entries and their DN pointers. 724 4.4.1. Aliases and Other DIT-Optimization Techniques 726 Additional flexibility in DIT structure is available to the policy 727 administrator via LDAP aliasing. Figure 8 illustrates this 728 flexibility. 730 +-----+ 731 ---------------->| A | 732 DN pointer to | | DN pointers to subtrees +---+ 733 starting object +-----+ +------------------------->| C | 734 | o--+----+ +---+ +---+ 735 | o--+------------->| B | / \ 736 +-----+ +---+ / \ 737 / \ / \ / ... \ 738 / \ / \ 739 / \ / \ 740 +---+ / +------+ \ 741 | X |<***************************|aliasX| 742 +---+ +------+ 744 Figure 8. Addition of an Alias Object 746 Even if it is necessary to store a policy entry X in a directory 747 location separate from the other policy entries, batch retrieval using 748 policy subtrees can still be done. The administrator simply inserts 749 into one of the subtrees of policy entries an alias entry aliasX 750 pointing to the outlying entry X. When the PDP requests all entries 751 in the subtree under B, a response will be returned for entry X, just 752 as responses are returned for all the (non-alias) entries that 753 actually are in the subtree. 755 Since resolution of an alias to its true entry is handled entirely by 756 the LDAP directory, and is invisible to directory clients, PDPs need 757 not do anything extra to support aliases. A Policy Management Tool 758 MAY make available to a policy administrator the ability to create 759 alias entries like the one in Figure 7. 761 In addition to aliases, there are several other techniques for 762 managing the placement of entries in the DIT and their retrieval by 763 directory clients. Among these other techniques are referrals, LDAP 764 URLs, attributes like seeAlso, and the extensible matching rule for 765 dereferencing DN pointers discussed in reference [8]. Discussion of 766 how these other techniques might be applied to policy-related entries 767 in a directory is outside the scope of this document. 769 5. Class Definitions 771 The semantics for the LDAP classes mapped directly from the 772 information model are detailed in reference [1]. Consequently, all 773 that this document presents for these classes is a bare specification 774 of the LDAP classes and attributes. More details are provided for the 775 attributes listed above in Figure 3, which realize in LDAP the 776 relationships defined in the information model. Finally, the classes 777 that exist only in the LDAP Core Schema are documented fully in this 778 document. 780 The formal language for specifying the classes, attributes, and DIT 781 structure and content rules is that defined in reference [2]. 783 Note: all attribute, object class, and name form OIDs, and all 784 structure rule integers, are place holders, and syntax OIDs in 785 definitions have been replaced by names for clarity. 787 5.1. The Abstract Class "policy" 789 The abstract class "policy" is a direct mapping of the abstract class 790 Policy from the Core Information Model. The five properties in 791 Policy, three of which are inherited from the class 792 cim23ManagedElement, map directly to attributes in the class "policy". 793 See reference [11] for the definition of the LDAP class 794 cim23ManagedElement. 796 The class value "policy" is also used as the mechanism for identifying 797 policy-related instances in the Directory Information Tree. An 798 instance of any class may be "tagged" with this class value by 799 attaching to it the auxiliary class policyElementAuxClass. 801 The class definition is as follows: 803 ( NAME 'policy' 804 DESC 'An abstract class with five attributes for describing 805 a policy-related instance. The attributes cimCaption, 806 cimDescription, and orderedCimKeys are inherited from 807 cim23ManagedElement.' 808 SUP cim23ManagedElement 809 ABSTRACT 810 MAY ( cn $ policyKeywords ) 811 ) 813 The three attributes cimCaption, cimDescription, and orderedCimKeys 814 are defined in reference [11]. The attribute "cn" is defined in 815 X.520. The remaining attribute, policyKeywords, is defined as 816 follows: 818 ( NAME 'policyKeywords' 819 DESC 'A set of keywords to assist directory clients in 820 locating the policy objects applicable to them. Each 821 value of the multi-valued attribute contains a single 822 keyword. Standard keyword values are listed in the 823 Policy Core Information Model document.' 824 SYNTAX IA5String 825 EQUALITY caseExactIA5Match 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.' 902 SYNTAX IA5String 903 EQUALITY caseExactIA5Match 904 SINGLE-VALUE 905 ) 907 5.3. The Class policyRule 909 This class represents the "If Condition then Action" semantics 910 associated with a policy. The conditions and actions associated with 911 a policy rule are modeled, respectively, with auxiliary subclasses of 912 the auxiliary classes policyConditionAuxClass and 913 policyActionAuxClass. Each of these auxiliary subclasses is attached 914 to an instance of one of two structural classes. A subclass of 915 policyConditionAuxClass is attached either to an instance of 916 policyRuleConditionAssociation or to an instance of 917 policyConditionInstance. Similarly, a subclass of 918 policyActionAuxClass is attached either to an instance of 919 policyRuleActionAssociation or to an instance of policyActionInstance. 921 Of the nine attributes in the policyRule class, eight are mapped 922 directly from corresponding properties in the information model. The 923 ninth attribute, policyRuleValidityPeriodList, realizes the 924 PolicyRuleValidityPeriod association from the information model. 925 Since this association has no "extra" properties (besides those that 926 tie the association to its associated objects), the attribute 927 policyRuleValidityPeriodList is simply a multi-valued DN pointer. 928 (Relationships in the information model can have "extra" properties 929 because CIM represents relationships as classes. See Sections 5.4 and 930 5.5 for examples of "extra" properties and how they are mapped to 931 LDAP.) This attribute provides an unordered set of DN pointers to one 932 or more instances of the policyTimePeriodConditionAuxClass, indicating 933 when the policy rule is scheduled to be active and when it is 934 scheduled to be inactive. A policy rule is scheduled to be active if 935 it is active according to AT LEAST ONE of the 936 policyTimePeriodConditionAuxClass instances pointed to by this 937 attribute. 939 The PolicyConditionInPolicyRule and PolicyActionInPolicyRule 940 associations, however, have additional properties: 941 PolicyActionInPolicyRule has an integer to sequence the actions, and 942 PolicyConditionInPolicyRule has an integer to group the conditions, 943 and a Boolean to specify whether a condition is to be negated. In the 944 Core Schema, these extra association properties are represented as 945 attributes of two classes introduced specifically to model the 946 associations: policyRuleConditionAssociation and 947 policyRuleActionAssociation, defined, respectively, in Sections 5.4 948 and 5.5. Thus they do not appear as attributes of the class 949 policyRule. 951 The class definition of policyRule is as follows: 953 ( NAME 'policyRule' 954 DESC 'The central class for representing the "If Condition 955 then Action" semantics associated with a policy rule.' 956 SUP policy 957 MUST ( policyRuleName ) 958 MAY ( policyRuleEnabled $ policyRuleConditionListType $ 959 policyRuleConditionList $ policyRuleActionList $ 960 policyRuleValidityPeriodList $ policyRuleUsage $ 961 policyRulePriority $ policyRuleMandatory $ 962 policyRuleSequencedActions $ policyRoles ) 963 ) 965 The following DIT content rule indicates that an instance of 966 policyRule may have attached to it the auxiliary classes 967 policyConditionAuxClass and policyActionAuxClass, or one of their 968 subclasses. This combination represents a simple policy rule. 970 ( 971 NAME 'policyRuleContentRule' 972 DESC 'shows what auxiliary classes go with this object' 973 AUX ( policyConditionAuxClass $ policyActionAuxClass ) 974 ) 976 The following DIT structure rules indicate that an instance of 977 policyRule may be named under any superior, using any of its three 978 naming attributes. 980 NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule 981 are named within the scope of ("are weak to" in the CIM jargon) an 982 instance of the CIM class System, or one of its subclasses. The most 983 natural way to map a weak relationship of this type is to DIT 984 structure rules specifying that an instance of policyGroup or 985 policyRule is subordinate to an object representing a CIM System. 986 Since, however, the mapping of CIM's System class to an LDAP class 987 falls outside the scope of this document, the DIT structure rules that 988 follow do not constrain the superiors under which an instance of 989 PolicyRule may be named. 991 ( NAME 'policyRuleNameForm1' 992 OC policyRule 993 MUST ( cn ) 994 ) 996 ( NAME 'policyRuleStructuralRule1' 997 FORM policyRuleNameForm1 998 ) 1000 ( NAME 'policyRuleNameForm2' 1001 OC policyRule 1002 MUST ( policyRuleName ) 1003 ) 1005 ( NAME 'policyRuleStructuralRule2' 1006 FORM policyRuleNameForm2 1007 ) 1008 ( NAME 'policyRuleNameForm3' 1009 OC policyRule 1010 MUST ( orderedCimKeys ) 1011 ) 1012 ( NAME 'policyRuleStructuralRule3' 1013 FORM policyRuleNameForm3 1014 ) 1016 The attributes of policyRule are defined as follows: 1018 ( NAME 'policyRuleName' 1019 DESC 'The user-friendly name of this policy rule.' 1020 SYNTAX IA5String 1021 EQUALITY caseExactIA5Match 1022 SINGLE-VALUE 1023 ) 1025 ( NAME 'policyRuleEnabled' 1026 DESC 'An enumeration indicating whether a policy rule is 1027 administratively enabled, administratively disabled, or 1028 enabled for debug mode. The defined values for this 1029 attribute are enabled(1), disabled(2), and 1030 enabledForDebug(3).' 1031 SYNTAX INTEGER 1032 EQUALITY integerMatch 1033 SINGLE-VALUE 1034 ) 1036 ( NAME 'policyRuleConditionListType' 1037 DESC 'Indicates whether the list of policy conditions 1038 associated with this policy rule is in disjunctive 1039 normal form (DNF) or conjunctive normal form (CNF). 1040 Defined values are DNF(1) and CNF(2).' 1041 SYNTAX INTEGER 1042 EQUALITY integerMatch 1043 SINGLE-VALUE 1044 ) 1046 ( NAME 'policyRuleConditionList' 1047 DESC 'Distinguished names of policyRuleConditionAssociation 1048 entries representing associations between this policy 1049 rule and its conditions. No order is implied.' 1050 SYNTAX DN 1051 EQUALITY distinguishedNameMatch 1052 ) 1054 ( NAME 'policyRuleActionList' 1055 DESC 'Distinguished names of policyRuleActionAssociation 1056 entries representing associations between this policy 1057 rule and its actions. No order is implied.' 1059 SYNTAX DN 1060 EQUALITY distinguishedNameMatch 1061 ) 1063 ( NAME 'policyRuleValidityPeriodList' 1064 DESC 'Distinguished names of policyTimePeriodConditions that 1065 determine when the policyRule is scheduled to be active 1066 / inactive. No order is implied.' 1067 SYNTAX DN 1068 EQUALITY distinguishedNameMatch 1069 ) 1071 ( NAME 'policyRuleUsage' 1072 DESC 'This attribute is used to provide guidelines on how 1073 this policy should be used.' 1074 SYNTAX DirectoryString 1075 EQUALITY caseIgnoreMatch 1076 SINGLE-VALUE 1077 ) 1079 ( NAME 'policyRulePriority' 1080 DESC 'A non-negative integer for prioritizing this policyRule 1081 relative to other policyRules. A larger value indicates 1082 a higher priority.' 1083 SYNTAX INTEGER 1084 EQUALITY integerMatch 1085 SINGLE-VALUE 1086 ) 1088 ( NAME 'policyRuleMandatory' 1089 DESC 'A flag indicating that the evaluation of the 1090 policyConditions and execution of policyActions (if the 1091 condition list evaluates to True) is required.' 1092 SYNTAX Boolean 1093 EQUALITY booleanMatch 1094 SINGLE-VALUE 1095 ) 1097 ( NAME 'policyRuleSequencedActions' 1098 DESC 'An enumeration indicating how to interpret the action 1099 ordering indicated via the policyRuleActionList 1100 attribute. The defined values for this attribute are 1101 mandatory(1), recommended(2), and dontCare(3).' 1102 SYNTAX INTEGER 1103 EQUALITY integerMatch 1104 ) 1106 ( NAME 'policyRoles' 1107 DESC 'Each value of this attribute represents a role 1108 combination, including the special case of a 1109 "combination" containing only one role. Since this 1110 is a multi-valued attribute, more than one role 1111 combination can be associated with a single policy 1112 rule. Each value is a string of the form 1114 [&&]* 1116 where the individual role names appear in alphabetical 1117 order according to the collating sequence for UCS-2.' 1119 SYNTAX DirectoryString 1120 EQUALITY caseIgnoreMatch 1121 ) 1123 5.4. The Class policyRuleConditionAssociation 1125 This class contains attributes to represent the "extra" properties of 1126 the information model's PolicyConditionInPolicyRule association. 1127 Instances of this class are related to an instance of policyRule via 1128 DIT containment. The policy conditions themselves are represented by 1129 auxiliary subclasses of the auxiliary class policyConditionAuxClass. 1130 These auxiliary classes are attached directly to instances of 1131 policyRuleConditionAssociation for rule-specific policy conditions. 1132 For a reusable policy condition, the auxiliary class is attached to an 1133 instance of the class policyConditionInstance, and there is a DN 1134 pointer to this instance from the instance of 1135 policyRuleConditionAssociation. 1137 The class definition is as follows: 1139 ( NAME 'policyRuleConditionAssociation' 1140 DESC 'The class contains attributes characterizing the 1141 relationship between a policy rule and one of its 1142 policy conditions.' 1143 SUP policy 1144 MUST ( policyConditionGroupNumber $ policyConditionNegated $ 1145 policyConditionName ) 1146 MAY ( policyConditionDN ) 1147 ) 1149 The following DIT content rule indicates that an instance of 1150 policyRuleConditionAssociation may have attached to it the auxiliary 1151 class policyConditionAuxClass, or one of its subclasses. This 1152 combination represents a rule-specific policy condition. 1154 ( 1155 NAME 'policyRuleConditionAssociationContentRule' 1156 DESC 'shows what auxiliary classes go with this object' 1157 AUX ( policyConditionAuxClass ) 1158 ) 1160 The following DIT structure rules indicate that an instance of 1161 policyRuleConditionAssociation may be named under an instance of 1162 policyRule, where each of these instances may be named using any of 1163 their three naming attributes. 1165 ( NAME 'policyRuleConditionAssociationNameForm1' 1166 OC policyRuleConditionAssociation 1167 MUST ( cn ) 1169 ( NAME 'policyRuleConditionAssociationStructuralRule1' 1170 FORM policyRuleConditionAssociationNameForm1 1171 SUP 1172 ) 1174 ( NAME 'policyRuleConditionAssociationNameForm2' 1175 OC policyRuleConditionAssociation 1176 MUST ( policyConditionName ) 1177 ) 1179 ( NAME 'policyRuleConditionAssociationStructuralRule2' 1180 FORM policyRuleConditionAssociationNameForm2 1181 SUP 1182 ) 1183 ( NAME 'policyRuleConditionAssociationNameForm3' 1184 OC policyRuleConditionAssociation 1185 MUST ( orderedCimKeys ) 1186 ) 1188 ( NAME 'policyRuleConditionAssociationStructuralRule3' 1189 FORM policyRuleConditionAssociationNameForm3 1190 SUP 1191 ) 1193 The attributes of policyRuleConditionAssociation are defined as 1194 follows. Note that the class-specific naming attribute 1195 policyConditionName is also used in the class policyConditionInstance, 1196 where it identifies a reusable policy condition. 1198 ( 1199 NAME 'policyConditionName' 1200 DESC 'A user-friendly name for a policy condition.' 1201 SYNTAX IA5String 1202 EQUALITY caseExactIA5Match 1203 SINGLE-VALUE 1204 ) 1206 ( 1207 NAME 'policyConditionGroupNumber' 1208 DESC 'The number of the group to which a policy condition 1209 belongs. These groups are used to form the DNF or 1210 CNF expression associated with a policy rule. 1211 SYNTAX INTEGER 1212 EQUALITY integerMatch 1213 SINGLE-VALUE 1214 ) 1216 ( 1217 NAME 'policyConditionNegated' 1218 DESC 'Indicates whether a policy condition is negated in 1219 the DNF or CNF expression associated with a policy 1220 rule. The value TRUE indicates that a condition is 1221 negated' 1222 SYNTAX Boolean 1223 EQUALITY booleanMatch 1224 SINGLE-VALUE 1225 ) 1227 ( 1228 NAME 'policyConditionDN' 1229 DESC 'A DN pointer to a reusable policy condition.' 1230 SYNTAX DN 1231 EQUALITY distinguishedNameMatch 1232 SINGLE-VALUE 1233 ) 1235 5.5. The Class policyRuleActionAssociation 1237 This class contains an attribute to represent the one "extra" property 1238 of the information model's PolicyActionInPolicyRule association, which 1239 makes it possible to specify an order for executing the actions 1240 associated with a policy rule. Instances of this class are related to 1241 an instance of policyRule via DIT containment. The actions themselves 1242 are represented by auxiliary subclasses of the auxiliary class 1243 policyActionAuxClass. These auxiliary classes are attached directly 1244 to instances of policyRuleActionAssociation for rule-specific policy 1245 actions. For a reusable policy action, the auxiliary class is 1246 attached to an instance of the class policyActionInstance, and there 1247 is a DN pointer to this instance from the instance of 1248 policyRuleActionAssociation. 1250 The class definition is as follows: 1252 ( NAME 'policyRuleActionAssociation' 1253 DESC 'The class contains an attribute that represents an 1254 execution order for an action in the context of a 1255 policy rule.' 1256 SUP policy 1257 MUST ( policyActionOrder $ 1258 policyActionName ) 1259 MAY ( policyActionDN ) 1260 ) 1262 The following DIT content rule indicates that an instance of 1263 policyRuleActionAssociation may have attached to it the auxiliary 1264 class policyActionAuxClass, or one of its subclasses. This 1265 combination represents a rule-specific policy action. 1267 ( 1268 NAME 'policyRuleActionAssociationContentRule' 1269 DESC 'shows what auxiliary classes go with this object' 1270 AUX ( policyActionAuxClass ) 1271 ) 1273 The following DIT structure rules indicate that an instance of 1274 policyRuleActionAssociation may be named under an instance of 1275 policyRule, where each of these instances may be named using any of 1276 their three naming attributes. 1278 ( NAME 'policyRuleActionAssociationNameForm1' 1279 OC policyRuleActionAssociation 1280 MUST ( cn ) 1281 ) 1283 ( NAME 'policyRuleActionAssociationStructuralRule1' 1284 FORM policyRuleActionAssociationNameForm1 1285 SUP 1286 ) 1288 ( NAME 'policyRuleActionAssociationNameForm2' 1289 OC policyRuleActionAssociation 1290 MUST ( policyActionName ) 1291 ) 1293 ( NAME 'policyRuleActionAssociationStructuralRule2' 1294 FORM policyRuleActionAssociationNameForm2 1295 SUP 1296 ) 1298 ( NAME 'policyRuleActionAssociationNameForm3' 1299 OC policyRuleActionAssociation 1300 MUST ( orderedCimKeys ) 1301 ) 1303 ( NAME 'policyRuleActionAssociationStructuralRule3' 1304 FORM policyRuleActionAssociationNameForm3 1305 SUP 1306 ) 1308 The attributes of policyRuleActionAssociation are defined as follows. 1309 Note that the class-specific naming attribute policyActionName is also 1310 used in the class policyActionInstance, where it identifies a reusable 1311 policy action. 1313 ( 1314 NAME 'policyActionName' 1315 DESC 'A user-friendly name for a policy action.' 1316 SYNTAX IA5String 1317 EQUALITY caseExactIA5Match 1318 SINGLE-VALUE 1319 ) 1321 ( 1322 NAME 'policyActionOrder' 1323 DESC 'An integer indicating the relative order of an action 1324 in the context of a policy rule. 1325 SYNTAX INTEGER 1326 EQUALITY integerMatch 1327 SINGLE-VALUE 1328 ) 1330 ( 1331 NAME 'policyActionDN' 1332 DESC 'A DN pointer to a reusable policy action.' 1333 SYNTAX DN 1334 EQUALITY distinguishedNameMatch 1335 SINGLE-VALUE 1336 ) 1338 5.6. The Auxiliary Class policyConditionAuxClass 1340 The purpose of a policy condition is to determine whether or not the 1341 set of actions (contained in the policyRule that the condition applies 1342 to) should be executed or not. This auxiliary class can be attached 1343 to instances of three other classes in the Core Policy Schema. When 1344 it is attached to an instance of policyRuleConditionAssociation, or to 1345 an instance of policyRule, it represents a rule-specific policy 1346 condition. When it is attached to an instance of 1347 policyConditionInstance, it represents a reusable policy condition. 1349 Since all of the classes to which this auxiliary class may be attached 1350 are derived from "policy", the attributes of "policy" will already be 1351 defined for the entries to which this class attaches. Thus this class 1352 is derived directly from "top". 1354 The class definition is as follows: 1356 ( NAME 'policyConditionAuxClass' 1357 DESC 'A class representing a condition to be evaluated in 1358 conjunction with a policy rule.' 1359 SUP top 1360 AUXILIARY 1361 ) 1363 5.7. The Auxiliary Class policyTimePeriodConditionAuxClass 1365 This class provides a means of representing the time periods during 1366 which a policy rule is valid, i.e., active. The class definition is 1367 as follows. 1369 ( NAME 'policyTimePeriodConditionAuxClass' 1370 DESC 'A class that provides the capability of enabling / 1371 disabling a policy rule according to a predetermined 1372 schedule.' 1373 SUP policyConditionAuxClass 1374 AUXILIARY 1375 MAY ( ptpConditionTime $ ptpConditionMonthOfYearMask $ 1376 ptpConditionDayOfMonthMask $ ptpConditionDayOfWeekMask $ 1377 ptpConditionTimeOfDayMask $ ptpConditionLocalOrUtcTime ) 1378 ) 1380 The attributes of policyTimePeriodConditionAuxClass are defined as 1381 follows. Note that several of the attributes are defined as bit 1382 strings of various fixed lengths. These attributes correspond to CIM 1383 properties that include four-octet length fields prior to their 1384 semantically significant bits. Since these length fields are 1385 unnecessary in LDAP, they are not included in the bit string 1386 attributes defined in this document. 1388 ( 1389 NAME 'ptpConditionTime' 1390 DESC 'The range of calendar dates on which a policy rule is 1391 valid. The format of the string is 1392 yyyymmddThhmmss/yyyymmddThhmmss, where the first 1393 date/time may be replaced with the string 1394 "THISANDPRIOR" or the second date/time may be replaced 1395 with the string "THISANDFUTURE".' 1396 SYNTAX PrintableString 1397 EQUALITY caseIgnoreMatch 1398 SINGLE-VALUE 1399 ) 1401 ( 1402 NAME 'ptpConditionMonthOfYearMask' 1403 DESC 'A mask identifying the months of the year in which a 1404 policy rule is valid. The format is a bit string of 1405 length 12, representing the months of the 1406 year from January through December.' 1407 SYNTAX Bit String 1408 EQUALITY bitStringMatch 1409 SINGLE-VALUE 1410 ) 1412 ( 1413 NAME 'ptpConditionDayOfMonthMask' 1414 DESC 'A mask identifying the days of the month on which a 1415 policy rule is valid. The format is a bit string of 1416 length 62. The first 31 positions represent 1417 the days of the month in ascending order, from day 1 to 1418 day 31. The next 31 positions represent the days of 1419 the month in descending order, from the last day to the 1420 day 31 days from the end.' 1421 SYNTAX Bit String 1422 EQUALITY bitStringMatch 1423 SINGLE-VALUE 1424 ) 1426 ( 1427 NAME 'ptpConditionDayOfWeekMask' 1428 DESC 'A mask identifying the days of the week on which a 1429 policy rule is valid. The format is a bit string of 1430 length 7, representing the days of the week 1431 from Sunday through Saturday.' 1432 SYNTAX Bit String 1433 EQUALITY bitStringMatch 1434 SINGLE-VALUE 1436 ) 1438 ( 1439 NAME 'ptpConditionTimeOfDayMask' 1440 DESC 'The range of times at which a policy rule is valid. If 1441 the second time is earlier than the first, then the 1442 interval spans midnight. The format of the string is 1443 Thhmmss/Thhmmss.' 1444 SYNTAX PrintableString 1445 EQUALITY caseIgnoreMatch 1446 ) 1448 ( 1449 NAME 'ptpConditionLocalOrUtcTime' 1450 DESC 'An indication of whether the other times in this 1451 instance represent local times or UTC times. The 1452 defined values for this attribute are localTime(1) 1453 and utcTime(2).' 1454 SYNTAX INTEGER 1455 EQUALITY integerMatch 1456 SINGLE-VALUE 1457 ) 1459 5.8. The Auxiliary Class vendorPolicyConditionAuxClass 1461 The class definition is as follows: 1463 ( NAME 'vendorPolicyConditionAuxClass' 1464 DESC 'A class that defines a registered means to describe a 1465 policy condition.' 1466 SUP policyConditionAuxClass 1467 AUXILIARY 1468 MAY ( vendorPolicyConstraintData $ 1469 vendorPolicyConstraintEncoding ) 1470 ) 1472 The attribute definitions for vendorPolicyConditionAuxClass are as 1473 follows: 1475 ( 1476 NAME 'vendorPolicyConstraintData' 1477 DESC 'Escape mechanism for representing constraints that have 1478 not been modeled as specific attributes. The format of 1479 the values is identified by the OID stored in the 1480 attribute vendorPolicyConstraintEncoding.' 1481 SYNTAX OctetString 1482 EQUALITY octetStringMatch 1483 ) 1485 ( 1486 NAME 'vendorPolicyConstraintEncoding' 1487 DESC 'An OID identifying the format and semantics for this 1488 instance"s vendorPolicyConstraintData attribute.' 1489 SYNTAX OID 1490 EQUALITY objectIdentifierMatch 1491 SINGLE-VALUE 1492 ) 1494 5.9. The Auxiliary Class policyActionAuxClass 1496 The purpose of a policy action is to execute one or more operations 1497 that will affect network traffic and/or systems, devices, etc. in 1498 order to achieve a desired policy state. This auxiliary class can be 1499 attached to instances of three other classes in the Core Policy 1500 Schema. When it is attached to an instance of 1501 policyRuleActionAssociation, or to an instance of policyRule, it 1502 represents a rule-specific policy action. When it is attached to an 1503 instance of policyActionInstance, it represents a reusable policy 1504 action. 1506 Since all of the classes to which this auxiliary class may be attached 1507 are derived from "policy", the attributes of "policy" will already be 1508 defined for the entries to which this class attaches. Thus this class 1509 is derived directly from "top". 1511 The class definition is as follows: 1513 ( NAME 'policyActionAuxClass' 1514 DESC 'A class representing an action to be performed as a 1515 result of a policy rule.' 1516 SUP top 1517 AUXILIARY 1518 ) 1520 5.10. The Auxiliary Class vendorPolicyActionAuxClass 1522 The class definition is as follows: 1524 ( NAME 'vendorPolicyActionAuxClass' 1525 DESC 'A class that defines a registered means to describe a 1526 policy action.' 1527 SUP policyActionAuxClass 1528 AUXILIARY 1529 MAY ( vendorPolicyActionData $ vendorPolicyActionEncoding ) 1530 ) 1532 The attribute definitions for vendorPolicyActionAuxClass are as 1533 follows: 1535 ( 1536 NAME 'vendorPolicyActionData' 1537 DESC 'Escape mechanism for representing actions that have not 1538 been modeled as specific attributes. The format of the 1539 values is identified by the OID stored in the attribute 1540 vendorPolicyActionEncoding.' 1542 SYNTAX OctetString 1543 EQUALITY octetStringMatch 1544 ) 1546 ( 1547 NAME 'vendorPolicyActionEncoding' 1548 DESC 'An OID identifying the format and semantics for this 1549 instance"s vendorPolicyActionData attribute.' 1550 SYNTAX OID 1551 EQUALITY objectIdentifierMatch 1552 SINGLE-VALUE 1553 ) 1555 5.11. The Class policyInstance 1557 The role of this class in the Core Schema is to serve as a structural 1558 class to which auxiliary classes representing policy information are 1559 attached when the information is reusable. For auxiliary classes 1560 representing policy conditions and policy actions, there are 1561 alternative structural classes that may be used. See Sections 5.12 1562 and 5.13. See Section 4.3 for a complete discussion of reusable 1563 policy conditions and actions, and of the role that this class plays 1564 in how they are represented. 1566 In addition to the cn attribute it inherits from "policy", this class 1567 uses the class-specific naming attribute policyInstanceName. 1569 The class definition is as follows: 1571 ( NAME 'policyInstance' 1572 DESC 'A structural class that contains reusable policy 1573 information.' 1574 SUP policy 1575 MAY ( policyInstanceName ) 1576 ) 1578 The following DIT content rule indicates that an instance of 1579 policyInstance may have attached to it instances of the auxiliary 1580 classes policyConditionAuxClass and policyActionAuxClass. Additional 1581 DIT content rules may be defined later, for attachment of other 1582 policy-related auxiliary classes to policyInstance. 1584 ( 1585 NAME 'policyInstanceContentRule' 1586 DESC 'shows what auxiliary classes go with this class' 1587 AUX ( policyConditionAuxClass $ policyActionAuxClass) 1588 ) 1590 The following DIT structure rules indicate that an instance of 1591 policyInstance may be named under an instance of policyRepository, 1592 using any of its three naming attributes. 1594 ( NAME 'policyInstanceNameForm1' 1595 OC policyInstance 1596 MUST ( cn ) 1597 ) 1599 ( 1602 ) 1604 ( NAME 'policyInstanceNameForm2' 1605 OC policyInstance 1606 MUST ( policyInstanceName ) 1607 ) 1609 ( NAME 'policyInstanceStructuralRule2' 1610 FORM policyInstanceNameForm2 1611 SUP 1612 ) 1614 ( NAME 'policyInstanceNameForm3' 1615 OC policyInstance 1616 MUST ( orderedCimKeys ) 1617 ) 1619 ( NAME 'policyInstanceStructuralRule3' 1620 FORM policyInstanceNameForm3 1621 SUP 1622 ) 1624 The one attribute of policyInstance is defined as: 1626 ( NAME 'policyInstanceName' 1627 DESC 'The user-friendly name of this policy instance.' 1628 SYNTAX IA5String 1629 EQUALITY caseExactIA5Match 1630 SINGLE-VALUE 1631 ) 1633 5.12. The Class policyConditionInstance 1635 The role of this class in the Core Schema is to serve as a structural 1636 class to which the auxiliary class policyConditionAuxClass may be 1637 attached to form a reusable policy condition. Alternatively, a 1638 reusable policyConditionAuxClass may be attached to the more generic 1639 structural class policyInstance, defined in Section 5.11. See Section 1640 4.3 for a complete discussion of reusable policy conditions and the 1641 role that this class plays in how they are represented. 1643 In addition to the cn attribute it inherits from "policy" and the 1644 policyInstanceName attribute it inherits from policyInstance, this 1645 class uses the naming attribute policyConditionName, which was defined 1646 above in Section 5.4. 1648 The class definition is as follows: 1650 ( NAME 'policyConditionInstance' 1651 DESC 'A structural class that contains a reusable policy 1652 condition.' 1653 SUP policyInstance 1654 MAY ( policyConditionName ) 1655 ) 1657 The following DIT content rule indicates that an instance of 1658 policyConditionInstance may have attached to it an instance of the 1659 auxiliary class policyConditionAuxClass. 1661 ( 1662 NAME 'policyConditionInstanceContentRule' 1663 DESC 'shows what auxiliary classes go with this class' 1664 AUX ( policyConditionAuxClass ) 1665 ) 1667 The following DIT structure rules indicate that an instance of 1668 policyConditionInstance may be named under an instance of 1669 policyRepository, using any of its four naming attributes. 1671 ( NAME 'policyConditionInstanceNameForm1' 1672 OC policyConditionInstance 1673 MUST ( cn ) 1674 ) 1676 ( NAME 'policyConditionInstanceStructuralRule1' 1677 FORM policyConditionInstanceNameForm1 1678 SUP 1679 ) 1681 ( NAME 'policyConditionInstanceNameForm2' 1682 OC policyConditionInstance 1683 MUST ( policyConditionName ) 1684 ) 1686 ( NAME 'policyConditionInstanceStructuralRule2' 1687 FORM policyConditionInstanceNameForm2 1688 SUP 1689 ) 1691 ( NAME 'policyConditionInstanceNameForm3' 1692 OC policyConditionInstance 1693 MUST ( orderedCimKeys ) 1694 ) 1696 ( NAME 'policyConditionInstanceStructuralRule3' 1697 FORM policyConditionInstanceNameForm3 1698 SUP 1700 ) 1702 ( NAME 'policyConditionInstanceNameForm4' 1703 OC policyConditionInstance 1704 MUST ( policyInstanceName ) 1705 ) 1707 ( NAME 'policyConditionInstanceStructuralRule4' 1708 FORM policyConditionInstanceNameForm4 1709 SUP 1710 ) 1712 5.13. The Class policyActionInstance 1714 The role of this class in the Core Schema is to serve as a structural 1715 class to which the auxiliary class policyActionAuxClass may be 1716 attached to form a reusable policy action. Alternatively, a reusable 1717 policyActionAuxClass may be attached to the more generic structural 1718 class policyInstance, defined in Section 5.11. See Section 4.3 for a 1719 complete discussion of reusable policy actions and the role that this 1720 class plays in how they are represented. 1722 In addition to the cn attribute it inherits from "policy" and the 1723 policyInstanceName attribute it inherits from policyInstance, this 1724 class uses the naming attribute policyActionName, which was defined 1725 above in Section 5.5. 1727 The class definition is as follows: 1729 ( NAME 'policyActionInstance' 1730 DESC 'A structural class that contains a reusable policy 1731 action.' 1732 SUP policyInstance 1733 MAY ( policyActionName ) 1735 The following DIT content rule indicates that an instance of 1736 policyActionInstance may have attached to it an instance of the 1737 auxiliary class policyActionAuxClass. 1739 ( 1740 NAME 'policyActionInstanceContentRule' 1741 DESC 'shows what auxiliary classes go with this class' 1742 AUX ( policyActionAuxClass ) 1743 ) 1745 The following DIT structure rules indicate that an instance of 1746 policyActionInstance may be named under an instance of 1747 policyRepository, using any of its three naming attributes. 1749 ( NAME 'policyActionInstanceNameForm1' 1750 OC policyActionInstance 1751 MUST ( cn ) 1752 ) 1754 ( NAME 'policyActionInstanceStructuralRule1' 1755 FORM policyActionInstanceNameForm1 1756 SUP 1757 ) 1759 ( NAME 'policyActionInstanceNameForm2' 1760 OC policyActionInstance 1761 MUST ( policyActionName ) 1762 ) 1764 ( NAME 'policyActionInstanceStructuralRule2' 1765 FORM policyActionInstanceNameForm2 1766 SUP 1767 ) 1769 ( NAME 'policyActionInstanceNameForm3' 1770 OC policyActionInstance 1771 MUST ( orderedCimKeys ) 1772 ) 1774 ( NAME 'policyActionInstanceStructuralRule3' 1775 FORM policyActionInstanceNameForm3 1776 SUP 1777 ) 1779 ( NAME 'policyActionInstanceNameForm4' 1780 OC policyActionInstance 1781 MUST ( policyInstanceName ) 1782 ) 1784 ( NAME 'policyActionInstanceStructuralRule4' 1785 FORM policyActionInstanceNameForm4 1786 SUP 1787 ) 1789 5.14. The Auxiliary Class policyElementAuxClass 1791 This class introduces no additional attributes, beyond those defined 1792 in the class "policy" from which it is derived. Its role is to "tag" 1793 an instance of a class defined outside the realm of policy as being 1794 nevertheless relevant to a policy specification. This tagging can 1795 potentially take place at two levels: 1797 o Every instance to which policyElementAuxClass is attached becomes 1798 an instance of the class "policy", since policyElementAuxClass is a 1799 subclass of "policy". Thus a DIT search with the filter 1800 "objectClass=policy" will return the instance. (As noted earlier, 1801 this approach does not work for some directory implementations. To 1802 accommodate these implementations, policy-related entries SHOULD be 1803 tagged with the keyword "POLICY".) 1805 o With the policyKeywords attribute that it inherits from "policy", 1806 an instance to which policyElementAuxClass is attached can be 1807 tagged as being relevant to a particular type or category of 1808 policy, using standard keywords, administrator-defined keywords, or 1809 both. 1811 The class definition is as follows: 1813 ( NAME 'policyElementAuxClass' 1814 DESC 'An auxiliary class used to tag instances of classes 1815 defined outside the realm of policy as relevant to a 1816 particular policy specification.' 1817 SUP policy 1818 AUXILIARY 1819 ) 1821 5.15. The Class policyRepository 1823 This class provides a container for reusable policy information, such 1824 as reusable policy conditions and/or reusable policy actions. It is 1825 derived from several classes defined in reference [11]: 1827 top 1828 | 1829 +--cim23ManagedElement (abstract) 1830 | 1831 +--cim23ManagedSystemElement (abstract) 1832 | 1833 +--cim23LogicalElement (abstract) 1834 | 1835 +--cim23System (abstract) 1836 | 1837 +--cim23AdminDomain (abstract) 1838 | 1839 +--policyRepository (structural) 1841 The class definition is as follows: 1843 ( NAME 'policyRepository' 1844 DESC 'A container for reusable information.' 1845 SUP cim23AdminDomain 1846 MUST ( policyRepositoryName ) 1847 ) 1849 The following DIT structure rules indicate that an instance of 1850 policyRepository may be named under any superior, using any of its 1851 three naming attributes. These DIT structure rules cover, as a 1852 special case, a policyRepository that is named within the scope of 1853 another policyRepository. This special case is the mapping for the 1854 CIM aggregation PolicyRepositoryInPolicyRepository. 1856 ( NAME 'policyRepositoryNameForm1' 1857 OC policyRepository 1858 MUST ( cn ) 1859 ) 1861 ( NAME 'policyRepositoryStructuralRule1' 1862 FORM policyRepositoryNameForm1 1863 ) 1865 ( NAME 'policyRepositoryNameForm2' 1866 OC policyRepository 1867 MUST ( policyRepositoryName ) 1868 ) 1870 ( NAME 'policyRepositoryStructuralRule2' 1871 FORM policyRepositoryNameForm2 1872 ) 1874 ( NAME 'policyRepositoryNameForm3' 1875 OC policyRepository 1876 MUST ( orderedCimKeys ) 1877 ) 1879 ( NAME 'policyRepositoryStructuralRule3' 1880 FORM policyRepositoryNameForm3 1881 ) 1883 The one attribute of policyRepository is defined as follows. 1885 ( NAME 'policyRepositoryName' 1886 DESC 'The user-friendly name of this policy repository.' 1887 SYNTAX IA5String 1888 EQUALITY caseExactIA5Match 1889 SINGLE-VALUE 1890 ) 1892 5.16. The Auxiliary Class policySubtreesPtrAuxClass 1894 This auxiliary class provides a single, multi-valued attribute that 1895 points to a set of objects that are at the root of DIT subtrees 1896 containing policy-related information. By attaching this attribute to 1897 instances of various other classes, a policy administrator has a 1898 flexible way of providing an entry point into the directory that 1899 allows a client to locate and retrieve the policy information relevant 1900 to it. 1902 These entries may be placed in the DIT such that a well-known DN can 1903 be used by placing the structural entry (e.g. container) with the 1904 policySubtreesPtrAuxClass attached thereto in the root of the 1905 directory suffix. In this case, the subtree entry point can contain 1906 and/or point to all related policy entries for any well-known policy 1907 disciplines. Similarly, the subtree entry point may be placed in the 1908 DIT such that the PDP's starting point is a subtree with policy- 1909 related entries that are dependent on a hierarchically-related set of 1910 subtrees (e.g., region, division, corporate). In this latter case, 1911 DNs may be provided to the PDPs via SNMP or other techniques. 1913 This object does not provide the semantic linkages between individual 1914 policy objects, such as those between a policy group and the policy 1915 rules that belong to it. Its only role is to enable efficient bulk 1916 retrieval of policy-related objects, as described in Section 4.4. 1917 Once the objects have been retrieved, a directory client can determine 1918 the semantic linkages by following DN pointers such as 1919 policyRulesAuxContainedSet locally. 1921 Since policy-related objects will often be included in the DIT subtree 1922 beneath an object to which this auxiliary class is attached, a client 1923 SHOULD request the policy-related objects from the subtree under the 1924 object with these pointers at the same time that it requests the 1925 pointers themselves. 1927 Since clients are expected to behave in this way, the policy 1928 administrator SHOULD make sure that this subtree does not contain so 1929 many objects unrelated to policy that an initial search done in this 1930 way results in a performance problem. For example, 1931 policySubtreesPtrAuxClass SHOULD NOT be attached to the partition root 1932 for a large directory partition containing a relatively few policy- 1933 related objects along with a large number of objects unrelated to 1934 policy. A better approach would be to introduce a container object 1935 immediately below the partition root, attach policySubtreesPtrAuxClass 1936 to this container object, and then place the policy-related objects in 1937 the subtree under it. 1939 The class definition is as follows: 1941 ( NAME 'policySubtreesPtrAuxClass' 1942 DESC 'An auxiliary class providing DN pointers to roots of 1943 DIT subtrees containing policy-related objects.' 1944 SUP top 1945 AUXILIARY 1946 MAY ( policySubtreesAuxContainedSet ) 1947 ) 1949 5.16.1. The Attribute policySubtreesAuxContainedSet 1951 This attribute provides an unordered set of DN pointers to one or more 1952 objects under which policy-related information is present. The 1953 objects pointed to may or may not themselves contain policy-related 1954 information. 1956 The attribute definition is as follows: 1958 ( 1959 NAME 'policySubtreesAuxContainedSet' 1960 DESC 'Distinguished names of objects that serve as roots for 1961 DIT subtrees containing policy-related objects. No 1962 order is implied.' 1963 SYNTAX DN 1964 EQUALITY distinguishedNameMatch 1965 ) 1967 5.17. The Auxiliary Class policyGroupContainmentAuxClass 1969 This auxiliary class provides a single, multi-valued attribute that 1970 points to a set of policyGroups. By attaching this attribute to 1971 instances of various other classes, a policy administrator has a 1972 flexible way of providing an entry point into the directory that 1973 allows a client to locate and retrieve the policyGroups relevant to 1974 it. 1976 As is the case with policyRules, a policy administrator might have 1977 several different pointers to a policyGroup in the overall directory 1978 structure. The policyGroupContainmentAuxClass is the mechanism that 1979 makes it possible for the policy administrator to define all these 1980 pointers. 1982 The class definition is as follows: 1984 ( NAME 'policyGroupContainmentAuxClass' 1985 DESC 'An auxiliary class used to bind policyGroups to an 1986 appropriate container object.' 1987 SUP top 1988 AUXILIARY 1989 MAY ( policyGroupsAuxContainedSet ) 1990 ) 1992 5.17.1. The Attribute policyGroupsAuxContainedSet 1994 This attribute provides an unordered set of DN pointers to one or more 1995 policyGroups associated with the instance of a structural class to 1996 which this attribute has been appended. The attribute definition is 1997 as follows: 1999 ( 2000 NAME 'policyGroupsAuxContainedSet' 2001 DESC 'Distinguished names of policyGroups associated in some 2002 way with the instance to which this attribute has been 2003 appended. No order is implied.' 2004 SYNTAX DN 2005 EQUALITY distinguishedNameMatch 2006 ) 2008 5.18. The Auxiliary Class policyRuleContainmentAuxClass 2010 This auxiliary class provides a single, multi-valued attribute that 2011 points to a set of policyRules. By attaching this attribute to 2012 instances of various other classes, a policy administrator has a 2013 flexible way of providing an entry point into the directory that 2014 allows a client to locate and retrieve the policyRules relevant to it. 2016 A policy administrator might have several different pointers to a 2017 policyRule in the overall directory structure. For example, there 2018 might be pointers to all policyRules for traffic originating in a 2019 particular subnet from a directory entry that represents that subnet. 2020 At the same time, there might be pointers to all policyRules related 2021 to a particular DiffServ setting from an instance of a policyGroup 2022 explicitly introduced as a container for DiffServ-related policyRules. 2023 The policyRuleContainmentAuxClass is the mechanism that makes it 2024 possible for the policy administrator to define all these pointers. 2026 Note that the cn attribute does NOT need to be defined for this class. 2027 This is because an auxiliary class is used as a means to collect 2028 common attributes and treat them as properties of an object. A good 2029 analogy is a #include file, except that since an auxiliary class is a 2030 class, all the benefits of a class (e.g., inheritance) can be applied 2031 to an auxiliary class. 2033 The class definition is as follows: 2035 ( NAME 'policyRuleContainmentAuxClass' 2036 DESC 'An auxiliary class used to bind policyRules to an 2037 appropriate container object.' 2038 SUP top 2039 AUXILIARY 2040 MAY ( policyRulesAuxContainedSet ) 2041 ) 2043 5.18.1. The Attribute policyRulesAuxContainedSet 2045 This attribute provides an unordered set of DN pointers to one or more 2046 policyRules associated with the instance of a structural class to 2047 which this attribute has been appended. The attribute definition is: 2049 ( 2050 NAME 'policyRulesAuxContainedSet' 2051 DESC 'Distinguished names of policyRules associated in some 2052 way with the instance to which this attribute has been 2053 appended. No order is implied.' 2054 SYNTAX DN 2055 EQUALITY distinguishedNameMatch 2056 ) 2058 6. Extending the Core Schema 2060 The following subsections provide general guidance on how to create a 2061 domain-specific schema derived from the Core Schema, discuss how the 2062 vendor classes in the Core Schema should be used, and explain how 2063 policyTimePeriodConditions are related to other policy conditions. 2065 6.1. Subclassing policyConditionAuxClass and policyActionAuxClass 2067 In Section 4.3 above, there is a discussion of how, by representing 2068 policy conditions and policy actions as auxiliary classes in a schema, 2069 the flexibility is retained to instantiate a particular condition or 2070 action as either rule-specific or reusable. This flexibility is lost 2071 if a condition or action class is defined as structural rather than 2072 auxiliary. For standardized schemata, this document specifies that 2073 domain-specific information MUST be expressed in auxiliary subclasses 2074 of policyConditionAuxClass and policyActionAuxClass. It is 2075 RECOMMENDED that non-standardized schemata follow this practice as 2076 well. 2078 6.2. Using the Vendor Policy Encoding Attributes 2080 As discussed Section 5.8 "The Class vendorPolicyConditionAuxClass", 2081 the attributes vendorPolicyConstraintData and 2082 vendorPolicyConstraintEncoding are included in 2083 vendorPolicyConditionAuxClass to provide an escape mechanism for 2084 representing "exceptional" policy conditions. The attributes 2085 vendorPolicyActionData and vendorPolicyActionEncoding in 2086 vendorPolicyActionAuxClass class play the same role with respect to 2087 actions. This enables interoperability between different vendors. 2089 For example, imagine a network composed of access devices from vendor 2090 A, edge and core devices from vendor B, and a policy server from 2091 vendor C. It is desirable for this policy server to be able to 2092 configure and manage all of the devices from vendors A and B. 2093 Unfortunately, these devices will in general have little in common 2094 (e.g., different mechanisms, different ways for controlling those 2095 mechanisms, different operating systems, different commands, and so 2096 forth). The escape conditions provide a way for vendor-specific 2097 commands to be encoded as OctetStrings, so that a single policy server 2098 can commonly manage devices from different vendors. 2100 6.3. Using Time Validity Periods 2102 Time validity periods are defined as a subclass of 2103 policyConditionAuxClass, called policyTimePeriodCondition. This is to 2104 allow their inclusion in the AND/OR condition definitions for a 2105 policyRule. Care should be taken not to subclass 2106 policyTimePeriodCondition to add domain-specific condition properties. 2107 For example, it would be incorrect to add IPSec- or QoS-specific 2108 condition properties to the policyTimePeriodCondition class, just 2109 because IPSec or QoS includes time in its condition definition. The 2110 correct subclassing would be to create IPSec or QoS-specific 2111 subclasses of policyConditionAuxClass and then combine instances of 2112 these domain-specific condition classes with the validity period 2113 criteria. This is accomplished using the AND/OR association 2114 capabilities for policyConditions in policyRules. 2116 7. Security Considerations 2118 o General: See reference [1]. 2120 o Users: See reference [1]. 2122 o Administrators of Schema: In general, most LDAP-accessible 2123 directories do not permit old or out-of-date schemas, or schema 2124 elements to be deleted. Instead, they are rendered inactive. 2125 This makes it that much more important to get it right the first 2126 time on an operational system, in order to avoid complex inactive 2127 schema artifacts from lying about in the operational directory. 2128 The good news is that it is expected that large network operators 2129 will change schema design infrequently, and, when they do, the 2130 schema creation changes will be tested on an off-line copy of the 2131 directory before the operational directory is updated. 2132 Typically, a small group of directory schema administrators will 2133 be authorized to make these changes in a service provider or 2134 enterprise environment. The ability to maintain audit trails is 2135 also required here. 2137 o Administrators of Schema Content (Directory Entries): This group 2138 requires authorization to load values (entries) into a policy 2139 repository directory schema, i.e. read/write access. An audit 2140 trail capability is also required here. 2142 o Applications and PDPs: These entities must be authorized for 2143 read-only access to the policy repository directory, so that they 2144 may acquire policy for the purposes of passing it to their 2145 respective enforcement entities. 2147 o Security Disciplines: 2149 o Audit Trail (Non-repudiation): In general, standardizing 2150 mechanisms for non-repudiation is outside the scope of the 2151 IETF; however, we can certainly document the need for this 2152 function in systems that maintain and distribute policy. The 2153 dependency for support of this function is on the implementers 2154 of these systems, and not on any specific standards for 2155 implementation. The requirement for a policy system is that a 2156 minimum level of auditing via an auditing facility must be 2157 provided. Logging should be enabled. This working group will 2158 not specify what this minimal auditing function consists of. 2160 o Access Control/Authorization: Access Control List (ACL) 2161 functionality must be provided. Standards for directories that 2162 use LDAPv3 as an access mechanism are still being worked on in 2163 the LDAPext working group, as of this writing. The two 2164 administrative sets of users documented above will form the 2165 basis for two administrative use cases that require support. 2167 o Authentication: In the LDAP-accessible directory case, both 2168 TLS and Kerberos are acceptable for authentication. Existing 2169 LDAP implementations provide these functions within the context 2170 of the BIND request, which is adequate. We advise against 2171 using weaker mechanisms, such as clear text and HTTP Digest. 2172 Mutual authentication is recommended. The LDAPv3 protocol 2173 supports this, but implementations vary in the functionality 2174 that they support. 2176 o Integrity/Privacy: In the LDAP-accessible directory case, TLS 2177 is acceptable for encryption and data integrity on the wire. 2178 If physical or virtual access to the policy repository is in 2179 question, it may also be necessary to encrypt the policy data 2180 as it is stored on the file system; however, specification of 2181 mechanisms for this purpose are outside the scope of this 2182 working group. In any case, we recommend that the physical 2183 server be located in a physically secure environment. 2185 In the case of PDP-to-PEP communications, the use of IPSEC is 2186 recommended for providing confidentiality, data origin 2187 authentication, integrity and replay prevention. See reference 2188 [9]. 2190 o Denial of Service: We recommend the use of multiple policy 2191 repository directories, such that a denial of service attack on 2192 any one directory server will not make all policy data 2193 inaccessible to legitimate users. However, this still leaves a 2194 denial of service attack exposure. Our belief is that the use of 2195 a policy schema, in a centrally administered but physically 2196 distributed policy directory, does not increase the risk of 2197 denial of service attacks; however, such attacks are still 2198 possible. If executed successfully, such an attack could prevent 2199 PDPs from accessing a policy repository, and thus prevent them 2200 from acquiring new policy. In such a case, the PDPs, and 2201 associated PEPs would continue operating under the policies in 2202 force before the denial of service attack was launched. Note 2203 that exposure of policy systems to denial of service attacks is 2204 not any greater than the exposure of DNS with DNSSEC in place. 2206 o Other LDAP-accessible Directory Schema Considerations: 2208 o Replication: Replication among directory copies across servers 2209 should also be protected. Replicating over connections secured 2210 by SSL or IPSEC is recommended. 2212 8. Intellectual Property 2214 The IETF takes no position regarding the validity or scope of any 2215 intellectual property or other rights that might be claimed to pertain 2216 to the implementation or use of the technology described in this 2217 document or the extent to which any license under such rights might or 2218 might not be available; neither does it represent that it has made any 2219 effort to identify any such rights. Information on the IETF's 2220 procedures with respect to rights in standards-track and standards- 2221 related documentation can be found in BCP-11. 2223 Copies of claims of rights made available for publication and any 2224 assurances of licenses to be made available, or the result of an 2225 attempt made to obtain a general license or permission for the use of 2226 such proprietary rights by implementers or users of this specification 2227 can be obtained from the IETF Secretariat. 2229 The IETF invites any interested party to bring to its attention any 2230 copyrights, patents or patent applications, or other proprietary 2231 rights that may cover technology that may be required to practice this 2232 standard. Please address the information to the IETF Executive 2233 Director. 2235 9. Acknowledgments 2237 Several of the policy classes in this model first appeared in early 2238 IETF drafts on IPSec policy and QoS policy. The authors of these 2239 drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy 2240 Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael 2241 See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar. 2242 This document is closely aligned with the work being done in the 2243 Distributed Management Task Force (DMTF) Service Level Agreements and 2244 Networks working groups. We would especially like to thank Andrea 2245 Westerinen, Lee Rafalow, Glenn Waters, David Black, Michael 2246 Richardson, Mark Stevens, David Jones, Hugh Mahon, Yoram Snir, and 2247 Yoram Ramberg for their helpful comments. 2249 10. References 2251 [1] Moore, B., and E. Ellesson, J. Strassner,, A. Westerinen "Policy 2252 Core Information Model -- Version 1 Specification", draft-ietf- 2253 policy-core-info-model-07.txt, July 2000. 2255 [2] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight 2256 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2257 2252, December 1997. 2259 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2260 Levels", BCP 14, RFC 2119, March 1997. 2262 [4] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 2263 Standards Process", BCP 11, RFC 2028, October 1996. 2265 [5] Strassner, J. and S. Judd, "Directory-Enabled Networks", version 2266 3.0c5 (August 1998). A PDF file is available at 2267 http://www.murchiso.com/den/#denspec. 2269 [6] Strassner, J., policy architecture BOF presentation, 42nd IETF 2270 Meeting, Chicago, Illinois, October, 1998. Minutes of this BOF are 2271 available at the following location: 2272 http://www.ietf.org/proceedings/98aug/index.html. 2274 [7] DMTF web site, http://www.dmtf.org. 2276 [8] Moats, R., and J. Maziarski, J. Strassner, "Extensible Match Rule 2277 to Dereference Pointers", draft-moats-ldap-dereference-match-02.txt 2278 December 1999. 2280 [9] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for 2281 Policy-based Admission Control", RFC 2753, January 2000. 2283 [10] Distributed Management Task Force, Inc., "Guidelines for CIM-to- 2284 LDAP Directory Mapping", May 8, 2000. . This document is available 2285 on the following DMTF web page: http://www.dmtf.org/spec/denh.html. 2287 [11] Distributed Management Task Force, Inc., "LDAP CIM Core Schema v2.3 2288 Mapping", May 8, 2000. . This document is available on the 2289 following DMTF web page: http://www.dmtf.org/spec/denh.html. 2291 11. Authors' Addresses 2293 John Strassner 2294 Cisco Systems, Bldg 15 2295 170 West Tasman Drive 2296 San Jose, CA 95134 2297 Phone: +1 408-527-1069 2298 Fax: +1 408-527-1722 2299 E-mail: johns@cisco.com 2301 Ed Ellesson 2302 Tivoli Systems 2303 Building 10, Office R2D39 2304 3901 Miami Blvd. 2305 Durham, NC 27703 2306 Phone: +1 919-224-2111 2307 Fax: +1 919-224-2540 2308 E-mail: ed_ellesson@tivoli.com 2310 Bob Moore 2311 IBM Corporation, BRQA/502 2312 4205 S. Miami Blvd. 2313 Research Triangle Park, NC 27709 2314 Phone: +1 919-254-4436 2315 Fax: +1 919-254-6243 2316 E-mail: remoore@us.ibm.com 2318 Ryan Moats 2319 15621 Drexel Circle 2320 Omaha, NE 68135 2321 USA 2322 Phone: +1-402-894-9456 2323 E-mail: rmoats@coreon.net 2325 12. Full Copyright Statement 2327 Copyright (C) The Internet Society (2000). All Rights Reserved. 2329 This document and translations of it may be copied and furnished to 2330 others, and derivative works that comment on or otherwise explain it 2331 or assist in its implementation may be prepared, copied, published and 2332 distributed, in whole or in part, without restriction of any kind, 2333 provided that the above copyright notice and this paragraph are 2334 included on all such copies and derivative works. However, this 2335 document itself may not be modified in any way, such as by removing 2336 the copyright notice or references to the Internet Society or other 2337 Internet organizations, except as needed for the purpose of developing 2338 Internet standards in which case the procedures for copyrights defined 2339 in the Internet Standards process must be followed, or as required to 2340 translate it into languages other than English. 2342 The limited permissions granted above are perpetual and will not be 2343 revoked by the Internet Society or its successors or assigns. 2345 This document and the information contained herein is provided on an 2346 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2347 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2348 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2349 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2350 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2352 13. Appendix: Constructing the Value of orderedCimKeys 2354 Within a CIM name space, the naming is basically flat; all instances 2355 are identified by the values of their key properties, and each 2356 combination of key values must be unique. A limited form of 2357 hierarchical naming is available in CIM, however, by using weak 2358 associations: since a weak association involves propagation of key 2359 properties and their values from the superior object to the 2360 subordinate one, the subordinate object can be thought of as being 2361 named "under" the superior object. Once they have been propagated, 2362 however, propagated key properties and their values function in 2363 exactly the same way that native key properties and their values do in 2364 identifying a CIM instance. 2366 In its mapping from the CIM_ManagedElement class to the LDAP class 2367 cim23ManagedElement, reference [11] introduces a third attribute, 2368 orderedCimKeys, alongside the two attributes that it derives from the 2369 properties in the CIM class. The orderedCimKeys attribute is used 2370 only in an environment where it is necessary to map between an LDAP- 2371 accessible directory and a CIM repository. For other environments, 2372 LDAP entries are identified via their other attributes that are 2373 suitable for naming. 2375 The role of orderedCimKeys is to represent the information necessary 2376 to correlate an entry in an LDAP-accessible directory with an instance 2377 in a CIM name space. Depending on how naming of CIM-related entries 2378 is handled in an LDAP directory, the value of orderedCimKeys 2379 represents one of two things: 2381 o If the DIT hierarchy does not mirror the "weakness hierarchy" of 2382 the CIM name space, then orderedCimKeys represents all the keys of 2383 the CIM instance, both native and propagated. 2385 o If the DIT hierarchy does mirror the "weakness hierarchy" of the 2386 CIM name space, then orderedCimKeys may represent either all the 2387 keys of the instance, or only the native keys. 2389 Regardless of which of these alternatives is taken, the syntax of 2390 orderedCimKeys is the same - a DirectoryString of the form 2392 .=[,=]* 2394 where the = elements are ordered by the names of the key 2395 properties, according to the collating sequence for US ASCII. The 2396 only spaces allowed in the DirectoryString are those that fall within 2397 a element. As with alphabetizing the key properties, the goal 2398 of suppressing the spaces is once again to make the results of string 2399 operations predictable. 2401 The values of the elements are derived from the various CIM 2402 syntaxes according to a grammar specified in reference [10]. 2404 NOTE: This section diverges from the current versions of references 2405 [10] and [11]. Currently these documents define two separate 2406 attributes, one for the case where an instance is identified with both 2407 native and propagated keys, and the other for the case where it is 2408 identified only with native keys. Implementation experience has shown 2409 that it is simpler to use a single attribute (orderedCimKeys) for both 2410 of these cases, so that is what's represented here. In their next 2411 revision, it is expected that references [10] and [11] will be changed 2412 to match the description here, based on interactions with and among 2413 the team responsible for updating these documents.