1 2 3 4 5 6 7Network Working Group J. Strassner 8Request for Comments: 3703 Intelliden Corporation 9Category: Standards Track B. Moore 10 IBM Corporation 11 R. Moats 12 Lemur Networks, Inc. 13 E. Ellesson 14 February 2004 15 16 17 Policy Core Lightweight Directory Access Protocol (LDAP) Schema 18 19Status of this Memo 20 21 This document specifies an Internet standards track protocol for the 22 Internet community, and requests discussion and suggestions for 23 improvements. Please refer to the current edition of the "Internet 24 Official Protocol Standards" (STD 1) for the standardization state 25 and status of this protocol. Distribution of this memo is unlimited. 26 27Copyright Notice 28 29 Copyright (C) The Internet Society (2004). All Rights Reserved. 30 31Abstract 32 33 This document defines a mapping of the Policy Core Information Model 34 to a form that can be implemented in a directory that uses 35 Lightweight Directory Access Protocol (LDAP) as its access protocol. 36 This model defines two hierarchies of object classes: structural 37 classes representing information for representing and controlling 38 policy data as specified in RFC 3060, and relationship classes that 39 indicate how instances of the structural classes are related to each 40 other. Classes are also added to the LDAP schema to improve the 41 performance of a client's interactions with an LDAP server when the 42 client is retrieving large amounts of policy-related information. 43 These classes exist only to optimize LDAP retrievals: there are no 44 classes in the information model that correspond to them. 45 46Table of Contents 47 48 1. Introduction ................................................. 2 49 2. The Policy Core Information Model ............................ 4 50 3. Inheritance Hierarchy for the PCLS ........................... 5 51 4. General Discussion of Mapping the Information Model to LDAP .. 6 52 4.1. Summary of Class and Association Mappings .............. 7 53 4.2. Usage of DIT Content and Structure Rules and Name Forms. 9 54 4.3. Naming Attributes in the PCLS .......................... 10 55 56 57 58Strassner, et al. Standards Track [Page 1] 59 60RFC 3703 Policy Core LDAP Schema February 2004 61 62 63 4.4. Rule-Specific and Reusable Conditions and Actions ...... 11 64 4.5. Location and Retrieval of Policy Objects in the 65 Directory .............................................. 16 66 4.5.1. Aliases and Other DIT-Optimization Techniques .. 19 67 5. Class Definitions ............................................ 19 68 5.1. The Abstract Class "pcimPolicy" ........................ 21 69 5.2. The Three Policy Group Classes ......................... 22 70 5.3. The Three Policy Rule Classes .......................... 23 71 5.4. The Class pcimRuleConditionAssociation ................. 30 72 5.5. The Class pcimRuleValidityAssociation .................. 32 73 5.6. The Class pcimRuleActionAssociation .................... 34 74 5.7. The Auxiliary Class pcimConditionAuxClass .............. 36 75 5.8. The Auxiliary Class pcimTPCAuxClass .................... 36 76 5.9. The Auxiliary Class pcimConditionVendorAuxClass ........ 40 77 5.10. The Auxiliary Class pcimActionAuxClass ................. 41 78 5.11. The Auxiliary Class pcimActionVendorAuxClass ........... 42 79 5.12. The Class pcimPolicyInstance ........................... 43 80 5.13. The Auxiliary Class pcimElementAuxClass ................ 44 81 5.14. The Three Policy Repository Classes .................... 45 82 5.15. The Auxiliary Class pcimSubtreesPtrAuxClass ............ 46 83 5.16. The Auxiliary Class pcimGroupContainmentAuxClass ....... 48 84 5.17. The Auxiliary Class pcimRuleContainmentAuxClass ........ 49 85 6. Extending the Classes Defined in This Document ............... 50 86 6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 50 87 6.2. Using the Vendor Policy Attributes ..................... 50 88 6.3. Using Time Validity Periods ............................ 51 89 7. Security Considerations ...................................... 51 90 8. IANA Considerations .......................................... 53 91 8.1. Object Identifiers ..................................... 53 92 8.2. Object Identifier Descriptors .......................... 53 93 9. Acknowledgments .............................................. 56 94 10. Appendix: Constructing the Value of orderedCIMKeys .......... 57 95 11. References ................................................... 58 96 11.1. Normative References ................................... 58 97 11.2. Informative References ................................. 59 98 12. Authors' Addresses ........................................... 60 99 13. Full Copyright Statement ..................................... 61 100 1011. Introduction 102 103 This document takes as its starting point the object-oriented 104 information model for representing information for representing and 105 controlling policy data as specified in [1]. Lightweight Directory 106 Access Protocol (LDAP) [2] implementers, please note that the use of 107 the term "policy" in this document does not refer to the use of the 108 term "policy" as defined in X.501 [4]. Rather, the use of the term 109 "policy" throughout this document is defined as follows: 110 111 112 113 114Strassner, et al. Standards Track [Page 2] 115 116RFC 3703 Policy Core LDAP Schema February 2004 117 118 119 Policy is defined as a set of rules to administer, manage, and 120 control access to network resources. 121 122 This work is currently under joint development in the IETF's Policy 123 Framework working group and in the Policy working group of the 124 Distributed Management Task Force (DMTF). This model defines two 125 hierarchies of object classes: structural classes representing policy 126 information and control of policies, and relationship classes that 127 indicate how instances of the structural classes are related to each 128 other. In general, both of these class hierarchies will need to be 129 mapped to a particular data store. 130 131 This document defines the mapping of these information model classes 132 to a directory that uses LDAP as its access protocol. Two types of 133 mappings are involved: 134 135 - For the structural classes in the information model, the 136 mapping is basically one-for-one: information model classes map 137 to LDAP classes, information model properties map to LDAP 138 attributes. 139 140 - For the relationship classes in the information model, 141 different mappings are possible. In this document, the Policy 142 Core Information Model's (PCIM's) relationship classes and 143 their properties are mapped in three ways: to LDAP auxiliary 144 classes, to attributes representing distinguished name (DN) 145 references, and to superior-subordinate relationships in the 146 Directory Information Tree (DIT). 147 148 Implementations that use an LDAP directory as their policy repository 149 and want to implement policy information according to RFC 3060 [1] 150 SHALL use the LDAP schema defined in this document, or a schema that 151 subclasses from the schema defined in this document. The use of the 152 information model defined in reference [1] as the starting point 153 enables the inheritance and the relationship class hierarchies to be 154 extensible, such that other types of policy repositories, such as 155 relational databases, can also use this information. 156 157 This document fits into the overall framework for representing, 158 deploying, and managing policies being developed by the Policy 159 Framework Working Group. 160 161 The LDAP schema described in this document uses the prefix "pcim" to 162 identify its classes and attributes. It consists of ten very general 163 classes: pcimPolicy (an abstract class), three policy group classes 164 (pcimGroup, pcimGroupAuxClass, and pcimGroupInstance), three policy 165 rule classes (pcimRule, pcimRuleAuxClass, and pcimRuleInstance), and 166 three special auxiliary classes (pcimConditionAuxClass, 167 168 169 170Strassner, et al. Standards Track [Page 3] 171 172RFC 3703 Policy Core LDAP Schema February 2004 173 174 175 pcimTPCAuxClass, and pcimActionAuxClass). (Note that the 176 PolicyTimePeriodCondition auxiliary class defined in [1] would 177 normally have been named pcimTimePeriodConditionAuxClass, but this 178 name is too long for some directories. Therefore, we have 179 abbreviated this name to be pcimTPCAuxClass). 180 181 The mapping for the PCIM classes pcimGroup and pcimRule is designed 182 to be as flexible as possible. Three classes are defined for these 183 two PCIM classes. First, an abstract superclass is defined that 184 contains all required properties of each PCIM class. Then, both an 185 auxiliary class as well as a structural class are derived from the 186 abstract superclass. This provides maximum flexibility for the 187 developer. 188 189 The schema also contains two less general classes: 190 pcimConditionVendorAuxClass and pcimActionVendorAuxClass. To achieve 191 the mapping of the information model's relationships, the schema also 192 contains two auxiliary classes: pcimGroupContainmentAuxClass and 193 pcimRuleContainmentAuxClass. Capturing the distinction between 194 rule-specific and reusable policy conditions and policy actions 195 introduces seven other classes: pcimRuleConditionAssociation, 196 pcimRuleValidityAssociation, pcimRuleActionAssociation, 197 pcimPolicyInstance, and three policy repository classes 198 (pcimRepository, pcimRepositoryAuxClass, and pcimRepositoryInstance). 199 Finally, the schema includes two classes (pcimSubtreesPtrAuxClass and 200 pcimElementAuxClass) for optimizing LDAP retrievals. In all, the 201 schema contains 23 classes. 202 203 Within the context of this document, the term "PCLS" (Policy Core 204 LDAP Schema) is used to refer to the LDAP class definitions that this 205 document contains. The term "PCIM" refers to classes defined in [1]. 206 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [10]. 210 2112. The Policy Core Information Model 212 213 This document contains an LDAP schema representing the classes 214 defined in the companion document "Policy Core Information 215 Model -- Version 1 Specification" [1]. Other documents may 216 subsequently be produced, with mappings of this same PCIM to other 217 storage technologies. Since the detailed semantics of the PCIM 218 classes appear only in [1], that document is a prerequisite for 219 reading and understanding this document. 220 221 222 223 224 225 226Strassner, et al. Standards Track [Page 4] 227 228RFC 3703 Policy Core LDAP Schema February 2004 229 230 2313. Inheritance Hierarchy for the PCLS 232 233 The following diagram illustrates the class hierarchy for the LDAP 234 Classes defined in this document: 235 236 top 237 | 238 +--dlm1ManagedElement (abstract) 239 | | 240 | +--pcimPolicy (abstract) 241 | | | 242 | | +--pcimGroup (abstract) 243 | | | | 244 | | | +--pcimGroupAuxClass (auxiliary) 245 | | | | 246 | | | +--pcimGroupInstance (structural) 247 | | | 248 | | +--pcimRule (abstract) 249 | | | | 250 | | | +--pcimRuleAuxClass (auxiliary) 251 | | | | 252 | | | +--pcimRuleInstance (structural) 253 | | | 254 | | +--pcimRuleConditionAssociation (structural) 255 | | | 256 | | +--pcimRuleValidityAssociation (structural) 257 | | | 258 | | +--pcimRuleActionAssociation (structural) 259 | | | 260 | | +--pcimPolicyInstance (structural) 261 | | | 262 | | +--pcimElementAuxClass (auxiliary) 263 | | 264 | +--dlm1ManagedSystemElement (abstract) 265 | | 266 | +--dlm1LogicalElement (abstract) 267 | | 268 | +--dlm1System (abstract) 269 | | 270 | +--dlm1AdminDomain (abstract) 271 | | 272 | +--pcimRepository (abstract) 273 | | 274 | +--pcimRepositoryAuxClass (auxiliary) 275 276 277 278 279 280 281 282Strassner, et al. Standards Track [Page 5] 283 284RFC 3703 Policy Core LDAP Schema February 2004 285 286 287 top 288 | | 289 | +--pcimRepositoryInstance 290 | (structural) 291 | 292 +--pcimConditionAuxClass (auxiliary) 293 | | 294 | +---pcimTPCAuxClass (auxiliary) 295 | | 296 | +---pcimConditionVendorAuxClass (auxiliary) 297 | 298 +--pcimActionAuxClass (auxiliary) 299 | | 300 | +---pcimActionVendorAuxClass (auxiliary) 301 | 302 +--pcimSubtreesPtrAuxClass (auxiliary) 303 | 304 +--pcimGroupContainmentAuxClass (auxiliary) 305 | 306 +--pcimRuleContainmentAuxClass (auxiliary) 307 308 Figure 1. LDAP Class Inheritance Hierarchy for the PCLS 309 3104. General Discussion of Mapping the Information Model to LDAP 311 312 The classes described in Section 5 below contain certain 313 optimizations for a directory that uses LDAP as its access protocol. 314 One example of this is the use of auxiliary classes to represent some 315 of the associations defined in the information model. Other data 316 stores might need to implement these associations differently. A 317 second example is the introduction of classes specifically designed 318 to optimize retrieval of large amounts of policy-related data from a 319 directory. This section discusses some general topics related to the 320 mapping from the information model to LDAP. 321 322 The remainder of this section will discuss the following topics. 323 Section 4.1 will discuss the strategy used in mapping the classes and 324 associations defined in [1] to a form that can be represented in a 325 directory that uses LDAP as its access protocol. Section 4.2 326 discusses DIT content and structure rules, as well as name forms. 327 Section 4.3 describes the strategy used in defining naming attributes 328 for the schema described in Section 5 of this document. Section 4.4 329 defines the strategy recommended for locating and retrieving 330 PCIM-derived objects in the directory. 331 332 333 334 335 336 337 338Strassner, et al. Standards Track [Page 6] 339 340RFC 3703 Policy Core LDAP Schema February 2004 341 342 3434.1. Summary of Class and Association Mappings 344 345 Fifteen of the classes in the PCLS come directly from the nine 346 corresponding classes in the information model. Note that names of 347 classes begin with an upper case character in the information model 348 (although for CIM in particular, case is not significant in class and 349 property names), but with a lower case character in LDAP. This is 350 because although LDAP doesn't care, X.500 doesn't allow class names 351 to begin with an uppercase character. Note also that the prefix 352 "pcim" is used to identify these LDAP classes. 353 354 +---------------------------+-------------------------------+ 355 | Information Model | LDAP Class(es) | 356 +---------------------------+-------------------------------+ 357 +---------------------------+-------------------------------+ 358 | Policy | pcimPolicy | 359 +---------------------------+-------------------------------+ 360 | PolicyGroup | pcimGroup | 361 | | pcimGroupAuxClass | 362 | | pcimGroupInstance | 363 +---------------------------+-------------------------------+ 364 | PolicyRule | pcimRule | 365 | | pcimRuleAuxClass | 366 | | pcimRuleInstance | 367 +---------------------------+-------------------------------+ 368 | PolicyCondition | pcimConditionAuxClass | 369 +---------------------------+-------------------------------+ 370 | PolicyAction | pcimActionAuxClass | 371 +---------------------------+-------------------------------+ 372 | VendorPolicyCondition | pcimConditionVendorAuxClass | 373 +---------------------------+-------------------------------+ 374 | VendorPolicyAction | pcimActionVendorAuxClass | 375 +---------------------------+-------------------------------+ 376 | PolicyTimePeriodCondition | pcimTPCAuxClass | 377 +---------------------------+-------------------------------+ 378 | PolicyRepository | pcimRepository | 379 | | pcimRepositoryAuxClass | 380 | | pcimRepositoryInstance | 381 +---------------------------+-------------------------------+ 382 383 Figure 2. Mapping of Information Model Classes to LDAP 384 385 The associations in the information model map to attributes that 386 reference DNs (Distinguished Names) or to Directory Information Tree 387 (DIT) containment (i.e., superior-subordinate relationships) in LDAP. 388 Two of the attributes that reference DNs appear in auxiliary classes, 389 which allow each of them to represent several relationships from the 390 information model. 391 392 393 394Strassner, et al. Standards Track [Page 7] 395 396RFC 3703 Policy Core LDAP Schema February 2004 397 398 399+----------------------------------+----------------------------------+ 400| Information Model Association | LDAP Attribute / Class | 401+-----------------------------------+---------------------------------+ 402+-----------------------------------+---------------------------------+ 403| PolicyGroupInPolicyGroup | pcimGroupsAuxContainedSet in | 404| | pcimGroupContainmentAuxClass | 405+-----------------------------------+---------------------------------+ 406| PolicyRuleInPolicyGroup | pcimRulesAuxContainedSet in | 407| | pcimRuleContainmentAuxClass | 408+-----------------------------------+---------------------------------+ 409| PolicyConditionInPolicyRule | DIT containment or | 410| | pcimRuleConditionList in | 411| | pcimRule or | 412| | pcimConditionDN in | 413| | pcimRuleConditionAssociation | 414+-----------------------------------+---------------------------------+ 415| PolicyActionInPolicyRule | DIT containment or | 416| | pcimRuleActionList in | 417| | pcimRule or | 418| | pcimActionDN in | 419| | pcimRuleActionAssociation | 420+-----------------------------------+---------------------------------+ 421| PolicyRuleValidityPeriod | pcimRuleValidityPeriodList | 422| | in pcimRule or (if reusable) | 423| | referenced through the | 424| | pcimTimePeriodConditionDN in | 425| | pcimRuleValidityAssociation | 426+-----------------------------------+---------------------------------+ 427| PolicyConditionInPolicyRepository | DIT containment | 428+-----------------------------------+---------------------------------+ 429| PolicyActionInPolicyRepository | DIT containment | 430+-----------------------------------+---------------------------------+ 431| PolicyRepositoryInPolicyRepository| DIT containment | 432+-----------------------------------+---------------------------------+ 433 434 Figure 3. Mapping of Information Model Associations to LDAP 435 436 Of the remaining classes in the PCLS, two (pcimElementAuxClass and 437 pcimSubtreesPtrAuxClass) are included to make navigation through the 438 DIT and retrieval of the entries found there more efficient. This 439 topic is discussed below in Section 4.5. 440 441 The remaining four classes in the PCLS, pcimRuleConditionAssociation, 442 pcimRuleValidityAssociation, pcimRuleActionAssociation, and 443 pcimPolicyInstance, are all involved with the representation of 444 policy conditions and policy actions in an LDAP directory. This 445 topic is discussed below in Section 4.4. 446 447 448 449 450Strassner, et al. Standards Track [Page 8] 451 452RFC 3703 Policy Core LDAP Schema February 2004 453 454 4554.2. Usage of DIT Content and Structure Rules and Name Forms 456 457 There are three powerful tools that can be used to help define 458 schemata. The first, DIT content rules, is a way of defining the 459 content of an entry for a structural object class. It can be used to 460 specify the following characteristics of the entry: 461 462 - additional mandatory attributes that the entries are required 463 to contain 464 - additional optional attributes the entries are allowed to 465 contain 466 - the set of additional auxiliary object classes that these 467 entries are allowed to be members of 468 - any optional attributes from the structural and auxiliary 469 object class definitions that the entries are required to 470 preclude 471 472 DIT content rules are NOT mandatory for any structural object class. 473 474 A DIT structure rule, together with a name form, controls the 475 placement and naming of an entry within the scope of a subschema. 476 Name forms define which attribute type(s) are required and are 477 allowed to be used in forming the Relative Distinguished Names (RDNs) 478 of entries. DIT structure rules specify which entries are allowed to 479 be superior to other entries, and hence control the way that RDNs are 480 added together to make DNs. 481 482 A name form specifies the following: 483 484 - the structural object class of the entries named by this name 485 form 486 - attributes that are required to be used in forming the RDNs of 487 these entries 488 - attributes that are allowed to be used in forming the RDNs of 489 these entries 490 - an object identifier to uniquely identify this name form 491 492 Note that name forms can only be specified for structural object 493 classes. However, every entry in the DIT must have a name form 494 controlling it. 495 496 Unfortunately, current LDAP servers vary quite a lot in their support 497 of these features. There are also three crucial implementation 498 points that must be followed. First, X.500 use of structure rules 499 requires that a structural object class with no superior structure 500 rule be a subschema administrative point. This is exactly NOT what 501 we want for policy information. Second, when an auxiliary class is 502 subclassed, if a content rule exists for the structural class that 503 504 505 506Strassner, et al. Standards Track [Page 9] 507 508RFC 3703 Policy Core LDAP Schema February 2004 509 510 511 the auxiliary class refers to, then that content rule needs to be 512 augmented. Finally, most LDAP servers unfortunately do not support 513 inheritance of structure and content rules. 514 515 Given these concerns, DIT structure and content rules have been 516 removed from the PCLS. This is because, if included, they would be 517 normative references and would require OIDs. However, we don't want 518 to lose the insight gained in building the structure and content 519 rules of the previous version of the schema. Therefore, we describe 520 where such rules could be used in this schema, what they would 521 control, and what their effect would be. 522 5234.3. Naming Attributes in the PCLS 524 525 Instances in a directory are identified by distinguished names (DNs), 526 which provide the same type of hierarchical organization that a file 527 system provides in a computer system. A distinguished name is a 528 sequence of RDNs. An RDN provides a unique identifier for an 529 instance within the context of its immediate superior, in the same 530 way that a filename provides a unique identifier for a file within 531 the context of the folder in which it resides. 532 533 To preserve maximum naming flexibility for policy administrators, 534 three optional (i.e., "MAY") naming attributes have been defined. 535 They are: 536 537 - Each of the structural classes defined in this schema has its 538 own unique ("MAY") naming attribute. Since the naming 539 attributes are different, a policy administrator can, by using 540 these attributes, guarantee that there will be no name 541 collisions between instances of different classes, even if the 542 same value is assigned to the instances' respective naming 543 attributes. 544 545 - The LDAP attribute cn (corresponding to X.500's commonName) is 546 included as a MAY attribute in the abstract class pcimPolicy, 547 and thus by inheritance in all of its subclasses. In X.500, 548 commonName typically functions as an RDN attribute, for naming 549 instances of many classes (e.g., X.500's person class). 550 551 - A special attribute is provided for implementations that expect 552 to map between native CIM and LDAP representations of policy 553 information. This attribute, called orderedCimKeys, is defined 554 in the class dlm1ManagedElement [6]. The value of this 555 attribute is derived algorithmically from values that are 556 already present in a CIM policy instance. The normative 557 reference for this algorithm is contained in [6]. See the 558 appendix of this document for a description of the algorithm. 559 560 561 562Strassner, et al. Standards Track [Page 10] 563 564RFC 3703 Policy Core LDAP Schema February 2004 565 566 567 Since any of these naming attributes MAY be used for naming an 568 instance of a PCLS class, implementations MUST be able to accommodate 569 instances named in any of these ways. 570 571 Note that it is recommended that two or more of these attributes 572 SHOULD NOT be used together to form a multi-part RDN, since support 573 for multi-part RDNs is limited among existing directory 574 implementations. 575 5764.4. Rule-Specific and Reusable Conditions and Actions 577 578 The PCIM [1] distinguishes between two types of policy conditions and 579 policy actions: those associated with a single policy rule, and 580 those that are reusable, in the sense that they may be associated 581 with more than one policy rule. While there is no inherent 582 functional difference between a rule-specific condition or action and 583 a reusable one, there is both a usage, as well as, an implementation 584 difference between them. 585 586 Defining a condition or action as reusable vs. rule-specific reflects 587 a conscious decision on the part of the administrator in defining how 588 they are used. In addition, there are variations that reflect 589 implementing rule-specific vs. reusable policy conditions and actions 590 and how they are treated in a policy repository. The major 591 implementation differences between a rule-specific and a reusable 592 condition or action are delineated below: 593 594 1. It is natural for a rule-specific condition or action to be 595 removed from the policy repository at the same time the rule is. 596 It is just the opposite for reusable conditions and actions. 597 This is because the condition or action is conceptually attached 598 to the rule in the rule-specific case, whereas it is referenced 599 (e.g., pointed at) in the reusable case. The persistence of a 600 pcimRepository instance is independent of the persistence of a 601 pcimRule instance. 602 2. Access permissions for a rule-specific condition or action are 603 usually identical to those for the rule itself. On the other 604 hand, access permissions of reusable conditions and actions must 605 be expressible without reference to a policy rule. 606 3. Rule-specific conditions and actions require fewer accesses, 607 because the conditions and actions are "attached" to the rule. 608 In contrast, reusable conditions and actions require more 609 accesses, because each condition or action that is reusable 610 requires a separate access. 611 4. Rule-specific conditions and actions are designed for use by a 612 single rule. As the number of rules that use the same 613 rule-specific condition increase, subtle problems are created 614 (the most obvious being how to keep the rule-specific conditions 615 616 617 618Strassner, et al. Standards Track [Page 11] 619 620RFC 3703 Policy Core LDAP Schema February 2004 621 622 623 and actions updated to reflect the same value). Reusable 624 conditions and actions lend themselves for use by multiple 625 independent rules. 626 5. Reusable conditions and actions offer an optimization when 627 multiple rules are using the same condition or action. This is 628 because the reusable condition or action only needs be updated 629 once, and by virtue of DN reference, the policy rules will be 630 automatically updated. 631 632 The preceding paragraph does not contain an exhaustive list of the 633 ways in which reusable and rule-specific conditions should be treated 634 differently. Its purpose is merely to justify making a semantic 635 distinction between rule-specific and reusable, and then reflecting 636 this distinction in the policy repository itself. 637 638 When the policy repository is realized in an LDAP-accessible 639 directory, the distinction between rule-specific and reusable 640 conditions and actions is realized via placement of auxiliary classes 641 and via DIT containment. Figure 4 illustrates a policy rule Rule1 642 with one rule-specific condition CA and one rule-specific action AB. 643 644 +-----+ 645 |Rule1| 646 | | 647 +-----|- -|-----+ 648 | +-----+ | 649 | * * | 650 | * * | 651 | **** **** | 652 | * * | 653 v * * v 654 +--------+ +--------+ 655 | CA+ca | | AB+ab | 656 +--------+ +--------+ 657 658 659 +------------------------------+ 660 |LEGEND: | 661 | ***** DIT containment | 662 | + auxiliary attachment | 663 | ----> DN reference | 664 +------------------------------+ 665 666 Figure 4 Rule-Specific Policy Conditions and Actions 667 668 669 670 671 672 673 674Strassner, et al. Standards Track [Page 12] 675 676RFC 3703 Policy Core LDAP Schema February 2004 677 678 679 Because the condition and action are specific to Rule1, the auxiliary 680 classes ca and ab that represent them are attached, respectively, to 681 the structural classes CA and AB. These structural classes represent 682 not the condition ca and action ab themselves, but rather the 683 associations between Rule1 and ca, and between Rule1 and ab. 684 685 As Figure 4 illustrates, Rule1 contains DN references to the 686 structural classes CA and AB that appear below it in the DIT. At 687 first glance it might appear that these DN references are 688 unnecessary, since a subtree search below Rule1 would find all of the 689 structural classes representing the associations between Rule1 and 690 its conditions and actions. Relying only on a subtree search, 691 though, runs the risk of missing conditions or actions that should 692 have appeared in the subtree, but for some reason did not, or of 693 finding conditions or actions that were inadvertently placed in the 694 subtree, or that should have been removed from the subtree, but for 695 some reason were not. Implementation experience has suggested that 696 many (but not all) of these risks are eliminated. 697 698 However, it must be noted that this comes at a price. The use of DN 699 references, as shown in Figure 4 above, thwarts inheritance of access 700 control information as well as existence dependency information. It 701 also is subject to referential integrity considerations. Therefore, 702 it is being included as an option for the designer. 703 704 Figure 5 illustrates a second way of representing rule-specific 705 conditions and actions in an LDAP-accessible directory: attachment of 706 the auxiliary classes directly to the instance representing the 707 policy rule. When all of the conditions and actions are attached to 708 a policy rule in this way, the rule is termed a "simple" policy rule. 709 When conditions and actions are not attached directly to a policy 710 rule, the rule is termed a "complex" policy rule. 711 712 +-----------+ 713 |Rule1+ca+ab| 714 | | 715 +-----------+ 716 717 +------------------------------+ 718 |LEGEND: | 719 | + auxiliary attachment | 720 +------------------------------+ 721 722 Figure 5. A Simple Policy Rule 723 724 725 726 727 728 729 730Strassner, et al. Standards Track [Page 13] 731 732RFC 3703 Policy Core LDAP Schema February 2004 733 734 735 The simple/complex distinction for a policy rule is not all or 736 nothing. A policy rule may have its conditions attached to itself 737 and its actions attached to other entries, or it may have its actions 738 attached to itself and its conditions attached to other entries. 739 However, it SHALL NOT have either its conditions or its actions 740 attached both to itself and to other entries, with one exception: a 741 policy rule may reference its validity periods with the 742 pcimRuleValidityPeriodList attribute, but have its other conditions 743 attached to itself. 744 745 The tradeoffs between simple and complex policy rules are between the 746 efficiency of simple rules and the flexibility and greater potential 747 for reuse of complex rules. With a simple policy rule, the semantic 748 options are limited: 749 750 - All conditions are ANDed together. This combination can be 751 represented in two ways in the Disjunctive Normal Form (DNF)/ 752 Conjunctive Normal Form (CNF) (please see [1] for definitions of 753 these terms) expressions characteristic of policy conditions: as 754 a DNF expression with a single AND group, or as a CNF expression 755 with multiple single-condition OR groups. The first of these is 756 arbitrarily chosen as the representation for the ANDed conditions 757 in a simple policy rule. 758 759 - If multiple actions are included, no order can be specified for 760 them. 761 762 If a policy administrator needs to combine conditions in some other 763 way, or if there is a set of actions that must be ordered, then the 764 only option is to use a complex policy rule. 765 766 Finally, Figure 6 illustrates the same policy rule Rule1, but this 767 time its condition and action are reusable. The association classes 768 CA and AB are still present, and they are still DIT contained under 769 Rule1. But rather than having the auxiliary classes ca and ab 770 attached directly to the association classes CA and AB, each now 771 contains DN references to other entries to which these auxiliary 772 classes are attached. These other entries, CIA and AIB, are DIT 773 contained under RepositoryX, which is an instance of the class 774 pcimRepository. Because they are named under an instance of 775 pcimRepository, ca and ab are clearly identified as reusable. 776 777 778 779 780 781 782 783 784 785 786Strassner, et al. Standards Track [Page 14] 787 788RFC 3703 Policy Core LDAP Schema February 2004 789 790 791 +-----+ +-------------+ 792 |Rule1| | RepositoryX | 793 +-|- -|--+ | | 794 | +-----+ | +-------------+ 795 | * * | * * 796 | * * | * * 797 | *** **** | * * 798 | * * v * * 799 | * +---+ * * 800 | * |AB | +------+ * 801 v * | -|-------->|AIB+ab| * 802 +---+ +---+ +------+ * 803 |CA | +------+ 804 | -|------------------------>|CIA+ca| 805 +---+ +------+ 806 807 +------------------------------+ 808 |LEGEND: | 809 | ***** DIT containment | 810 | + auxiliary attachment | 811 | ----> DN reference | 812 +------------------------------+ 813 814 Figure 6. Reusable Policy Conditions and Actions 815 816 The classes pcimConditionAuxClass and pcimActionAuxClass do not 817 themselves represent actual conditions and actions: these are 818 introduced in their subclasses. What pcimConditionAuxClass and 819 pcimActionAuxClass do introduce are the semantics of being a policy 820 condition or a policy action. These are the semantics that all the 821 subclasses of pcimConditionAuxClass and pcimActionAuxClass inherit. 822 Among these semantics are those of representing either a 823 rule-specific or a reusable policy condition or policy action. 824 825 In order to preserve the ability to represent a rule-specific or a 826 reusable condition or action, as well as a simple policy rule, all 827 the subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST 828 also be auxiliary classes. 829 830 831 832 833 834 835 836 837 838 839 840 841 842Strassner, et al. Standards Track [Page 15] 843 844RFC 3703 Policy Core LDAP Schema February 2004 845 846 8474.5. Location and Retrieval of Policy Objects in the Directory 848 849 When a Policy Decision Point (PDP) goes to an LDAP directory to 850 retrieve the policy object instances relevant to the Policy 851 Enforcement Points (PEPs) it serves, it is faced with two related 852 problems: 853 854 - How does it locate and retrieve the directory entries that apply 855 to its PEPs? These entries may include instances of the PCLS 856 classes, instances of domain-specific subclasses of these 857 classes, and instances of other classes modeling such resources 858 as user groups, interfaces, and address ranges. 859 860 - How does it retrieve the directory entries it needs in an 861 efficient manner, so that retrieval of policy information from 862 the directory does not become a roadblock to scalability? There 863 are two facets to this efficiency: retrieving only the relevant 864 directory entries, and retrieving these entries using as few LDAP 865 calls as possible. 866 867 The placement of objects in the Directory Information Tree (DIT) 868 involves considerations other than how the policy-related objects 869 will be retrieved by a PDP. Consequently, all that the PCLS can do 870 is to provide a "toolkit" of classes to assist the policy 871 administrator as the DIT is being designed and built. A PDP SHOULD 872 be able to take advantage of any tools that the policy administrator 873 is able to build into the DIT, but it MUST be able to use a less 874 efficient means of retrieval if that is all it has available to it. 875 876 The basic idea behind the LDAP optimization classes is a simple one: 877 make it possible for a PDP to retrieve all the policy-related objects 878 it needs, and only those objects, using as few LDAP calls as 879 possible. An important assumption underlying this approach is that 880 the policy administrator has sufficient control over the underlying 881 DIT structure to define subtrees for storing policy information. If 882 the policy administrator does not have this level of control over DIT 883 structure, a PDP can still retrieve the policy-related objects it 884 needs individually. But it will require more LDAP access operations 885 to do the retrieval in this way. Figure 7 illustrates how LDAP 886 optimization is accomplished. 887 888 889 890 891 892 893 894 895 896 897 898Strassner, et al. Standards Track [Page 16] 899 900RFC 3703 Policy Core LDAP Schema February 2004 901 902 903 +-----+ 904 ---------------->| A | 905 DN reference to | | DN references to subtrees +---+ 906 starting object +-----+ +-------------------------->| C | 907 | o--+----+ +---+ +---+ 908 | o--+------------->| B | / \ 909 +-----+ +---+ / \ 910 / \ / \ / ... \ 911 / \ / \ 912 / \ / ... \ 913 914 Figure 7. Using the pcimSubtreesPtrAuxClass to Locate Policies 915 916 The PDP is configured initially with a DN reference to some entry in 917 the DIT. The structural class of this entry is not important; the 918 PDP is interested only in the pcimSubtreesPtrAuxClass attached to it. 919 This auxiliary class contains a multi-valued attribute with DN 920 references to objects that anchor subtrees containing policy-related 921 objects of interest to the PDP. Since pcimSubtreesPtrAuxClass is an 922 auxiliary class, it can be attached to an entry that the PDP would 923 need to access anyway - perhaps an entry containing initial 924 configuration settings for the PDP, or for a PEP that uses the PDP. 925 926 Once it has retrieved the DN references, the PDP will direct to each 927 of the objects identified by them an LDAP request that all entries in 928 its subtree be evaluated against the selection criteria specified in 929 the request. The LDAP-enabled directory then returns all entries in 930 that subtree that satisfy the specified criteria. 931 932 The selection criteria always specify that object class="pcimPolicy". 933 Since all classes representing policy rules, policy conditions, and 934 policy actions, both in the PCLS and in any domain-specific schema 935 derived from it, are subclasses of the abstract class policy, this 936 criterion evaluates to TRUE for all instances of these classes. To 937 accommodate special cases where a PDP needs to retrieve objects that 938 are not inherently policy-related (for example, an IP address range 939 object referenced by a subclass of pcimActionAuxClass representing 940 the DHCP action "assign from this address range"), the auxiliary 941 class pcimElementAuxClass can be used to "tag" an entry, so that it 942 will be found by the selection criterion "object class=pcimPolicy". 943 944 The approach described in the preceding paragraph will not work for 945 certain directory implementations, because these implementations do 946 not support matching of auxiliary classes in the objectClass 947 attribute. For environments where these implementations are expected 948 to be present, the "tagging" of entries as relevant to policy can be 949 950 951 952 953 954Strassner, et al. Standards Track [Page 17] 955 956RFC 3703 Policy Core LDAP Schema February 2004 957 958 959 accomplished by inserting the special value "POLICY" into the list of 960 values contained in the pcimKeywords attribute (provided by the 961 pcimPolicy class). 962 963 If a PDP needs only a subset of the policy-related objects in the 964 indicated subtrees, then it can be configured with additional 965 selection criteria based on the pcimKeywords attribute defined in the 966 pcimPolicy class. This attribute supports both standardized and 967 administrator- defined values. For example, a PDP could be 968 configured to request only those policy-related objects containing 969 the keywords "DHCP" and "Eastern US". 970 971 To optimize what is expected to be a typical case, the initial 972 request from the client includes not only the object to which its 973 "seed" DN references, but also the subtree contained under this 974 object. The filter for searching this subtree is whatever the client 975 is going to use later to search the other subtrees: object 976 class="pcimPolicy" or the presence of the keyword "POLICY", and/or 977 presence of a more specific value of pcimKeywords (e.g., "QoS Edge 978 Policy"). 979 980 Returning to the example in Figure 7, we see that in the best case, a 981 PDP can get all the policy-related objects it needs, and only those 982 objects, with exactly three LDAP requests: one to its starting 983 object A to get the references to B and C, as well as the 984 policy-related objects it needs from the subtree under A, and then 985 one each to B and C to get all the policy-related objects that pass 986 the selection criteria with which it was configured. Once it has 987 retrieved all of these objects, the PDP can then traverse their 988 various DN references locally to understand the semantic 989 relationships among them. The PDP should also be prepared to find a 990 reference to another subtree attached to any of the objects it 991 retrieves, and to follow this reference first, before it follows any 992 of the semantically significant references it has received. This 993 recursion permits a structured approach to identifying related 994 policies. In Figure 7, for example, if the subtree under B includes 995 departmental policies and the one under C includes divisional 996 policies, then there might be a reference from the subtree under C to 997 an object D that roots the subtree of corporate-level policies. 998 999 A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be 1000 capable of retrieving and processing the entries in the subtrees it 1001 references, and SHOULD be capable of doing all of this recursively. 1002 The same requirements apply to any other entity needing to retrieve 1003 policy information from the directory. Thus, a Policy Management 1004 Tool that retrieves policy entries from the directory in order to 1005 perform validation and conflict detection SHOULD also understand and 1006 be capable of using the pcimSubtreesPtrAuxClass. All of these 1007 1008 1009 1010Strassner, et al. Standards Track [Page 18] 1011 1012RFC 3703 Policy Core LDAP Schema February 2004 1013 1014 1015 requirements are "SHOULD"s rather than "MUST"s because an LDAP client 1016 that doesn't implement them can still access and retrieve the 1017 directory entries it needs. The process of doing so will just be 1018 less efficient than it would have been if the client had implemented 1019 these optimizations. 1020 1021 When it is serving as a tool for creating policy entries in the 1022 directory, a Policy Management Tool SHOULD support creation of 1023 pcimSubtreesPtrAuxClass entries and their references to object 1024 instances. 1025 10264.5.1. Aliases and Other DIT-Optimization Techniques 1027 1028 Additional flexibility in DIT structure is available to the policy 1029 administrator via LDAP aliasing and other techniques. Previous 1030 versions of this document have used aliases. However, because 1031 aliases are experimental, the use of aliases has been removed from 1032 this version of this document. This is because the IETF has yet to 1033 produce a specification on how aliases are represented in the 1034 directory or how server implementations are to process aliases. 1035 10365. Class Definitions 1037 1038 The semantics for the policy information classes that are to be 1039 mapped directly from the information model to an LDAP representation 1040 are detailed in [1]. Consequently, all that this document presents 1041 for these classes is the specification for how to do the mapping from 1042 the information model (which is independent of repository type and 1043 access protocol) to a form that can be accessed using LDAP. Remember 1044 that some new classes needed to be created (that were not part of 1045 [1]) to implement the LDAP mapping. These new LDAP-only classes are 1046 fully documented in this document. 1047 1048 The formal language for specifying the classes, attributes, and DIT 1049 structure and content rules is that defined in reference [3]. If 1050 your implementation does not support auxiliary class inheritance, you 1051 will have to list auxiliary classes in content rules explicitly or 1052 define them in another (implementation-specific) way. 1053 1054 The following notes apply to this section in its entirety. 1055 1056 Note 1: in the following definitions, the class and attribute 1057 definitions follow RFC 2252 [3] but they are line-wrapped to enhance 1058 human readability. 1059 1060 Note 2: where applicable, the possibilities for specifying DIT 1061 structure and content rules are noted. However, care must be taken 1062 in specifying DIT structure rules. This is because X.501 [4] states 1063 1064 1065 1066Strassner, et al. Standards Track [Page 19] 1067 1068RFC 3703 Policy Core LDAP Schema February 2004 1069 1070 1071 that an entry may only exist in the DIT as a subordinate to another 1072 superior entry (the superior) if a DIT structure rule exists in the 1073 governing subschema which: 1074 1075 1) indicates a name form for the structural object class of the 1076 subordinate entry, and 1077 2) either includes the entry's superior structure rule as a possible 1078 superior structure rule, or 1079 3) does not specify a superior structure rule. 1080 1081 If this last case (3) applies, then the entry is defined to be a 1082 subschema administrative point. This is not what is desired. 1083 Therefore, care must be taken in defining structure rules, and in 1084 particular, they must be locally augmented. 1085 1086 Note 3: Wherever possible, both an equality and a substring matching 1087 rule are defined for a particular attribute (as well as an ordering 1088 match rule to enable sorting of matching results). This provides two 1089 different choices for the developer for maximum flexibility. 1090 1091 For example, consider the pcimRoles attribute (section 5.3). Suppose 1092 that a PEP has reported that it is interested in pcimRules for three 1093 roles R1, R2, and R3. If the goal is to minimize queries, then the 1094 PDP can supply three substring filters containing the three role 1095 names. 1096 1097 These queries will return all of the pcimRules that apply to the PEP, 1098 but they may also get some that do not apply (e.g., ones that contain 1099 one of the roles R1, R2, or R3 and one or more other roles present in 1100 a role-combination [1]). 1101 1102 Another strategy would be for the PDP to use only equality filters. 1103 This approach eliminates the extraneous replies, but it requires the 1104 PDP to explicitly build the desired role-combinations itself. It 1105 also requires extra queries. Note that this approach is practical 1106 only because the role names in a role combination are required to 1107 appear in alphabetical order. 1108 1109 Note 4: in the following definitions, note that all LDAP matching 1110 rules are defined in [3] and in [9]. The corresponding X.500 1111 matching rules are defined in [8]. 1112 1113 Note 5: some of the following attribute definitions specify 1114 additional constraints on various data types (e.g., this integer has 1115 values that are valid from 1..10). Text has been added to instruct 1116 servers and applications what to do if a value outside of this range 1117 1118 1119 1120 1121 1122Strassner, et al. Standards Track [Page 20] 1123 1124RFC 3703 Policy Core LDAP Schema February 2004 1125 1126 1127 is encountered. In all cases, if a constraint is violated, then the 1128 policy rule SHOULD be treated as being disabled, meaning that 1129 execution of the policy rule SHOULD be stopped. 1130 11315.1. The Abstract Class pcimPolicy 1132 1133 The abstract class pcimPolicy is a direct mapping of the abstract 1134 class Policy from the PCIM. The class value "pcimPolicy" is also 1135 used as the mechanism for identifying policy-related instances in the 1136 Directory Information Tree. An instance of any class may be "tagged" 1137 with this class value by attaching to it the auxiliary class 1138 pcimElementAuxClass. Since pcimPolicy is derived from the class 1139 dlm1ManagedElement defined in reference [6], this specification has a 1140 normative dependency on that element of reference [6]. 1141 1142 The class definition is as follows: 1143 1144 ( 1.3.6.1.1.6.1.1 NAME 'pcimPolicy' 1145 DESC 'An abstract class that is the base class for all classes 1146 that describe policy-related instances.' 1147 SUP dlm1ManagedElement 1148 ABSTRACT 1149 MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $ 1150 pcimKeywords ) 1151 ) 1152 1153 The attribute cn is defined in RFC 2256 [7]. The dlmCaption, 1154 dlmDescription, and orderedCimKeys attributes are defined in [6]. 1155 1156 The pcimKeywords attribute is a multi-valued attribute that contains 1157 a set of keywords to assist directory clients in locating the policy 1158 objects identified by these keywords. It is defined as follows: 1159 1160 ( 1.3.6.1.1.6.2.3 NAME 'pcimKeywords' 1161 DESC 'A set of keywords to assist directory clients in 1162 locating the policy objects applicable to them.' 1163 EQUALITY caseIgnoreMatch 1164 ORDERING caseIgnoreOrderingMatch 1165 SUBSTR caseIgnoreSubstringsMatch 1166 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1167 ) 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178Strassner, et al. Standards Track [Page 21] 1179 1180RFC 3703 Policy Core LDAP Schema February 2004 1181 1182 11835.2. The Three Policy Group Classes 1184 1185 PCIM [1] defines the PolicyGroup class to serve as a generalized 1186 aggregation mechanism, enabling PolicyRules and/or PolicyGroups to be 1187 aggregated together. PCLS maps this class into three LDAP classes, 1188 called pcimGroup, pcimGroupAuxClass, and pcimGroupInstance. This is 1189 done in order to provide maximum flexibility for the DIT designer. 1190 1191 The class definitions for the three policy group classes are listed 1192 below. These class definitions do not include attributes to realize 1193 the PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations 1194 from the PCIM. This is because a pcimGroup object refers to 1195 instances of pcimGroup and pcimRule via, respectively, the attribute 1196 pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object 1197 class and the attribute pcimRulesAuxContainedSet in the 1198 pcimRuleContainmentAuxClass object class. 1199 1200 To maximize flexibility, the pcimGroup class is defined as abstract. 1201 The subclass pcimGroupAuxClass provides for auxiliary attachment to 1202 another entry, while the structural subclass pcimGroupInstance is 1203 available to represent a policy group as a standalone entry. 1204 1205 The class definitions are as follows. First, the definition of the 1206 abstract class pcimGroup: 1207 1208 ( 1.3.6.1.1.6.1.2 NAME 'pcimGroup' 1209 DESC 'A container for a set of related pcimRules and/or 1210 a set of related pcimGroups.' 1211 SUP pcimPolicy 1212 ABSTRACT 1213 MAY ( pcimGroupName ) 1214 ) 1215 1216 The one attribute of pcimGroup is pcimGroupName. This attribute is 1217 used to define a user-friendly name of this policy group, and may be 1218 used as a naming attribute if desired. It is defined as follows: 1219 1220 ( 1.3.6.1.1.6.2.4 NAME 'pcimGroupName' 1221 DESC 'The user-friendly name of this policy group.' 1222 EQUALITY caseIgnoreMatch 1223 ORDERING caseIgnoreOrderingMatch 1224 SUBSTR caseIgnoreSubstringsMatch 1225 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1226 SINGLE-VALUE 1227 ) 1228 1229 1230 1231 1232 1233 1234Strassner, et al. Standards Track [Page 22] 1235 1236RFC 3703 Policy Core LDAP Schema February 2004 1237 1238 1239 The two subclasses of pcimGroup are defined as follows. The class 1240 pcimGroupAuxClass is an auxiliary class that can be used to collect a 1241 set of related pcimRule and/or pcimGroup classes. It is defined as 1242 follows: 1243 1244 ( 1.3.6.1.1.6.1.3 NAME 'pcimGroupAuxClass' 1245 DESC 'An auxiliary class that collects a set of related 1246 pcimRule and/or pcimGroup entries.' 1247 SUP pcimGroup 1248 AUXILIARY 1249 ) 1250 1251 The class pcimGroupInstance is a structural class that can be used to 1252 collect a set of related pcimRule and/or pcimGroup classes. It is 1253 defined as follows: 1254 1255 ( 1.3.6.1.1.6.1.4 NAME 'pcimGroupInstance' 1256 DESC 'A structural class that collects a set of related 1257 pcimRule and/or pcimGroup entries.' 1258 SUP pcimGroup 1259 STRUCTURAL 1260 ) 1261 1262 A DIT content rule could be written to enable an instance of 1263 pcimGroupInstance to have attached to it either references to one or 1264 more policy groups (using pcimGroupContainmentAuxClass) or references 1265 to one or more policy rules (using pcimRuleContainmentAuxClass). 1266 This would be used to formalize the semantics of the PolicyGroup 1267 class [1]. Since these semantics do not include specifying any 1268 properties of the PolicyGroup class, the content rule would not need 1269 to specify any attributes. 1270 1271 Similarly, three separate DIT structure rules could be written, each 1272 of which would refer to a specific name form that identified one of 1273 the three possible naming attributes (i.e., pcimGroupName, cn, and 1274 orderedCIMKeys) for the pcimGroup object class. This structure rule 1275 SHOULD include a superiorStructureRule (see Note 2 at the beginning 1276 of section 5). The three name forms referenced by the three 1277 structure rules would each define one of the three naming attributes. 1278 12795.3. The Three Policy Rule Classes 1280 1281 The information model defines a PolicyRule class to represent the "If 1282 Condition then Action" semantics associated with processing policy 1283 information. For maximum flexibility, the PCLS maps this class into 1284 three LDAP classes. 1285 1286 1287 1288 1289 1290Strassner, et al. Standards Track [Page 23] 1291 1292RFC 3703 Policy Core LDAP Schema February 2004 1293 1294 1295 To maximize flexibility, the pcimRule class is defined as abstract. 1296 The subclass pcimRuleAuxClass provides for auxiliary attachment to 1297 another entry, while the structural subclass pcimRuleInstance is 1298 available to represent a policy rule as a standalone entry. 1299 1300 The conditions and actions associated with a policy rule are modeled, 1301 respectively, with auxiliary subclasses of the auxiliary classes 1302 pcimConditionAuxClass and pcimActionAuxClass. Each of these 1303 auxiliary subclasses is attached to an instance of one of three 1304 structural classes. A subclass of pcimConditionAuxClass is attached 1305 to an instance of pcimRuleInstance, to an instance of 1306 pcimRuleConditionAssociation, or to an instance of 1307 pcimPolicyInstance. Similarly, a subclass of pcimActionAuxClass is 1308 attached to an instance of pcimRuleInstance, to an instance of 1309 pcimRuleActionAssociation, or to an instance of pcimPolicyInstance. 1310 1311 The pcimRuleValidityPeriodList attribute (defined below) realizes the 1312 PolicyRuleValidityPeriod association defined in the PCIM. Since this 1313 association has no additional properties besides those that tie the 1314 association to its associated objects, this association can be 1315 realized by simply using an attribute. Thus, the 1316 pcimRuleValidityPeriodList attribute is simply a multi-valued 1317 attribute that provides an unordered set of DN references to one or 1318 more instances of the pcimTPCAuxClass, indicating when the policy 1319 rule is scheduled to be active and when it is scheduled to be 1320 inactive. A policy rule is scheduled to be active if it is active 1321 according to AT LEAST ONE of the pcimTPCAuxClass instances referenced 1322 by this attribute. 1323 1324 The PolicyConditionInPolicyRule and PolicyActionInPolicyRule 1325 associations, however, do have additional attributes. The 1326 association PolicyActionInPolicyRule defines an integer attribute to 1327 sequence the actions, and the association PolicyConditionInPolicyRule 1328 has both an integer attribute to group the condition terms as well as 1329 a Boolean property to specify whether a condition is to be negated. 1330 1331 In the PCLS, these additional association attributes are represented 1332 as attributes of two classes introduced specifically to model these 1333 associations. These classes are the pcimRuleConditionAssociation 1334 class and the pcimRuleActionAssociation class, which are defined in 1335 Sections 5.4 and 5.5, respectively. Thus, they do not appear as 1336 attributes of the class pcimRule. Instead, the pcimRuleConditionList 1337 and pcimRuleActionList attributes can be used to reference these 1338 classes. 1339 1340 1341 1342 1343 1344 1345 1346Strassner, et al. Standards Track [Page 24] 1347 1348RFC 3703 Policy Core LDAP Schema February 2004 1349 1350 1351 The class definitions for the three pcimRule classes are as follows. 1352 1353 The abstract class pcimRule is a base class for representing the "If 1354 Condition then Action" semantics associated with a policy rule. It 1355 is defined as follows: 1356 1357 ( 1.3.6.1.1.6.1.5 NAME 'pcimRule' 1358 DESC 'The base class for representing the "If Condition 1359 then Action" semantics associated with a policy rule.' 1360 SUP pcimPolicy 1361 ABSTRACT 1362 MAY ( pcimRuleName $ pcimRuleEnabled $ 1363 pcimRuleConditionListType $ pcimRuleConditionList $ 1364 pcimRuleActionList $ pcimRuleValidityPeriodList $ 1365 pcimRuleUsage $ pcimRulePriority $ 1366 pcimRuleMandatory $ pcimRuleSequencedActions $ 1367 pcimRoles ) 1368 ) 1369 1370 The PCIM [1] defines seven properties for the PolicyRule class. The 1371 PCLS defines eleven attributes for the pcimRule class, which is the 1372 LDAP equivalent of the PolicyRule class. Of these eleven attributes, 1373 seven are mapped directly from corresponding properties in PCIM's 1374 PolicyRule class. The remaining four attributes are a class-specific 1375 optional naming attribute, and three attributes used to realize the 1376 three associations that the pcimRule class participates in. 1377 1378 The pcimRuleName attribute is used as a user-friendly name of this 1379 policy rule, and can also serve as the class-specific optional naming 1380 attribute. It is defined as follows: 1381 1382 ( 1.3.6.1.1.6.2.5 NAME 'pcimRuleName' 1383 DESC 'The user-friendly name of this policy rule.' 1384 EQUALITY caseIgnoreMatch 1385 ORDERING caseIgnoreOrderingMatch 1386 SUBSTR caseIgnoreSubstringsMatch 1387 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1388 SINGLE-VALUE 1389 ) 1390 1391 The pcimRuleEnabled attribute is an integer enumeration indicating 1392 whether a policy rule is administratively enabled (value=1), 1393 administratively disabled (value=2), or enabled for debug (value=3). 1394 It is defined as follows: 1395 1396 ( 1.3.6.1.1.6.2.6 NAME 'pcimRuleEnabled' 1397 DESC 'An integer indicating whether a policy rule is 1398 administratively enabled (value=1), disabled 1399 1400 1401 1402Strassner, et al. Standards Track [Page 25] 1403 1404RFC 3703 Policy Core LDAP Schema February 2004 1405 1406 1407 (value=2), or enabled for debug (value=3).' 1408 EQUALITY integerMatch 1409 ORDERING integerOrderingMatch 1410 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1411 SINGLE-VALUE 1412 ) 1413 1414 Note: All other values for the pcimRuleEnabled attribute are 1415 considered errors, and the administrator SHOULD treat this rule as 1416 being disabled if an invalid value is found. 1417 1418 The pcimRuleConditionListType attribute is used to indicate whether 1419 the list of policy conditions associated with this policy rule is in 1420 disjunctive normal form (DNF, value=1) or conjunctive normal form 1421 (CNF, value=2). It is defined as follows: 1422 1423 ( 1.3.6.1.1.6.2.7 NAME 'pcimRuleConditionListType' 1424 DESC 'A value of 1 means that this policy rule is in 1425 disjunctive normal form; a value of 2 means that this 1426 policy rule is in conjunctive normal form.' 1427 EQUALITY integerMatch 1428 ORDERING integerOrderingMatch 1429 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1430 SINGLE-VALUE 1431 ) 1432 1433 Note: any value other than 1 or 2 for the pcimRuleConditionListType 1434 attribute is considered an error. Administrators SHOULD treat this 1435 rule as being disabled if an invalid value is found, since it is 1436 unclear how to structure the condition list. 1437 1438 The pcimRuleConditionList attribute is a multi-valued attribute that 1439 is used to realize the policyRuleInPolicyCondition association 1440 defined in [1]. It contains a set of DNs of 1441 pcimRuleConditionAssociation entries representing associations 1442 between this policy rule and its conditions. No order is implied. 1443 It is defined as follows: 1444 1445 ( 1.3.6.1.1.6.2.8 NAME 'pcimRuleConditionList' 1446 DESC 'Unordered set of DNs of pcimRuleConditionAssociation 1447 entries representing associations between this policy 1448 rule and its conditions.' 1449 EQUALITY distinguishedNameMatch 1450 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1451 ) 1452 1453 1454 1455 1456 1457 1458Strassner, et al. Standards Track [Page 26] 1459 1460RFC 3703 Policy Core LDAP Schema February 2004 1461 1462 1463 The pcimRuleActionList attribute is a multi-valued attribute that is 1464 used to realize the policyRuleInPolicyAction association defined in 1465 [1]. It contains a set of DNs of pcimRuleActionAssociation entries 1466 representing associations between this policy rule and its actions. 1467 No order is implied. It is defined as follows: 1468 1469 ( 1.3.6.1.1.6.2.9 NAME 'pcimRuleActionList' 1470 DESC 'Unordered set of DNs of pcimRuleActionAssociation 1471 entries representing associations between this policy 1472 rule and its actions.' 1473 EQUALITY distinguishedNameMatch 1474 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1475 ) 1476 1477 The pcimRuleValidityPeriodList attribute is a multi-valued attribute 1478 that is used to realize the pcimRuleValidityPeriod association that 1479 is defined in [1]. It contains a set of DNs of 1480 pcimRuleValidityAssociation entries that determine when the pcimRule 1481 is scheduled to be active or inactive. No order is implied. It is 1482 defined as follows: 1483 1484 ( 1.3.6.1.1.6.2.10 NAME 'pcimRuleValidityPeriodList' 1485 DESC 'Unordered set of DNs of pcimRuleValidityAssociation 1486 entries that determine when the pcimRule is scheduled 1487 to be active or inactive.' 1488 EQUALITY distinguishedNameMatch 1489 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1490 ) 1491 1492 The pcimRuleUsage attribute is a free-form string providing 1493 guidelines on how this policy should be used. It is defined as 1494 follows: 1495 1496 ( 1.3.6.1.1.6.2.11 NAME 'pcimRuleUsage' 1497 DESC 'This attribute is a free-form sting providing 1498 guidelines on how this policy should be used.' 1499 EQUALITY caseIgnoreMatch 1500 ORDERING caseIgnoreOrderingMatch 1501 SUBSTR caseIgnoreSubstringsMatch 1502 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1503 SINGLE-VALUE 1504 ) 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514Strassner, et al. Standards Track [Page 27] 1515 1516RFC 3703 Policy Core LDAP Schema February 2004 1517 1518 1519 The pcimRulePriority attribute is a non-negative integer that is used 1520 to prioritize this pcimRule relative to other pcimRules. A larger 1521 value indicates a higher priority. It is defined as follows: 1522 1523 ( 1.3.6.1.1.6.2.12 NAME 'pcimRulePriority' 1524 DESC 'A non-negative integer for prioritizing this 1525 pcimRule relative to other pcimRules. A larger 1526 value indicates a higher priority.' 1527 EQUALITY integerMatch 1528 ORDERING integerOrderingMatch 1529 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1530 SINGLE-VALUE 1531 ) 1532 1533 Note: if the value of the pcimRulePriority field is 0, then it SHOULD 1534 be treated as "don't care". On the other hand, if the value is 1535 negative, then it SHOULD be treated as an error and Administrators 1536 SHOULD treat this rule as being disabled. 1537 1538 The pcimRuleMandatory attribute is a Boolean attribute that, if TRUE, 1539 indicates that for this policy rule, the evaluation of its conditions 1540 and execution of its actions (if the condition is satisfied) is 1541 required. If it is FALSE, then the evaluation of its conditions and 1542 execution of its actions (if the condition is satisfied) is not 1543 required. This attribute is defined as follows: 1544 1545 ( 1.3.6.1.1.6.2.13 NAME 'pcimRuleMandatory' 1546 DESC 'If TRUE, indicates that for this policy rule, the 1547 evaluation of its conditions and execution of its 1548 actions (if the condition is satisfied) is required.' 1549 EQUALITY booleanMatch 1550 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1551 SINGLE-VALUE 1552 ) 1553 1554 The pcimRuleSequencedActions attribute is an integer enumeration that 1555 is used to indicate that the ordering of actions defined by the 1556 pcimActionOrder attribute is either mandatory(value=1), 1557 recommended(value=2), or dontCare(value=3). It is defined as 1558 follows: 1559 1560 ( 1.3.6.1.1.6.2.14 NAME 'pcimRuleSequencedActions' 1561 DESC 'An integer enumeration indicating that the ordering of 1562 actions defined by the pcimActionOrder attribute is 1563 mandatory(1), recommended(2), or dontCare(3).' 1564 EQUALITY integerMatch 1565 ORDERING integerOrderingMatch 1566 1567 1568 1569 1570Strassner, et al. Standards Track [Page 28] 1571 1572RFC 3703 Policy Core LDAP Schema February 2004 1573 1574 1575 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1576 SINGLE-VALUE 1577 ) 1578 1579 Note: if the value of pcimRulesSequencedActions field is not one of 1580 these three values, then Administrators SHOULD treat this rule as 1581 being disabled. 1582 1583 The pcimRoles attribute represents the policyRoles property of [1]. 1584 Each value of this attribute represents a role-combination, which is 1585 a string of the form: 1586 <RoleName>[&&<RoleName>]* where the individual role names appear 1587 in alphabetical order according to the collating sequence for UCS-2. 1588 This attribute is defined as follows: 1589 1590 ( 1.3.6.1.1.6.2.15 NAME 'pcimRoles' 1591 DESC 'Each value of this attribute represents a role- 1592 combination.' 1593 EQUALITY caseIgnoreMatch 1594 ORDERING caseIgnoreOrderingMatch 1595 SUBSTR caseIgnoreSubstringsMatch 1596 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1597 ) 1598 1599 Note: if the value of the pcimRoles attribute does not conform to the 1600 format "<RoleName>[&&<RoleName>]*" (see Section 6.3.7 of [1]), then 1601 this attribute is malformed and its policy rule SHOULD be treated as 1602 being disabled. 1603 1604 The two subclasses of the pcimRule class are defined as follows. 1605 First, the pcimRuleAuxClass is an auxiliary class for representing 1606 the "If Condition then Action" semantics associated with a policy 1607 rule. Its class definition is as follows: 1608 1609 ( 1.3.6.1.1.6.1.6 NAME 'pcimRuleAuxClass' 1610 DESC 'An auxiliary class for representing the "If Condition 1611 then Action" semantics associated with a policy rule.' 1612 SUP pcimRule 1613 AUXILIARY 1614 ) 1615 1616 The pcimRuleInstance is a structural class for representing the "If 1617 Condition then Action" semantics associated with a policy rule. Its 1618 class definition is as follows: 1619 1620 ( 1.3.6.1.1.6.1.7 NAME 'pcimRuleInstance' 1621 DESC 'A structural class for representing the "If Condition 1622 then Action" semantics associated with a policy rule.' 1623 1624 1625 1626Strassner, et al. Standards Track [Page 29] 1627 1628RFC 3703 Policy Core LDAP Schema February 2004 1629 1630 1631 SUP pcimRule 1632 STRUCTURAL 1633 ) 1634 1635 A DIT content rule could be written to enable an instance of 1636 pcimRuleInstance to have attached to it either references to one or 1637 more policy conditions (using pcimConditionAuxClass) or references to 1638 one or more policy actions (using pcimActionAuxClass). This would be 1639 used to formalize the semantics of the PolicyRule class [1]. Since 1640 these semantics do not include specifying any properties of the 1641 PolicyRule class, the content rule would not need to specify any 1642 attributes. 1643 1644 Similarly, three separate DIT structure rules could be written, each 1645 of which would refer to a specific name form that identified one of 1646 its three possible naming attributes (i.e., pcimRuleName, cn, and 1647 orderedCIMKeys). This structure rule SHOULD include a 1648 superiorStructureRule (see Note 2 at the beginning of section 5). 1649 The three name forms referenced by the three structure rules would 1650 each define one of the three naming attributes. 1651 16525.4. The Class pcimRuleConditionAssociation 1653 1654 This class contains attributes to represent the properties of the 1655 PCIM's PolicyConditionInPolicyRule association. Instances of this 1656 class are related to an instance of pcimRule via DIT containment. 1657 The policy conditions themselves are represented by auxiliary 1658 subclasses of the auxiliary class pcimConditionAuxClass. These 1659 auxiliary classes are attached directly to instances of 1660 pcimRuleConditionAssociation for rule-specific policy conditions. 1661 For a reusable policy condition, the policyCondition auxiliary 1662 subclass is attached to an instance of the class pcimPolicyInstance 1663 (which is presumably associated with a pcimRepository by DIT 1664 containment), and the policyConditionDN attribute (of this class) is 1665 used to reference the reusable policyCondition instance. 1666 1667 The class definition is as follows: 1668 1669 ( 1.3.6.1.1.6.1.8 NAME 'pcimRuleConditionAssociation' 1670 DESC 'This class contains attributes characterizing the 1671 relationship between a policy rule and one of its 1672 policy conditions.' 1673 SUP pcimPolicy 1674 MUST ( pcimConditionGroupNumber $ pcimConditionNegated ) 1675 MAY ( pcimConditionName $ pcimConditionDN ) 1676 ) 1677 1678 1679 1680 1681 1682Strassner, et al. Standards Track [Page 30] 1683 1684RFC 3703 Policy Core LDAP Schema February 2004 1685 1686 1687 The attributes of this class are defined as follows. 1688 1689 The pcimConditionGroupNumber attribute is a non-negative integer. It 1690 is used to identify the group to which the condition referenced by 1691 this association is assigned. This attribute is defined as follows: 1692 1693 ( 1.3.6.1.1.6.2.16 1694 NAME 'pcimConditionGroupNumber' 1695 DESC 'The number of the group to which a policy condition 1696 belongs. This is used to form the DNF or CNF 1697 expression associated with a policy rule.' 1698 EQUALITY integerMatch 1699 ORDERING integerOrderingMatch 1700 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1701 SINGLE-VALUE 1702 ) 1703 1704 Note that this number is non-negative. A negative value for this 1705 attribute is invalid, and any policy rule that refers to an invalid 1706 entry SHOULD be treated as being disabled. 1707 1708 The pcimConditionNegated attribute is a Boolean attribute that 1709 indicates whether this policy condition is to be negated or not. If 1710 it is TRUE (FALSE), it indicates that a policy condition IS (IS NOT) 1711 negated in the DNF or CNF expression associated with a policy rule. 1712 This attribute is defined as follows: 1713 1714 ( 1.3.6.1.1.6.2.17 1715 NAME 'pcimConditionNegated' 1716 DESC 'If TRUE (FALSE), it indicates that a policy condition 1717 IS (IS NOT) negated in the DNF or CNF expression 1718 associated with a policy rule.' 1719 EQUALITY booleanMatch 1720 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1721 SINGLE-VALUE 1722 ) 1723 1724 The pcimConditionName is a user-friendly name for identifying this 1725 policy condition, and may be used as a naming attribute if desired. 1726 This attribute is defined as follows: 1727 1728 ( 1.3.6.1.1.6.2.18 1729 NAME 'pcimConditionName' 1730 DESC 'A user-friendly name for a policy condition.' 1731 EQUALITY caseIgnoreMatch 1732 ORDERING caseIgnoreOrderingMatch 1733 SUBSTR caseIgnoreSubstringsMatch 1734 1735 1736 1737 1738Strassner, et al. Standards Track [Page 31] 1739 1740RFC 3703 Policy Core LDAP Schema February 2004 1741 1742 1743 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1744 SINGLE-VALUE 1745 ) 1746 1747 The pcimConditionDN attribute is a DN that references an instance of 1748 a reusable policy condition. This attribute is defined as follows: 1749 1750 ( 1.3.6.1.1.6.2.19 1751 NAME 'pcimConditionDN' 1752 DESC 'A DN that references an instance of a reusable policy 1753 condition.' 1754 EQUALITY distinguishedNameMatch 1755 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1756 SINGLE-VALUE 1757 ) 1758 1759 A DIT content rule could be written to enable an instance of 1760 pcimRuleConditionAssociation to have attached to it an instance of 1761 the auxiliary class pcimConditionAuxClass, or one of its subclasses. 1762 This would be used to formalize the semantics of the 1763 PolicyConditionInPolicyRule association. Specifically, this would be 1764 used to represent a rule-specific policy condition [1]. 1765 Similarly, three separate DIT structure rules could be written. Each 1766 of these DIT structure rules would refer to a specific name form that 1767 defined two important semantics. First, each name form would 1768 identify one of the three possible naming attributes (i.e., 1769 pcimConditionName, cn, and orderedCIMKeys) for the 1770 pcimRuleConditionAssociation object class. Second, each name form 1771 would require that an instance of the pcimRuleConditionAssociation 1772 class have as its superior an instance of the pcimRule class. This 1773 structure rule SHOULD also include a superiorStructureRule (see Note 1774 2 at the beginning of section 5). 1775 17765.5. The Class pcimRuleValidityAssociation 1777 1778 The policyRuleValidityPeriod aggregation is mapped to the PCLS 1779 pcimRuleValidityAssociation class. This class represents the 1780 scheduled activation and deactivation of a policy rule by binding the 1781 definition of times that the policy is active to the policy rule 1782 itself. The "scheduled" times are either identified through an 1783 attached auxiliary class pcimTPCAuxClass, or are referenced through 1784 its pcimTimePeriodConditionDN attribute. 1785 1786 This class is defined as follows: 1787 1788 ( 1.3.6.1.1.6.1.9 NAME 'pcimRuleValidityAssociation' 1789 DESC 'This defines the scheduled activation or deactivation 1790 of a policy rule.' 1791 1792 1793 1794Strassner, et al. Standards Track [Page 32] 1795 1796RFC 3703 Policy Core LDAP Schema February 2004 1797 1798 1799 SUP pcimPolicy 1800 STRUCTURAL 1801 MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN ) 1802 ) 1803 1804 The attributes of this class are defined as follows: 1805 1806 The pcimValidityConditionName attribute is used to define a 1807 user-friendly name of this condition, and may be used as a naming 1808 attribute if desired. This attribute is defined as follows: 1809 1810 ( 1.3.6.1.1.6.2.20 1811 NAME 'pcimValidityConditionName' 1812 DESC 'A user-friendly name for identifying an instance of 1813 a pcimRuleValidityAssociation entry.' 1814 EQUALITY caseIgnoreMatch 1815 ORDERING caseIgnoreOrderingMatch 1816 SUBSTR caseIgnoreSubstringsMatch 1817 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1818 SINGLE-VALUE 1819 ) 1820 1821 The pcimTimePeriodConditionDN attribute is a DN that references a 1822 reusable time period condition. It is defined as follows: 1823 1824 ( 1.3.6.1.1.6.2.21 1825 NAME 'pcimTimePeriodConditionDN' 1826 DESC 'A reference to a reusable policy time period 1827 condition.' 1828 EQUALITY distinguishedNameMatch 1829 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1830 SINGLE-VALUE 1831 ) 1832 1833 A DIT content rule could be written to enable an instance of 1834 pcimRuleValidityAssociation to have attached to it an instance of the 1835 auxiliary class pcimTPCAuxClass, or one of its subclasses. This 1836 would be used to formalize the semantics of the 1837 PolicyRuleValidityPeriod aggregation [1]. 1838 1839 Similarly, three separate DIT structure rules could be written. Each 1840 of these DIT structure rules would refer to a specific name form that 1841 defined two important semantics. First, each name form would 1842 identify one of the three possible naming attributes (i.e., 1843 pcimValidityConditionName, cn, and orderedCIMKeys) for the 1844 pcimRuleValidityAssociation object class. Second, each name form 1845 would require that an instance of the pcimRuleValidityAssociation 1846 class have as its superior an instance of the pcimRule class. This 1847 1848 1849 1850Strassner, et al. Standards Track [Page 33] 1851 1852RFC 3703 Policy Core LDAP Schema February 2004 1853 1854 1855 structure rule SHOULD also include a superiorStructureRule (see Note 1856 2 at the beginning of section 5). 1857 18585.6. The Class pcimRuleActionAssociation 1859 1860 This class contains an attribute to represent the one property of the 1861 PCIM PolicyActionInPolicyRule association, ActionOrder. This 1862 property is used to specify an order for executing the actions 1863 associated with a policy rule. Instances of this class are related 1864 to an instance of pcimRule via DIT containment. The actions 1865 themselves are represented by auxiliary subclasses of the auxiliary 1866 class pcimActionAuxClass. 1867 1868 These auxiliary classes are attached directly to instances of 1869 pcimRuleActionAssociation for rule-specific policy actions. For a 1870 reusable policy action, the pcimAction auxiliary subclass is attached 1871 to an instance of the class pcimPolicyInstance (which is presumably 1872 associated with a pcimRepository by DIT containment), and the 1873 pcimActionDN attribute (of this class) is used to reference the 1874 reusable pcimCondition instance. 1875 1876 The class definition is as follows: 1877 1878 ( 1.3.6.1.1.6.1.10 NAME 'pcimRuleActionAssociation' 1879 DESC 'This class contains attributes characterizing the 1880 relationship between a policy rule and one of its 1881 policy actions.' 1882 SUP pcimPolicy 1883 MUST ( pcimActionOrder ) 1884 MAY ( pcimActionName $ pcimActionDN ) 1885 ) 1886 1887 The pcimActionName attribute is used to define a user-friendly name 1888 of this action, and may be used as a naming attribute if desired. 1889 This attribute is defined as follows: 1890 1891 ( 1.3.6.1.1.6.2.22 1892 NAME 'pcimActionName' 1893 DESC 'A user-friendly name for a policy action.' 1894 EQUALITY caseIgnoreMatch 1895 ORDERING caseIgnoreOrderingMatch 1896 SUBSTR caseIgnoreSubstringsMatch 1897 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1898 SINGLE-VALUE 1899 ) 1900 1901 1902 1903 1904 1905 1906Strassner, et al. Standards Track [Page 34] 1907 1908RFC 3703 Policy Core LDAP Schema February 2004 1909 1910 1911 The pcimActionOrder attribute is an unsigned integer that is used to 1912 indicate the relative position of an action in a sequence of actions 1913 that are associated with a given policy rule. When this number is 1914 positive, it indicates a place in the sequence of actions to be 1915 performed, with smaller values indicating earlier positions in the 1916 sequence. If the value is zero, then this indicates that the order 1917 is irrelevant. Note that if two or more actions have the same 1918 non-zero value, they may be performed in any order as long as they 1919 are each performed in the correct place in the overall sequence of 1920 actions. This attribute is defined as follows: 1921 1922 ( 1.3.6.1.1.6.2.23 1923 NAME 'pcimActionOrder' 1924 DESC 'An integer indicating the relative order of an action 1925 in the context of a policy rule.' 1926 EQUALITY integerMatch 1927 ORDERING integerOrderingMatch 1928 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1929 SINGLE-VALUE 1930 ) 1931 1932 Note: if the value of the pcimActionOrder field is negative, then it 1933 SHOULD be treated as an error and any policy rule that refers to such 1934 an entry SHOULD be treated as being disabled. 1935 1936 The pcimActionDN attribute is a DN that references a reusable policy 1937 action. It is defined as follows: 1938 1939 ( 1.3.6.1.1.6.2.24 1940 NAME 'pcimActionDN' 1941 DESC 'A DN that references a reusable policy action.' 1942 EQUALITY distinguishedNameMatch 1943 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1944 SINGLE-VALUE 1945 ) 1946 1947 A DIT content rule could be written to enable an instance of 1948 pcimRuleActionAssociation to have attached to it an instance of the 1949 auxiliary class pcimActionAuxClass, or one of its subclasses. This 1950 would be used to formalize the semantics of the 1951 PolicyActionInPolicyRule association. Specifically, this would be 1952 used to represent a rule-specific policy action [1]. 1953 1954 Similarly, three separate DIT structure rules could be written. Each 1955 of these DIT structure rules would refer to a specific name form that 1956 defined two important semantics. First, each name form would 1957 identify one of the three possible naming attributes (i.e., 1958 pcimActionName, cn, and orderedCIMKeys) for the 1959 1960 1961 1962Strassner, et al. Standards Track [Page 35] 1963 1964RFC 3703 Policy Core LDAP Schema February 2004 1965 1966 1967 pcimRuleActionAssociation object class. Second, each name form would 1968 require that an instance of the pcimRuleActionAssociation class have 1969 as its superior an instance of the pcimRule class. This structure 1970 rule should also include a superiorStructureRule (see Note 2 at the 1971 beginning of section 5). 1972 19735.7. The Auxiliary Class pcimConditionAuxClass 1974 1975 The purpose of a policy condition is to determine whether or not the 1976 set of actions (contained in the pcimRule that the condition applies 1977 to) should be executed or not. This class defines the basic 1978 organizational semantics of a policy condition, as specified in [1]. 1979 Subclasses of this auxiliary class can be attached to instances of 1980 three other classes in the PCLS. When a subclass of this class is 1981 attached to an instance of pcimRuleConditionAssociation, or to an 1982 instance of pcimRule, it represents a rule-specific policy condition. 1983 When a subclass of this class is attached to an instance of 1984 pcimPolicyInstance, it represents a reusable policy condition. 1985 1986 Since all of the classes to which subclasses of this auxiliary class 1987 may be attached are derived from the pcimPolicy class, the attributes 1988 of pcimPolicy will already be defined for the entries to which these 1989 subclasses attach. Thus, this class is derived directly from "top". 1990 1991 The class definition is as follows: 1992 1993 ( 1.3.6.1.1.6.1.11 NAME 'pcimConditionAuxClass' 1994 DESC 'A class representing a condition to be evaluated in 1995 conjunction with a policy rule.' 1996 SUP top 1997 AUXILIARY 1998 ) 1999 20005.8. The Auxiliary Class pcimTPCAuxClass 2001 2002 The PCIM defines a time period class, PolicyTimePeriodCondition, to 2003 provide a means of representing the time periods during which a 2004 policy rule is valid, i.e., active. It also defines an aggregation, 2005 PolicyRuleValidityPeriod, so that time periods can be associated with 2006 a PolicyRule. The LDAP mapping also provides two classes, one for 2007 the time condition itself, and one for the aggregation. 2008 2009 In the PCIM, the time period class is named 2010 PolicyTimePeriodCondition. However, the resulting name of the 2011 auxiliary class in this mapping (pcimTimePeriodConditionAuxClass) 2012 exceeds the length of a name that some directories can store. 2013 Therefore, the name has been shortened to pcimTPCAuxClass. 2014 2015 2016 2017 2018Strassner, et al. Standards Track [Page 36] 2019 2020RFC 3703 Policy Core LDAP Schema February 2004 2021 2022 2023 The class definition is as follows: 2024 2025 ( 1.3.6.1.1.6.1.12 NAME 'pcimTPCAuxClass' 2026 DESC 'This provides the capability of enabling or disabling 2027 a policy rule according to a predetermined schedule.' 2028 SUP pcimConditionAuxClass 2029 AUXILIARY 2030 MAY ( pcimTPCTime $ pcimTPCMonthOfYearMask $ 2031 pcimTPCDayOfMonthMask $ pcimTPCDayOfWeekMask $ 2032 pcimTPCTimeOfDayMask $ pcimTPCLocalOrUtcTime ) 2033 ) 2034 2035 The attributes of the pcimTPCAuxClass are defined as follows. 2036 2037 The pcimTPCTime attribute represents the time period that a policy 2038 rule is enabled for. This attribute is defined as a string in [1] 2039 with a special format which defines a time period with a starting 2040 date and an ending date separated by a forward slash ("/"), as 2041 follows: 2042 2043 yyyymmddThhmmss/yyyymmddThhmmss 2044 2045 where the first date and time may be replaced with the string 2046 "THISANDPRIOR" or the second date and time may be replaced with the 2047 string "THISANDFUTURE". This attribute is defined as follows: 2048 2049 ( 1.3.6.1.1.6.2.25 2050 NAME 'pcimTPCTime' 2051 DESC 'The start and end times on which a policy rule is 2052 valid.' 2053 EQUALITY caseIgnoreMatch 2054 ORDERING caseIgnoreOrderingMatch 2055 SUBSTR caseIgnoreSubstringsMatch 2056 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 2057 SINGLE-VALUE 2058 ) 2059 2060 The value of this attribute SHOULD be checked against its defined 2061 format ("yyyymmddThhmmss/yyyymmddThhmmss", where the first and second 2062 date strings may be replaced with the strings "THISANDPRIOR" and 2063 "THISANDFUTURE"). If the value of this attribute does not conform to 2064 this syntax, then this SHOULD be considered an error and the policy 2065 rule SHOULD be treated as being disabled. 2066 2067 The next four attributes (pcimTPCMonthOfYearMask, 2068 pcimTPCDayOfMonthMask, pcimTPCDayOfWeekMask, and 2069 pcimTPCTimeOfDayMask) are all defined as octet strings in [1]. 2070 However, the semantics of each of these attributes are contained in 2071 2072 2073 2074Strassner, et al. Standards Track [Page 37] 2075 2076RFC 3703 Policy Core LDAP Schema February 2004 2077 2078 2079 bit strings of various fixed lengths. Therefore, the PCLS uses a 2080 syntax of Bit String to represent each of them. The definition of 2081 these four attributes are as follows. 2082 2083 The pcimTPCMonthOfYearMask attribute defines a 12-bit mask 2084 identifying the months of the year in which a policy rule is valid. 2085 The format is a bit string of length 12, representing the months of 2086 the year from January through December. The definition of this 2087 attribute is as follows: 2088 2089 ( 1.3.6.1.1.6.2.26 2090 NAME 'pcimTPCMonthOfYearMask' 2091 DESC 'This identifies the valid months of the year for a 2092 policy rule using a 12-bit string that represents the 2093 months of the year from January through December.' 2094 EQUALITY bitStringMatch 2095 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 2096 SINGLE-VALUE 2097 ) 2098 2099 The value of this attribute SHOULD be checked against its defined 2100 format. If the value of this attribute does not conform to this 2101 syntax, then this SHOULD be considered an error and the policy rule 2102 SHOULD be treated as being disabled. 2103 2104 The pcimTPCMonthOfDayMask attribute defines a mask identifying the 2105 days of the month on which a policy rule is valid. The format is a 2106 bit string of length 62. The first 31 positions represent the days 2107 of the month in ascending order, from day 1 to day 31. The next 31 2108 positions represent the days of the month in descending order, from 2109 the last day to the day 31 days from the end. The definition of this 2110 attribute is as follows: 2111 2112 ( 1.3.6.1.1.6.2.27 2113 NAME 'pcimTPCDayOfMonthMask' 2114 DESC 'This identifies the valid days of the month for a 2115 policy rule using a 62-bit string. The first 31 2116 positions represent the days of the month in ascending 2117 order, and the next 31 positions represent the days of 2118 the month in descending order.' 2119 EQUALITY bitStringMatch 2120 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 2121 SINGLE-VALUE 2122 ) 2123 2124 2125 2126 2127 2128 2129 2130Strassner, et al. Standards Track [Page 38] 2131 2132RFC 3703 Policy Core LDAP Schema February 2004 2133 2134 2135 The value of this attribute SHOULD be checked against its defined 2136 format. If the value of this attribute does not conform to this 2137 syntax, then this SHOULD be considered an error and the policy rule 2138 SHOULD be treated as being disabled. 2139 2140 The pcimTPCDayOfWeekMask attribute defines a mask identifying the 2141 days of the week on which a policy rule is valid. The format is a 2142 bit string of length 7, representing the days of the week from Sunday 2143 through Saturday. The definition of this attribute is as follows: 2144 2145 ( 1.3.6.1.1.6.2.28 2146 NAME 'pcimTPCDayOfWeekMask' 2147 DESC 'This identifies the valid days of the week for a 2148 policy rule using a 7-bit string. This represents 2149 the days of the week from Sunday through Saturday.' 2150 EQUALITY bitStringMatch 2151 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 2152 SINGLE-VALUE 2153 ) 2154 2155 The value of this attribute SHOULD be checked against its defined 2156 format. If the value of this attribute does not conform to this 2157 syntax, then this SHOULD be considered an error and the policy rule 2158 SHOULD be treated as being disabled. 2159 2160 The pcimTPCTimeOfDayMask attribute defines the range of times at 2161 which a policy rule is valid. If the second time is earlier than the 2162 first, then the interval spans midnight. The format of the string is 2163 Thhmmss/Thhmmss. The definition of this attribute is as follows: 2164 2165 ( 1.3.6.1.1.6.2.29 2166 NAME 'pcimTPCTimeOfDayMask' 2167 DESC 'This identifies the valid range of times for a policy 2168 using the format Thhmmss/Thhmmss.' 2169 EQUALITY caseIgnoreMatch 2170 ORDERING caseIgnoreOrderingMatch 2171 SUBSTR caseIgnoreSubstringsMatch 2172 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 2173 SINGLE-VALUE 2174 ) 2175 2176 The value of this attribute SHOULD be checked against its defined 2177 format. If the value of this attribute does not conform to this 2178 syntax, then this SHOULD be considered an error and the policy rule 2179 SHOULD be treated as being disabled. 2180 2181 2182 2183 2184 2185 2186Strassner, et al. Standards Track [Page 39] 2187 2188RFC 3703 Policy Core LDAP Schema February 2004 2189 2190 2191 Finally, the pcimTPCLocalOrUtcTime attribute is used to choose 2192 between local or UTC time representation. This is mapped as a simple 2193 integer syntax, with the value of 1 representing local time and the 2194 value of 2 representing UTC time. The definition of this attribute 2195 is as follows: 2196 2197 ( 1.3.6.1.1.6.2.30 2198 NAME 'pcimTPCLocalOrUtcTime' 2199 DESC 'This defines whether the times in this instance 2200 represent local (value=1) times or UTC (value=2) 2201 times.' 2202 EQUALITY integerMatch 2203 ORDERING integerOrderingMatch 2204 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 2205 SINGLE-VALUE 2206 ) 2207 2208 Note: if the value of the pcimTPCLocalOrUtcTime is not 1 or 2, then 2209 this SHOULD be considered an error and the policy rule SHOULD be 2210 disabled. If the attribute is not present at all, then all times are 2211 interpreted as if it were present with the value 2, that is, UTC 2212 time. 2213 22145.9. The Auxiliary Class pcimConditionVendorAuxClass 2215 2216 This class provides a general extension mechanism for representing 2217 policy conditions that have not been modeled with specific 2218 properties. Instead, its two properties are used to define the 2219 content and format of the condition, as explained below. This class 2220 is intended for vendor-specific extensions that are not amenable to 2221 using pcimCondition; standardized extensions SHOULD NOT use this 2222 class. 2223 2224 The class definition is as follows: 2225 2226 ( 1.3.6.1.1.6.1.13 NAME 'pcimConditionVendorAuxClass' 2227 DESC 'A class that defines a registered means to describe a 2228 policy condition.' 2229 SUP pcimConditionAuxClass 2230 AUXILIARY 2231 MAY ( pcimVendorConstraintData $ 2232 pcimVendorConstraintEncoding ) 2233 ) 2234 2235 The pcimVendorConstraintData attribute is a multi-valued attribute. 2236 It provides a general mechanism for representing policy conditions 2237 that have not been modeled as specific attributes. This information 2238 is encoded in a set of octet strings. The format of the octet 2239 2240 2241 2242Strassner, et al. Standards Track [Page 40] 2243 2244RFC 3703 Policy Core LDAP Schema February 2004 2245 2246 2247 strings is identified by the OID stored in the 2248 pcimVendorConstraintEncoding attribute. This attribute is defined as 2249 follows: 2250 2251 ( 1.3.6.1.1.6.2.31 2252 NAME 'pcimVendorConstraintData' 2253 DESC 'Mechanism for representing constraints that have not 2254 been modeled as specific attributes. Their format is 2255 identified by the OID stored in the attribute 2256 pcimVendorConstraintEncoding.' 2257 EQUALITY octetStringMatch 2258 ORDERING octetStringOrderingMatch 2259 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 2260 ) 2261 2262 The pcimVendorConstraintEncoding attribute is used to identify the 2263 format and semantics for the pcimVendorConstraintData attribute. 2264 This attribute is defined as follows: 2265 2266 ( 1.3.6.1.1.6.2.32 2267 NAME 'pcimVendorConstraintEncoding' 2268 DESC 'An OID identifying the format and semantics for the 2269 pcimVendorConstraintData for this instance.' 2270 EQUALITY objectIdentifierMatch 2271 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 2272 SINGLE-VALUE 2273 ) 2274 22755.10. The Auxiliary Class pcimActionAuxClass 2276 2277 The purpose of a policy action is to execute one or more operations 2278 that will affect network traffic and/or systems, devices, etc. in 2279 order to achieve a desired policy state. This class is used to 2280 represent an action to be performed as a result of a policy rule 2281 whose condition clause was satisfied. 2282 2283 Subclasses of this auxiliary class can be attached to instances of 2284 three other classes in the PCLS. When a subclass of this class is 2285 attached to an instance of pcimRuleActionAssociation, or to an 2286 instance of pcimRule, it represents a rule-specific policy action. 2287 When a subclass of this class is attached to an instance of 2288 pcimPolicyInstance, it represents a reusable policy action. 2289 2290 Since all of the classes to which subclasses of this auxiliary class 2291 may be attached are derived from the pcimPolicy class, the attributes 2292 of the pcimPolicy class will already be defined for the entries to 2293 which these subclasses attach. Thus, this class is derived directly 2294 from "top". 2295 2296 2297 2298Strassner, et al. Standards Track [Page 41] 2299 2300RFC 3703 Policy Core LDAP Schema February 2004 2301 2302 2303 The class definition is as follows: 2304 2305 ( 1.3.6.1.1.6.1.14 NAME 'pcimActionAuxClass' 2306 DESC 'A class representing an action to be performed as a 2307 result of a policy rule.' 2308 SUP top 2309 AUXILIARY 2310 ) 2311 23125.11. The Auxiliary Class pcimActionVendorAuxClass 2313 2314 The purpose of this class is to provide a general extension mechanism 2315 for representing policy actions that have not been modeled with 2316 specific properties. Instead, its two properties are used to define 2317 the content and format of the action, as explained below. 2318 2319 As its name suggests, this class is intended for vendor-specific 2320 extensions that are not amenable to using the standard pcimAction 2321 class. Standardized extensions SHOULD NOT use this class. 2322 2323 The class definition is as follows: 2324 2325 ( 1.3.6.1.1.6.1.15 NAME 'pcimActionVendorAuxClass' 2326 DESC 'A class that defines a registered means to describe a 2327 policy action.' 2328 SUP pcimActionAuxClass 2329 AUXILIARY 2330 MAY ( pcimVendorActionData $ pcimVendorActionEncoding ) 2331 ) 2332 2333 The pcimVendorActionData attribute is a multi-valued attribute. It 2334 provides a general mechanism for representing policy actions that 2335 have not been modeled as specific attributes. This information is 2336 encoded in a set of octet strings. The format of the octet strings 2337 is identified by the OID stored in the pcimVendorActionEncoding 2338 attribute. This attribute is defined as follows: 2339 2340 ( 1.3.6.1.1.6.2.33 2341 NAME 'pcimVendorActionData' 2342 DESC ' Mechanism for representing policy actions that have 2343 not been modeled as specific attributes. Their 2344 format is identified by the OID stored in the 2345 attribute pcimVendorActionEncoding.' 2346 EQUALITY octetStringMatch 2347 ORDERING octetStringOrderingMatch 2348 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 2349 ) 2350 2351 2352 2353 2354Strassner, et al. Standards Track [Page 42] 2355 2356RFC 3703 Policy Core LDAP Schema February 2004 2357 2358 2359 The pcimVendorActionEncoding attribute is used to identify the format 2360 and semantics for the pcimVendorActionData attribute. This attribute 2361 is defined as follows: 2362 2363 ( 1.3.6.1.1.6.2.34 2364 NAME 'pcimVendorActionEncoding' 2365 DESC 'An OID identifying the format and semantics for the 2366 pcimVendorActionData attribute of this instance.' 2367 EQUALITY objectIdentifierMatch 2368 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 2369 SINGLE-VALUE 2370 ) 2371 23725.12. The Class pcimPolicyInstance 2373 2374 This class is not defined in the PCIM. Its role is to serve as a 2375 structural class to which auxiliary classes representing policy 2376 information are attached when the information is reusable. For 2377 auxiliary classes representing policy conditions and policy actions, 2378 there are alternative structural classes that may be used. See 2379 Section 4.4 for a complete discussion of reusable policy conditions 2380 and actions, and of the role that this class plays in how they are 2381 represented. 2382 2383 The class definition is as follows: 2384 2385 ( 1.3.6.1.1.6.1.16 NAME 'pcimPolicyInstance' 2386 DESC 'A structural class to which aux classes containing 2387 reusable policy information can be attached.' 2388 SUP pcimPolicy 2389 MAY ( pcimPolicyInstanceName ) 2390 ) 2391 2392 The pcimPolicyInstanceName attribute is used to define a 2393 user-friendly name of this class, and may be used as a naming 2394 attribute if desired. It is defined as follows: 2395 2396 ( 1.3.6.1.1.6.2.35 NAME 'pcimPolicyInstanceName' 2397 DESC 'The user-friendly name of this policy instance.' 2398 EQUALITY caseIgnoreMatch 2399 ORDERING caseIgnoreOrderingMatch 2400 SUBSTR caseIgnoreSubstringsMatch 2401 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 2402 SINGLE-VALUE 2403 ) 2404 2405 2406 2407 2408 2409 2410Strassner, et al. Standards Track [Page 43] 2411 2412RFC 3703 Policy Core LDAP Schema February 2004 2413 2414 2415 A DIT content rule could be written to enable an instance of 2416 pcimPolicyInstance to have attached to it either instances of one or 2417 more of the auxiliary object classes pcimConditionAuxClass and 2418 pcimActionAuxClass. Since these semantics do not include specifying 2419 any properties, the content rule would not need to specify any 2420 attributes. Note that other content rules could be defined to enable 2421 other policy-related auxiliary classes to be attached to 2422 pcimPolicyInstance. 2423 2424 Similarly, three separate DIT structure rules could be written. Each 2425 of these DIT structure rules would refer to a specific name form that 2426 defined two important semantics. First, each name form would 2427 identify one of the three possible naming attributes (i.e., 2428 pcimPolicyInstanceName, cn, and orderedCIMKeys) for this object 2429 class. Second, each name form would require that an instance of the 2430 pcimPolicyInstance class have as its superior an instance of the 2431 pcimRepository class. This structure rule SHOULD also include a 2432 superiorStructureRule (see Note 2 at the beginning of section 5). 2433 24345.13. The Auxiliary Class pcimElementAuxClass 2435 2436 This class introduces no additional attributes, beyond those defined 2437 in the class pcimPolicy from which it is derived. Its role is to 2438 "tag" an instance of a class defined outside the realm of policy 2439 information as represented by PCIM as being nevertheless relevant to 2440 a policy specification. This tagging can potentially take place at 2441 two levels: 2442 2443 - Every instance to which pcimElementAuxClass is attached becomes 2444 an instance of the class pcimPolicy, since pcimElementAuxClass is 2445 a subclass of pcimPolicy. Searching for object 2446 class="pcimPolicy" will return the instance. (As noted earlier, 2447 this approach does NOT work for some directory implementations. 2448 To accommodate these implementations, policy-related entries 2449 SHOULD be tagged with the pcimKeyword "POLICY".) 2450 2451 - With the pcimKeywords attribute that it inherits from pcimPolicy, 2452 an instance to which pcimElementAuxClass is attached can be 2453 tagged as being relevant to a particular type or category of 2454 policy information, using standard keywords, 2455 administrator-defined keywords, or both. 2456 2457 The class definition is as follows: 2458 2459 ( 1.3.6.1.1.6.1.17 NAME 'pcimElementAuxClass' 2460 DESC 'An auxiliary class used to tag instances of classes 2461 defined outside the realm of policy as relevant to a 2462 particular policy specification.' 2463 2464 2465 2466Strassner, et al. Standards Track [Page 44] 2467 2468RFC 3703 Policy Core LDAP Schema February 2004 2469 2470 2471 SUP pcimPolicy 2472 AUXILIARY 2473 ) 2474 24755.14. The Three Policy Repository Classes 2476 2477 These classes provide a container for reusable policy information, 2478 such as reusable policy conditions and/or reusable policy actions. 2479 This document is concerned with mapping just the properties that 2480 appear in these classes. Conceptually, this may be thought of as a 2481 special location in the DIT where policy information may reside. 2482 Since pcimRepository is derived from the class dlm1AdminDomain 2483 defined in reference [6], this specification has a normative 2484 dependency on that element of reference [6] (as well as on its entire 2485 derivation hierarchy, which also appears in reference [6]). To 2486 maximize flexibility, the pcimRepository class is defined as 2487 abstract. A subclass pcimRepositoryAuxClass provides for auxiliary 2488 attachment to another entry, while a structural subclass 2489 pcimRepositoryInstance is available to represent a policy repository 2490 as a standalone entry. 2491 2492 The definition for the pcimRepository class is as follows: 2493 2494 ( 1.3.6.1.1.6.1.18 NAME 'pcimRepository' 2495 DESC 'A container for reusable policy information.' 2496 SUP dlm1AdminDomain 2497 ABSTRACT 2498 MAY ( pcimRepositoryName ) 2499 ) 2500 2501 The pcimRepositoryName attribute is used to define a user-friendly 2502 name of this class, and may be used as a naming attribute if desired. 2503 It is defined as follows: 2504 2505 ( 1.3.6.1.1.6.2.36 NAME 'pcimRepositoryName' 2506 DESC 'The user-friendly name of this policy repository.' 2507 EQUALITY caseIgnoreMatch 2508 ORDERING caseIgnoreOrderingMatch 2509 SUBSTR caseIgnoreSubstringsMatch 2510 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 2511 SINGLE-VALUE 2512 ) 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522Strassner, et al. Standards Track [Page 45] 2523 2524RFC 3703 Policy Core LDAP Schema February 2004 2525 2526 2527 The two subclasses of pcimRepository are defined as follows. First, 2528 the pcimRepositoryAuxClass is an auxiliary class that can be used to 2529 aggregate reusable policy information. It is defined as follows: 2530 2531 ( 1.3.6.1.1.6.1.19 NAME 'pcimRepositoryAuxClass' 2532 DESC 'An auxiliary class that can be used to aggregate 2533 reusable policy information.' 2534 SUP pcimRepository 2535 AUXILIARY 2536 ) 2537 2538 In cases where structural classes are needed instead of an auxiliary 2539 class, the pcimRepositoryInstance class is a structural class that 2540 can be used to aggregate reusable policy information. It is defined 2541 as follows: 2542 2543 ( 1.3.6.1.1.6.1.20 NAME 'pcimRepositoryInstance' 2544 DESC 'A structural class that can be used to aggregate 2545 reusable policy information.' 2546 SUP pcimRepository 2547 STRUCTURAL 2548 ) 2549 2550 Three separate DIT structure rules could be written for this class. 2551 Each of these DIT structure rules would refer to a specific name form 2552 that enabled an instance of the pcimRepository class to be named 2553 under any superior using one of the three possible naming attributes 2554 (i.e., pcimRepositoryName, cn, and orderedCIMKeys). This structure 2555 rule SHOULD also include a superiorStructureRule (see Note 2 at the 2556 beginning of section 5). 2557 25585.15. The Auxiliary Class pcimSubtreesPtrAuxClass 2559 2560 This auxiliary class provides a single, multi-valued attribute that 2561 references a set of objects that are at the root of DIT subtrees 2562 containing policy-related information. By attaching this attribute 2563 to instances of various other classes, a policy administrator has a 2564 flexible way of providing an entry point into the directory that 2565 allows a client to locate and retrieve the policy information 2566 relevant to it. 2567 2568 It is intended that these entries are placed in the DIT such that 2569 well-known DNs can be used to reference a well-known structural entry 2570 that has the pcimSubtreesPtrAuxClass attached to it. In effect, this 2571 defines a set of entry points. Each of these entry points can 2572 contain and/or reference all related policy entries for 2573 2574 2575 2576 2577 2578Strassner, et al. Standards Track [Page 46] 2579 2580RFC 3703 Policy Core LDAP Schema February 2004 2581 2582 2583 any well-known policy domains. The pcimSubtreesPtrAuxClass functions 2584 as a tag to identify portions of the DIT that contain policy 2585 information. 2586 2587 This object does not provide the semantic linkages between individual 2588 policy objects, such as those between a policy group and the policy 2589 rules that belong to it. Its only role is to enable efficient bulk 2590 retrieval of policy-related objects, as described in Section 4.5. 2591 2592 Once the objects have been retrieved, a directory client can 2593 determine the semantic linkages by following references contained in 2594 multi-valued attributes, such as pcimRulesAuxContainedSet. 2595 2596 Since policy-related objects will often be included in the DIT 2597 subtree beneath an object to which this auxiliary class is attached, 2598 a client SHOULD request the policy-related objects from the subtree 2599 under the object with these references at the same time that it 2600 requests the references themselves. 2601 2602 Since clients are expected to behave in this way, the policy 2603 administrator SHOULD make sure that this subtree does not contain so 2604 many objects unrelated to policy that an initial search done in this 2605 way results in a performance problem. The pcimSubtreesPtrAuxClass 2606 SHOULD NOT be attached to the partition root for a large directory 2607 partition containing a relatively few number of policy-related 2608 objects along with a large number of objects unrelated to policy 2609 (again, "policy" here refers to the PCIM, not the X.501, definition 2610 and use of "policy"). A better approach would be to introduce a 2611 container object immediately below the partition root, attach 2612 pcimSubtreesPtrAuxClass to this container object, and then place all 2613 of the policy-related objects in that subtree. 2614 2615 The class definition is as follows: 2616 2617 ( 1.3.6.1.1.6.1.21 NAME 'pcimSubtreesPtrAuxClass' 2618 DESC 'An auxiliary class providing DN references to roots of 2619 DIT subtrees containing policy-related objects.' 2620 SUP top 2621 AUXILIARY 2622 MAY ( pcimSubtreesAuxContainedSet ) 2623 ) 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634Strassner, et al. Standards Track [Page 47] 2635 2636RFC 3703 Policy Core LDAP Schema February 2004 2637 2638 2639 The attribute pcimSubtreesAuxContainedSet provides an unordered set 2640 of DN references to instances of one or more objects under which 2641 policy-related information is present. The objects referenced may or 2642 may not themselves contain policy-related information. The attribute 2643 definition is as follows: 2644 2645 ( 1.3.6.1.1.6.2.37 2646 NAME 'pcimSubtreesAuxContainedSet' 2647 DESC 'DNs of objects that serve as roots for DIT subtrees 2648 containing policy-related objects.' 2649 EQUALITY distinguishedNameMatch 2650 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2651 ) 2652 2653 Note that the cn attribute does NOT need to be defined for this 2654 class. This is because an auxiliary class is used as a means to 2655 collect common attributes and treat them as properties of an object. 2656 A good analogy is a #include file, except that since an auxiliary 2657 class is a class, all the benefits of a class (e.g., inheritance) can 2658 be applied to an auxiliary class. 2659 26605.16. The Auxiliary Class pcimGroupContainmentAuxClass 2661 2662 This auxiliary class provides a single, multi-valued attribute that 2663 references a set of pcimGroups. By attaching this attribute to 2664 instances of various other classes, a policy administrator has a 2665 flexible way of providing an entry point into the directory that 2666 allows a client to locate and retrieve the pcimGroups relevant to it. 2667 2668 As is the case with pcimRules, a policy administrator might have 2669 several different references to a pcimGroup in the overall directory 2670 structure. The pcimGroupContainmentAuxClass is the mechanism that 2671 makes it possible for the policy administrator to define all these 2672 different references. 2673 2674 The class definition is as follows: 2675 2676 ( 1.3.6.1.1.6.1.22 NAME 'pcimGroupContainmentAuxClass' 2677 DESC 'An auxiliary class used to bind pcimGroups to an 2678 appropriate container object.' 2679 SUP top 2680 AUXILIARY 2681 MAY ( pcimGroupsAuxContainedSet ) 2682 ) 2683 2684 2685 2686 2687 2688 2689 2690Strassner, et al. Standards Track [Page 48] 2691 2692RFC 3703 Policy Core LDAP Schema February 2004 2693 2694 2695 The attribute pcimGroupsAuxContainedSet provides an unordered set of 2696 references to instances of one or more pcimGroups associated with the 2697 instance of a structural class to which this attribute has been 2698 appended. 2699 2700 The attribute definition is as follows: 2701 2702 ( 1.3.6.1.1.6.2.38 2703 NAME 'pcimGroupsAuxContainedSet' 2704 DESC 'DNs of pcimGroups associated in some way with the 2705 instance to which this attribute has been appended.' 2706 EQUALITY distinguishedNameMatch 2707 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2708 ) 2709 2710 Note that the cn attribute does NOT have to be defined for this class 2711 for the same reasons as those given for the pcimSubtreesPtrAuxClass 2712 in section 5.15. 2713 27145.17. The Auxiliary Class pcimRuleContainmentAuxClass 2715 2716 This auxiliary class provides a single, multi-valued attribute that 2717 references a set of pcimRules. By attaching this attribute to 2718 instances of various other classes, a policy administrator has a 2719 flexible way of providing an entry point into the directory that 2720 allows a client to locate and retrieve the pcimRules relevant to it. 2721 2722 A policy administrator might have several different references to a 2723 pcimRule in the overall directory structure. For example, there 2724 might be references to all pcimRules for traffic originating in a 2725 particular subnet from a directory entry that represents that subnet. 2726 At the same time, there might be references to all pcimRules related 2727 to a particular DiffServ setting from an instance of a pcimGroup 2728 explicitly introduced as a container for DiffServ-related pcimRules. 2729 The pcimRuleContainmentAuxClass is the mechanism that makes it 2730 possible for the policy administrator to define all these separate 2731 references. 2732 2733 The class definition is as follows: 2734 2735 ( 1.3.6.1.1.6.1.23 NAME 'pcimRuleContainmentAuxClass' 2736 DESC 'An auxiliary class used to bind pcimRules to an 2737 appropriate container object.' 2738 SUP top 2739 AUXILIARY 2740 MAY ( pcimRulesAuxContainedSet ) 2741 ) 2742 2743 2744 2745 2746Strassner, et al. Standards Track [Page 49] 2747 2748RFC 3703 Policy Core LDAP Schema February 2004 2749 2750 2751 The attribute pcimRulesAuxContainedSet provides an unordered set of 2752 references to one or more instances of pcimRules associated with the 2753 instance of a structural class to which this attribute has been 2754 appended. The attribute definition is as follows: 2755 2756 ( 1.3.6.1.1.6.2.39 2757 NAME 'pcimRulesAuxContainedSet' 2758 DESC 'DNs of pcimRules associated in some way with the 2759 instance to which this attribute has been appended.' 2760 EQUALITY distinguishedNameMatch 2761 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2762 ) 2763 2764 The cn attribute does NOT have to be defined for this class for the 2765 same reasons as those given for the pcimSubtreesPtrAuxClass in 2766 section 5.15. 2767 27686. Extending the Classes Defined in This Document 2769 2770 The following subsections provide general guidance on how to create a 2771 domain-specific schema derived from this document, discuss how the 2772 vendor classes in the PCLS should be used, and explain how 2773 policyTimePeriodConditions are related to other policy conditions. 2774 27756.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 2776 2777 In Section 4.4, there is a discussion of how, by representing policy 2778 conditions and policy actions as auxiliary classes in a schema, the 2779 flexibility is retained to instantiate a particular condition or 2780 action as either rule-specific or reusable. This flexibility is lost 2781 if a condition or action class is defined as structural rather than 2782 auxiliary. For standardized schemata, this document specifies that 2783 domain-specific information MUST be expressed in auxiliary subclasses 2784 of pcimConditionAuxClass and pcimActionAuxClass. It is RECOMMENDED 2785 that non-standardized schemata follow this practice as well. 2786 27876.2. Using the Vendor Policy Attributes 2788 2789 As discussed Section 5.9, the attributes pcimVendorConstraintData and 2790 pcimVendorConstraintEncoding are included in the 2791 pcimConditionVendorAuxClass to provide a mechanism for representing 2792 vendor-specific policy conditions that are not amenable to being 2793 represented with the pcimCondition class (or its subclasses). The 2794 attributes pcimVendorActionData and pcimVendorActionEncoding in the 2795 pcimActionVendorAuxClass class play the same role with respect to 2796 actions. This enables interoperability between different vendors who 2797 could not otherwise interoperate. 2798 2799 2800 2801 2802Strassner, et al. Standards Track [Page 50] 2803 2804RFC 3703 Policy Core LDAP Schema February 2004 2805 2806 2807 For example, imagine a network composed of access devices from vendor 2808 A, edge and core devices from vendor B, and a policy server from 2809 vendor C. It is desirable for this policy server to be able to 2810 configure and manage all of the devices from vendors A and B. 2811 Unfortunately, these devices will in general have little in common 2812 (e.g., different mechanisms, different ways for controlling those 2813 mechanisms, different operating systems, different commands, and so 2814 forth). The extension conditions provide a way for vendor-specific 2815 commands to be encoded as octet strings, so that a single policy 2816 server can commonly manage devices from different vendors. 2817 28186.3. Using Time Validity Periods 2819 2820 Time validity periods are defined as an auxiliary subclass of 2821 pcimConditionAuxClass, called pcimTPCAuxClass. This is to allow 2822 their inclusion in the AND/OR condition definitions for a pcimRule. 2823 Care should be taken not to subclass pcimTPCAuxClass to add 2824 domain-specific condition properties. 2825 2826 For example, it would be incorrect to add IPsec- or QoS-specific 2827 condition properties to the pcimTPCAuxClass class, just because IPsec 2828 or QoS includes time in its condition definition. The correct 2829 subclassing would be to create IPsec or QoS-specific subclasses of 2830 pcimConditionAuxClass and then combine instances of these 2831 domain-specific condition classes with the appropriate validity 2832 period criteria. This is accomplished using the AND/OR association 2833 capabilities for policy conditions in pcimRules. 2834 28357. Security Considerations 2836 2837 The PCLS, presented in this document, provides a mapping of the 2838 object-oriented model for describing policy information (PCIM) into a 2839 data model that forms the basic framework for describing the 2840 structure of policy data, in the case where the policy repository 2841 takes the form of an LDAP-accessible directory. 2842 2843 PCLS is not intended to represent any particular system design or 2844 implementation. PCLS is not directly useable in a real world system, 2845 without the discipline-specific mappings that are works in progress 2846 in the Policy Framework Working Group of the IETF. 2847 2848 These other derivative documents, which use PCIM and its 2849 discipline-specific extensions as a base, will need to convey more 2850 specific security considerations (refer to RFC 3060 for more 2851 information.) 2852 2853 2854 2855 2856 2857 2858Strassner, et al. Standards Track [Page 51] 2859 2860RFC 3703 Policy Core LDAP Schema February 2004 2861 2862 2863 The reason that PCLS, as defined here, is not representative of any 2864 real-world system, is that its object classes were designed to be 2865 independent of any specific discipline, or policy domain. For 2866 example, DiffServ and IPsec represent two different policy domains. 2867 Each document that extends PCIM to one of these domains will derive 2868 subclasses from the classes and relationships defined in PCIM, in 2869 order to represent extensions of a generic model to cover specific 2870 technical domains. 2871 2872 PCIM-derived documents will thus subclass the PCIM classes into 2873 classes specific to each technical policy domain (QOS, IPsec, etc.), 2874 which will, in turn, be mapped, to directory-specific schemata 2875 consistent with the PCLS documented here. 2876 2877 Even though discipline-specific security requirements are not 2878 appropriate for PCLS, specific security requirements MUST be defined 2879 for each operational real-world application of PCIM. Just as there 2880 will be a wide range of operational, real-world systems using PCIM, 2881 there will also be a wide range of security requirements for these 2882 systems. Some operational, real-world systems that are deployed 2883 using PCLS may have extensive security requirements that impact 2884 nearly all object classes utilized by such a system, while other 2885 systems' security requirements might have very little impact. 2886 2887 The derivative documents, discussed above, will create the context 2888 for applying operational, real-world, system-level security 2889 requirements against the various models that derive from PCIM, 2890 consistent with PCLS. 2891 2892 In some real-world scenarios, the values associated with certain 2893 properties, within certain instantiated object classes, may represent 2894 information associated with scarce, and/or costly (and therefore 2895 valuable) resources. It may be the case that these values must not 2896 be disclosed to, or manipulated by, unauthorized parties. 2897 2898 Since this document forms the basis for the representation of a 2899 policy data model in a specific format (an LDAP-accessible 2900 directory), it is herein appropriate to reference the data 2901 model-specific tools and mechanisms that are available for achieving 2902 the authentication and authorization implicit in a requirement that 2903 restricts read and/or read- write access to these values stored in a 2904 directory. 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914Strassner, et al. Standards Track [Page 52] 2915 2916RFC 3703 Policy Core LDAP Schema February 2004 2917 2918 2919 General LDAP security considerations apply, as documented in RFC 3377 2920 [2]. LDAP-specific authentication and authorization tools and 2921 mechanisms are found in the following standards track documents, 2922 which are appropriate for application to the management of security 2923 applied to policy data models stored in an LDAP-accessible directory: 2924 2925 - RFC 2829 (Authentication Methods for LDAP) 2926 - RFC 2830 (Lightweight Directory Access Protocol (v3): Extension 2927 for Transport Layer Security) 2928 2929 Any identified security requirements that are not dealt with in the 2930 appropriate discipline-specific information model documents, or in 2931 this document, MUST be dealt with in the derivative data model 2932 documents which are specific to each discipline. 2933 29348. IANA Considerations 2935 2936 Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA) 2937 Considerations for the Lightweight Directory Access Protocol (LDAP)" 2938 [16]. 2939 29408.1. Object Identifiers 2941 2942 The IANA has registered an LDAP Object Identifier for use in this 2943 technical specification according to the following template: 2944 2945 Subject: Request for LDAP OID Registration 2946 Person & email address to contact for further information: 2947 Bob Moore (remoore@us.ibm.com) 2948 Specification: RFC 3703 2949 Author/Change Controller: IESG 2950 Comments: 2951 The assigned OID will be used as a base for identifying 2952 a number of schema elements defined in this document. 2953 2954 IANA has assigned an OID of 1.3.6.1.1.6 with the name of pcimSchema 2955 to this registration as recorded in the following registry: 2956 2957 http://www.iana.org/assignments/smi-numbers 2958 29598.2. Object Identifier Descriptors 2960 2961 The IANA has registered the LDAP Descriptors used in this technical 2962 specification as detailed in the following template: 2963 2964 Subject: Request for LDAP Descriptor Registration Update 2965 Descriptor (short name): see comment 2966 Object Identifier: see comment 2967 2968 2969 2970Strassner, et al. Standards Track [Page 53] 2971 2972RFC 3703 Policy Core LDAP Schema February 2004 2973 2974 2975 Person & email address to contact for further information: 2976 Bob Moore (remoore@us.ibm.com) 2977 Usage: see comment 2978 Specification: RFC 3703 2979 Author/Change Controller: IESG 2980 Comments: 2981 2982 The following descriptors have been added: 2983 2984 NAME Type OID 2985 -------------- ---- ------------ 2986 pcimPolicy O 1.3.6.1.1.6.1.1 2987 pcimGroup O 1.3.6.1.1.6.1.2 2988 pcimGroupAuxClass O 1.3.6.1.1.6.1.3 2989 pcimGroupInstance O 1.3.6.1.1.6.1.4 2990 pcimRule O 1.3.6.1.1.6.1.5 2991 pcimRuleAuxClass O 1.3.6.1.1.6.1.6 2992 pcimRuleInstance O 1.3.6.1.1.6.1.7 2993 pcimRuleConditionAssociation O 1.3.6.1.1.6.1.8 2994 pcimRuleValidityAssociation O 1.3.6.1.1.6.1.9 2995 pcimRuleActionAssociation O 1.3.6.1.1.6.1.10 2996 pcimConditionAuxClass O 1.3.6.1.1.6.1.11 2997 pcimTPCAuxClass O 1.3.6.1.1.6.1.12 2998 pcimConditionVendorAuxClass O 1.3.6.1.1.6.1.13 2999 pcimActionAuxClass O 1.3.6.1.1.6.1.14 3000 pcimActionVendorAuxClass O 1.3.6.1.1.6.1.15 3001 pcimPolicyInstance O 1.3.6.1.1.6.1.16 3002 pcimElementAuxClass O 1.3.6.1.1.6.1.17 3003 pcimRepository O 1.3.6.1.1.6.1.18 3004 pcimRepositoryAuxClass O 1.3.6.1.1.6.1.19 3005 pcimRepositoryInstance O 1.3.6.1.1.6.1.20 3006 pcimSubtreesPtrAuxClass O 1.3.6.1.1.6.1.21 3007 pcimGroupContainmentAuxClass O 1.3.6.1.1.6.1.22 3008 pcimRuleContainmentAuxClass O 1.3.6.1.1.6.1.23 3009 pcimKeywords A 1.3.6.1.1.6.2.3 3010 pcimGroupName A 1.3.6.1.1.6.2.4 3011 pcimRuleName A 1.3.6.1.1.6.2.5 3012 pcimRuleEnabled A 1.3.6.1.1.6.2.6 3013 pcimRuleConditionListType A 1.3.6.1.1.6.2.7 3014 pcimRuleConditionList A 1.3.6.1.1.6.2.8 3015 pcimRuleActionList A 1.3.6.1.1.6.2.9 3016 pcimRuleValidityPeriodList A 1.3.6.1.1.6.2.10 3017 pcimRuleUsage A 1.3.6.1.1.6.2.11 3018 pcimRulePriority A 1.3.6.1.1.6.2.12 3019 pcimRuleMandatory A 1.3.6.1.1.6.2.13 3020 pcimRuleSequencedActions A 1.3.6.1.1.6.2.14 3021 pcimRoles A 1.3.6.1.1.6.2.15 3022 pcimConditionGroupNumber A 1.3.6.1.1.6.2.16 3023 3024 3025 3026Strassner, et al. Standards Track [Page 54] 3027 3028RFC 3703 Policy Core LDAP Schema February 2004 3029 3030 3031 NAME Type OID 3032 -------------- ---- ------------ 3033 pcimConditionNegated A 1.3.6.1.1.6.2.17 3034 pcimConditionName A 1.3.6.1.1.6.2.18 3035 pcimConditionDN A 1.3.6.1.1.6.2.19 3036 pcimValidityConditionName A 1.3.6.1.1.6.2.20 3037 pcimTimePeriodConditionDN A 1.3.6.1.1.6.2.21 3038 pcimActionName A 1.3.6.1.1.6.2.22 3039 pcimActionOrder A 1.3.6.1.1.6.2.23 3040 pcimActionDN A 1.3.6.1.1.6.2.24 3041 pcimTPCTime A 1.3.6.1.1.6.2.25 3042 pcimTPCMonthOfYearMask A 1.3.6.1.1.6.2.26 3043 pcimTPCDayOfMonthMask A 1.3.6.1.1.6.2.27 3044 pcimTPCDayOfWeekMask A 1.3.6.1.1.6.2.28 3045 pcimTPCTimeOfDayMask A 1.3.6.1.1.6.2.29 3046 pcimTPCLocalOrUtcTime A 1.3.6.1.1.6.2.30 3047 pcimVendorConstraintData A 1.3.6.1.1.6.2.31 3048 pcimVendorConstraintEncoding A 1.3.6.1.1.6.2.32 3049 pcimVendorActionData A 1.3.6.1.1.6.2.33 3050 pcimVendorActionEncoding A 1.3.6.1.1.6.2.34 3051 pcimPolicyInstanceName A 1.3.6.1.1.6.2.35 3052 pcimRepositoryName A 1.3.6.1.1.6.2.36 3053 pcimSubtreesAuxContainedSet A 1.3.6.1.1.6.2.37 3054 pcimGroupsAuxContainedSet A 1.3.6.1.1.6.2.38 3055 pcimRulesAuxContainedSet A 1.3.6.1.1.6.2.39 3056 3057 where Type A is Attribute, Type O is ObjectClass 3058 3059 These assignments are recorded in the following registry: 3060 3061 http://www.iana.org/assignments/ldap-parameters 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082Strassner, et al. Standards Track [Page 55] 3083 3084RFC 3703 Policy Core LDAP Schema February 2004 3085 3086 30879. Acknowledgments 3088 3089 We would like to thank Kurt Zeilenga, Roland Hedburg, and Steven Legg 3090 for doing a review of this document and making many helpful 3091 suggestions and corrections. 3092 3093 Several of the policy classes in this model first appeared in early 3094 IETF drafts on IPsec policy and QoS policy. The authors of these 3095 drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy 3096 Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael 3097 See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar. 3098 3099 This document is closely aligned with the work being done in the 3100 Distributed Management Task Force (DMTF) Policy and Networks working 3101 groups. We would especially like to thank Lee Rafalow, Glenn Waters, 3102 David Black, Michael Richardson, Mark Stevens, David Jones, Hugh 3103 Mahon, Yoram Snir, and Yoram Ramberg for their helpful comments. 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138Strassner, et al. Standards Track [Page 56] 3139 3140RFC 3703 Policy Core LDAP Schema February 2004 3141 3142 314310. Appendix: Constructing the Value of orderedCIMKeys 3144 3145 This appendix is non-normative, and is included in this document as a 3146 guide to implementers that wish to exchange information between CIM 3147 schemata and LDAP schemata. 3148 3149 Within a CIM name space, the naming is basically flat; all instances 3150 are identified by the values of their key properties, and each 3151 combination of key values must be unique. A limited form of 3152 hierarchical naming is available in CIM, however, by using weak 3153 associations: since a weak association involves propagation of key 3154 properties and their values from the superior object to the 3155 subordinate one, the subordinate object can be thought of as being 3156 named "under" the superior object. Once they have been propagated, 3157 however, propagated key properties and their values function in 3158 exactly the same way that native key properties and their values do 3159 in identifying a CIM instance. 3160 3161 The CIM mapping document [6] introduces a special attribute, 3162 orderedCIMKeys, to help map from the CIM_ManagedElement class to the 3163 LDAP class dlm1ManagedElement. This attribute SHOULD only be used in 3164 an environment where it is necessary to map between an 3165 LDAP-accessible directory and a CIM repository. For an LDAP 3166 environment, other LDAP naming attributes are defined (i.e., cn and a 3167 class-specific naming attribute) that SHOULD be used instead. 3168 3169 The role of orderedCIMKeys is to represent the information necessary 3170 to correlate an entry in an LDAP-accessible directory with an 3171 instance in a CIM name space. Depending on how naming of CIM-related 3172 entries is handled in an LDAP directory, the value of orderedCIMKeys 3173 represents one of two things: 3174 3175 - If the DIT hierarchy does not mirror the "weakness hierarchy" of 3176 the CIM name space, then orderedCIMKeys represents all the 3177 keys of the CIM instance, both native and propagated. 3178 - If the DIT hierarchy does mirror the "weakness hierarchy" of the 3179 CIM name space, then orderedCIMKeys may represent either all the 3180 keys of the instance, or only the native keys. 3181 3182 Regardless of which of these alternatives is taken, the syntax of 3183 orderedCIMKeys is the same - a DirectoryString of the form 3184 3185 <className>.<key>=<value>[,<key>=<value>]* 3186 3187 where the <key>=<value> elements are ordered by the names of the key 3188 properties, according to the collating sequence for US ASCII. The 3189 only spaces allowed in the DirectoryString are those that fall within 3190 a <value> element. As with alphabetizing the key properties, the 3191 3192 3193 3194Strassner, et al. Standards Track [Page 57] 3195 3196RFC 3703 Policy Core LDAP Schema February 2004 3197 3198 3199 goal of suppressing the spaces is once again to make the results of 3200 string operations predictable. 3201 3202 The values of the <value> elements are derived from the various CIM 3203 syntaxes according to a grammar specified in [5]. 3204 320511. References 3206 320711.1. Normative References 3208 3209 [1] Moore, B., Ellesson,E., Strassner, J. and A. Westerinen "Policy 3210 Core Information Model -- Version 1 Specification", RFC 3060, 3211 February 2001. 3212 3213 [2] Hodges, J. and R. Morgan, "Lightweight Directory Access 3214 Protocol (v3): Technical Specification", RFC 3377, September 3215 2002. 3216 3217 [3] Wahl, M., Coulbeck, A., Howes,T. and S. Kille, "Lightweight 3218 Directory Access Protocol (v3): Attribute Syntax Definitions", 3219 RFC 2252, December 1997. 3220 3221 [4] The Directory: Models. ITU-T Recommendation X.501, 2001. 3222 3223 [5] Distributed Management Task Force, Inc., "Common Information 3224 Model (CIM) Specification", Version 2.2, June 14, 1999. This 3225 document is available on the following DMTF web page: 3226 http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf 3227 3228 [6] Distributed Management Task Force, Inc., "DMTF LDAP Schema for 3229 the CIM v2.5 Core Information Model", April 15, 2002. This 3230 document is available on the following DMTF web page: 3231 http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf 3232 3233 [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with 3234 LDAPv3", RFC 2256, December 1997. 3235 3236 [8] The Directory: Selected Attribute Types. ITU-T Recommendation 3237 X.520, 2001. 3238 3239 [9] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 3240 (LDAP): Additional Matching Rules", RFC 3698, February 2004. 3241 3242 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3243 Levels", BCP 14, RFC 2119, March 1997. 3244 3245 3246 3247 3248 3249 3250Strassner, et al. Standards Track [Page 58] 3251 3252RFC 3703 Policy Core LDAP Schema February 2004 3253 3254 325511.2. Informative References 3256 3257 [11] Hovey, R. and S. Bradner, "The Organizations Involved in the 3258 IETF Standards Process", BCP 11, RFC 2028, October 1996. 3259 3260 [12] Strassner, J., policy architecture BOF presentation, 42nd IETF 3261 Meeting, Chicago, Illinois, October 1998. Minutes of this BOF 3262 are available at the following location: 3263 http://www.ietf.org/proceedings/98aug/index.html. 3264 3265 [13] Yavatkar, R., Guerin, R. and D. Pendarakis, "A Framework for 3266 Policy-based Admission Control", RFC 2753, January 2000. 3267 3268 [14] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, 3269 "Authentication Methods for LDAP", RFC 2829, May 2000 3270 3271 [15] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory 3272 Access Protocol (v3): Extension for Transport Layer Security", 3273 RFC 2830, May 2000. 3274 3275 [16] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 3276 Considerations for the Lightweight Directory Access Protocol 3277 (LDAP)", BCP 64, RFC 3383, September 2002. 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306Strassner, et al. Standards Track [Page 59] 3307 3308RFC 3703 Policy Core LDAP Schema February 2004 3309 3310 331112. Authors' Addresses 3312 3313 John Strassner 3314 Intelliden Corporation 3315 90 South Cascade Avenue 3316 Colorado Springs, CO 80903 3317 3318 Phone: +1.719.785.0648 3319 Fax: +1.719.785.0644 3320 EMail: john.strassner@intelliden.com 3321 3322 3323 Bob Moore 3324 IBM Corporation 3325 P. O. Box 12195, BRQA/B501/G206 3326 3039 Cornwallis Rd. 3327 Research Triangle Park, NC 27709-2195 3328 3329 Phone: +1 919-254-4436 3330 Fax: +1 919-254-6243 3331 EMail: remoore@us.ibm.com 3332 3333 3334 Ryan Moats 3335 Lemur Networks, Inc. 3336 15621 Drexel Circle 3337 Omaha, NE 68135 3338 3339 Phone: +1-402-894-9456 3340 EMail: rmoats@lemurnetworks.net 3341 3342 3343 Ed Ellesson 3344 3026 Carriage Trail 3345 Hillsborough, NC 27278 3346 3347 Phone: +1 919-644-3977 3348 EMail: ellesson@mindspring.com 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362Strassner, et al. Standards Track [Page 60] 3363 3364RFC 3703 Policy Core LDAP Schema February 2004 3365 3366 336713. Full Copyright Statement 3368 3369 Copyright (C) The Internet Society (2004). This document is subject 3370 to the rights, licenses and restrictions contained in BCP 78 and 3371 except as set forth therein, the authors retain all their rights. 3372 3373 This document and the information contained herein are provided on an 3374 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3375 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 3376 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 3377 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3378 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3379 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3380 3381Intellectual Property 3382 3383 The IETF takes no position regarding the validity or scope of any 3384 Intellectual Property Rights or other rights that might be claimed 3385 to pertain to the implementation or use of the technology 3386 described in this document or the extent to which any license 3387 under such rights might or might not be available; nor does it 3388 represent that it has made any independent effort to identify any 3389 such rights. Information on the procedures with respect to 3390 rights in RFC documents can be found in BCP 78 and BCP 79. 3391 3392 Copies of IPR disclosures made to the IETF Secretariat and any 3393 assurances of licenses to be made available, or the result of an 3394 attempt made to obtain a general license or permission for the use 3395 of such proprietary rights by implementers or users of this 3396 specification can be obtained from the IETF on-line IPR repository 3397 at http://www.ietf.org/ipr. 3398 3399 The IETF invites any interested party to bring to its attention 3400 any copyrights, patents or patent applications, or other 3401 proprietary rights that may cover technology that may be required 3402 to implement this standard. Please address the information to the 3403 IETF at ietf-ipr@ietf.org. 3404 3405Acknowledgement 3406 3407 Funding for the RFC Editor function is currently provided by the 3408 Internet Society. 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418Strassner, et al. Standards Track [Page 61] 3419 3420