idnits 2.17.1 draft-ietf-policy-core-schema-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 60 instances of lines with control characters in the document. ** The abstract seems to contain references ([5], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1044 has weird spacing: '...ment to anot...' == Line 1255 has weird spacing: '... either manda...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2002) is 7922 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 2552, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 2555, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 2560, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2562, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2565, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2568, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2252 (ref. '2') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2256 (ref. '6') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Obsolete informational reference (is this intentional?): RFC 2028 (ref. '10') (Obsoleted by RFC 9281) -- Obsolete informational reference (is this intentional?): RFC 2829 (ref. '14') (Obsoleted by RFC 4510, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 2830 (ref. '15') (Obsoleted by RFC 4510, RFC 4511, RFC 4513) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Policy Framework Working Group J. Strassner 2 Internet-draft Intelliden Corporation 3 Category: Standards Track E. Ellesson 4 LongBoard, Inc. 5 B. Moore 6 IBM Corporation 7 R. Moats 8 Lemur Networks, Inc. 9 August 2002 10 Policy Core LDAP Schema 11 draft-ietf-policy-core-schema-15.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 This document defines a mapping of the Policy Core Information Model [1] 40 to a form that can be implemented in a directory that uses LDAP as its 41 access protocol. This model defines two hierarchies of object classes: 42 structural classes representing information for representing and 43 controlling policy data as specified in RFC3060, and relationship 44 classes that indicate how instances of the structural classes are 45 related to each other. Classes are also added to the LDAP schema to 46 improve the performance of a client's interactions with an LDAP server 47 when the client is retrieving large amounts of policy-related 48 information. These classes exist only to optimize LDAP retrievals: 49 there are no classes in the information model that correspond to them. 51 Table of Contents 53 1. Introduction 3 54 2. The Policy Core Information Model 4 55 3. Inheritance Hierarchy for the PCLS 5 56 4. General Discussion of Mapping the Information Model to LDAP 6 57 4.1. Summary of Class and Association Mappings 7 58 4.2. Usage of DIT Content and Structure Rules and Name Forms 9 59 4.3. Naming Attributes in the PCLS 10 60 4.4. Rule-Specific and Reusable Conditions and Actions 11 61 4.5. Location and Retrieval of Policy Objects in the Directory 15 62 4.5.1. Aliases and Other DIT-Optimization Techniques 17 63 5. Class Definitions 18 64 5.1. The Abstract Class "pcimPolicy" 19 65 5.2. The Three Policy Group Classes 20 66 5.3. The Three Policy Rule Classes 22 67 5.4. The Class pcimRuleConditionAssociation 28 68 5.5. The Class pcimRuleValidityAssociation 30 69 5.6. The Class pcimRuleActionAssociation 31 70 5.7. The Auxiliary Class pcimConditionAuxClass 33 71 5.8. The Auxiliary Class pcimTPCAuxClass 34 72 5.9. The Auxiliary Class pcimConditionVendorAuxClass 37 73 5.10. The Auxiliary Class pcimActionAuxClass 38 74 5.11. The Auxiliary Class pcimActionVendorAuxClass 38 75 5.12. The Class pcimPolicyInstance 40 76 5.13. The Auxiliary Class pcimElementAuxClass 41 77 5.14. The Three Policy Repository Classes 41 78 5.15. The Auxiliary Class pcimSubtreesPtrAuxClass 43 79 5.16. The Auxiliary Class pcimGroupContainmentAuxClass 44 80 5.17. The Auxiliary Class pcimRuleContainmentAuxClass 45 81 6. Extending the Classes Defined in This Document 47 82 6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 47 83 6.2. Using the Vendor Policy Attributes 47 84 6.3. Using Time Validity Periods 47 85 7. Security Considerations 48 86 8. IANA Considerations 49 87 8.1. Object Identifiers 49 88 8.2. Object Identifier Descriptors 50 89 9. Intellectual Property 51 90 10. Acknowledgments 52 91 11. Normative References 53 92 12. Informative References 54 93 13. Authors' Addresses 55 94 14. Full Copyright Statement 56 95 15. Appendix: Constructing the Value of orderedCIMKeys 57 96 PLEASE NOTE: 97 OIDs for the schema elements in this document have not been assigned. 98 This note to be removed by the RFC editor before publication. All uses 99 of OIDs are indicated symbolically: for example, IANA-ASSIGNED-OID.1.1 100 is a placeholder that will be replaced by a real OID that is assigned by 101 IANA before publication. 103 1. Introduction 105 This document takes as its starting point the object-oriented 106 information model for representing information for representing and 107 controlling policy data as specified in [1]. LDAP implementers, please 108 note that the use of the term "policy" in this document does not refer 109 to the use of the term "policy" as defined in X.501 [3]. Rather, the use 110 of the term "policy" throughout this document is defined as follows: 112 Policy is defined as a set of rules to administer, manage, and 113 control access to network resources. 115 This work is currently under joint development in the IETF's Policy 116 Framework working group and in the Policy working group of the 117 Distributed Management Task Force (DMTF). This model defines two 118 hierarchies of object classes: structural classes representing policy 119 information and control of policies, and relationship classes that 120 indicate how instances of the structural classes are related to each 121 other. In general, both of these class hierarchies will need to be 122 mapped to a particular data store. 124 This draft defines the mapping of these information model classes to a 125 directory that uses LDAPv3 as its access protocol. Two types of 126 mappings are involved: 128 - For the structural classes in the information model, the mapping is 129 basically one-for-one: information model classes map to LDAP 130 classes, information model properties map to LDAP attributes. 132 - For the relationship classes in the information model, different 133 mappings are possible. In this document, the PCIM's relationship 134 classes and their properties are mapped in three ways: to LDAP 135 auxiliary classes, to attributes representing DN references, and 136 to superior-subordinate relationships in the Directory Information 137 Tree (DIT). 139 Implementations that use an LDAP directory as their policy repository 140 and want to implement policy information according to RFC3060 [1] SHALL 141 use the LDAP schema defined in this document, or a schema that 142 subclasses from the schema defined in this document. The use of the 143 information model defined in reference [1] as the starting point 144 enables the inheritance and the relationship class hierarchies to be 145 extensible, such that other types of policy repositories, such as 146 relational databases, can also use this information. 148 This document fits into the overall framework for representing, 149 deploying, and managing policies being developed by the Policy 150 Framework Working Group. 152 The LDAP schema described in this document uses the prefix "pcim" to 153 identify its classes and attributes. It consists of ten very general 154 classes: pcimPolicy (an abstract class), three policy group classes 155 (pcimGroup, pcimGroupAuxClass, and pcimGroupInstance), three policy rule 156 classes (pcimRule, pcimRuleAuxClass, and pcimRuleInstance), and three 157 special auxiliary classes (pcimConditionAuxClass, pcimTPCAuxClass, and 158 pcimActionAuxClass). (Note that the PolicyTimePeriodCondition auxiliary 159 class defined in [1] would normally have been named 160 pcimTimePeriodConditionAuxClass, but this name is too long for some 161 directories. Therefore, we have abbreviated this name to be 162 pcimTPCAuxClass). 164 The mapping for the PCIM classes pcimGroup and pcimRule is designed to 165 be as flexible as possible. An abstract superclass is defined that 166 contains all required properties, and then both an auxiliary class as 167 well as a structural class are derived from it. This provides maximum 168 flexibility for the developer. 170 The schema also contains two less general classes: 171 pcimConditionVendorAuxClass and pcimActionVendorAuxClass. To achieve 172 the mapping of the information model's relationships, the schema also 173 contains two auxiliary classes: pcimGroupContainmentAuxClass and 174 pcimRuleContainmentAuxClass. Capturing the distinction between rule- 175 specific and reusable policy conditions and policy actions introduces 176 seven other classes: pcimRuleConditionAssociation, 177 pcimRuleValidityAssociation, pcimRuleActionAssociation, 178 pcimPolicyInstance, and three policy repository classes (pcimRepository, 179 pcimRepositoryAuxClass, and pcimRepositoryInstance). Finally, the 180 schema includes two classes (pcimSubtreesPtrAuxClass and 181 pcimElementAuxClass) for optimizing LDAP retrievals. In all, the schema 182 contains 23 classes. 184 Within the context of this document, the term "PCLS" (Policy Core LDAP 185 Schema) is used to refer to the LDAP class definitions that this 186 document contains. The term "PCIM" refers to classes defined in [1]. 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119 [9]. 192 2. The Policy Core Information Model 194 This document contains an LDAP schema representing the classes defined 195 in the companion document "Policy Core Information Model -- Version 1 196 Specification" [1]. Other documents may subsequently be produced, with 197 mappings of this same PCIM to other storage technologies. Since the 198 detailed semantics of the PCIM classes appear only in [1], that document 199 is a prerequisite for reading and understanding this document. 201 3. Inheritance Hierarchy for the PCLS 203 The following diagram illustrates the class hierarchy for the LDAP 204 Classes defined in this document: 206 top 207 | 208 +--dlm1ManagedElement (abstract) 209 | | 210 | +--pcimPolicy (abstract) 211 | | | 212 | | +--pcimGroup (abstract) 213 | | | | 214 | | | +--pcimGroupAuxClass (auxiliary) 215 | | | | 216 | | | +--pcimGroupInstance (structural) 217 | | | 218 | | +--pcimRule (abstract) 219 | | | | 220 | | | +--pcimRuleAuxClass (auxiliary) 221 | | | | 222 | | | +--pcimRuleInstance (structural) 223 | | | 224 | | +--pcimRuleConditionAssociation (structural) 225 | | | 226 | | +--pcimRuleValidityAssociation (structural) 227 | | | 228 | | +--pcimRuleActionAssociation (structural) 229 | | | 230 | | +--pcimPolicyInstance (structural) 231 | | | 232 | | +--pcimElementAuxClass (auxiliary) 233 | | 234 | +--dlm1ManagedSystemElement (abstract) 235 | | 236 | +--dlm1LogicalElement (abstract) 237 | | 238 | +--dlm1System (abstract) 239 | | 240 | +--dlm1AdminDomain (abstract) 241 | | 242 | +--pcimRepository (abstract) 243 | | 244 | +--pcimRepositoryAuxClass (auxiliary) 245 | | 246 | +--pcimRepositoryInstance 247 | (structural) 249 (continued on following page) 250 (continued from previous page) 252 top 253 | 254 +--pcimConditionAuxClass (auxiliary) 255 | | 256 | +---pcimTPCAuxClass (auxiliary) 257 | | 258 | +---pcimConditionVendorAuxClass (auxiliary) 259 | 260 +--pcimActionAuxClass (auxiliary) 261 | | 262 | +---pcimActionVendorAuxClass (auxiliary) 263 | 264 +--pcimSubtreesPtrAuxClass (auxiliary) 265 | 266 +--pcimGroupContainmentAuxClass (auxiliary) 267 | 268 +--pcimRuleContainmentAuxClass (auxiliary) 270 Figure 1. LDAP Class Inheritance Hierarchy for the PCLS 272 4. General Discussion of Mapping the Information Model to LDAP 274 The classes described in Section 5 below contain certain optimizations 275 for a directory that uses LDAP as its access protocol. One example of 276 this is the use of auxiliary classes to represent some of the 277 associations defined in the information model. Other data stores might 278 need to implement these associations differently. A second example is 279 the introduction of classes specifically designed to optimize retrieval 280 of large amounts of policy-related data from a directory. This section 281 discusses some general topics related to the mapping from the 282 information model to LDAP. 284 The remainder of this section will discuss the following topics. Section 285 4.1 will discuss the strategy used in mapping the classes and 286 associations defined in [1] to a form that can be represented in a 287 directory that uses LDAP as its access protocol. Section 4.2 discusses 288 DIT content and structure rules, as well as name forms. Section 4.3 289 describes the strategy used in defining naming attributes for the schema 290 described in Section 5 of this document. Section 4.4 defines the 291 strategy recommended for locating and retrieving PCIM-derived objects in 292 the directory. 294 4.1. Summary of Class and Association Mappings 296 Fifteen of the classes in the PCLS come directly from the nine 297 corresponding classes in the information model. Note that names of 298 classes begin with an upper case character in the information model 299 (although for CIM in particular, case is not significant in class and 300 property names), but with a lower case character in LDAP. This is 301 because although LDAP doesn't care, X.500 doesn't allow class names to 302 begin with an uppercase character. Note also that the prefix "pcim" is 303 used to identify these LDAP classes. 305 +---------------------------+-------------------------------+ 306 | Information Model | LDAP Class(es) | 307 +---------------------------+-------------------------------+ 308 +---------------------------+-------------------------------+ 309 | Policy | pcimPolicy | 310 +---------------------------+-------------------------------+ 311 | PolicyGroup | pcimGroup | 312 | | pcimGroupAuxClass | 313 | | pcimGroupInstance | 314 +---------------------------+-------------------------------+ 315 | PolicyRule | pcimRule | 316 | | pcimRuleAuxClass | 317 | | pcimRuleInstance | 318 +---------------------------+-------------------------------+ 319 | PolicyCondition | pcimConditionAuxClass | 320 +---------------------------+-------------------------------+ 321 | PolicyAction | pcimActionAuxClass | 322 +---------------------------+-------------------------------+ 323 | VendorPolicyCondition | pcimConditionVendorAuxClass | 324 +---------------------------+-------------------------------+ 325 | VendorPolicyAction | pcimActionVendorAuxClass | 326 +---------------------------+-------------------------------+ 327 | PolicyTimePeriodCondition | pcimTPCAuxClass | 328 +---------------------------+-------------------------------+ 329 | PolicyRepository | pcimRepository | 330 | | pcimRepositoryAuxClass | 331 | | pcimRepositoryInstance | 332 +---------------------------+-------------------------------+ 334 Figure 2. Mapping of Information Model Classes to LDAP 336 The associations in the information model map to attributes that 337 reference DNs (Distinguished Names) or to Directory Information Tree 338 (DIT) containment (i.e., superior-subordinate relationships) in LDAP. 339 Two of the attributes that reference DNs appear in auxiliary classes, 340 which allow each of them to represent several relationships from the 341 information model. 343 +----------------------------------+----------------------------------+ 344 | Information Model Association | LDAP Attribute / Class | 345 +-----------------------------------+---------------------------------+ 346 +-----------------------------------+---------------------------------+ 347 | PolicyGroupInPolicyGroup | pcimGroupsAuxContainedSet in | 348 | | pcimGroupContainmentAuxClass | 349 +-----------------------------------+---------------------------------+ 350 | PolicyRuleInPolicyGroup | pcimRulesAuxContainedSet in | 351 | | pcimRuleContainmentAuxClass | 352 +-----------------------------------+---------------------------------+ 353 | PolicyConditionInPolicyRule | DIT containment or | 354 | | pcimRuleConditionList in | 355 | | pcimRule or | 356 | | pcimConditionDN in | 357 | | pcimRuleConditionAssociation | 358 +-----------------------------------+---------------------------------+ 359 | PolicyActionInPolicyRule | DIT containment or | 360 | | pcimRuleActionList in | 361 | | pcimRule or | 362 | | pcimActionDN in | 363 | | pcimRuleActionAssociation | 364 +-----------------------------------+---------------------------------+ 365 | PolicyRuleValidityPeriod | pcimRuleValidityPeriodList | 366 | | in pcimRule or (if reusable) | 367 | | referenced through the | 368 | | pcimTimePeriodConditionDN in | 369 | | pcimRuleValidityAssociation | 370 +-----------------------------------+---------------------------------+ 371 | PolicyConditionInPolicyRepository | DIT containment | 372 +-----------------------------------+---------------------------------+ 373 | PolicyActionInPolicyRepository | DIT containment | 374 +-----------------------------------+---------------------------------+ 375 | PolicyRepositoryInPolicyRepository| DIT containment | 376 +-----------------------------------+---------------------------------+ 378 Figure 3. Mapping of Information Model Associations to LDAP 380 Of the remaining classes in the PCLS, two (pcimElementAuxClass and 381 pcimSubtreesPtrAuxClass) are included to make navigation through the DIT 382 and retrieval of the entries found there more efficient. This topic is 383 discussed in Section 4.5 below. 385 The remaining four classes in the PCLS, pcimRuleConditionAssociation, 386 pcimRuleValidityAssociation, pcimRuleActionAssociation, and 387 pcimPolicyInstance, are all involved with the representation of policy 388 conditions and policy actions in an LDAP directory. This topic is 389 discussed in Section 4.4 below. 391 4.2 Usage of DIT Content and Structure Rules and Name Forms 393 There are three powerful tools that can be used to help define schemata. 394 The first, DIT content rules, is a way of defining the content of an 395 entry for a structural object class. It can be used to specify the 396 following characteristics of the entry: 398 - additional mandatory attributes that the entries MUST contain 399 - additional optional attributes that the entries MAY contain 400 - the set of additional auxiliary object classes that these entries 401 MAY be members of 402 - any optional attributes from the structural and auxiliary object 403 class definitions that the entries MUST NOT contain. 405 DIT content rules are NOT mandatory for any structural object class. 407 A DIT structure rule, together with a name form, controls the placement 408 and naming of an entry within the scope of a subschema. Name forms 409 define which attribute type(s) MUST and MAY be used in forming the 410 Relative Distinguished Names (RDNs) of entries. DIT structure rules 411 specify which entries MAY be superior to other entries, and hence 412 control the way that RDNs are added together to make DNs. 414 A name form specifies the following: 416 - the structural object class of the entries named by this name form 417 - attributes that MUST be used in forming the RDNs of these entries 418 - attributes that MAY be used in forming the RDNs of these entries 419 - an object identifier to uniquely identify this name form 421 Note that name forms can only be specified for structural object 422 classes. However, every entry in the DIT must have a name form 423 controlling it. 425 Unfortunately, current LDAP servers vary quite a lot in their support of 426 these features. There are also three crucial implementation points that 427 must be followed. First, X.500 use of structure rules requires that a 428 structural object class with no superior structure rule be a subschema 429 administrative point. This is exactly NOT what we want for policy 430 information. Second, when an auxiliary class is subclassed, if a content 431 rule exists for the structural class that the auxiliary class refers to, 432 then that content rule needs to be augmented. Finally, most LDAP servers 433 unfortunately do not support inheritance of structure and content rules. 435 Given these concerns, DIT structure and content rules have been removed 436 from the PCLS. This is because, if included, they would be normative 437 references and would require OIDs. However, we don't want to lose the 438 insight gained in building the structure and content rules of the 439 previous version of the schema. Therefore, we describe where such rules 440 could be used in this schema, what they would control, and what their 441 effect would be. 443 4.3. Naming Attributes in the PCLS 445 Instances in a directory are identified by distinguished names (DNs), 446 which provide the same type of hierarchical organization that a file 447 system provides in a computer system. A distinguished name is a 448 sequence of RDNs. An RDN provides a unique identifier for an instance 449 within the context of its immediate superior, in the same way that a 450 filename provides a unique identifier for a file within the context of 451 the folder in which it resides. 453 To preserve maximum naming flexibility for policy administrators, three 454 optional (i.e., "MAY") naming attributes have been defined. They are: 456 - Each of the structural classes defined in this schema has its own 457 unique ("MAY") naming attribute. Since the naming attributes are 458 different, a policy administrator can, by using these attributes, 459 guarantee that there will be no name collisions between instances of 460 different classes, even if the same value is assigned to the 461 instances' respective naming attributes. 463 - The LDAP attribute cn (corresponding to X.500's commonName) is 464 included as a MAY attribute in the abstract class pcimPolicy, and 465 thus by inheritance in all of its subclasses. In X.500, commonName 466 typically functions as an RDN attribute, for naming instances of 467 many classes (e.g., X.500's person class). 469 - A special attribute is provided for implementations that expect to 470 map between native CIM and LDAP representations of policy 471 information. This attribute, called orderedCimKeys, is defined in 472 the class dlm1ManagedElement [5]. The value of this attribute is 473 derived algorithmically from values that are already present in a 474 CIM policy instance. The normative reference for this algorithm is 475 contained in [5]. See the appendix of this document for a 476 description of the algorithm. 478 Since any of these naming attributes MAY be used for naming an instance 479 of a PCLS class, implementations MUST be able to accommodate instances 480 named in any of these ways. 482 Note that it is recommended that two or more of these attributes SHOULD 483 NOT be used together to form a multi-part RDN, since support for multi- 484 part RDNs is limited among existing directory implementations. 486 4.4. Rule-Specific and Reusable Conditions and Actions 488 The PCIM [1] distinguishes between two types of policy conditions and 489 policy actions: ones associated with a single policy rule, and ones 490 that are reusable, in the sense that they may be associated with more 491 than one policy rule. While there is no inherent functional difference 492 between a rule-specific condition or action and a reusable one, there is 493 both a usage as well as an implementation difference between them. 495 Defining a condition or action as reusable vs. rule-specific reflects a 496 conscious decision on the part of the administrator in defining how they 497 are used. In addition, there are differences that reflect the difference 498 in implementing rule-specific vs. reusable policy conditions and actions 499 in how they are treated in a policy repository. The major implementation 500 differences between a rule-specific and a reusable condition or 501 actionare delineated below: 503 1. It is natural for a rule-specific condition or action to be removed 504 from the policy repository at the same time the rule is. It is just 505 the opposite for reusable conditions and actions. This is because 506 the condition or action is conceptually attached to the rule in the 507 rule-specific case, whereas it is referenced (e.g., pointed at) in 508 the reusable case. The persistence of a pcimRepository instance is 509 independent of the persistence of a pcimRule instance. 510 2. Access permissions for a rule-specific condition or action are 511 usually identical to those for the rule itself. On the other hand, 512 access permissions of reusable conditions and actions must be 513 expressible without reference to a policy rule. 514 3. Rule-specific conditions and actions require fewer accesses, 515 because the conditions and actions are "attached" to the rule. In 516 contrast, reusable conditions and actions require more accesses, 517 because each condition or action that is reusable requires a 518 separate access. 519 4. Rule-specific conditions and actions are designed for use by a 520 single rule. As the number of rules that use the same rule-specific 521 condition increase, subtle problems are created (the most obvious 522 being how to keep the rule-specific conditions and actions updated 523 to reflect the same value). Reusable conditions and actions lend 524 themselves for use by multiple independent rules. 525 5. Reusable conditions and actions offer an optimization when multiple 526 rules are using the same condition or action. This is because the 527 reusable condition or action only needs be updated once, and by 528 virtue of DN reference, the policy rules will be automatically 529 updated. 531 The preceding paragraph does not contain an exhaustive list of the ways 532 in which reusable and rule-specific conditions should be treated 533 differently. Its purpose is merely to justify making a semantic 534 distinction between rule-specific and reusable, and then reflecting this 535 distinction in the policy repository itself. 537 When the policy repository is realized in an LDAP-accessible directory, 538 the distinction between rule-specific and reusable conditions and 539 actions is realized via placement of auxiliary classes and via DIT 540 containment. Figure 4 illustrates a policy rule Rule1 with one rule- 541 specific condition CA and one rule-specific action AB. 543 +-----+ 544 |Rule1| 545 | | 546 +-----|- -|-----+ 547 | +-----+ | 548 | * * | 549 | * * | 550 | **** **** | 551 | * * | 552 v * * v 553 +--------+ +--------+ 554 | CA+ca | | AB+ab | 555 +--------+ +--------+ 557 +------------------------------+ 558 |LEGEND: | 559 | ***** DIT containment | 560 | + auxiliary attachment | 561 | ----> DN reference | 562 +------------------------------+ 564 Figure 4. Rule-Specific Policy Conditions and Actions 566 Because the condition and action are specific to Rule1, the auxiliary 567 classes ca and ab that represent them are attached, respectively, to the 568 structural classes CA and AB. These structural classes represent not 569 the condition ca and action ab themselves, but rather the associations 570 between Rule1 and ca, and between Rule1 and ab. 572 As Figure 4 illustrates, Rule1 contains DN references to the structural 573 classes CA and AB that appear below it in the DIT. At first glance it 574 might appear that these DN references are unnecessary, since a subtree 575 search below Rule1 would find all of the structural classes representing 576 the associations between Rule1 and its conditions and actions. Relying 577 only on a subtree search, though, runs the risk of missing conditions or 578 actions that should have appeared in the subtree, but for some reason 579 did not, or of finding conditions or actions that were inadvertently 580 placed in the subtree, or that should have been removed from the 581 subtree, but for some reason were not. Implementation experience has 582 suggested that many (but not all) of these risks are eliminated. 584 However, it must be noted that this comes at a price. The use of DN 585 references, as shown in Figure 4 above, thwarts inheritance of access 586 control information as well as existence dependency information. It also 587 is subject to referential integrity considerations. Therefore, it is 588 being included as an option for the designer. 590 Figure 5 illustrates a second way of representing rule-specific 591 conditions and actions in an LDAP-accessible directory: attachment of 592 the auxiliary classes directly to the instance representing the policy 593 rule. When all of the conditions and actions are attached to a policy 594 rule in this way, the rule is termed a "simple" policy rule. When 595 conditions and actions are not attached directly to a policy rule, the 596 rule is termed a "complex" policy rule. 598 +-----------+ 599 |Rule1+ca+ab| 600 | | 601 +-----------+ 603 +------------------------------+ 604 |LEGEND: | 605 | + auxiliary attachment | 606 +------------------------------+ 608 Figure 5. A Simple Policy Rule 610 The simple/complex distinction for a policy rule is not all or nothing. 611 A policy rule may have its conditions attached to itself and its actions 612 attached to other entries, or it may have its actions attached to itself 613 and its conditions attached to other entries. However, it SHALL NOT have 614 either its conditions or its actions attached both to itself and to 615 other entries, with one exception: a policy rule may reference its 616 validity periods with the pcimRuleValidityPeriodList attribute, but have 617 its other conditions attached to itself. 619 The tradeoffs between simple and complex policy rules are between the 620 efficiency of simple rules and the flexibility and greater potential for 621 reuse of complex rules. With a simple policy rule, the semantic options 622 are limited: 624 - All conditions are ANDed together. This combination can be 625 represented in two ways in the DNF / CNF (please see [1] for 626 definitions of these terms) expressions characteristic of policy 627 conditions: as a DNF expression with a single AND group, or as 628 a CNF expression with multiple single-condition OR groups. The 629 first of these is arbitrarily chosen as the representation for 630 the ANDed conditions in a simple policy rule. 632 - If multiple actions are included, no order can be specified for 633 them. 635 If a policy administrator needs to combine conditions in some other way, 636 or if there is a set of actions that must be ordered, then the only 637 option is to use a complex policy rule. 639 Finally, Figure 6 illustrates the same policy rule Rule1, but this time 640 its condition and action are reusable. The association classes CA and 641 AB are still present, and they are still DIT contained under Rule1. But 642 rather than having the auxiliary classes ca and ab attached directly to 643 the association classes CA and AB, each now contains DN references to 644 other entries to which these auxiliary classes are attached. These 645 other entries, CIA and AIB, are DIT contained under RepositoryX, which 646 is an instance of the class pcimRepository. Because they are named 647 under an instance of pcimRepository, ca and ab are clearly identified as 648 reusable. 650 +-----+ +-------------+ 651 |Rule1| | RepositoryX | 652 +-|- -|--+ | | 653 | +-----+ | +-------------+ 654 | * * | * * 655 | * * | * * 656 | *** **** | * * 657 | * * v * * 658 | * +---+ * * 659 | * |AB | +------+ * 660 v * | -|-------->|AIB+ab| * 661 +---+ +---+ +------+ * 662 |CA | +------+ 663 | -|------------------------>|CIA+ca| 664 +---+ +------+ 666 +------------------------------+ 667 |LEGEND: | 668 | ***** DIT containment | 669 | + auxiliary attachment | 670 | ----> DN reference | 671 +------------------------------+ 673 Figure 6. Reusable Policy Conditions and Actions 675 The classes pcimConditionAuxClass and pcimActionAuxClass do not 676 themselves represent actual conditions and actions: these are 677 introduced in their subclasses. What pcimConditionAuxClass and 678 pcimActionAuxClass do introduce are the semantics of being a policy 679 condition or a policy action. These are the semantics that all the 680 subclasses of pcimConditionAuxClass and pcimActionAuxClass inherit. 681 Among these semantics are those of representing either a rule-specific 682 or a reusable policy condition or policy action. 684 In order to preserve the ability to represent a rule-specific or a 685 reusable condition or action, as well as a simple policy rule, all the 686 subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST also be 687 auxiliary classes. 689 4.5. Location and Retrieval of Policy Objects in the Directory 691 When a PDP goes to an LDAP directory to retrieve the policy object 692 instances relevant to the PEPs it serves, it is faced with two related 693 problems: 695 - How does it locate and retrieve the directory entries that apply to 696 its PEPs? These entries may include instances of the PCLS classes, 697 instances of domain-specific subclasses of these classes, and 698 instances of other classes modeling such resources as user groups, 699 interfaces, and address ranges. 701 - How does it retrieve the directory entries it needs in an efficient 702 manner, so that retrieval of policy information from the directory 703 does not become a roadblock to scalability? There are two facets to 704 this efficiency: retrieving only the relevant directory entries, 705 and retrieving these entries using as few LDAP calls as possible. 707 The placement of objects in the Directory Information Tree (DIT) 708 involves considerations other than how the policy-related objects will 709 be retrieved by a PDP. Consequently, all that the PCLS can do is to 710 provide a "toolkit" of classes to assist the policy administrator as the 711 DIT is being designed and built. A PDP SHOULD be able to take advantage 712 of any tools that the policy administrator is able to build into the 713 DIT, but it MUST be able to use a less efficient means of retrieval if 714 that is all it has available to it. 716 The basic idea behind the LDAP optimization classes is a simple one: 717 make it possible for a PDP to retrieve all the policy-related objects it 718 needs, and only those objects, using as few LDAP calls as possible. An 719 important assumption underlying this approach is that the policy 720 administrator has sufficient control over the underlying DIT structure 721 to define subtrees for storing policy information. If the policy 722 administrator does not have this level of control over DIT structure, a 723 PDP can still retrieve the policy-related objects it needs individually. 724 But it will require more LDAP access operations to do the retrieval in 725 this way. Figure 7 illustrates how LDAP optimization is accomplished. 727 +-----+ 728 ---------------->| A | 729 DN reference to | | DN references to subtrees +---+ 730 starting object +-----+ +-------------------------->| C | 731 | o--+----+ +---+ +---+ 732 | o--+------------->| B | / \ 733 +-----+ +---+ / \ 734 / \ / \ / ... \ 735 / \ / \ 736 / \ / ... \ 738 Figure 7. Using the pcimSubtreesPtrAuxClass to Locate Policies 739 The PDP is configured initially with a DN reference to some entry in the 740 DIT. The structural class of this entry is not important; the PDP is 741 interested only in the pcimSubtreesPtrAuxClass attached to it. This 742 auxiliary class contains a multi-valued attribute with DN references to 743 objects that anchor subtrees containing policy-related objects of 744 interest to the PDP. Since pcimSubtreesPtrAuxClass is an auxiliary 745 class, it can be attached to an entry that the PDP would need to access 746 anyway - perhaps an entry containing initial configuration settings for 747 the PDP, or for a PEP that uses the PDP. 749 Once it has retrieved the DN references, the PDP will direct to each of 750 the objects identified by them an LDAP request that all entries in its 751 subtree be evaluated against the selection criteria specified in the 752 request. The LDAP-enabled directory then returns all entries in that 753 subtree that satisfy the specified criteria. 755 The selection criteria always specify that object class="pcimPolicy". 756 Since all classes representing policy rules, policy conditions, and 757 policy actions, both in the PCLS and in any domain-specific schema 758 derived from it, are subclasses of the abstract class policy, this 759 criterion evaluates to TRUE for all instances of these classes. To 760 accommodate special cases where a PDP needs to retrieve objects that are 761 not inherently policy-related (for example, an IP address range object 762 referenced by a subclass of pcimActionAuxClass representing the DHCP 763 action "assign from this address range"), the auxiliary class 764 pcimElementAuxClass can be used to "tag" an entry, so that it will be 765 found by the selection criterion "object class=pcimPolicy". 767 The approach described in the preceding paragraph will not work for 768 certain directory implementations, because these implementations do not 769 support matching of auxiliary classes in the objectClass attribute. For 770 environments where these implementations are expected to be present, the 771 "tagging" of entries as relevant to policy can be accomplished by 772 inserting the special value "POLICY" into the list of values contained 773 in the pcimKeywords attribute (provided by the pcimPolicy class). 775 If a PDP needs only a subset of the policy-related objects in the 776 indicated subtrees, then it can be configured with additional selection 777 criteria based on the pcimKeywords attribute defined in the pcimPolicy 778 class. This attribute supports both standardized and administrator- 779 defined values. For example, a PDP could be configured to request only 780 those policy-related objects containing the keywords "DHCP" and "Eastern 781 US". 783 To optimize what is expected to be a typical case, the initial request 784 from the client includes not only the object to which its "seed" DN 785 references, but also the subtree contained under this object. The 786 filter for searching this subtree is whatever the client is going to use 787 later to search the other subtrees: object class="pcimPolicy" or the 788 presence of the keyword "POLICY", and/or presence of a more specific 789 value of pcimKeywords (e.g., "QoS Edge Policy"). 791 Returning to the example in Figure 7, we see that in the best case, a 792 PDP can get all the policy-related objects it needs, and only those 793 objects, with exactly three LDAP requests: one to its starting object A 794 to get the references to B and C, as well as the policy-related objects 795 it needs from the subtree under A, and then one each to B and C to get 796 all the policy-related objects that pass the selection criteria with 797 which it was configured. Once it has retrieved all of these objects, 798 the PDP can then traverse their various DN references locally to 799 understand the semantic relationships among them. The PDP should also 800 be prepared to find a reference to another subtree attached to any of 801 the objects it retrieves, and to follow this reference first, before it 802 follows any of the semantically significant references it has received. 803 This recursion permits a structured approach to identifying related 804 policies. In Figure 7, for example, if the subtree under B includes 805 departmental policies and the one under C includes divisional policies, 806 then there might be a reference from the subtree under C to an object D 807 that roots the subtree of corporate-level policies. 809 A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be 810 capable of retrieving and processing the entries in the subtrees it 811 references, and SHOULD be capable of doing all of this recursively. The 812 same requirements apply to any other entity needing to retrieve policy 813 information from the directory. Thus, a Policy Management Tool that 814 retrieves policy entries from the directory in order to perform 815 validation and conflict detection SHOULD also understand and be capable 816 of using the pcimSubtreesPtrAuxClass. All of these requirements are 817 "SHOULD"s rather than "MUST"s because an LDAP client that doesn't 818 implement them can still access and retrieve the directory entries it 819 needs. The process of doing so will just be less efficient than it 820 would have been if the client had implemented these optimizations. 822 When it is serving as a tool for creating policy entries in the 823 directory, a Policy Management Tool SHOULD support creation of 824 pcimSubtreesPtrAuxClass entries and their references to object 825 instances. 827 4.5.1. Aliases and Other DIT-Optimization Techniques 829 Additional flexibility in DIT structure is available to the policy 830 administrator via LDAP aliasing and other techniques. Previous versions 831 of this document have used aliases. However, because aliases are 832 experimental, the use of aliases has been removed from this version of 833 this document. This is because the IETF has yet to produce a 834 specification on how aliases are represented in the directory or how 835 server implementations are to process aliases. 837 5. Class Definitions 839 The semantics for the policy information classes that are to be mapped 840 directly from the information model to an LDAP representation are 841 detailed in [1]. Consequently, all that this document presents for 842 these classes is the specification for how to do the mapping from the 843 information model (which is independent of repository type and access 844 protocol) to a form that can be accessed using LDAP. Remember that some 845 new classes needed to be created (that were not part of [1]) to 846 implement the LDAP mapping. These new LDAP-only classes are fully 847 documented in this document. 849 The formal language for specifying the classes, attributes, and DIT 850 structure and content rules is that defined in reference [2]. If your 851 implementation does not support auxiliary class inheritance, you will 852 have to list auxiliary classes in content rules explicitly or define 853 them in another (implementation-specific) way. 855 The following notes apply to this section in its entirety. 857 Note 1: in the following definitions, the class and attribute 858 definitions follow RFC2252 [2] but they are line-wrapped to enhance 859 human readability. 861 Note 2: where applicable, the possibilities for specifying DIT structure 862 and content rules are noted. However, care must be taken in specifying 863 DIT structure rules. This is because X.501 [3] states that an entry may 864 only exist in the DIT as a subordinate to another superior entry (the 865 superior) if a DIT structure rule exists in the governing subschema 866 which: 868 1) indicates a name form for the structural object class of the 869 subordinate entry, and 870 2) either includes the entry's superior structure rule as a possible 871 superior structure rule, or 872 3) does not specify a superior structure rule. 874 If this last case (3) applies, then the entry is defined to be a 875 subschema administrative point. This is not what is desired. Therefore, 876 care must be taken in defining structure rules, and in particular, they 877 must be locally augmented. 879 Note 3: Wherever possible, both an equality and a substring matching 880 rule are defined for a particular attribute (as well as an ordering 881 match rule to enable sorting of matching results). This provides two 882 different choices for the developer for maximum flexibility. 884 For example, consider the pcimRoles attribute (section 5.3). Suppose 885 that a PEP has reported that it is interested in pcimRules for three 886 roles R1, R2, and R3. If the goal is to minimize queries, then the PDP 887 can supply three substring filters containing the three role names. 889 These queries will return all of the pcimRules that apply to the PEP, 890 but they may also get some that do not apply (e.g., ones that contain 891 one of the roles R1, R2, or R3 and one or more other roles present in a 892 role-combination [1]). 894 Another strategy would be for the PDP to use only equality filters. This 895 approach eliminates the extraneous replies, but it requires the PDP to 896 explicitly build the desired role-combinations itself. It also requires 897 extra queries. Note that this approach is practical only because the 898 role names in a role combination are required to appear in alphabetical 899 order. 901 Note 4: in the following definitions, note that all LDAP matching rules 902 are defined in [2] and in [8]. The corresponding X.500 matching rules 903 are defined in [7]. 905 Note 5: some of the following attribute definitions specify additional 906 constraints on various data types (e.g., this integer has values that are valid 907 from 1..10). Text has been added to instruct servers and applications what to 908 do if a value outside of this range is encountered. 909 In all cases, if a constraint is violated, then the policy rule SHOULD be 910 treated as being disabled, meaning that execution of the policy rule SHOULD be 911 stopped. 913 5.1. The Abstract Class pcimPolicy 915 The abstract class pcimPolicy is a direct mapping of the abstract class 916 Policy from the PCIM. The class value "pcimPolicy" is also used as the 917 mechanism for identifying policy-related instances in the Directory 918 Information Tree. An instance of any class may be "tagged" with this 919 class value by attaching to it the auxiliary class pcimElementAuxClass. 920 Since pcimPolicy is derived from the class dlm1ManagedElement defined in 921 reference [5], this specification has a normative dependency on that 922 element of reference [5]. 924 The class definition is as follows: 926 ( IANA-ASSIGNED-OID.1.1 NAME 'pcimPolicy' 927 DESC 'An abstract class that is the base class for all classes 928 that describe policy-related instances.' 929 SUP dlm1ManagedElement 930 ABSTRACT 931 MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $ 932 pcimKeywords ) 933 ) 935 The attribute cn is defined in RFC 2256 [6]. The dlmCaption, 936 dlmDescription, and orderedCimKeys attributes are defined in [5]. 938 The pcimKeywords attribute is a multi-valued attribute that contains a 939 set of keywords to assist directory clients in locating the policy 940 objects identified by these keywords. It is defined as follows: 942 ( IANA-ASSIGNED-OID.2.3 NAME 'pcimKeywords' 943 DESC 'A set of keywords to assist directory clients in 944 locating the policy objects applicable to them.' 945 EQUALITY caseIgnoreMatch 946 ORDERING caseIgnoreOrderingMatch 947 SUBSTR caseIgnoreSubstringsMatch 948 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 949 ) 951 5.2. The Three Policy Group Classes 953 PCIM [1] defines the PolicyGroup class to serve as a generalized 954 aggregation mechanism, enabling PolicyRules and/or PolicyGroups to be 955 aggregated together. PCLS maps this class into three LDAP classes, 956 called pcimGroup, pcimGroupAuxClass, and pcimGroupInstance. This is done 957 in order to provide maximum flexibility for the DIT designer. 959 The class definitions for the three policy group classes are listed 960 below. These class definitions do not include attributes to realize the 961 PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from 962 the PCIM. This is because a pcimGroup object refers to instances of 963 pcimGroup and pcimRule via, respectively, the attribute 964 pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object 965 class and the attribute pcimRulesAuxContainedSet in the 966 pcimRuleContainmentAuxClass object class. 968 To maximize flexibility, the pcimGroup class is defined as abstract. The 969 subclass pcimGroupAuxClass provides for auxiliary attachment to 970 another entry, while the structural subclass pcimGroupInstance is 971 available to represent a policy group as a standalone entry. 973 The class definitions are as follows. First, the definition of the 974 abstract class pcimGroup: 976 ( IANA-ASSIGNED-OID.1.2 NAME 'pcimGroup' 977 DESC 'A container for a set of related pcimRules and/or 978 a set of related pcimGroups.' 979 SUP pcimPolicy 980 ABSTRACT 981 MAY ( pcimGroupName ) 982 ) 983 The one attribute of pcimGroup is pcimGroupName. This attribute is used 984 to define a user-friendly name of this policy group, and may be used as 985 a naming attribute if desired. It is defined as follows: 987 ( IANA-ASSIGNED-OID.2.4 NAME 'pcimGroupName' 988 DESC 'The user-friendly name of this policy group.' 989 EQUALITY caseIgnoreMatch 990 ORDERING caseIgnoreOrderingMatch 991 SUBSTR caseIgnoreSubstringsMatch 992 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 993 SINGLE-VALUE 994 ) 996 The two subclasses of pcimGroup are defined as follows. The class 997 pcimGroupAuxClass is an auxiliary class that can be used to collect a 998 set of related pcimRule and/or pcimGroup classes. It is defined as 999 follows: 1001 ( IANA-ASSIGNED-OID.1.3 NAME 'pcimGroupAuxClass' 1002 DESC 'An auxiliary class that collects a set of related 1003 pcimRule and/or pcimGroup entries.' 1004 SUP pcimGroup 1005 AUXILIARY 1006 ) 1008 The class pcimGroupInstance is a structural class that can be used to 1009 collect a set of related pcimRule and/or pcimGroup classes. It is 1010 defined as follows: 1012 ( IANA-ASSIGNED-OID.1.4 NAME 'pcimGroupInstance' 1013 DESC 'A structural class that collects a set of related 1014 pcimRule and/or pcimGroup entries.' 1015 SUP pcimGroup 1016 STRUCTURAL 1017 ) 1019 A DIT content rule could be written to enable an instance of 1020 pcimGroupInstance to have attached to it either references to one or 1021 more policy groups (using pcimGroupContainmentAuxClass) or references to 1022 one or more policy rules (using pcimRuleContainmentAuxClass). This would 1023 be used to formalize the semantics of the PolicyGroup class [1]. Since 1024 these semantics do not include specifying any properties of the 1025 PolicyGroup class, the content rule would not need to specify any 1026 attributes. 1028 Similarly, three separate DIT structure rules could be written, each of 1029 which would refer to a specific name form that identified one of the 1030 three possible naming attributes (i.e., pcimGroupName, cn, and 1031 orderedCIMKeys) for the pcimGroup object class. This structure rule 1032 SHOULD include a superiorStructureRule (see Note 2 at the beginning of 1033 section 5). The three name forms referenced by the three structure rules 1034 would each define one of the three naming attributes. 1036 5.3. The Three Policy Rule Classes 1038 The information model defines a PolicyRule class to represent the "If 1039 Condition then Action" semantics associated with processing policy 1040 information. For maximum flexibility, the PCLS maps this class into 1041 three LDAP classes. 1043 To maximize flexibility, the pcimRule class is defined as abstract. The 1044 subclass pcimRuleAuxClass provides for auxiliary attachment to another 1045 entry, while the structural subclass pcimRuleInstance is available to 1046 represent a policy rule as a standalone entry. 1048 The conditions and actions associated with a policy rule are modeled, 1049 respectively, with auxiliary subclasses of the auxiliary classes 1050 pcimConditionAuxClass and pcimActionAuxClass. Each of these auxiliary 1051 subclasses is attached to an instance of one of three structural 1052 classes. A subclass of pcimConditionAuxClass is attached to an instance 1053 of pcimRuleInstance, to an instance of pcimRuleConditionAssociation, or 1054 to an instance of pcimPolicyInstance. Similarly, a subclass of 1055 pcimActionAuxClass is attached to an instance of pcimRuleInstance, to an 1056 instance of pcimRuleActionAssociation, or to an instance of 1057 pcimPolicyInstance. 1059 The pcimRuleValidityPeriodList attribute (defined below) realizes the 1060 PolicyRuleValidityPeriod association defined in the PCIM. Since this 1061 association has no additional properties besides those that tie the 1062 association to its associated objects, this association can be realized 1063 by simply using an attribute. Thus, the pcimRuleValidityPeriodList 1064 attribute is simply a multi-valued attribute that provides an unordered 1065 set of DN references to one or more instances of the pcimTPCAuxClass, 1066 indicating when the policy rule is scheduled to be active and when it is 1067 scheduled to be inactive. A policy rule is scheduled to be active if it 1068 is active according to AT LEAST ONE of the pcimTPCAuxClass instances 1069 referenced by this attribute. 1071 The PolicyConditionInPolicyRule and PolicyActionInPolicyRule 1072 associations, however, do have additional attributes. The association 1073 PolicyActionInPolicyRule defines an integer attribute to sequence the 1074 actions, and the association PolicyConditionInPolicyRule has both an 1075 integer attribute to group the condition terms as well as a Boolean 1076 property to specify whether a condition is to be negated. 1078 In the PCLS, these additional association attributes are represented as 1079 attributes of two classes introduced specifically to model these 1080 associations. These classes are the pcimRuleConditionAssociation class 1081 and the pcimRuleActionAssociation class, which are defined in Sections 1082 5.4 and 5.5, respectively. Thus, they do not appear as attributes of 1083 the class pcimRule. Instead, the pcimRuleConditionList and 1084 pcimRuleActionList attributes can be used to reference these classes. 1086 The class definitions for the three pcimRule classes are as follows. 1088 The abstract class pcimRule is a base class for representing the "If 1089 Condition then Action" semantics associated with a policy rule. It is 1090 defined as follows: 1092 ( IANA-ASSIGNED-OID.1.5 NAME 'pcimRule' 1093 DESC 'The base class for representing the "If Condition 1094 then Action" semantics associated with a policy rule.' 1095 SUP pcimPolicy 1096 ABSTRACT 1097 MAY ( pcimRuleName $ pcimRuleEnabled $ 1098 pcimRuleConditionListType $ pcimRuleConditionList $ 1099 pcimRuleActionList $ pcimRuleValidityPeriodList $ 1100 pcimRuleUsage $ pcimRulePriority $ 1101 pcimRuleMandatory $ pcimRuleSequencedActions $ 1102 pcimRoles ) 1103 ) 1105 The PCIM [1] defines seven properties for the PolicyRule class. The PCLS 1106 defines eleven attributes for the pcimRule class, which is the LDAP 1107 equivalent of the PolicyRule class. Of these eleven attributes, seven 1108 are mapped directly from corresponding properties in PCIM's PolicyRule 1109 class. The remaining four attributes are a class-specific optional 1110 naming attribute, and three attributes used to realize the three 1111 associations that the pcimRule class participates in. 1113 The pcimRuleName attribute is used as a user-friendly name of this 1114 policy rule, and can also serve as the class-specific optional naming 1115 attribute. It is defined as follows: 1117 ( IANA-ASSIGNED-OID.2.5 NAME 'pcimRuleName' 1118 DESC 'The user-friendly name of this policy rule.' 1119 EQUALITY caseIgnoreMatch 1120 ORDERING caseIgnoreOrderingMatch 1121 SUBSTR caseIgnoreSubstringsMatch 1122 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1123 SINGLE-VALUE 1124 ) 1125 The pcimRuleEnabled attribute is an integer enumeration indicating 1126 whether a policy rule is administratively enabled (value=1), 1127 administratively disabled (value=2), or enabled for debug (value=3). It 1128 is defined as follows: 1130 ( IANA-ASSIGNED-OID.2.6 NAME 'pcimRuleEnabled' 1131 DESC 'An integer indicating whether a policy rule is 1132 administratively enabled (value=1), disabled 1133 (value=2), or enabled for debug (value=3).' 1134 EQUALITY integerMatch 1135 ORDERING integerOrderingMatch 1136 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1137 SINGLE-VALUE 1138 ) 1140 Note: All other values for the pcimRuleEnabled attribute are considered 1141 errors, and the administrator SHOULD treat this rule as being disabled 1142 if an invalid value is found. 1144 The pcimRuleConditionListType attribute is used to indicate whether the 1145 list of policy conditions associated with this policy rule is in 1146 disjunctive normal form (DNF, value=1) or conjunctive normal form (CNF, 1147 value=2). It is defined as follows: 1149 ( IANA-ASSIGNED-OID.2.7 NAME 'pcimRuleConditionListType' 1150 DESC 'A value of 1 means that this policy rule is in 1151 disjunctive normal form; a value of 2 means that this 1152 policy rule is in conjunctive normal form.' 1153 EQUALITY integerMatch 1154 ORDERING integerOrderingMatch 1155 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1156 SINGLE-VALUE 1157 ) 1159 Note: any value other than 1 or 2 for the pcimRuleConditionListType 1160 attribute is considered an error. Administrators SHOULD treat this rule 1161 as being disabled if an invalid value is found, since it is unclear how 1162 to structure the condition list. 1164 The pcimRuleConditionList attribute is a multi-valued attribute that is 1165 used to realize the policyRuleInPolicyCondition association defined in 1166 [1]. It contains a set of DNs of pcimRuleConditionAssociation entries 1167 representing associations between this policy rule and its conditions. 1168 No order is implied. It is defined as follows: 1170 ( IANA-ASSIGNED-OID.2.8 NAME 'pcimRuleConditionList' 1171 DESC 'Unordered set of DNs of pcimRuleConditionAssociation 1172 entries representing associations between this policy 1173 rule and its conditions.' 1174 EQUALITY distinguishedNameMatch 1175 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1176 ) 1177 The pcimRuleActionList attribute is a multi-valued attribute that is 1178 used to realize the policyRuleInPolicyAction association defined in [1]. 1179 It contains a set of DNs of pcimRuleActionAssociation entries 1180 representing associations between this policy rule and its actions. No 1181 order is implied. It is defined as follows: 1183 ( IANA-ASSIGNED-OID.2.9 NAME 'pcimRuleActionList' 1184 DESC 'Unordered set of DNs of pcimRuleActionAssociation 1185 entries representing associations between this policy 1186 rule and its actions.' 1187 EQUALITY distinguishedNameMatch 1188 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1189 ) 1191 The pcimRuleValidityPeriodList attribute is a multi-valued attribute 1192 that is used to realize the pcimRuleValidityPeriod association that is 1193 defined in [1]. It contains a set of DNs of pcimRuleValidityAssociation 1194 entries that determine when the pcimRule is scheduled to be active or 1195 inactive. No order is implied. It is defined as follows: 1197 ( IANA-ASSIGNED-OID.2.10 NAME 'pcimRuleValidityPeriodList' 1198 DESC 'Unordered set of DNs of pcimRuleValidityAssociation 1199 entries that determine when the pcimRule is scheduled 1200 to be active or inactive.' 1201 EQUALITY distinguishedNameMatch 1202 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1203 ) 1205 The pcimRuleUsage attribute is a free-form sting providing guidelines on 1206 how this policy should be used. It is defined as follows: 1208 ( IANA-ASSIGNED-OID.2.11 NAME 'pcimRuleUsage' 1209 DESC 'This attribute is a free-form sting providing 1210 guidelines on how this policy should be used.' 1211 EQUALITY caseIgnoreMatch 1212 ORDERING caseIgnoreOrderingMatch 1213 SUBSTR caseIgnoreSubstringsMatch 1214 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1215 SINGLE-VALUE 1216 ) 1218 The pcimRulePriority attribute is a non-negative integer that is used to 1219 prioritize this pcimRule relative to other pcimRules. A larger value 1220 indicates a higher priority. It is defined as follows: 1222 ( IANA-ASSIGNED-OID.2.12 NAME 'pcimRulePriority' 1223 DESC 'A non-negative integer for prioritizing this 1224 pcimRule relative to other pcimRules. A larger 1225 value indicates a higher priority.' 1226 EQUALITY integerMatch 1227 ORDERING integerOrderingMatch 1228 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1229 SINGLE-VALUE 1230 ) 1232 Note: if the value of the pcimRulePriority field is 0, then it SHOULD be 1233 treated as "don't care". On the other hand, if the value is negative, 1234 then it SHOULD be treated as an error and Administrators SHOULD treat 1235 this rule as being disabled. 1237 The pcimRuleMandatory attribute is a Boolean attribute that, if TRUE, 1238 indicates that for this policy rule, the evaluation of its conditions 1239 and execution of its actions (if the condition is satisfied) is 1240 required. If it is FALSE, then the evaluation of its conditions and 1241 execution of its actions (if the condition is satisfied) is not 1242 required. This attribute is defined as follows: 1244 ( IANA-ASSIGNED-OID.2.13 NAME 'pcimRuleMandatory' 1245 DESC 'If TRUE, indicates that for this policy rule, the 1246 evaluation of its conditions and execution of its 1247 actions (if the condition is satisfied) is required.' 1248 EQUALITY booleanMatch 1249 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1250 SINGLE-VALUE 1251 ) 1253 The pcimRuleSequencedActions attribute is an integer enumeration that is 1254 used to indicate that the ordering of actions defined by the 1255 pcimActionOrder attribute is either mandatory(value=1), 1256 recommended(value=2), or dontCare(value=3). It is defined as follows: 1258 ( IANA-ASSIGNED-OID.2.14 NAME 'pcimRuleSequencedActions' 1259 DESC 'An integer enumeration indicating that the ordering of 1260 actions defined by the pcimActionOrder attribute is 1261 mandatory(1), recommended(2), or dontCare(3).' 1262 EQUALITY integerMatch 1263 ORDERING integerOrderingMatch 1264 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1265 SINGLE-VALUE 1266 ) 1268 Note: if the value of pcimRulesSequencedActions field is not one of 1269 these three values, then Administrators SHOULD treat this rule as being 1270 disabled. 1272 The pcimRoles attribute represents the policyRoles property of [1]. Each 1273 value of this attribute represents a role-combination, which is a string 1274 of the form: 1275 [&&]* 1276 where the individual role names appear in alphabetical order according 1277 to the collating sequence for UCS-2. This attribute is defined as 1278 follows: 1280 ( IANA-ASSIGNED-OID.2.15 NAME 'pcimRoles' 1281 DESC 'Each value of this attribute represents a role- 1282 combination.' 1283 EQUALITY caseIgnoreMatch 1284 ORDERING caseIgnoreOrderingMatch 1285 SUBSTR caseIgnoreSubstringsMatch 1286 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1287 ) 1289 Note: if the value of the pcimRoles attribute does not conform to the 1290 format "[&&]*" (see Section 6.3.7 of [1]), then this 1291 attribute is malformed and its policy rule SHOULD be treated as being 1292 disabled. 1294 The two subclasses of the pcimRule class are defined as follows. First, 1295 the pcimRuleAuxClass is an auxiliary class for representing the "If 1296 Condition then Action" semantics associated with a policy rule. Its 1297 class definition is as follows: 1299 ( IANA-ASSIGNED-OID.1.6 NAME 'pcimRuleAuxClass' 1300 DESC 'An auxiliary class for representing the "If Condition 1301 then Action" semantics associated with a policy rule.' 1302 SUP pcimRule 1303 AUXILIARY 1304 ) 1306 The pcimRuleInstance is a structural class for representing the "If 1307 Condition then Action" semantics associated with a policy rule. Its 1308 class definition is as follows: 1310 ( IANA-ASSIGNED-OID.1.7 NAME 'pcimRuleInstance' 1311 DESC 'A structural class for representing the "If Condition 1312 then Action" semantics associated with a policy rule.' 1313 SUP pcimRule 1314 STRUCTURAL 1315 ) 1316 A DIT content rule could be written to enable an instance of 1317 pcimRuleInstance to have attached to it either references to one or more 1318 policy conditions (using pcimConditionAuxClass) or references to one or 1319 more policy actions (using pcimActionAuxClass). This would be used to 1320 formalize the semantics of the PolicyRule class [1]. Since these 1321 semantics do not include specifying any properties of the PolicyRule 1322 class, the content rule would not need to specify any attributes. 1324 Similarly, three separate DIT structure rules could be written, each of 1325 which would refer to a specific name form that identified one of its 1326 three possible naming attributes (i.e., pcimRuleName, cn, and 1327 orderedCIMKeys). This structure rule SHOULD include a 1328 superiorStructureRule (see Note 2 at the beginning of section 5). The 1329 three name forms referenced by the three structure rules would each 1330 define one of the three naming attributes. 1332 5.4. The Class pcimRuleConditionAssociation 1334 This class contains attributes to represent the properties of the PCIM's 1335 PolicyConditionInPolicyRule association. Instances of this class are 1336 related to an instance of pcimRule via DIT containment. The policy 1337 conditions themselves are represented by auxiliary subclasses of the 1338 auxiliary class pcimConditionAuxClass. These auxiliary classes are 1339 attached directly to instances of pcimRuleConditionAssociation for rule- 1340 specific policy conditions. For a reusable policy condition, the 1341 policyCondition auxiliary subclass is attached to an instance of the 1342 class pcimPolicyInstance (which is presumably associated with a 1343 pcimRepository by DIT containment), and the policyConditionDN attribute 1344 (of this class) is used to reference the reusable policyCondition 1345 instance. 1347 The class definition is as follows: 1349 ( IANA-ASSIGNED-OID.1.8 NAME 'pcimRuleConditionAssociation' 1350 DESC 'This class contains attributes characterizing the 1351 relationship between a policy rule and one of its 1352 policy conditions.' 1353 SUP pcimPolicy 1354 MUST ( pcimConditionGroupNumber $ pcimConditionNegated ) 1355 MAY ( pcimConditionName $ pcimConditionDN ) 1356 ) 1358 The attributes of this class are defined as follows. 1360 The pcimConditionGroupNumber attribute is a non-negative integer. It is 1361 used to identify the group to which the condition referenced by this 1362 association is assigned. This attribute is defined as follows: 1364 ( IANA-ASSIGNED-OID.2.16 1365 NAME 'pcimConditionGroupNumber' 1366 DESC 'The number of the group to which a policy condition 1367 belongs. This is used to form the DNF or CNF 1368 expression associated with a policy rule.' 1369 EQUALITY integerMatch 1370 ORDERING integerOrderingMatch 1371 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1372 SINGLE-VALUE 1373 ) 1375 Note that this number is non-negative. A negative value for this 1376 attribute is invalid, and any policy rule that refers to an invalid 1377 entry SHOULD be treated as being disabled. 1379 The pcimConditionNegated attribute is a Boolean attribute that indicates 1380 whether this policy condition is to be negated or not. If it is TRUE 1381 (FALSE), it indicates that a policy condition IS (IS NOT) negated in the 1382 DNF or CNF expression associated with a policy rule. This attribute is 1383 defined as follows: 1385 ( IANA-ASSIGNED-OID.2.17 1386 NAME 'pcimConditionNegated' 1387 DESC 'If TRUE (FALSE), it indicates that a policy condition 1388 IS (IS NOT) negated in the DNF or CNF expression 1389 associated with a policy rule.' 1390 EQUALITY booleanMatch 1391 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1392 SINGLE-VALUE 1393 ) 1395 The pcimConditionName is a user-friendly name for identifying this 1396 policy condition, and may be used as a naming attribute if desired. This 1397 attribute is defined as follows: 1399 ( IANA-ASSIGNED-OID.2.18 1400 NAME 'pcimConditionName' 1401 DESC 'A user-friendly name for a policy condition.' 1402 EQUALITY caseIgnoreMatch 1403 ORDERING caseIgnoreOrderingMatch 1404 SUBSTR caseIgnoreSubstringsMatch 1405 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1406 SINGLE-VALUE 1407 ) 1409 The pcimConditionDN attribute is a DN that references an instance of a 1410 reusable policy condition. This attribute is defined as follows: 1412 ( IANA-ASSIGNED-OID.2.19 1413 NAME 'pcimConditionDN' 1414 DESC 'A DN that references an instance of a reusable policy 1415 condition.' 1416 EQUALITY distinguishedNameMatch 1417 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1418 SINGLE-VALUE 1419 ) 1421 A DIT content rule could be written to enable an instance of 1422 pcimRuleConditionAssociation to have attached to it an instance of the 1423 auxiliary class pcimConditionAuxClass, or one of its subclasses. This 1424 would be used to formalize the semantics of the 1425 PolicyConditionInPolicyRule association. Specifically, this would be 1426 used to represent a rule-specific policy condition [1]. 1428 Similarly, three separate DIT structure rules could be written. Each of 1429 these DIT structure rules would refer to a specific name form that 1430 defined two important semantics. First, each name form would identify 1431 one of the three possible naming attributes (i.e., pcimConditionName, 1432 cn, and orderedCIMKeys) for the pcimRuleConditionAssociation object 1433 class. Second, each name form would require that an instance of the 1434 pcimRuleConditionAssociation class have as its superior an instance of 1435 the pcimRule class. This structure rule SHOULD also include a 1436 superiorStructureRule (see Note 2 at the beginning of section 5). 1438 5.5. The Class pcimRuleValidityAssociation 1440 The policyRuleValidityPeriod aggregation is mapped to the PCLS 1441 pcimRuleValidityAssociation class. This class represents the scheduled 1442 activation and deactivation of a policy rule by binding the definition 1443 of times that the policy is active to the policy rule itself. The 1444 "scheduled" times are either identified through an attached auxiliary 1445 class pcimTPCAuxClass, or are referenced through its 1446 pcimTimePeriodConditionDN attribute. 1448 This class is defined as follows: 1450 ( IANA-ASSIGNED-OID.1.9 NAME 'pcimRuleValidityAssociation' 1451 DESC 'This defines the scheduled activation or deactivation 1452 of a policy rule.' 1453 SUP pcimPolicy 1454 STRUCTURAL 1455 MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN ) 1456 ) 1458 The attributes of this class are defined as follows: 1460 The pcimValidityConditionName attribute is used to define a user- 1461 friendly name of this condition, and may be used as a naming attribute 1462 if desired. This attribute is defined as follows: 1464 ( IANA-ASSIGNED-OID.2.20 1465 NAME 'pcimValidityConditionName' 1466 DESC 'A user-friendly name for identifying an instance of 1467 a pcimRuleValidityAssociation entry.' 1468 EQUALITY caseIgnoreMatch 1469 ORDERING caseIgnoreOrderingMatch 1470 SUBSTR caseIgnoreSubstringsMatch 1471 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1472 SINGLE-VALUE 1473 ) 1475 The pcimTimePeriodConditionDN attribute is a DN that references a 1476 reusable time period condition. It is defined as follows: 1478 ( IANA-ASSIGNED-OID.2.21 1479 NAME 'pcimTimePeriodConditionDN' 1480 DESC 'A reference to a reusable policy time period 1481 condition.' 1482 EQUALITY distinguishedNameMatch 1483 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1484 SINGLE-VALUE 1485 ) 1487 A DIT content rule could be written to enable an instance of 1488 pcimRuleValidityAssociation to have attached to it an instance of the 1489 auxiliary class pcimTPCAuxClass, or one of its subclasses. This would be 1490 used to formalize the semantics of the PolicyRuleValidityPeriod 1491 aggregation [1]. 1493 Similarly, three separate DIT structure rules could be written. Each of 1494 these DIT structure rules would refer to a specific name form that 1495 defined two important semantics. First, each name form would identify 1496 one of the three possible naming attributes (i.e., 1497 pcimValidityConditionName, cn, and orderedCIMKeys) for the 1498 pcimRuleValidityAssociation object class. Second, each name form would 1499 require that an instance of the pcimRuleValidityAssociation class have 1500 as its superior an instance of the pcimRule class. This structure rule 1501 SHOULD also include a superiorStructureRule (see Note 2 at the beginning 1502 of section 5). 1504 5.6. The Class pcimRuleActionAssociation 1506 This class contains an attribute to represent the one property of the 1507 PCIM PolicyActionInPolicyRule association, ActionOrder. This property is 1508 used to specify an order for executing the actions associated with a 1509 policy rule. Instances of this class are related to an instance of 1510 pcimRule via DIT containment. The actions themselves are represented by 1511 auxiliary subclasses of the auxiliary class pcimActionAuxClass. 1513 These auxiliary classes are attached directly to instances of 1514 pcimRuleActionAssociation for rule-specific policy actions. For a 1515 reusable policy action, the pcimAction auxiliary subclass is attached to 1516 an instance of the class pcimPolicyInstance (which is presumably 1517 associated with a pcimRepository by DIT containment), and the 1518 pcimActionDN attribute (of this class) is used to reference the reusable 1519 pcimCondition instance. 1521 The class definition is as follows: 1523 ( IANA-ASSIGNED-OID.1.10 NAME 'pcimRuleActionAssociation' 1524 DESC 'This class contains attributes characterizing the 1525 relationship between a policy rule and one of its 1526 policy actions.' 1527 SUP pcimPolicy 1528 MUST ( pcimActionOrder ) 1529 MAY ( pcimActionName $ pcimActionDN ) 1530 ) 1532 The pcimActionName attribute is used to define a user-friendly name of 1533 this action, and may be used as a naming attribute if desired. This 1534 attribute is defined as follows: 1536 ( IANA-ASSIGNED-OID.2.22 1537 NAME 'pcimActionName' 1538 DESC 'A user-friendly name for a policy action.' 1539 EQUALITY caseIgnoreMatch 1540 ORDERING caseIgnoreOrderingMatch 1541 SUBSTR caseIgnoreSubstringsMatch 1542 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1543 SINGLE-VALUE 1544 ) 1546 The pcimActionOrder attribute is an unsigned integer that is used to 1547 indicate the relative position of an action in a sequence of actions 1548 that are associated with a given policy rule. When this number is 1549 positive, it indicates a place in the sequence of actions to be 1550 performed, with smaller values indicating earlier positions in the 1551 sequence. If the value is zero, then this indicates that the order is 1552 irrelevant. Note that if two or more actions have the same non-zero 1553 value, they may be performed in any order as long as they are each 1554 performed in the correct place in the overall sequence of actions. This 1555 attribute is defined as follows: 1557 ( IANA-ASSIGNED-OID.2.23 1558 NAME 'pcimActionOrder' 1559 DESC 'An integer indicating the relative order of an action 1560 in the context of a policy rule.' 1561 EQUALITY integerMatch 1562 ORDERING integerOrderingMatch 1563 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1564 SINGLE-VALUE 1565 ) 1566 Note: if the value of the pcimActionOrder field is negative, then it 1567 SHOULD be treated as an error and any policy rule that refers to such an 1568 entry SHOULD be treated as being disabled. 1570 The pcimActionDN attribute is a DN that references a reusable policy 1571 action. It is defined as follows: 1573 ( IANA-ASSIGNED-OID.2.24 1574 NAME 'pcimActionDN' 1575 DESC 'A DN that references a reusable policy action.' 1576 EQUALITY distinguishedNameMatch 1577 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1578 SINGLE-VALUE 1579 ) 1581 A DIT content rule could be written to enable an instance of 1582 pcimRuleActionAssociation to have attached to it an instance of the 1583 auxiliary class pcimActionAuxClass, or one of its subclasses. This would 1584 be used to formalize the semantics of the PolicyActionInPolicyRule 1585 association. Specifically, this would be used to represent a rule- 1586 specific policy action [1]. 1588 Similarly, three separate DIT structure rules could be written. Each of 1589 these DIT structure rules would refer to a specific name form that 1590 defined two important semantics. First, each name form would identify 1591 one of the three possible naming attributes (i.e., pcimActionName, cn, 1592 and orderedCIMKeys) for the pcimRuleActionAssociation object class. 1593 Second, each name form would require that an instance of the 1594 pcimRuleActionAssociation class have as its superior an instance of the 1595 pcimRule class. This structure rule should also include a 1596 superiorStructureRule (see Note 2 at the beginning of section 5). 1598 5.7. The Auxiliary Class pcimConditionAuxClass 1600 The purpose of a policy condition is to determine whether or not the set 1601 of actions (contained in the pcimRule that the condition applies to) 1602 should be executed or not. This class defines the basic organizational 1603 semantics of a policy condition, as specified in [1]. Subclasses of this 1604 auxiliary class can be attached to instances of three other classes in 1605 the PCLS. When a subclass of this class is attached to an instance of 1606 pcimRuleConditionAssociation, or to an instance of pcimRule, it 1607 represents a rule-specific policy condition. When a subclass of this 1608 class is attached to an instance of pcimPolicyInstance, it represents a 1609 reusable policy condition. 1611 Since all of the classes to which subclasses of this auxiliary class may 1612 be attached are derived from the pcimPolicy class, the attributes of 1613 pcimPolicy will already be defined for the entries to which these 1614 subclasses attach. Thus, this class is derived directly from "top". 1616 The class definition is as follows: 1618 ( IANA-ASSIGNED-OID.1.11 NAME 'pcimConditionAuxClass' 1619 DESC 'A class representing a condition to be evaluated in 1620 conjunction with a policy rule.' 1621 SUP top 1622 AUXILIARY 1623 ) 1625 5.8. The Auxiliary Class pcimTPCAuxClass 1627 The PCIM defines a time period class, PolicyTimePeriodCondition, to 1628 provide a means of representing the time periods during which a policy 1629 rule is valid, i.e., active. It also defines an aggregation, 1630 PolicyRuleValidityPeriod, so that time periods can be associated with a 1631 PolicyRule. The LDAP mapping also provides two classes, one for the 1632 time condition itself, and one for the aggregation. 1634 In the PCIM, the time period class is named PolicyTimePeriodCondition. 1635 However, the resulting name of the auxiliary class in this mapping 1636 (pcimTimePeriodConditionAuxClass) exceeds the length of a name that some 1637 directories can store. Therefore, the name has been shortened to 1638 pcimTPCAuxClass. 1640 The class definition is as follows: 1642 ( IANA-ASSIGNED-OID.1.12 NAME 'pcimTPCAuxClass' 1643 DESC 'This provides the capability of enabling or disabling 1644 a policy rule according to a predetermined schedule.' 1645 SUP pcimConditionAuxClass 1646 AUXILIARY 1647 MAY ( pcimTPCTime $ pcimTPCMonthOfYearMask $ 1648 pcimTPCDayOfMonthMask $ pcimTPCDayOfWeekMask $ 1649 pcimTPCTimeOfDayMask $ pcimTPCLocalOrUtcTime ) 1650 ) 1652 The attributes of the pcimTPCAuxClass are defined as follows. 1654 The pcimTPCTime attribute represents the time period that a policy rule 1655 is enabled for. This attribute is defined as a string in [1] with a 1656 special format which defines a time period with a starting date and an 1657 ending date separated by a forward slash ("/"), as follows: 1659 yyyymmddThhmmss/yyyymmddThhmmss 1661 where the first date and time may be replaced with the string 1662 "THISANDPRIOR" or the second date and time may be replaced with the 1663 string "THISANDFUTURE". This attribute is defined as follows: 1665 ( IANA-ASSIGNED-OID.2.25 1666 NAME 'pcimTPCTime' 1667 DESC 'The start and end times on which a policy rule is 1668 valid.' 1669 EQUALITY caseIgnoreMatch 1670 ORDERING caseIgnoreOrderingMatch 1671 SUBSTR caseIgnoreSubstringsMatch 1672 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1673 SINGLE-VALUE 1674 ) 1676 The value of this attribute SHOULD be checked against its defined format 1677 ("yyyymmddThhmmss/yyyymmddThhmmss", where the first and second date 1678 strings may be replaced with the strings "THISANDPRIOR" and 1679 "THISANDFUTURE"). If the value of this attribute does not conform to 1680 this syntax, then this SHOULD be considered an error and the policy rule 1681 SHOULD be treated as being disabled. 1683 The next four attributes (pcimTPCMonthOfYearMask, pcimTPCDayOfMonthMask, 1684 pcimTPCDayOfWeekMask, and pcimTPCTimeOfDayMask) are all defined as octet 1685 strings in [1]. However, the semantics of each of these attributes are 1686 contained in bit strings of various fixed lengths. Therefore, the PCLS 1687 uses a syntax of Bit String to represent each of them. The definition of 1688 these four attributes are as follows. 1690 The pcimTPCMonthOfYearMask attribute defines a 12-bit mask identifying 1691 the months of the year in which a policy rule is valid. The format is a 1692 bit string of length 12, representing the months of the year from 1693 January through December. The definition of this attribute is as 1694 follows: 1696 ( IANA-ASSIGNED-OID.2.26 1697 NAME 'pcimTPCMonthOfYearMask' 1698 DESC 'This identifies the valid months of the year for a 1699 policy rule using a 12-bit string that represents the 1700 months of the year from January through December.' 1701 EQUALITY bitStringMatch 1702 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1703 SINGLE-VALUE 1704 ) 1706 The value of this attribute SHOULD be checked against its defined 1707 format. If the value of this attribute does not conform to this syntax, 1708 then this SHOULD be considered an error and the policy rule SHOULD be 1709 treated as being disabled. 1711 The pcimTPCMonthOfDayMask attribute defines a mask identifying the days 1712 of the month on which a policy rule is valid. The format is a bit string 1713 of length 62. The first 31 positions represent the days of the month in 1714 ascending order, from day 1 to day 31. The next 31 positions represent 1715 the days of the month in descending order, from the last day to the day 1716 31 days from the end. The definition of this attribute is as follows: 1718 ( IANA-ASSIGNED-OID.2.27 1719 NAME 'pcimTPCDayOfMonthMask' 1720 DESC 'This identifies the valid days of the month for a 1721 policy rule using a 62-bit string. The first 31 1722 positions represent the days of the month in ascending 1723 order, and the next 31 positions represent the days of 1724 the month in descending order.' 1725 EQUALITY bitStringMatch 1726 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1727 SINGLE-VALUE 1728 ) 1730 The value of this attribute SHOULD be checked against its defined 1731 format. If the value of this attribute does not conform to this syntax, 1732 then this SHOULD be considered an error and the policy rule SHOULD be 1733 treated as being disabled. 1735 The pcimTPCDayOfWeekMask attribute defines a mask identifying the days 1736 of the week on which a policy rule is valid. The format is a bit string 1737 of length 7, representing the days of the week from Sunday through 1738 Saturday. The definition of this attribute is as follows: 1740 ( IANA-ASSIGNED-OID.2.28 1741 NAME 'pcimTPCDayOfWeekMask' 1742 DESC 'This identifies the valid days of the week for a 1743 policy rule using a 7-bit string. This represents 1744 the days of the week from Sunday through Saturday.' 1745 EQUALITY bitStringMatch 1746 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1747 SINGLE-VALUE 1748 ) 1750 The value of this attribute SHOULD be checked against its defined 1751 format. If the value of this attribute does not conform to this syntax, 1752 then this SHOULD be considered an error and the policy rule SHOULD be 1753 treated as being disabled. 1755 The pcimTPCTimeOfDayMask attribute defines the range of times at which a 1756 policy rule is valid. If the second time is earlier than the first, then 1757 the interval spans midnight. The format of the string is 1758 Thhmmss/Thhmmss. The definition of this attribute is as follows: 1760 ( IANA-ASSIGNED-OID.2.29 1761 NAME 'pcimTPCTimeOfDayMask' 1762 DESC 'This identifies the valid range of times for a policy 1763 using the format Thhmmss/Thhmmss.' 1764 EQUALITY caseIgnoreMatch 1765 ORDERING caseIgnoreOrderingMatch 1766 SUBSTR caseIgnoreSubstringsMatch 1767 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1768 SINGLE-VALUE 1769 ) 1770 The value of this attribute SHOULD be checked against its defined 1771 format. If the value of this attribute does not conform to this syntax, 1772 then this SHOULD be considered an error and the policy rule SHOULD be 1773 treated as being disabled. 1775 Finally, the pcimTPCLocalOrUtcTime attribute is used to choose between 1776 local or UTC time representation. This is mapped as a simple integer 1777 syntax, with the value of 1 representing local time and the value of 2 1778 representing UTC time. The definition of this attribute is as follows: 1780 ( IANA-ASSIGNED-OID.2.30 1781 NAME 'pcimTPCLocalOrUtcTime' 1782 DESC 'This defines whether the times in this instance 1783 represent local (value=1) times or UTC (value=2) 1784 times.' 1785 EQUALITY integerMatch 1786 ORDERING integerOrderingMatch 1787 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1788 SINGLE-VALUE 1789 ) 1791 Note: if the value of the pcimTPCLocalOrUtcTime is not 1 or 2, then this 1792 SHOULD be considered an error and the policy rule SHOULD be disabled. 1793 If the attribute is not present at all, then all times are interpreted 1794 as if it were present with the value 2, that is, UTC time. 1796 5.9. The Auxiliary Class pcimConditionVendorAuxClass 1798 This class provides a general extension mechanism for representing 1799 policy conditions that have not been modeled with specific properties. 1800 Instead, its two properties are used to define the content and format of 1801 the condition, as explained below. This class is intended for vendor- 1802 specific extensions that are not amenable to using pcimCondition; 1803 standardized extensions SHOULD NOT use this class. 1805 The class definition is as follows: 1807 ( IANA-ASSIGNED-OID.1.13 NAME 'pcimConditionVendorAuxClass' 1808 DESC 'A class that defines a registered means to describe a 1809 policy condition.' 1810 SUP pcimConditionAuxClass 1811 AUXILIARY 1812 MAY ( pcimVendorConstraintData $ 1813 pcimVendorConstraintEncoding ) 1814 ) 1815 The pcimVendorConstraintData attribute is a multi-valued attribute. It 1816 provides a general mechanism for representing policy conditions that 1817 have not been modeled as specific attributes. This information is 1818 encoded in a set of octet strings. The format of the octet strings is 1819 identified by the OID stored in the pcimVendorConstraintEncoding 1820 attribute. This attribute is defined as follows: 1822 ( IANA-ASSIGNED-OID.2.31 1823 NAME 'pcimVendorConstraintData' 1824 DESC 'Mechanism for representing constraints that have not 1825 been modeled as specific attributes. Their format is 1826 identified by the OID stored in the attribute 1827 pcimVendorConstraintEncoding.' 1828 EQUALITY octetStringMatch 1829 ORDERING octetStringOrderingMatch 1830 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1831 ) 1833 The pcimVendorConstraintEncoding attribute is used to identify the 1834 format and semantics for the pcimVendorConstraintData attribute. This 1835 attribute is defined as follows: 1837 ( IANA-ASSIGNED-OID.2.32 1838 NAME 'pcimVendorConstraintEncoding' 1839 DESC 'An OID identifying the format and semantics for the 1840 pcimVendorConstraintData for this instance.' 1841 EQUALITY objectIdentifierMatch 1842 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1843 SINGLE-VALUE 1844 ) 1846 5.10. The Auxiliary Class pcimActionAuxClass 1848 The purpose of a policy action is to execute one or more operations that 1849 will affect network traffic and/or systems, devices, etc. in order to 1850 achieve a desired policy state. This class is used to represent an 1851 action to be performed as a result of a policy rule whose condition 1852 clause was satisfied. 1854 Subclasses of this auxiliary class can be attached to instances of three 1855 other classes in the PCLS. When a subclass of this class is attached to 1856 an instance of pcimRuleActionAssociation, or to an instance of pcimRule, 1857 it represents a rule-specific policy action. When a subclass of this 1858 class is attached to an instance of pcimPolicyInstance, it represents a 1859 reusable policy action. 1861 Since all of the classes to which subclasses of this auxiliary class may 1862 be attached are derived from the pcimPolicy class, the attributes of the 1863 pcimPolicy class will already be defined for the entries to which these 1864 subclasses attach. Thus, this class is derived directly from "top". 1866 The class definition is as follows: 1868 ( IANA-ASSIGNED-OID.1.14 NAME 'pcimActionAuxClass' 1869 DESC 'A class representing an action to be performed as a 1870 result of a policy rule.' 1871 SUP top 1872 AUXILIARY 1873 ) 1875 5.11. The Auxiliary Class pcimActionVendorAuxClass 1877 The purpose of this class is to provide a general extension mechanism 1878 for representing policy actions that have not been modeled with specific 1879 properties. Instead, its two properties are used to define the content 1880 and format of the action, as explained below. 1882 As its name suggests, this class is intended for vendor-specific 1883 extensions that are not amenable to using the standard pcimAction class. 1884 Standardized extensions SHOULD NOT use this class. 1886 The class definition is as follows: 1888 ( IANA-ASSIGNED-OID.1.15 NAME 'pcimActionVendorAuxClass' 1889 DESC 'A class that defines a registered means to describe a 1890 policy action.' 1891 SUP pcimActionAuxClass 1892 AUXILIARY 1893 MAY ( pcimVendorActionData $ pcimVendorActionEncoding ) 1894 ) 1896 The pcimVendorActionData attribute is a multi-valued attribute. It 1897 provides a general mechanism for representing policy actions that have 1898 not been modeled as specific attributes. This information is encoded in 1899 a set of octet strings. The format of the octet strings is identified by 1900 the OID stored in the pcimVendorActionEncoding attribute. This attribute 1901 is defined as follows: 1903 ( IANA-ASSIGNED-OID.2.33 1904 NAME 'pcimVendorActionData' 1905 DESC ' Mechanism for representing policy actions that have 1906 not been modeled as specific attributes. Their format 1907 is identified by the OID stored in the attribute 1908 pcimVendorActionEncoding.' 1909 EQUALITY octetStringMatch 1910 ORDERING octetStringOrderingMatch 1911 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1912 ) 1913 The pcimVendorActionEncoding attribute is used to identify the format 1914 and semantics for the pcimVendorActionData attribute. This attribute is 1915 defined as follows: 1917 ( IANA-ASSIGNED-OID.2.34 1918 NAME 'pcimVendorActionEncoding' 1919 DESC 'An OID identifying the format and semantics for the 1920 pcimVendorActionData attribute of this instance.' 1921 EQUALITY objectIdentifierMatch 1922 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1923 SINGLE-VALUE 1924 ) 1926 5.12. The Class pcimPolicyInstance 1928 This class is not defined in the PCIM. Its role is to serve as a 1929 structural class to which auxiliary classes representing policy 1930 information are attached when the information is reusable. For 1931 auxiliary classes representing policy conditions and policy actions, 1932 there are alternative structural classes that may be used. See Section 1933 4.4 for a complete discussion of reusable policy conditions and actions, 1934 and of the role that this class plays in how they are represented. 1936 The class definition is as follows: 1938 ( IANA-ASSIGNED-OID.1.16 NAME 'pcimPolicyInstance' 1939 DESC 'A structural class to which aux classes containing 1940 reusable policy information can be attached.' 1941 SUP pcimPolicy 1942 MAY ( pcimPolicyInstanceName ) 1943 ) 1945 The pcimPolicyInstanceName attribute is used to define a user-friendly 1946 name of this class, and may be used as a naming attribute if desired. It 1947 is defined as follows: 1949 ( IANA-ASSIGNED-OID.2.35 NAME 'pcimPolicyInstanceName' 1950 DESC 'The user-friendly name of this policy instance.' 1951 EQUALITY caseIgnoreMatch 1952 ORDERING caseIgnoreOrderingMatch 1953 SUBSTR caseIgnoreSubstringsMatch 1954 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1955 SINGLE-VALUE 1956 ) 1958 A DIT content rule could be written to enable an instance of 1959 pcimPolicyInstance to have attached to it either instances of one or 1960 more of the auxiliary object classes pcimConditionAuxClass and 1961 pcimActionAuxClass. Since these semantics do not include specifying any 1962 properties, the content rule would not need to specify any attributes. 1963 Note that other content rules could be defined to enable other policy- 1964 related auxiliary classes to be attached to pcimPolicyInstance. 1966 Similarly, three separate DIT structure rules could be written. Each of 1967 these DIT structure rules would refer to a specific name form that 1968 defined two important semantics. First, each name form would identify 1969 one of the three possible naming attributes (i.e., 1970 pcimPolicyInstanceName, cn, and orderedCIMKeys) for this object class. 1971 Second, each name form would require that an instance of the 1972 pcimPolicyInstance class have as its superior an instance of the 1973 pcimRepository class. This structure rule SHOULD also include a 1974 superiorStructureRule (see Note 2 at the beginning of section 5). 1976 5.13. The Auxiliary Class pcimElementAuxClass 1978 This class introduces no additional attributes, beyond those defined in 1979 the class pcimPolicy from which it is derived. Its role is to "tag" an 1980 instance of a class defined outside the realm of policy information as 1981 represented by PCIM as being nevertheless relevant to a policy 1982 specification. This tagging can potentially take place at two levels: 1984 - Every instance to which pcimElementAuxClass is attached becomes 1985 an instance of the class pcimPolicy, since pcimElementAuxClass is a 1986 subclass of pcimPolicy. Searching for object class="pcimPolicy" 1987 will return the instance. (As noted earlier, this approach does 1988 NOT work for some directory implementations. To accommodate these 1989 implementations, policy-related entries SHOULD be tagged with the 1990 pcimKeyword "POLICY".) 1992 - With the pcimKeywords attribute that it inherits from pcimPolicy, 1993 an instance to which pcimElementAuxClass is attached can be 1994 tagged as being relevant to a particular type or category of 1995 policy information, using standard keywords, administrator-defined 1996 keywords, or both. 1998 The class definition is as follows: 2000 ( IANA-ASSIGNED-OID.1.17 NAME 'pcimElementAuxClass' 2001 DESC 'An auxiliary class used to tag instances of classes 2002 defined outside the realm of policy as relevant to a 2003 particular policy specification.' 2004 SUP pcimPolicy 2005 AUXILIARY 2006 ) 2008 5.14. The Three Policy Repository Classes 2010 These classes provide a container for reusable policy information, such 2011 as reusable policy conditions and/or reusable policy actions. This 2012 document is concerned with mapping just the properties that appear in 2013 these classes. Conceptually, this may be thought of as a special 2014 location in the DIT where policy information may reside. Since 2015 pcimRepository is derived from the class dlm1AdminDomain defined in 2016 reference [5], this specification has a normative dependency on that 2017 element of reference [5] (as well as on its entire derivation 2018 hierarchy, which also appears in reference [5]). To maximize 2019 flexibility, the pcimRepository class is defined as abstract. A 2020 subclass pcimRepositoryAuxClass provides for auxiliary attachment to 2021 another entry, while a structural subclass pcimRepositoryInstance is 2022 available to represent a policy repository as a standalone entry. 2024 The definition for the pcimRepository class is as follows: 2026 ( IANA-ASSIGNED-OID.1.18 NAME 'pcimRepository' 2027 DESC 'A container for reusable policy information.' 2028 SUP dlm1AdminDomain 2029 ABSTRACT 2030 MAY ( pcimRepositoryName ) 2031 ) 2033 The pcimRepositoryName attribute is used to define a user-friendly name 2034 of this class, and may be used as a naming attribute if desired. It is 2035 defined as follows: 2037 ( IANA-ASSIGNED-OID.2.36 NAME 'pcimRepositoryName' 2038 DESC 'The user-friendly name of this policy repository.' 2039 EQUALITY caseIgnoreMatch 2040 ORDERING caseIgnoreOrderingMatch 2041 SUBSTR caseIgnoreSubstringsMatch 2042 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 2043 SINGLE-VALUE 2044 ) 2046 The two subclasses of pcimRepository are defined as follows. First, the 2047 pcimRepositoryAuxClass is an auxiliary class that can be used to 2048 aggregate reusable policy information. It is defined as follows: 2050 ( IANA-ASSIGNED-OID.1.19 NAME 'pcimRepositoryAuxClass' 2051 DESC 'An auxiliary class that can be used to aggregate 2052 reusable policy information.' 2053 SUP pcimRepository 2054 AUXILIARY 2055 ) 2057 In cases where structural classes are needed instead of an auxiliary 2058 class, the pcimRepositoryInstance class is a structural class that can 2059 be used to aggregate reusable policy information. It is defined as 2060 follows: 2062 ( IANA-ASSIGNED-OID.1.20 NAME 'pcimRepositoryInstance' 2063 DESC 'A structural class that can be used to aggregate 2064 reusable policy information.' 2065 SUP pcimRepository 2066 STRUCTURAL 2067 ) 2068 Three separate DIT structure rules could be written for this class. Each 2069 of these DIT structure rules would refer to a specific name form that 2070 enabled an instance of the pcimRepository class to be named under any 2071 superior using one of the three possible naming attributes (i.e., 2072 pcimRepositoryName, cn, and orderedCIMKeys). This structure rule SHOULD 2073 also include a superiorStructureRule (see Note 2 at the beginning of 2074 section 5). 2076 5.15. The Auxiliary Class pcimSubtreesPtrAuxClass 2078 This auxiliary class provides a single, multi-valued attribute that 2079 references a set of objects that are at the root of DIT subtrees 2080 containing policy-related information. By attaching this attribute to 2081 instances of various other classes, a policy administrator has a 2082 flexible way of providing an entry point into the directory that allows 2083 a client to locate and retrieve the policy information relevant to it. 2085 It is intended that these entries are placed in the DIT such that well- 2086 known DNs can be used to reference a well-known structural entry that 2087 has the pcimSubtreesPtrAuxClass attached to it. In effect, this defines 2088 a set of entry points. Each of these entry points can contain and/or 2089 reference all related policy entries for any well-known policy domains. 2090 The pcimSubtreesPtrAuxClass functions as a tag to identify portions of 2091 the DIT that contain policy information. 2093 This object does not provide the semantic linkages between individual 2094 policy objects, such as those between a policy group and the policy 2095 rules that belong to it. Its only role is to enable efficient bulk 2096 retrieval of policy-related objects, as described in Section 4.5. 2098 Once the objects have been retrieved, a directory client can determine 2099 the semantic linkages by following references contained in multi-valued 2100 attributes, such as pcimRulesAuxContainedSet. 2102 Since policy-related objects will often be included in the DIT subtree 2103 beneath an object to which this auxiliary class is attached, a client 2104 SHOULD request the policy-related objects from the subtree under the 2105 object with these references at the same time that it requests the 2106 references themselves. 2108 Since clients are expected to behave in this way, the policy 2109 administrator SHOULD make sure that this subtree does not contain so 2110 many objects unrelated to policy that an initial search done in this way 2111 results in a performance problem. The pcimSubtreesPtrAuxClass SHOULD 2112 NOT be attached to the partition root for a large directory partition 2113 containing a relatively few number of policy-related objects along with 2114 a large number of objects unrelated to policy (again, "policy" here 2115 refers to the PCIM, not the X.501, definition and use of "policy"). A 2116 better approach would be to introduce a container object immediately 2117 below the partition root, attach pcimSubtreesPtrAuxClass to this 2118 container object, and then place all of the policy-related objects in 2119 that subtree. 2121 The class definition is as follows: 2123 ( IANA-ASSIGNED-OID.1.21 NAME 'pcimSubtreesPtrAuxClass' 2124 DESC 'An auxiliary class providing DN references to roots of 2125 DIT subtrees containing policy-related objects.' 2126 SUP top 2127 AUXILIARY 2128 MAY ( pcimSubtreesAuxContainedSet ) 2129 ) 2131 The attribute pcimSubtreesAuxContainedSet provides an unordered set of 2132 DN references to instances of one or more objects under which policy- 2133 related information is present. The objects referenced may or may not 2134 themselves contain policy-related information. The attribute definition 2135 is as follows: 2137 ( IANA-ASSIGNED-OID.2.37 2138 NAME 'pcimSubtreesAuxContainedSet' 2139 DESC 'DNs of objects that serve as roots for DIT subtrees 2140 containing policy-related objects.' 2141 EQUALITY distinguishedNameMatch 2142 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2143 ) 2145 Note that the cn attribute does NOT need to be defined for this class. 2146 This is because an auxiliary class is used as a means to collect common 2147 attributes and treat them as properties of an object. A good analogy is 2148 a #include file, except that since an auxiliary class is a class, all 2149 the benefits of a class (e.g., inheritance) can be applied to an 2150 auxiliary class. 2152 5.16. The Auxiliary Class pcimGroupContainmentAuxClass 2154 This auxiliary class provides a single, multi-valued attribute that 2155 references a set of pcimGroups. By attaching this attribute to 2156 instances of various other classes, a policy administrator has a 2157 flexible way of providing an entry point into the directory that allows 2158 a client to locate and retrieve the pcimGroups relevant to it. 2160 As is the case with pcimRules, a policy administrator might have several 2161 different references to a pcimGroup in the overall directory structure. 2162 The pcimGroupContainmentAuxClass is the mechanism that makes it possible 2163 for the policy administrator to define all these different references. 2165 The class definition is as follows: 2167 ( IANA-ASSIGNED-OID.1.22 NAME 'pcimGroupContainmentAuxClass' 2168 DESC 'An auxiliary class used to bind pcimGroups to an 2169 appropriate container object.' 2170 SUP top 2171 AUXILIARY 2172 MAY ( pcimGroupsAuxContainedSet ) 2173 ) 2175 The attribute pcimGroupsAuxContainedSet provides an unordered set of 2176 references to instances of one or more pcimGroups associated with the 2177 instance of a structural class to which this attribute has been 2178 appended. 2180 The attribute definition is as follows: 2182 ( IANA-ASSIGNED-OID.2.38 2183 NAME 'pcimGroupsAuxContainedSet' 2184 DESC 'DNs of pcimGroups associated in some way with the 2185 instance to which this attribute has been appended.' 2186 EQUALITY distinguishedNameMatch 2187 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2188 ) 2190 Note that the cn attribute does NOT have to be defined for this class 2191 for the same reasons as those given for the pcimSubtreesPtrAuxClass in 2192 section 5.15. 2194 5.17. The Auxiliary Class pcimRuleContainmentAuxClass 2196 This auxiliary class provides a single, multi-valued attribute that 2197 references a set of pcimRules. By attaching this attribute to instances 2198 of various other classes, a policy administrator has a flexible way of 2199 providing an entry point into the directory that allows a client to 2200 locate and retrieve the pcimRules relevant to it. 2202 A policy administrator might have several different references to a 2203 pcimRule in the overall directory structure. For example, there might 2204 be references to all pcimRules for traffic originating in a particular 2205 subnet from a directory entry that represents that subnet. At the same 2206 time, there might be references to all pcimRules related to a particular 2207 DiffServ setting from an instance of a pcimGroup explicitly introduced 2208 as a container for DiffServ-related pcimRules. The 2209 pcimRuleContainmentAuxClass is the mechanism that makes it possible for 2210 the policy administrator to define all these separate references. 2212 The class definition is as follows: 2214 ( IANA-ASSIGNED-OID.1.23 NAME 'pcimRuleContainmentAuxClass' 2215 DESC 'An auxiliary class used to bind pcimRules to an 2216 appropriate container object.' 2217 SUP top 2218 AUXILIARY 2219 MAY ( pcimRulesAuxContainedSet ) 2220 ) 2222 The attribute pcimRulesAuxContainedSet provides an unordered set of 2223 references to one or more instances of pcimRules associated with the 2224 instance of a structural class to which this attribute has been 2225 appended. The attribute definition is as follows: 2227 ( IANA-ASSIGNED-OID.2.39 2228 NAME 'pcimRulesAuxContainedSet' 2229 DESC 'DNs of pcimRules associated in some way with the 2230 instance to which this attribute has been appended.' 2231 EQUALITY distinguishedNameMatch 2232 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2233 ) 2235 The cn attribute does NOT have to be defined for this class for the same 2236 reasons as those given for the pcimSubtreesPtrAuxClass in section 5.15. 2238 6. Extending the Classes Defined in This Document 2240 The following subsections provide general guidance on how to create a 2241 domain-specific schema derived from this document, discuss how the 2242 vendor classes in the PCLS should be used, and explain how 2243 policyTimePeriodConditions are related to other policy conditions. 2245 6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 2247 In Section 4.4, there is a discussion of how, by representing policy 2248 conditions and policy actions as auxiliary classes in a schema, the 2249 flexibility is retained to instantiate a particular condition or action 2250 as either rule-specific or reusable. This flexibility is lost if a 2251 condition or action class is defined as structural rather than 2252 auxiliary. For standardized schemata, this document specifies that 2253 domain-specific information MUST be expressed in auxiliary subclasses of 2254 pcimConditionAuxClass and pcimActionAuxClass. It is RECOMMENDED that 2255 non-standardized schemata follow this practice as well. 2257 6.2. Using the Vendor Policy Attributes 2259 As discussed Section 5.9, the attributes pcimVendorConstraintData and 2260 pcimVendorConstraintEncoding are included in the 2261 pcimConditionVendorAuxClass to provide a mechanism for representing 2262 vendor-specific policy conditions that are not amenable to being 2263 represented with the pcimCondition class (or its subclasses). The 2264 attributes pcimVendorActionData and pcimVendorActionEncoding in the 2265 pcimActionVendorAuxClass class play the same role with respect to 2266 actions. This enables interoperability between different vendors who 2267 could not otherwise interoperate. 2269 For example, imagine a network composed of access devices from vendor A, 2270 edge and core devices from vendor B, and a policy server from vendor C. 2271 It is desirable for this policy server to be able to configure and 2272 manage all of the devices from vendors A and B. Unfortunately, these 2273 devices will in general have little in common (e.g., different 2274 mechanisms, different ways for controlling those mechanisms, different 2275 operating systems, different commands, and so forth). The extension 2276 conditions provide a way for vendor-specific commands to be encoded as 2277 octet strings, so that a single policy server can commonly manage 2278 devices from different vendors. 2280 6.3. Using Time Validity Periods 2282 Time validity periods are defined as an auxiliary subclass of 2283 pcimConditionAuxClass, called pcimTPCAuxClass. This is to allow their 2284 inclusion in the AND/OR condition definitions for a pcimRule. Care 2285 should be taken not to subclass pcimTPCAuxClass to add domain-specific 2286 condition properties. 2288 For example, it would be incorrect to add IPsec- or QoS-specific 2289 condition properties to the pcimTPCAuxClass class, just because IPsec or 2290 QoS includes time in its condition definition. The correct subclassing 2291 would be to create IPsec or QoS-specific subclasses of 2292 pcimConditionAuxClass and then combine instances of these domain- 2293 specific condition classes with the appropriate validity period 2294 criteria. This is accomplished using the AND/OR association capabilities 2295 for policy conditions in pcimRules. 2297 7. Security Considerations 2299 The PCLS, presented in this document, provides a mapping of the object- 2300 oriented model for describing policy information (PCIM) into a data 2301 model that forms the basic framework for describing the structure of 2302 policy data, in the case where the policy repository takes the form of 2303 an LDAP-accessible directory. 2305 PCLS is not intended to represent any particular system design or 2306 implementation. PCLS is not directly useable in a real world system, 2307 without the discipline-specific mappings that are works in progress in 2308 the Policy Framework Working Group of the IETF. 2310 These other derivative documents, which use PCIM and its discipline- 2311 specific extensions as a base, will need to convey more specific 2312 security considerations (refer to RFC3060 for more information.) 2314 The reason that PCLS, as defined here, is not representative of any 2315 real-world system, is that its object classes were designed to be 2316 independent of any specific discipline, or policy domain. For example, 2317 DiffServ and IPsec represent two different policy domains. Each document 2318 that extends PCIM to one of these domains will derive subclasses from 2319 the classes and relationships defined in PCIM, in order to represent 2320 extensions of a generic model to cover specific technical domains. 2322 PCIM-derived documents will thus subclass the PCIM classes into classes 2323 specific to each technical policy domain (QOS, IPsec, etc.), which will, 2324 in turn, be mapped, to directory-specific schemata consistent with the 2325 PCLS documented here. 2327 Even though discipline-specific security requirements are not 2328 appropriate for PCLS, specific security requirements MUST be defined for 2329 each operational real-world application of PCIM. Just as there will be 2330 a wide range of operational, real-world systems using PCIM, there will 2331 also be a wide range of security requirements for these systems. Some 2332 operational, real-world systems that are deployed using PCLS may have 2333 extensive security requirements that impact nearly all object classes 2334 utilized by such a system, while other systems' security requirements 2335 might have very little impact. 2337 The derivative documents, discussed above, will create the context for 2338 applying operational, real-world, system-level security requirements 2339 against the various models that derive from PCIM, consistent with PCLS. 2341 In some real-world scenarios, the values associated with certain 2342 properties, within certain instantiated object classes, may represent 2343 information associated with scarce, and/or costly (and therefore 2344 valuable) resources. It may be the case that these values must not be 2345 disclosed to, or manipulated by, unauthorized parties. 2347 Since this document forms the basis for the representation of a policy 2348 data model in a specific format (an LDAP-accessible directory), it is 2349 herein appropriate to reference the data model-specific tools and 2350 mechanisms that are available for achieving the authentication and 2351 authorization implicit in a requirement that restricts read and/or read- 2352 write access to these values stored in a directory. 2354 LDAP-specific authentication and authorization tools and mechanisms are 2355 found in the following standards track documents, which are appropriate 2356 for application to the management of security applied to policy data 2357 models stored in an LDAP-accessible directory: 2359 - RFC 2829 (Authentication Methods for LDAP) 2360 - RFC 2830 (Lightweight Directory Access Protocol (v3): Extension 2361 for Transport Layer Security) 2363 Any identified security requirements that are not dealt with in the 2364 appropriate discipline-specific information model documents, or in this 2365 document, MUST be dealt with in the derivative data model documents 2366 which are specific to each discipline. 2368 8. IANA Considerations 2370 8.1. Object Identifiers 2372 It is requested that IANA register an LDAP Object Identifer 2373 for use in this technical specification according to the 2374 following template: 2376 Subject: Request for LDAP OID Registration 2377 Person & email address to contact for further information: 2378 Bob Moore (remoore@us.ibm.com) 2379 Specification: RFC XXXX 2380 Author/Change Controller: IESG 2381 Comments: 2382 The assigned OID will be used as a base for identifying 2383 a number of schema elements defined in this document. 2385 8.2. Object Identifier Descriptors 2387 It is requested that IANA register the LDAP Descriptors used 2388 in this technical specification as detailed in the following 2389 template: 2391 Subject: Request for LDAP Descriptor Registration Update 2392 Descriptor (short name): see comment 2393 Object Identifier: see comment 2394 Person & email address to contact for further information: 2395 Bob Moore (remoore@us.ibm.com) 2396 Usage: see comment 2397 Specification: RFC XXXX 2398 Author/Change Controller: IESG 2399 Comments: 2401 The following descriptors should be added: 2403 NAME Type OID 2404 -------------- ---- ------------ 2405 pcimPolicy' O IANA-ASSIGNED-OID.1.1 2406 pcimGroup O IANA-ASSIGNED-OID.1.2 2407 pcimGroupAuxClass O IANA-ASSIGNED-OID.1.3 2408 pcimGroupInstance O IANA-ASSIGNED-OID.1.4 2409 pcimRule O IANA-ASSIGNED-OID.1.5 2410 pcimRuleAuxClass O IANA-ASSIGNED-OID.1.6 2411 pcimRuleInstance O IANA-ASSIGNED-OID.1.7 2412 pcimRuleConditionAssociation O IANA-ASSIGNED-OID.1.8 2413 pcimRuleValidityAssociation O IANA-ASSIGNED-OID.1.9 2414 pcimRuleActionAssociation O IANA-ASSIGNED-OID.1.10 2415 pcimConditionAuxClass O IANA-ASSIGNED-OID.1.11 2416 pcimTPCAuxClass O IANA-ASSIGNED-OID.1.12 2417 pcimConditionVendorAuxClass O IANA-ASSIGNED-OID.1.13 2418 pcimActionAuxClass O IANA-ASSIGNED-OID.1.14 2419 pcimActionVendorAuxClass O IANA-ASSIGNED-OID.1.15 2420 pcimPolicyInstance O IANA-ASSIGNED-OID.1.16 2421 pcimElementAuxClass O IANA-ASSIGNED-OID.1.17 2422 pcimRepository O IANA-ASSIGNED-OID.1.18 2423 pcimRepositoryAuxClass O IANA-ASSIGNED-OID.1.19 2424 pcimRepositoryInstance O IANA-ASSIGNED-OID.1.20 2425 pcimSubtreesPtrAuxClass O IANA-ASSIGNED-OID.1.21 2426 pcimGroupContainmentAuxClass O IANA-ASSIGNED-OID.1.22 2427 pcimRuleContainmentAuxClass O IANA-ASSIGNED-OID.1.23 2428 pcimKeywords A IANA-ASSIGNED-OID.2.3 2429 pcimGroupName A IANA-ASSIGNED-OID.2.4 2430 pcimRuleName A IANA-ASSIGNED-OID.2.5 2431 pcimRuleEnabled A IANA-ASSIGNED-OID.2.6 2432 pcimRuleConditionListType A IANA-ASSIGNED-OID.2.7 2433 pcimRuleConditionList A IANA-ASSIGNED-OID.2.8 2434 pcimRuleActionList A IANA-ASSIGNED-OID.2.9 2436 (descriptors continued on next page) 2437 (descriptors continued from previous page) 2439 NAME Type OID 2440 -------------- ---- ------------ 2442 pcimRuleValidityPeriodList A IANA-ASSIGNED-OID.2.10 2443 pcimRuleUsage A IANA-ASSIGNED-OID.2.11 2444 pcimRulePriority A IANA-ASSIGNED-OID.2.12 2445 pcimRuleMandatory A IANA-ASSIGNED-OID.2.13 2446 pcimRuleSequencedActions A IANA-ASSIGNED-OID.2.14 2447 pcimRoles A IANA-ASSIGNED-OID.2.15 2448 pcimConditionGroupNumber A IANA-ASSIGNED-OID.2.16 2449 pcimConditionNegated A IANA-ASSIGNED-OID.2.17 2450 pcimConditionName A IANA-ASSIGNED-OID.2.18 2451 pcimConditionDN A IANA-ASSIGNED-OID.2.19 2452 pcimValidityConditionName A IANA-ASSIGNED-OID.2.20 2453 pcimTimePeriodConditionDN A IANA-ASSIGNED-OID.2.21 2454 pcimActionName A IANA-ASSIGNED-OID.2.22 2455 pcimActionOrder A IANA-ASSIGNED-OID.2.23 2456 pcimActionDN A IANA-ASSIGNED-OID.2.24 2457 pcimTPCTime A IANA-ASSIGNED-OID.2.25 2458 pcimTPCMonthOfYearMask A IANA-ASSIGNED-OID.2.26 2459 pcimTPCDayOfMonthMask A IANA-ASSIGNED-OID.2.27 2460 pcimTPCDayOfWeekMask A IANA-ASSIGNED-OID.2.28 2461 pcimTPCTimeOfDayMask A IANA-ASSIGNED-OID.2.29 2462 pcimTPCLocalOrUtcTime A IANA-ASSIGNED-OID.2.30 2463 pcimVendorConstraintData A IANA-ASSIGNED-OID.2.31 2464 pcimVendorConstraintEncoding A IANA-ASSIGNED-OID.2.32 2465 pcimVendorActionData A IANA-ASSIGNED-OID.2.33 2466 pcimVendorActionEncoding A IANA-ASSIGNED-OID.2.34 2467 pcimPolicyInstanceName A IANA-ASSIGNED-OID.2.35 2468 pcimRepositoryName A IANA-ASSIGNED-OID.2.36 2469 pcimSubtreesAuxContainedSet A IANA-ASSIGNED-OID.2.37 2470 pcimGroupsAuxContainedSet A IANA-ASSIGNED-OID.2.38 2471 pcimRulesAuxContainedSet A IANA-ASSIGNED-OID.2.39 2473 where Type A is Attribute, Type O is ObjectClass 2475 9. Intellectual Property 2477 The IETF takes no position regarding the validity or scope of any 2478 intellectual property or other rights that might be claimed to pertain 2479 to the implementation or use of the technology described in this 2480 document or the extent to which any license under such rights might or 2481 might not be available; neither does it represent that it has made any 2482 effort to identify any such rights. Information on the IETF's 2483 procedures with respect to rights in standards-track and standards- 2484 related documentation can be found in BCP-11. 2486 Copies of claims of rights made available for publication and any 2487 assurances of licenses to be made available, or the result of an attempt 2488 made to obtain a general license or permission for the use of such 2489 proprietary rights by implementers or users of this specification can be 2490 obtained from the IETF Secretariat. 2492 The IETF invites any interested party to bring to its attention any 2493 copyrights, patents or patent applications, or other proprietary rights 2494 that may cover technology that may be required to practice this 2495 standard. Please address the information to the IETF Executive 2496 Director. 2498 10. Acknowledgments 2500 We would like to thank Kurt Zeilenga, Roland Hedburg, and Steven Legg 2501 for doing a review of this document and making many helpful suggestions 2502 and corrections. 2504 Several of the policy classes in this model first appeared in early IETF 2505 drafts on IPsec policy and QoS policy. The authors of these drafts were 2506 Partha Bhattacharya, Rob Adams, William Dixon, Roy Pereira, Raju Rajan, 2507 Jean-Christophe Martin, Sanjay Kamat, Michael See, Rajiv Chaudhury, 2508 Dinesh Verma, George Powers, and Raj Yavatkar. 2510 This document is closely aligned with the work being done in the 2511 Distributed Management Task Force (DMTF) Policy and Networks working 2512 groups. We would especially like to thank Lee Rafalow, Glenn Waters, 2513 David Black, Michael Richardson, Mark Stevens, David Jones, Hugh Mahon, 2514 Yoram Snir, and Yoram Ramberg for their helpful comments. 2516 11. Normative References 2518 [1] Moore, B., and E. Ellesson, J. Strassner, A. Westerinen "Policy 2519 Core Information Model -- Version 1 Specification", RFC 3060, 2520 February 2001. 2522 [2] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight 2523 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2524 2252, December 1997. 2526 [3] The Directory: Models. ITU-T Recommendation X.501, 2001. 2528 [4] Distributed Management Task Force, Inc., "Common Information 2529 Model (CIM) Specification", Version 2.2, June 14, 1999. This 2530 document is available on the following DMTF web page: 2531 http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf 2533 [5] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the 2534 CIM v2.5 Core Information Model", April 15, 2002. This document 2535 is available on the following DMTF web page: 2536 http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf 2538 [6] Wahl, M., "A Summary of the X.500(96) User Schema for use with 2539 LDAPv3", RFC 2256, December 1997. 2541 [7] The Directory: Selected Attribute Types. ITU-T Recommendation 2542 X.520, 2001. 2544 [8] K. Zeilenga, ed., "LDAPv3: A Collection of User Schema", 2545 , May 2002. 2547 12. Informative References 2549 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2550 Levels", BCP 14, RFC 2119, March 1997. 2552 [10] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 2553 Standards Process", BCP 11, RFC 2028, October 1996. 2555 [11] Strassner, J., policy architecture BOF presentation, 42nd IETF 2556 Meeting, Chicago, Illinois, October 1998. Minutes of this BOF are 2557 available at the following location: 2558 http://www.ietf.org/proceedings/98aug/index.html. 2560 [12] DMTF web site, http://www.dmtf.org. 2562 [13] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for 2563 Policy-based Admission Control", RFC 2753, January 2000. 2565 [14] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication 2566 Methods for LDAP", RFC 2829, May 2000 2568 [15] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access 2569 Protocol (v3): Extension for Transport Layer Security", RFC 2830, 2570 May 2000. 2572 13. Authors' Addresses 2574 John Strassner 2575 Intelliden Corporation 2576 90 South Cascade Avenue 2577 Colorado Springs, CO 80903 2578 Phone: +1.719.785.0648 2579 Fax: +1.719.785.0644 2580 E-mail: john.strassner@intelliden.com 2582 Ed Ellesson 2583 3026 Carriage Trail 2584 Hillsborough, NC 27278 2585 Phone: +1 919-361-3230 2586 E-mail: ellesson@mindspring.com 2588 Bob Moore 2589 IBM Corporation 2590 P. O. Box 12195, BRQA/B501/E116 2591 3039 Cornwallis Rd. 2592 Research Triangle Park, NC 27709-2195 2593 Phone: +1 919-254-4436 2594 Fax: +1 919-254-6243 2595 E-mail: remoore@us.ibm.com 2597 Ryan Moats 2598 Lemur Networks, Inc. 2599 15621 Drexel Circle 2600 Omaha, NE 68135 2601 Phone: +1-402-894-9456 2602 E-mail: rmoats@lemurnetworks.net 2603 14. Full Copyright Statement 2605 Copyright (C) The Internet Society (2002). All Rights Reserved. 2607 This document and translations of it may be copied and furnished to 2608 others, and derivative works that comment on or otherwise explain it or 2609 assist in its implementation may be prepared, copied, published and 2610 distributed, in whole or in part, without restriction of any kind, 2611 provided that the above copyright notice and this paragraph are included 2612 on all such copies and derivative works. However, this document itself 2613 may not be modified in any way, such as by removing the copyright notice 2614 or references to the Internet Society or other Internet organizations, 2615 except as needed for the purpose of developing Internet standards in 2616 which case the procedures for copyrights defined in the Internet 2617 Standards process must be followed, or as required to translate it into 2618 languages other than English. 2620 The limited permissions granted above are perpetual and will not be 2621 revoked by the Internet Society or its successors or assigns. 2623 This document and the information contained herein is provided on an "AS 2624 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2625 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2626 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2627 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2628 FITNESS FOR A PARTICULAR PURPOSE. 2630 15. Appendix: Constructing the Value of orderedCIMKeys 2632 This appendix is non-normative, and is included in this document as a 2633 guide to implementers that wish to exchange information between CIM 2634 schemata and LDAP schemata. 2636 Within a CIM name space, the naming is basically flat; all instances are 2637 identified by the values of their key properties, and each combination 2638 of key values must be unique. A limited form of hierarchical naming is 2639 available in CIM, however, by using weak associations: since a weak 2640 association involves propagation of key properties and their values from 2641 the superior object to the subordinate one, the subordinate object can 2642 be thought of as being named "under" the superior object. Once they 2643 have been propagated, however, propagated key properties and their 2644 values function in exactly the same way that native key properties and 2645 their values do in identifying a CIM instance. 2647 The CIM mapping document [5] introduces a special attribute, 2648 orderedCIMKeys, to help map from the CIM_ManagedElement class to the 2649 LDAP class dlm1ManagedElement. This attribute SHOULD only be used in an 2650 environment where it is necessary to map between an LDAP-accessible 2651 directory and a CIM repository. For an LDAP environment, other LDAP 2652 naming attributes are defined (i.e., cn and a class-specific naming 2653 attribute) that SHOULD be used instead. 2655 The role of orderedCIMKeys is to represent the information necessary to 2656 correlate an entry in an LDAP-accessible directory with an instance in a 2657 CIM name space. Depending on how naming of CIM-related entries is 2658 handled in an LDAP directory, the value of orderedCIMKeys represents one 2659 of two things: 2661 - If the DIT hierarchy does not mirror the "weakness hierarchy" of 2662 the CIM name space, then orderedCIMKeys represents all the 2663 keys of the CIM instance, both native and propagated. 2664 - If the DIT hierarchy does mirror the "weakness hierarchy" of the 2665 CIM name space, then orderedCIMKeys may represent either all the 2666 keys of the instance, or only the native keys. 2668 Regardless of which of these alternatives is taken, the syntax of 2669 orderedCIMKeys is the same - a DirectoryString of the form 2671 .=[,=]* 2673 where the = elements are ordered by the names of the key 2674 properties, according to the collating sequence for US ASCII. The only 2675 spaces allowed in the DirectoryString are those that fall within a 2676 element. As with alphabetizing the key properties, the goal of 2677 suppressing the spaces is once again to make the results of string 2678 operations predictable. 2680 The values of the elements are derived from the various CIM 2681 syntaxes according to a grammar specified in [4].