idnits 2.17.1 draft-ietf-policy-core-schema-14.txt: -(108): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(109): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(298): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(299): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(512): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(900): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(901): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1237): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1294): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2121): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 27 instances of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 53 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3], [10], [11], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1046 has weird spacing: '...ment to anot...' == Line 1259 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 (January 2002) is 8127 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: '4' is defined on line 2428, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2433, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2438, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2440, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2459, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2462, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2252 (ref. '2') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2028 (ref. '4') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2256 (ref. '11') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2829 (ref. '13') (Obsoleted by RFC 4510, RFC 4513) ** Obsolete normative reference: RFC 2830 (ref. '14') (Obsoleted by RFC 4510, RFC 4511, RFC 4513) -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Policy Framework Working Group J. Strassner 2 Internet-draft 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 January 2002 10 Policy Core LDAP Schema 11 draft-ietf-policy-core-schema-14.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 (2001). 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 [1], and relationship classes 44 that indicate how instances of the structural classes are related to 45 each other. Classes are also added to the LDAP schema to improve the 46 performance of a client's interactions with an LDAP server when the 47 client is retrieving large amounts of policy-related information. These 48 classes exist only to optimize LDAP retrievals: there are no classes in 49 the information model that correspond to them. 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [3]. 55 Table of Contents 57 1. Introduction 3 58 2. The Policy Core Information Model 4 59 3. Inheritance Hierarchy for the PCLS 5 60 4. General Discussion of Mapping the Information Model to LDAP 6 61 4.1. Summary of Class and Association Mappings 7 62 4.2. Usage of DIT Content and Structure Rules and Name Forms 9 63 4.3. Naming Attributes in the PCLS 10 64 4.4. Rule-Specific and Reusable Conditions and Actions 11 65 4.5. Location and Retrieval of Policy Objects in the Directory 15 66 4.5.1. Aliases and Other DIT-Optimization Techniques 17 67 5. Class Definitions 18 68 5.1. The Abstract Class "pcimPolicy" 19 69 5.2. The Three Policy Group Classes 20 70 5.3. The Three Policy Rule Classes 22 71 5.4. The Class pcimRuleConditionAssociation 28 72 5.5. The Class pcimRuleValidityAssociation 30 73 5.6. The Class pcimRuleActionAssociation 31 74 5.7. The Auxiliary Class pcimConditionAuxClass 33 75 5.8. The Auxiliary Class pcimTPCAuxClass 34 76 5.9. The Auxiliary Class pcimConditionVendorAuxClass 37 77 5.10. The Auxiliary Class pcimActionAuxClass 38 78 5.11. The Auxiliary Class pcimActionVendorAuxClass 38 79 5.12. The Class pcimPolicyInstance 40 80 5.13. The Auxiliary Class pcimElementAuxClass 41 81 5.14. The Three Policy Repository Classes 41 82 5.15. The Auxiliary Class pcimSubtreesPtrAuxClass 43 83 5.16. The Auxiliary Class pcimGroupContainmentAuxClass 44 84 5.17. The Auxiliary Class pcimRuleContainmentAuxClass 45 85 6. Extending the Classes Defined in This Document 47 86 6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 47 87 6.2. Using the Vendor Policy Attributes 47 88 6.3. Using Time Validity Periods 47 89 7. Security Considerations 48 90 8. Intellectual Property 49 91 9. Acknowledgments 50 92 10. References 50 93 11. Authors' Addresses 51 94 12. Full Copyright Statement 52 95 13. Appendix: Constructing the Value of orderedCIMKeys 53 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 in brackets (for example, 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 [5]. 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 2. The Policy Core Information Model 190 This document contains an LDAP schema representing the classes defined 191 in the companion document "Policy Core Information Model -- Version 1 192 Specification" [1]. Other documents may subsequently be produced, with 193 mappings of this same PCIM to other storage technologies. Since the 194 detailed semantics of the PCIM classes appear only in [1], that document 195 is a prerequisite for reading and understanding this document. 197 3. Inheritance Hierarchy for the PCLS 199 The following diagram illustrates the class hierarchy for the LDAP 200 Classes defined in this document: 202 top 203 | 204 +--dlm1ManagedElement (abstract) 205 | | 206 | +--pcimPolicy (abstract) 207 | | | 208 | | +--pcimGroup (abstract) 209 | | | | 210 | | | +--pcimGroupAuxClass (auxiliary) 211 | | | | 212 | | | +--pcimGroupInstance (structural) 213 | | | 214 | | +--pcimRule (abstract) 215 | | | | 216 | | | +--pcimRuleAuxClass (auxiliary) 217 | | | | 218 | | | +--pcimRuleInstance (structural) 219 | | | 220 | | +--pcimRuleConditionAssociation (structural) 221 | | | 222 | | +--pcimRuleValidityAssociation (structural) 223 | | | 224 | | +--pcimRuleActionAssociation (structural) 225 | | | 226 | | +--pcimPolicyInstance (structural) 227 | | | 228 | | +--pcimElementAuxClass (auxiliary) 229 | | 230 | +--dlm1ManagedSystemElement (abstract) 231 | | 232 | +--dlm1LogicalElement (abstract) 233 | | 234 | +--dlm1System (abstract) 235 | | 236 | +--dlm1AdminDomain (abstract) 237 | | 238 | +--pcimRepository (abstract) 239 | | 240 | +--pcimRepositoryAuxClass (auxiliary) 241 | | 242 | +--pcimRepositoryInstance 243 (structural) 245 (continued on following page) 247 (continued from previous page) 249 top 250 | 251 +--pcimConditionAuxClass (auxiliary) 252 | | 253 | +---pcimTPCAuxClass (auxiliary) 254 | | 255 | +---pcimConditionVendorAuxClass (auxiliary) 256 | 257 +--pcimActionAuxClass (auxiliary) 258 | | 259 | +---pcimActionVendorAuxClass (auxiliary) 260 | 261 +--pcimSubtreesPtrAuxClass (auxiliary) 262 | 263 +--pcimGroupContainmentAuxClass (auxiliary) 264 | 265 +--pcimRuleContainmentAuxClass (auxiliary) 267 Figure 1. LDAP Class Inheritance Hierarchy for the PCLS 269 4. General Discussion of Mapping the Information Model to LDAP 271 The classes described in Section 5 below contain certain optimizations 272 for a directory that uses LDAP as its access protocol. One example of 273 this is the use of auxiliary classes to represent some of the 274 associations defined in the information model. Other data stores might 275 need to implement these associations differently. A second example is 276 the introduction of classes specifically designed to optimize retrieval 277 of large amounts of policy-related data from a directory. This section 278 discusses some general topics related to the mapping from the 279 information model to LDAP. 281 The remainder of this section will discuss the following topics. Section 282 4.1 will discuss the strategy used in mapping the classes and 283 associations defined in [1] to a form that can be represented in a 284 directory that uses LDAP as its access protocol. Section 4.2 discusses 285 DIT content and structure rules, as well as name forms. Section 4.3 286 describes the strategy used in defining naming attributes for the schema 287 described in Section 5 of this document. Section 4.4 defines the 288 strategy recommended for locating and retrieving PCIM-derived objects in 289 the directory. 291 4.1. Summary of Class and Association Mappings 293 Fifteen of the classes in the PCLS come directly from the nine 294 corresponding classes in the information model. Note that names of 295 classes begin with an upper case character in the information model 296 (although for CIM in particular, case is not significant in class and 297 property names), but with a lower case character in LDAP. This is 298 because although LDAP doesn�t care, X.500 doesn�t allow class names to 299 begin with an uppercase character. Note also that the prefix �pcim� is 300 used to identify these LDAP classes. 302 +---------------------------+-------------------------------+ 303 | Information Model | LDAP Class(es) | 304 +---------------------------+-------------------------------+ 305 +---------------------------+-------------------------------+ 306 | Policy | pcimPolicy | 307 +---------------------------+-------------------------------+ 308 | PolicyGroup | pcimGroup | 309 | | pcimGroupAuxClass | 310 | | pcimGroupInstance | 311 +---------------------------+-------------------------------+ 312 | PolicyRule | pcimRule | 313 | | pcimRuleAuxClass | 314 | | pcimRuleInstance | 315 +---------------------------+-------------------------------+ 316 | PolicyCondition | pcimConditionAuxClass | 317 +---------------------------+-------------------------------+ 318 | PolicyAction | pcimActionAuxClass | 319 +---------------------------+-------------------------------+ 320 | VendorPolicyCondition | pcimConditionVendorAuxClass | 321 +---------------------------+-------------------------------+ 322 | VendorPolicyAction | pcimActionVendorAuxClass | 323 +---------------------------+-------------------------------+ 324 | PolicyTimePeriodCondition | pcimTPCAuxClass | 325 +---------------------------+-------------------------------+ 326 | PolicyRepository | pcimRepository | 327 | | pcimRepositoryAuxClass | 328 | | pcimRepositoryInstance | 329 +---------------------------+-------------------------------+ 331 Figure 2. Mapping of Information Model Classes to LDAP 333 The associations in the information model map to attributes that 334 reference DNs (Distinguished Names) or to Directory Information Tree 335 (DIT) containment (i.e., superior-subordinate relationships) in LDAP. 336 Two of the attributes that reference DNs appear in auxiliary classes, 337 which allow each of them to represent several relationships from the 338 information model. 340 +----------------------------------+----------------------------------+ 341 | Information Model Association | LDAP Attribute / Class | 342 +-----------------------------------+---------------------------------+ 343 +-----------------------------------+---------------------------------+ 344 | PolicyGroupInPolicyGroup | pcimGroupsAuxContainedSet in | 345 | | pcimGroupContainmentAuxClass | 346 +-----------------------------------+---------------------------------+ 347 | PolicyRuleInPolicyGroup | pcimRulesAuxContainedSet in | 348 | | pcimRuleContainmentAuxClass | 349 +-----------------------------------+---------------------------------+ 350 | PolicyConditionInPolicyRule | DIT containment or | 351 | | pcimRuleConditionList in | 352 | | pcimRule or | 353 | | pcimConditionDN in | 354 | | pcimRuleConditionAssociation | 355 +-----------------------------------+---------------------------------+ 356 | PolicyActionInPolicyRule | DIT containment or | 357 | | pcimRuleActionList in | 358 | | pcimRule or | 359 | | pcimActionDN in | 360 | | pcimRuleActionAssociation | 361 +-----------------------------------+---------------------------------+ 362 | PolicyRuleValidityPeriod | pcimRuleValidityPeriodList | 363 | | in pcimRule or (if reusable) | 364 | | referenced through the | 365 | | pcimTimePeriodConditionDN in | 366 | | pcimRuleValidityAssociation | 367 +-----------------------------------+---------------------------------+ 368 | PolicyConditionInPolicyRepository | DIT containment | 369 +-----------------------------------+---------------------------------+ 370 | PolicyActionInPolicyRepository | DIT containment | 371 +-----------------------------------+---------------------------------+ 372 | PolicyRepositoryInPolicyRepository| DIT containment | 373 +-----------------------------------+---------------------------------+ 375 Figure 3. Mapping of Information Model Associations to LDAP 377 Of the remaining classes in the PCLS, two (pcimElementAuxClass and 378 pcimSubtreesPtrAuxClass) are included to make navigation through the DIT 379 and retrieval of the entries found there more efficient. This topic is 380 discussed in Section 4.5 below. 382 The remaining four classes in the PCLS, pcimRuleConditionAssociation, 383 pcimRuleValidityAssociation, pcimRuleActionAssociation, and 384 pcimPolicyInstance, are all involved with the representation of policy 385 conditions and policy actions in an LDAP directory. This topic is 386 discussed in Section 4.4 below. 388 4.2 Usage of DIT Content and Structure Rules and Name Forms 390 There are three powerful tools that can be used to help define schemata. 391 The first, DIT content rules, is a way of defining the content of an 392 entry for a structural object class. It can be used to specify the 393 following characteristics of the entry: 395 - additional mandatory attributes that the entries MUST contain 396 - additional optional attributes that the entries MAY contain 397 - the set of additional auxiliary object classes that these entries 398 MAY be members of 399 - any optional attributes from the structural and auxiliary object 400 class definitions that the entries MUST NOT contain. 402 DIT content rules are NOT mandatory for any structural object class. 404 A DIT structure rule, together with a name form, controls the placement 405 and naming of an entry within the scope of a subschema. Name forms 406 define which attribute type(s) MUST and MAY be used in forming the 407 Relative Distinguished Names (RDNs) of entries. DIT structure rules 408 specify which entries MAY be superior to other entries, and hence 409 control the way that RDNs are added together to make DNs. 411 A name form specifies the following: 413 - the structural object class of the entries named by this name form 414 - attributes that MUST be used in forming the RDNs of these entries 415 - attributes that MAY be used in forming the RDNs of these entries 416 - an object identifier to uniquely identify this name form 418 Note that name forms can only be specified for structural object 419 classes. However, every entry in the DIT must have a name form 420 controlling it. 422 Unfortunately, current LDAP servers vary quite a lot in their support of 423 these features. There are also three crucial implementation points that 424 must be followed. First, X.500 use of structure rules requires that a 425 structural object class with no superior structure rule be a subschema 426 administrative point. This is exactly NOT what we want for policy 427 information. Second, when an auxiliary class is subclassed, if a content 428 rule exists for the structural class that the auxiliary class refers to, 429 then that content rule needs to be augmented. Finally, most LDAP servers 430 unfortunately do not support inheritance of structure and content rules. 432 Given these concerns, DIT structure and content rules have been removed 433 from the PCLS. This is because, if included, they would be normative 434 references and would require OIDs. However, we don�t want to lose the 435 insight gained in building the structure and content rules of the 436 previous version of the schema. Therefore, we describe where such rules 437 could be used in this schema, what they would control, and what their 438 effect would be. 440 4.3. Naming Attributes in the PCLS 442 Instances in a directory are identified by distinguished names (DNs), 443 which provide the same type of hierarchical organization that a file 444 system provides in a computer system. A distinguished name is a 445 sequence of RDNs. An RDN provides a unique identifier for an instance 446 within the context of its immediate superior, in the same way that a 447 filename provides a unique identifier for a file within the context of 448 the folder in which it resides. 450 To preserve maximum naming flexibility for policy administrators, three 451 optional (i.e., "MAY") naming attributes have been defined. They are: 453 - Each of the structural classes defined in this schema has its own 454 unique ("MAY") naming attribute. Since the naming attributes are 455 different, a policy administrator can, by using these attributes, 456 guarantee that there will be no name collisions between instances of 457 different classes, even if the same value is assigned to the 458 instances' respective naming attributes. 460 - The LDAP attribute cn (corresponding to X.500's commonName) is 461 included as a MAY attribute in the abstract class pcimPolicy, and 462 thus by inheritance in all of its subclasses. In X.500, commonName 463 typically functions as an RDN attribute, for naming instances of 464 many classes (e.g., X.500's person class). 466 - A special attribute is provided for implementations that expect to 467 map between native CIM and LDAP representations of policy 468 information. This attribute, called orderedCimKeys, is defined in 469 the class dlm1ManagedElement [10]. The value of this attribute is 470 derived algorithmically from values that are already present in a 471 CIM policy instance. The normative reference for this algorithm is 472 contained in [10]. See the appendix of this document for a 473 description of the algorithm. 475 Since any of these naming attributes MAY be used for naming an instance 476 of a PCLS class, implementations MUST be able to accommodate instances 477 named in any of these ways. 479 Note that it is recommended that two or more of these attributes SHOULD 480 NOT be used together to form a multi-part RDN, since support for multi- 481 part RDNs is limited among existing directory implementations. 483 4.4. Rule-Specific and Reusable Conditions and Actions 485 The PCIM [1] distinguishes between two types of policy conditions and 486 policy actions: ones associated with a single policy rule, and ones 487 that are reusable, in the sense that they may be associated with more 488 than one policy rule. While there is no inherent functional difference 489 between a rule-specific condition or action and a reusable one, there is 490 both a usage as well as an implementation difference between them. 492 Defining a condition or action as reusable vs. rule-specific reflects a 493 conscious decision on the part of the administrator in defining how they 494 are used. In addition, there are differences that reflect the difference 495 in implementing rule-specific vs. reusable policy conditions and actions 496 in how they are treated in a policy repository. The major implementation 497 differences between a rule-specific and a reusable condition or 498 actionare delineated below: 500 1. It is natural for a rule-specific condition or action to be removed 501 from the policy repository at the same time the rule is. It is just 502 the opposite for reusable conditions and actions. This is because 503 the condition or action is conceptually attached to the rule in the 504 rule-specific case, whereas it is referenced (e.g., pointed at) in 505 the reusable case. The persistence of a pcimRepository instance is 506 independent of the persistence of a pcimRule instance. 507 2. Access permissions for a rule-specific condition or action are 508 usually identical to those for the rule itself. On the other hand, 509 access permissions of reusable conditions and actions must be 510 expressible without reference to a policy rule. 511 3. Rule-specific conditions and actions require fewer accesses, 512 because the conditions and actions are �attached� to the rule. In 513 contrast, reusable conditions and actions require more accesses, 514 because each condition or action that is reusable requires a 515 separate access. 516 4. Rule-specific conditions and actions are designed for use by a 517 single rule. As the number of rules that use the same rule-specific 518 condition increase, subtle problems are created (the most obvious 519 being how to keep the rule-specific conditions and actions updated 520 to reflect the same value). Reusable conditions and actions lend 521 themselves for use by multiple independent rules. 522 5. Reusable conditions and actions offer an optimization when multiple 523 rules are using the same condition or action. This is because the 524 reusable condition or action only needs be updated once, and by 525 virtue of DN reference, the policy rules will be automatically 526 updated. 528 The preceding paragraph does not contain an exhaustive list of the ways 529 in which reusable and rule-specific conditions should be treated 530 differently. Its purpose is merely to justify making a semantic 531 distinction between rule-specific and reusable, and then reflecting this 532 distinction in the policy repository itself. 534 When the policy repository is realized in an LDAP-accessible directory, 535 the distinction between rule-specific and reusable conditions and 536 actions is realized via placement of auxiliary classes and via DIT 537 containment. Figure 4 illustrates a policy rule Rule1 with one rule- 538 specific condition CA and one rule-specific action AB. 540 +-----+ 541 |Rule1| 542 | | 543 +-----|- -|-----+ 544 | +-----+ | 545 | * * | 546 | * * | 547 | **** **** | 548 | * * | 549 v * * v 550 +--------+ +--------+ 551 | CA+ca | | AB+ab | 552 +--------+ +--------+ 554 +------------------------------+ 555 |LEGEND: | 556 | ***** DIT containment | 557 | + auxiliary attachment | 558 | ----> DN reference | 559 +------------------------------+ 561 Figure 4. Rule-Specific Policy Conditions and Actions 563 Because the condition and action are specific to Rule1, the auxiliary 564 classes ca and ab that represent them are attached, respectively, to the 565 structural classes CA and AB. These structural classes represent not 566 the condition ca and action ab themselves, but rather the associations 567 between Rule1 and ca, and between Rule1 and ab. 569 As Figure 4 illustrates, Rule1 contains DN references to the structural 570 classes CA and AB that appear below it in the DIT. At first glance it 571 might appear that these DN references are unnecessary, since a subtree 572 search below Rule1 would find all of the structural classes representing 573 the associations between Rule1 and its conditions and actions. Relying 574 only on a subtree search, though, runs the risk of missing conditions or 575 actions that should have appeared in the subtree, but for some reason 576 did not, or of finding conditions or actions that were inadvertently 577 placed in the subtree, or that should have been removed from the 578 subtree, but for some reason were not. Implementation experience has 579 suggested that many (but not all) of these risks are eliminated. 581 However, it must be noted that this comes at a price. The use of DN 582 references, as shown in Figure 4 above, thwarts inheritance of access 583 control information as well as existence dependency information. It also 584 is subject to referential integrity considerations. Therefore, it is 585 being included as an option for the designer. 587 Figure 5 illustrates a second way of representing rule-specific 588 conditions and actions in an LDAP-accessible directory: attachment of 589 the auxiliary classes directly to the instance representing the policy 590 rule. When all of the conditions and actions are attached to a policy 591 rule in this way, the rule is termed a "simple" policy rule. When 592 conditions and actions are not attached directly to a policy rule, the 593 rule is termed a "complex" policy rule. 595 +-----------+ 596 |Rule1+ca+ab| 597 | | 598 +-----------+ 600 +------------------------------+ 601 |LEGEND: | 602 | + auxiliary attachment | 603 +------------------------------+ 605 Figure 5. A Simple Policy Rule 607 The simple/complex distinction for a policy rule is not all or nothing. 608 A policy rule may have its conditions attached to itself and its actions 609 attached to other entries, or it may have its actions attached to itself 610 and its conditions attached to other entries. However, it SHALL NOT have 611 either its conditions or its actions attached both to itself and to 612 other entries, with one exception: a policy rule may reference its 613 validity periods with the pcimRuleValidityPeriodList attribute, but have 614 its other conditions attached to itself. 616 The tradeoffs between simple and complex policy rules are between the 617 efficiency of simple rules and the flexibility and greater potential for 618 reuse of complex rules. With a simple policy rule, the semantic options 619 are limited: 621 - All conditions are ANDed together. This combination can be 622 represented in two ways in the DNF / CNF (please see [1] for 623 definitions of these terms) expressions characteristic of policy 624 conditions: as a DNF expression with a single AND group, or as 625 a CNF expression with multiple single-condition OR groups. The 626 first of these is arbitrarily chosen as the representation for 627 the ANDed conditions in a simple policy rule. 629 - If multiple actions are included, no order can be specified for 630 them. 632 If a policy administrator needs to combine conditions in some other way, 633 or if there is a set of actions that must be ordered, then the only 634 option is to use a complex policy rule. 636 Finally, Figure 6 illustrates the same policy rule Rule1, but this time 637 its condition and action are reusable. The association classes CA and 638 AB are still present, and they are still DIT contained under Rule1. But 639 rather than having the auxiliary classes ca and ab attached directly to 640 the association classes CA and AB, each now contains DN references to 641 other entries to which these auxiliary classes are attached. These 642 other entries, CIA and AIB, are DIT contained under RepositoryX, which 643 is an instance of the class pcimRepository. Because they are named 644 under an instance of pcimRepository, ca and ab are clearly identified as 645 reusable. 647 +-----+ +-------------+ 648 |Rule1| | RepositoryX | 649 +-|- -|--+ | | 650 | +-----+ | +-------------+ 651 | * * | * * 652 | * * | * * 653 | *** **** | * * 654 | * * v * * 655 | * +---+ * * 656 | * |AB | +------+ * 657 v * | -|-------->|AIB+ab| * 658 +---+ +---+ +------+ * 659 |CA | +------+ 660 | -|------------------------>|CIA+ca| 661 +---+ +------+ 663 +------------------------------+ 664 |LEGEND: | 665 | ***** DIT containment | 666 | + auxiliary attachment | 667 | ----> DN reference | 668 +------------------------------+ 670 Figure 6. Reusable Policy Conditions and Actions 672 The classes pcimConditionAuxClass and pcimActionAuxClass do not 673 themselves represent actual conditions and actions: these are 674 introduced in their subclasses. What pcimConditionAuxClass and 675 pcimActionAuxClass do introduce are the semantics of being a policy 676 condition or a policy action. These are the semantics that all the 677 subclasses of pcimConditionAuxClass and pcimActionAuxClass inherit. 678 Among these semantics are those of representing either a rule-specific 679 or a reusable policy condition or policy action. 681 In order to preserve the ability to represent a rule-specific or a 682 reusable condition or action, as well as a simple policy rule, all the 683 subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST also be 684 auxiliary classes. 686 4.5. Location and Retrieval of Policy Objects in the Directory 688 When a PDP goes to an LDAP directory to retrieve the policy object 689 instances relevant to the PEPs it serves, it is faced with two related 690 problems: 692 - How does it locate and retrieve the directory entries that apply to 693 its PEPs? These entries may include instances of the PCLS classes, 694 instances of domain-specific subclasses of these classes, and 695 instances of other classes modeling such resources as user groups, 696 interfaces, and address ranges. 698 - How does it retrieve the directory entries it needs in an efficient 699 manner, so that retrieval of policy information from the directory 700 does not become a roadblock to scalability? There are two facets to 701 this efficiency: retrieving only the relevant directory entries, 702 and retrieving these entries using as few LDAP calls as possible. 704 The placement of objects in the Directory Information Tree (DIT) 705 involves considerations other than how the policy-related objects will 706 be retrieved by a PDP. Consequently, all that the PCLS can do is to 707 provide a "toolkit" of classes to assist the policy administrator as the 708 DIT is being designed and built. A PDP SHOULD be able to take advantage 709 of any tools that the policy administrator is able to build into the 710 DIT, but it MUST be able to use a less efficient means of retrieval if 711 that is all it has available to it. 713 The basic idea behind the LDAP optimization classes is a simple one: 714 make it possible for a PDP to retrieve all the policy-related objects it 715 needs, and only those objects, using as few LDAP calls as possible. An 716 important assumption underlying this approach is that the policy 717 administrator has sufficient control over the underlying DIT structure 718 to define subtrees for storing policy information. If the policy 719 administrator does not have this level of control over DIT structure, a 720 PDP can still retrieve the policy-related objects it needs individually. 721 But it will require more LDAP access operations to do the retrieval in 722 this way. Figure 7 illustrates how LDAP optimization is accomplished. 724 +-----+ 725 ---------------->| A | 726 DN reference to | | DN references to subtrees +---+ 727 starting object +-----+ +-------------------------->| C | 728 | o--+----+ +---+ +---+ 729 | o--+------------->| B | / \ 730 +-----+ +---+ / \ 731 / \ / \ / ... \ 732 / \ / \ 733 / \ / ... \ 735 Figure 7. Using the pcimSubtreesPtrAuxClass to Locate Policies 737 The PDP is configured initially with a DN reference to some entry in the 738 DIT. The structural class of this entry is not important; the PDP is 739 interested only in the pcimSubtreesPtrAuxClass attached to it. This 740 auxiliary class contains a multi-valued attribute with DN references to 741 objects that anchor subtrees containing policy-related objects of 742 interest to the PDP. Since pcimSubtreesPtrAuxClass is an auxiliary 743 class, it can be attached to an entry that the PDP would need to access 744 anyway - perhaps an entry containing initial configuration settings for 745 the PDP, or for a PEP that uses the PDP. 747 Once it has retrieved the DN references, the PDP will direct to each of 748 the objects identified by them an LDAP request that all entries in its 749 subtree be evaluated against the selection criteria specified in the 750 request. The LDAP-enabled directory then returns all entries in that 751 subtree that satisfy the specified criteria. 753 The selection criteria always specify that object class="pcimPolicy". 754 Since all classes representing policy rules, policy conditions, and 755 policy actions, both in the PCLS and in any domain-specific schema 756 derived from it, are subclasses of the abstract class policy, this 757 criterion evaluates to TRUE for all instances of these classes. To 758 accommodate special cases where a PDP needs to retrieve objects that are 759 not inherently policy-related (for example, an IP address range object 760 referenced by a subclass of pcimActionAuxClass representing the DHCP 761 action "assign from this address range), the auxiliary class 762 pcimElementAuxClass can be used to "tag" an entry, so that it will be 763 found by the selection criterion "object class=pcimPolicy". 765 The approach described in the preceding paragraph will not work for 766 certain directory implementations, because these implementations do not 767 support matching of auxiliary classes in the objectClass attribute. For 768 environments where these implementations are expected to be present, the 769 "tagging" of entries as relevant to policy can be accomplished by 770 inserting the special value "POLICY" into the list of values contained 771 in the pcimKeywords attribute (provided by the pcimPolicy class). 773 If a PDP needs only a subset of the policy-related objects in the 774 indicated subtrees, then it can be configured with additional selection 775 criteria based on the pcimKeywords attribute defined in the pcimPolicy 776 class. This attribute supports both standardized and administrator- 777 defined values. For example, a PDP could be configured to request only 778 those policy-related objects containing the keywords "DHCP" and "Eastern 779 US". 781 To optimize what is expected to be a typical case, the initial request 782 from the client includes not only the object to which its "seed" DN 783 references, but also the subtree contained under this object. The 784 filter for searching this subtree is whatever the client is going to use 785 later to search the other subtrees: object class="pcimPolicy" or the 786 presence of the keyword "POLICY", and/or presence of a more specific 787 value of pcimKeywords (e.g., �QoS Edge Policy�). 789 Returning to the example in Figure 7, we see that in the best case, a 790 PDP can get all the policy-related objects it needs, and only those 791 objects, with exactly three LDAP requests: one to its starting object A 792 to get the references to B and C, as well as the policy-related objects 793 it needs from the subtree under A, and then one each to B and C to get 794 all the policy-related objects that pass the selection criteria with 795 which it was configured. Once it has retrieved all of these objects, 796 the PDP can then traverse their various DN references locally to 797 understand the semantic relationships among them. The PDP should also 798 be prepared to find a reference to another subtree attached to any of 799 the objects it retrieves, and to follow this reference first, before it 800 follows any of the semantically significant references it has received. 801 This recursion permits a structured approach to identifying related 802 policies. In Figure 7, for example, if the subtree under B includes 803 departmental policies and the one under C includes divisional policies, 804 then there might be a reference from the subtree under C to an object D 805 that roots the subtree of corporate-level policies. 807 A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be 808 capable of retrieving and processing the entries in the subtrees it 809 references, and SHOULD be capable of doing all of this recursively. The 810 same requirements apply to any other entity needing to retrieve policy 811 information from the directory. Thus, a Policy Management Tool that 812 retrieves policy entries from the directory in order to perform 813 validation and conflict detection SHOULD also understand and be capable 814 of using the pcimSubtreesPtrAuxClass. All of these requirements are 815 "SHOULD"s rather than "MUST"s because an LDAP client that doesn't 816 implement them can still access and retrieve the directory entries it 817 needs. The process of doing so will just be less efficient than it 818 would have been if the client had implemented these optimizations. 820 When it is serving as a tool for creating policy entries in the 821 directory, a Policy Management Tool SHOULD support creation of 822 pcimSubtreesPtrAuxClass entries and their references to object 823 instances. 825 4.5.1. Aliases and Other DIT-Optimization Techniques 827 Additional flexibility in DIT structure is available to the policy 828 administrator via LDAP aliasing and other techniques. Previous versions 829 of this document have used aliases. However, because aliases are 830 experimental, the use of aliases has been removed from this version of 831 this document. This is because the IETF has yet to produce a 832 specification on how aliases are represented in the directory or how 833 server implementations are to process aliases. 835 5. Class Definitions 837 The semantics for the policy information classes that are to be mapped 838 directly from the information model to an LDAP representation are 839 detailed in [1]. Consequently, all that this document presents for 840 these classes is the specification for how to do the mapping from the 841 information model (which is independent of repository type and access 842 protocol) to a form that can be accessed using LDAP. Remember that some 843 new classes needed to be created (that were not part of [1]) to 844 implement the LDAP mapping. These new LDAP-only classes are fully 845 documented in this document. 847 The formal language for specifying the classes, attributes, and DIT 848 structure and content rules is that defined in reference [2]. If your 849 implementation does not support auxiliary class inheritance, you will 850 have to list auxiliary classes in content rules explicitly or define 851 them in another (implementation-specific) way. 853 The following notes apply to this section in its entirety. 855 Note 1: in the following definitions, the class and attribute 856 definitions follow RFC2252 [2] but they are line-wrapped to enhance 857 human readability. 859 Note 2: where applicable, the possibilities for specifying DIT structure 860 and content rules are noted. However, care must be taken in specifying 861 DIT structure rules. This is because X.501 [5] states that an entry may 862 only exist in the DIT as a subordinate to another superior entry (the 863 superior) if a DIT structure rule exists in the governing subschema 864 which: 866 1) indicates a name form for the structural object class of the 867 subordinate entry, and 868 2) either includes the entry�s superior structure rule as a possible 869 superior structure rule, or 870 3) does not specify a superior structure rule. 872 If this last case (3) applies, then the entry is defined to be a 873 subschema administrative point. This is not what is desired. Therefore, 874 care must be taken in defining structure rules, and in particular, they 875 must be locally augmented. 877 Note 3: Wherever possible, both an equality and a substring matching 878 rule are defined for a particular attribute (as well as an ordering 879 match rule to enable sorting of matching results). This provides two 880 different choices for the developer for maximum flexibility. 882 For example, consider the pcimRoles attribute (section 5.3). Suppose 883 that a PEP has reported that it is interested in pcimRules for three 884 roles R1, R2, and R3. If the goal is to minimize queries, then the PDP 885 can supply three substring filters containing the three role names. 887 These queries will return all of the pcimRules that apply to the PEP, 888 but they may also get some that do not apply (e.g., ones that contain 889 one of the roles R1, R2, or R3 and one or more other roles present in a 890 role-combination [1]). 892 Another strategy would be for the PDP to use only equality filters. This 893 approach eliminates the extraneous replies, but it requires the PDP to 894 explicitly build the desired role-combinations itself. It also requires 895 extra queries. Note that this approach is practical only because the 896 role names in a role combination are required to appear in alphabetical 897 order. 899 Note 4: in the following definitions, OIDs are indicated by placeholders 900 of the form: , where xx can be �oc� for �object class� or 901 �at� for �attribute�. These placeholder values will be replaced with 902 real OIDs assigned by the RFC Editor from IANA before publication. This 903 note (only) to be removed by the RFC editor before publication. 905 Note 5: in the following definitions, note that all LDAP matching rules 906 are defined in [2] and in [15]. The corresponding X.500 matching rules 907 are defined in [12]. 909 Note 6: some of the following attribute definitions specify additional 910 constraints on various data types (e.g., this integer has values that 911 are valid from 1..10). Text has been added to instruct servers and 912 applications what to do if a value outside of this range is encountered. 913 In all cases, if a constraint is violated, then the policy rule SHOULD 914 be treated as being disabled, meaning that execution of the policy rule 915 SHOULD be stopped. 917 5.1. The Abstract Class pcimPolicy 919 The abstract class pcimPolicy is a direct mapping of the abstract class 920 Policy from the PCIM. The class value "pcimPolicy" is also used as the 921 mechanism for identifying policy-related instances in the Directory 922 Information Tree. An instance of any class may be "tagged" with this 923 class value by attaching to it the auxiliary class pcimElementAuxClass. 925 The class definition is as follows: 927 ( NAME 'pcimPolicy' 928 DESC 'An abstract class that is the base class for all classes 929 that describe policy-related instances.' 930 SUP dlm1ManagedElement 931 ABSTRACT 932 MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $ 933 pcimKeywords ) 934 ) 936 The attribute cn is defined in RFC 2256 [11]. The dlmCaption, 937 dlmDescription, and orderedCimKeys attributes are defined in [10]. 939 The pcimKeywords attribute is a multi-valued attribute that contains a 940 set of keywords to assist directory clients in locating the policy 941 objects identified by these keywords. It is defined as follows: 943 ( NAME 'pcimKeywords' 944 DESC 'A set of keywords to assist directory clients in 945 locating the policy objects applicable to them.' 946 EQUALITY caseIgnoreMatch 947 ORDERING caseIgnoreOrderingMatch 948 SUBSTR caseIgnoreSubstringsMatch 949 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 950 ) 952 5.2. The Three Policy Group Classes 954 PCIM [1] defines the PolicyGroup class to serve as a generalized 955 aggregation mechanism, enabling PolicyRules and/or PolicyGroups to be 956 aggregated together. PCLS maps this class into three LDAP classes, 957 called pcimGroup, pcimGroupAuxClass, and pcimGroupInstance. This is done 958 in order to provide maximum flexibility for the DIT designer. 960 The class definitions for the three policy group classes are listed 961 below. These class definitions do not include attributes to realize the 962 PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from 963 the PCIM. This is because a pcimGroup object refers to instances of 964 pcimGroup and pcimRule via, respectively, the attribute 965 pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object 966 class and the attribute pcimRulesAuxContainedSet in the 967 pcimRuleContainmentAuxClass object class. 969 To maximize flexibility, the pcimGroup class is defined as abstract. The 970 subclass pcimGroupAuxClass provides for auxiliary attachment to 971 another entry, while the structural subclass pcimGroupInstance is 972 available to represent a policy group as a standalone entry. 974 The class definitions are as follows. First, the definition of the 975 abstract class pcimGroup: 977 ( NAME 'pcimGroup' 978 DESC 'A container for a set of related pcimRules and/or 979 a set of related pcimGroups.' 980 SUP pcimPolicy 981 ABSTRACT 982 MAY ( pcimGroupName ) 983 ) 985 The one attribute of pcimGroup is pcimGroupName. This attribute is used 986 to define a user-friendly name of this policy group, and may be used as 987 a naming attribute if desired. It is defined as follows: 989 ( NAME 'pcimGroupName' 990 DESC 'The user-friendly name of this policy group.' 991 EQUALITY caseIgnoreMatch 992 ORDERING caseIgnoreOrderingMatch 993 SUBSTR caseIgnoreSubstringsMatch 994 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 995 SINGLE-VALUE 996 ) 998 The two subclasses of pcimGroup are defined as follows. The class 999 pcimGroupAuxClass is an auxiliary class that can be used to collect a 1000 set of related pcimRule and/or pcimGroup classes. It is defined as 1001 follows: 1003 ( NAME 'pcimGroupAuxClass' 1004 DESC 'An auxiliary class that collects a set of related 1005 pcimRule and/or pcimGroup entries.' 1006 SUP pcimGroup 1007 AUXILIARY 1008 ) 1010 The class pcimGroupInstance is a structural class that can be used to 1011 collect a set of related pcimRule and/or pcimGroup classes. It is 1012 defined as follows: 1014 ( NAME 'pcimGroupInstance' 1015 DESC 'A structural class that collects a set of related 1016 pcimRule and/or pcimGroup entries.' 1017 SUP pcimGroup 1018 STRUCTURAL 1019 ) 1021 A DIT content rule could be written to enable an instance of 1022 pcimGroupInstance to have attached to it either references to one or 1023 more policy groups (using pcimGroupContainmentAuxClass) or references to 1024 one or more policy rules (using pcimRuleContainmentAuxClass). This would 1025 be used to formalize the semantics of the PolicyGroup class [1]. Since 1026 these semantics do not include specifying any properties of the 1027 PolicyGroup class, the content rule would not need to specify any 1028 attributes. 1030 Similarly, three separate DIT structure rules could be written, each of 1031 which would refer to a specific name form that identified one of the 1032 three possible naming attributes (i.e., pcimGroupName, cn, and 1033 orderedCIMKeys) for the pcimGroup object class. This structure rule 1034 SHOULD include a superiorStructureRule (see Note 2 at the beginning of 1035 section 5). The three name forms referenced by the three structure rules 1036 would each define one of the three naming attributes. 1038 5.3. The Three Policy Rule Classes 1040 The information model defines a PolicyRule class to represent the "If 1041 Condition then Action" semantics associated with processing policy 1042 information. For maximum flexibility, the PCLS maps this class into 1043 three LDAP classes. 1045 To maximize flexibility, the pcimRule class is defined as abstract. The 1046 subclass pcimRuleAuxClass provides for auxiliary attachment to another 1047 entry, while the structural subclass pcimRuleInstance is available to 1048 represent a policy rule as a standalone entry. 1050 The conditions and actions associated with a policy rule are modeled, 1051 respectively, with auxiliary subclasses of the auxiliary classes 1052 pcimConditionAuxClass and pcimActionAuxClass. Each of these auxiliary 1053 subclasses is attached to an instance of one of three structural 1054 classes. A subclass of pcimConditionAuxClass is attached to an instance 1055 of pcimRuleInstance, to an instance of pcimRuleConditionAssociation, or 1056 to an instance of pcimPolicyInstance. Similarly, a subclass of 1057 pcimActionAuxClass is attached to an instance of pcimRuleInstance, to an 1058 instance of pcimRuleActionAssociation, or to an instance of 1059 pcimPolicyInstance. 1061 The pcimRuleValidityPeriodList attribute (defined below) realizes the 1062 PolicyRuleValidityPeriod association defined in the PCIM. Since this 1063 association has no additional properties besides those that tie the 1064 association to its associated objects, this association can be realized 1065 by simply using an attribute. Thus, the pcimRuleValidityPeriodList 1066 attribute is simply a multi-valued attribute that provides an unordered 1067 set of DN references to one or more instances of the pcimTPCAuxClass, 1068 indicating when the policy rule is scheduled to be active and when it is 1069 scheduled to be inactive. A policy rule is scheduled to be active if it 1070 is active according to AT LEAST ONE of the pcimTPCAuxClass instances 1071 referenced by this attribute. 1073 The PolicyConditionInPolicyRule and PolicyActionInPolicyRule 1074 associations, however, do have additional attributes. The association 1075 PolicyActionInPolicyRule defines an integer attribute to sequence the 1076 actions, and the association PolicyConditionInPolicyRule has both an 1077 integer attribute to group the condition terms as well as a Boolean 1078 property to specify whether a condition is to be negated. 1080 In the PCLS, these additional association attributes are represented as 1081 attributes of two classes introduced specifically to model these 1082 associations. These classes are the pcimRuleConditionAssociation class 1083 and the pcimRuleActionAssociation class, which are defined in Sections 1084 5.4 and 5.5, respectively. Thus, they do not appear as attributes of 1085 the class pcimRule. Instead, the pcimRuleConditionList and 1086 pcimRuleActionList attributes can be used to reference these classes. 1088 The class definitions for the three pcimRule classes are as follows. 1090 The abstract class pcimRule is a base class for representing the "If 1091 Condition then Action" semantics associated with a policy rule. It is 1092 defined as follows: 1094 ( NAME 'pcimRule' 1095 DESC 'The base class for representing the "If Condition 1096 then Action" semantics associated with a policy rule.' 1097 SUP pcimPolicy 1098 ABSTRACT 1099 MAY ( pcimRuleName $ pcimRuleEnabled $ 1100 pcimRuleConditionListType $ pcimRuleConditionList $ 1101 pcimRuleActionList $ pcimRuleValidityPeriodList $ 1102 pcimRuleUsage $ pcimRulePriority $ 1103 pcimRuleMandatory $ pcimRuleSequencedActions $ 1104 pcimRoles ) 1105 ) 1107 The PCIM [1] defines seven properties for the PolicyRule class. The PCLS 1108 defines eleven attributes for the pcimRule class, which is the LDAP 1109 equivalent of the PolicyRule class. Of these eleven attributes, seven 1110 are mapped directly from corresponding properties in PCIM�s PolicyRule 1111 class. The remaining four attributes are a class-specific optional 1112 naming attribute, and three attributes used to realize the three 1113 associations that the pcimRule class participates in. 1115 The pcimRuleName attribute is used as a user-friendly name of this 1116 policy rule, and can also serve as the class-specific optional naming 1117 attribute. It is defined as follows: 1119 ( NAME 'pcimRuleName' 1120 DESC 'The user-friendly name of this policy rule.' 1121 EQUALITY caseIgnoreMatch 1122 ORDERING caseIgnoreOrderingMatch 1123 SUBSTR caseIgnoreSubstringsMatch 1124 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1125 SINGLE-VALUE 1126 ) 1128 The pcimRuleEnabled attribute is an integer enumeration indicating 1129 whether a policy rule is administratively enabled (value=1), 1130 administratively disabled (value=2), or enabled for debug (value=3). It 1131 is defined as follows: 1133 ( NAME 'pcimRuleEnabled' 1134 DESC 'An integer indicating whether a policy rule is 1135 administratively enabled (value=1), disabled 1136 (value=2), or enabled for debug (value=3).' 1137 EQUALITY integerMatch 1138 ORDERING integerOrderingMatch 1139 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1140 SINGLE-VALUE 1141 ) 1143 Note: All other values for the pcimRuleEnabled attribute are considered 1144 errors, and the administrator SHOULD treat this rule as being disabled 1145 if an invalid value is found. 1147 The pcimRuleConditionListType attribute is used to indicate whether the 1148 list of policy conditions associated with this policy rule is in 1149 disjunctive normal form (DNF, value=1) or conjunctive normal form (CNF, 1150 value=2). It is defined as follows: 1152 ( NAME 'pcimRuleConditionListType' 1153 DESC 'A value of 1 means that this policy rule is in 1154 disjunctive normal form; a value of 2 means that this 1155 policy rule is in conjunctive normal form.' 1156 EQUALITY integerMatch 1157 ORDERING integerOrderingMatch 1158 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1159 SINGLE-VALUE 1160 ) 1162 Note: any value other than 1 or 2 for the pcimRuleConditionListType 1163 attribute is considered an error. Administrators SHOULD treat this rule 1164 as being disabled if an invalid value is found, since it is unclear how 1165 to structure the condition list. 1167 The pcimRuleConditionList attribute is a multi-valued attribute that is 1168 used to realize the policyRuleInPolicyCondition association defined in 1169 [1]. It contains a set of DNs of pcimRuleConditionAssociation entries 1170 representing associations between this policy rule and its conditions. 1171 No order is implied. It is defined as follows: 1173 ( NAME 'pcimRuleConditionList' 1174 DESC 'Unordered set of DNs of pcimRuleConditionAssociation 1175 entries representing associations between this policy 1176 rule and its conditions.' 1177 EQUALITY distinguishedNameMatch 1178 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1179 ) 1181 The pcimRuleActionList attribute is a multi-valued attribute that is 1182 used to realize the policyRuleInPolicyAction association defined in [1]. 1183 It contains a set of DNs of pcimRuleActionAssociation entries 1184 representing associations between this policy rule and its actions. No 1185 order is implied. It is defined as follows: 1187 ( NAME 'pcimRuleActionList' 1188 DESC 'Unordered set of DNs of pcimRuleActionAssociation 1189 entries representing associations between this policy 1190 rule and its actions.' 1191 EQUALITY distinguishedNameMatch 1192 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1193 ) 1195 The pcimRuleValidityPeriodList attribute is a multi-valued attribute 1196 that is used to realize the pcimRuleValidityPeriod association that is 1197 defined in [1]. It contains a set of DNs of pcimRuleValidityAssociation 1198 entries that determine when the pcimRule is scheduled to be active or 1199 inactive. No order is implied. It is defined as follows: 1201 ( NAME 'pcimRuleValidityPeriodList' 1202 DESC 'Unordered set of DNs of pcimRuleValidityAssociation 1203 entries that determine when the pcimRule is scheduled 1204 to be active or inactive.' 1205 EQUALITY distinguishedNameMatch 1206 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1207 ) 1209 The pcimRuleUsage attribute is a free-form sting providing guidelines on 1210 how this policy should be used. It is defined as follows: 1212 ( NAME 'pcimRuleUsage' 1213 DESC 'This attribute is a free-form sting providing 1214 guidelines on how this policy should be used.' 1215 EQUALITY caseIgnoreMatch 1216 ORDERING caseIgnoreOrderingMatch 1217 SUBSTR caseIgnoreSubstringsMatch 1218 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1219 SINGLE-VALUE 1220 ) 1222 The pcimRulePriority attribute is a non-negative integer that is used to 1223 prioritize this pcimRule relative to other pcimRules. A larger value 1224 indicates a higher priority. It is defined as follows: 1226 ( NAME 'pcimRulePriority' 1227 DESC 'A non-negative integer for prioritizing this 1228 pcimRule relative to other pcimRules. A larger 1229 value indicates a higher priority.' 1230 EQUALITY integerMatch 1231 ORDERING integerOrderingMatch 1232 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1233 SINGLE-VALUE 1234 ) 1236 Note: if the value of the pcimRulePriority field is 0, then it SHOULD be 1237 treated as �don�t care�. On the other hand, if the value is negative, 1238 then it SHOULD be treated as an error and Administrators SHOULD treat 1239 this rule as being disabled. 1241 The pcimRuleMandatory attribute is a Boolean attribute that, if TRUE, 1242 indicates that for this policy rule, the evaluation of its conditions 1243 and execution of its actions (if the condition is satisfied) is 1244 required. If it is FALSE, then the evaluation of its conditions and 1245 execution of its actions (if the condition is satisfied) is not 1246 required. This attribute is defined as follows: 1248 ( NAME 'pcimRuleMandatory' 1249 DESC 'If TRUE, indicates that for this policy rule, the 1250 evaluation of its conditions and execution of its 1251 actions (if the condition is satisfied) is required.' 1252 EQUALITY booleanMatch 1253 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1254 SINGLE-VALUE 1255 ) 1257 The pcimRuleSequencedActions attribute is an integer enumeration that is 1258 used to indicate that the ordering of actions defined by the 1259 pcimActionOrder attribute is either mandatory(value=1), 1260 recommended(value=2), or dontCare(value=3). It is defined as follows: 1262 ( NAME 'pcimRuleSequencedActions' 1263 DESC 'An integer enumeration indicating that the ordering of 1264 actions defined by the pcimActionOrder attribute is 1265 mandatory(1), recommended(2), or dontCare(3).' 1266 EQUALITY integerMatch 1267 ORDERING integerOrderingMatch 1268 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1269 SINGLE-VALUE 1270 ) 1272 Note: if the value of pcimRulesSequencedActions field is not one of 1273 these three values, then Administrators SHOULD treat this rule as being 1274 disabled. 1276 The pcimRoles attribute represents the policyRoles property of [1]. Each 1277 value of this attribute represents a role-combination, which is a string 1278 of the form: 1279 [&&]* 1280 where the individual role names appear in alphabetical order according 1281 to the collating sequence for UCS-2. This attribute is defined as 1282 follows: 1284 ( NAME 'pcimRoles' 1285 DESC 'Each value of this attribute represents a role- 1286 combination.' 1287 EQUALITY caseIgnoreMatch 1288 ORDERING caseIgnoreOrderingMatch 1289 SUBSTR caseIgnoreSubstringsMatch 1290 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1291 ) 1293 Note: if the value of the pcimRoles attribute does not conform to the 1294 format �[&&]*� (see Section 6.3.7 of [1]), then this 1295 attribute is malformed and its policy rule SHOULD be treated as being 1296 disabled. 1298 The two subclasses of the pcimRule class are defined as follows. First, 1299 the pcimRuleAuxClass is an auxiliary class for representing the "If 1300 Condition then Action" semantics associated with a policy rule. Its 1301 class definition is as follows: 1303 ( NAME 'pcimRuleAuxClass' 1304 DESC 'An auxiliary class for representing the "If Condition 1305 then Action" semantics associated with a policy rule.' 1306 SUP pcimRule 1307 AUXILIARY 1308 ) 1310 The pcimRuleInstance is a structural class for representing the "If 1311 Condition then Action" semantics associated with a policy rule. Its 1312 class definition is as follows: 1314 ( NAME 'pcimRuleInstance' 1315 DESC 'A structural class for representing the "If Condition 1316 then Action" semantics associated with a policy rule.' 1317 SUP pcimRule 1318 STRUCTURAL 1319 ) 1321 A DIT content rule could be written to enable an instance of 1322 pcimRuleInstance to have attached to it either references to one or more 1323 policy conditions (using pcimConditionAuxClass) or references to one or 1324 more policy actions (using pcimActionAuxClass). This would be used to 1325 formalize the semantics of the PolicyRule class [1]. Since these 1326 semantics do not include specifying any properties of the PolicyRule 1327 class, the content rule would not need to specify any attributes. 1329 Similarly, three separate DIT structure rules could be written, each of 1330 which would refer to a specific name form that identified one of its 1331 three possible naming attributes (i.e., pcimRuleName, cn, and 1332 orderedCIMKeys). This structure rule SHOULD include a 1333 superiorStructureRule (see Note 2 at the beginning of section 5). The 1334 three name forms referenced by the three structure rules would each 1335 define one of the three naming attributes. 1337 5.4. The Class pcimRuleConditionAssociation 1339 This class contains attributes to represent the properties of the PCIM's 1340 PolicyConditionInPolicyRule association. Instances of this class are 1341 related to an instance of pcimRule via DIT containment. The policy 1342 conditions themselves are represented by auxiliary subclasses of the 1343 auxiliary class pcimConditionAuxClass. These auxiliary classes are 1344 attached directly to instances of pcimRuleConditionAssociation for rule- 1345 specific policy conditions. For a reusable policy condition, the 1346 policyCondition auxiliary subclass is attached to an instance of the 1347 class pcimPolicyInstance (which is presumably associated with a 1348 pcimRepository by DIT containment), and the policyConditionDN attribute 1349 (of this class) is used to reference the reusable policyCondition 1350 instance. 1352 The class definition is as follows: 1354 ( NAME 'pcimRuleConditionAssociation' 1355 DESC 'This class contains attributes characterizing the 1356 relationship between a policy rule and one of its 1357 policy conditions.' 1358 SUP pcimPolicy 1359 MUST ( pcimConditionGroupNumber $ pcimConditionNegated ) 1360 MAY ( pcimConditionName $ pcimConditionDN ) 1361 ) 1363 The attributes of this class are defined as follows. 1365 The pcimConditionGroupNumber attribute is a non-negative integer. It is 1366 used to identify the group to which the condition referenced by this 1367 association is assigned. This attribute is defined as follows: 1369 ( 1370 NAME 'pcimConditionGroupNumber' 1371 DESC 'The number of the group to which a policy condition 1372 belongs. This is used to form the DNF or CNF 1373 expression associated with a policy rule.' 1374 EQUALITY integerMatch 1375 ORDERING integerOrderingMatch 1376 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1377 SINGLE-VALUE 1378 ) 1380 Note that this number is non-negative. A negative value for this 1381 attribute is invalid, and any policy rule that refers to an invalid 1382 entry SHOULD be treated as being disabled. 1384 The pcimConditionNegated attribute is a Boolean attribute that indicates 1385 whether this policy condition is to be negated or not. If it is TRUE 1386 (FALSE), it indicates that a policy condition IS (IS NOT) negated in the 1387 DNF or CNF expression associated with a policy rule. This attribute is 1388 defined as follows: 1390 ( 1391 NAME 'pcimConditionNegated' 1392 DESC 'If TRUE (FALSE), it indicates that a policy condition 1393 IS (IS NOT) negated in the DNF or CNF expression 1394 associated with a policy rule.' 1395 EQUALITY booleanMatch 1396 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 1397 SINGLE-VALUE 1398 ) 1400 The pcimConditionName is a user-friendly name for identifying this 1401 policy condition, and may be used as a naming attribute if desired. This 1402 attribute is defined as follows: 1404 ( 1405 NAME 'pcimConditionName' 1406 DESC 'A user-friendly name for a policy condition.' 1407 EQUALITY caseIgnoreMatch 1408 ORDERING caseIgnoreOrderingMatch 1409 SUBSTR caseIgnoreSubstringsMatch 1410 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1411 SINGLE-VALUE 1412 ) 1414 The pcimConditionDN attribute is a DN that references an instance of a 1415 reusable policy condition. This attribute is defined as follows: 1417 ( 1418 NAME 'pcimConditionDN' 1419 DESC 'A DN that references an instance of a reusable policy 1420 condition.' 1421 EQUALITY distinguishedNameMatch 1422 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1423 SINGLE-VALUE 1424 ) 1426 A DIT content rule could be written to enable an instance of 1427 pcimRuleConditionAssociation to have attached to it an instance of the 1428 auxiliary class pcimConditionAuxClass, or one of its subclasses. This 1429 would be used to formalize the semantics of the 1430 PolicyConditionInPolicyRule association. Specifically, this would be 1431 used to represent a rule-specific policy condition [1]. 1433 Similarly, three separate DIT structure rules could be written. Each of 1434 these DIT structure rules would refer to a specific name form that 1435 defined two important semantics. First, each name form would identify 1436 one of the three possible naming attributes (i.e., pcimConditionName, 1437 cn, and orderedCIMKeys) for the pcimRuleConditionAssociation object 1438 class. Second, each name form would require that an instance of the 1439 pcimRuleConditionAssociation class have as its superior an instance of 1440 the pcimRule class. This structure rule SHOULD also include a 1441 superiorStructureRule (see Note 2 at the beginning of section 5). 1443 5.5. The Class pcimRuleValidityAssociation 1445 The policyRuleValidityPeriod aggregation is mapped to the PCLS 1446 pcimRuleValidityAssociation class. This class represents the scheduled 1447 activation and deactivation of a policy rule by binding the definition 1448 of times that the policy is active to the policy rule itself. The 1449 "scheduled" times are either identified through an attached auxiliary 1450 class pcimTPCAuxClass, or are referenced through its 1451 pcimTimePeriodConditionDN attribute. 1453 This class is defined as follows: 1455 ( NAME 'pcimRuleValidityAssociation' 1456 DESC 'This defines the scheduled activation or deactivation 1457 of a policy rule.' 1458 SUP pcimPolicy 1459 STRUCTURAL 1460 MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN ) 1461 ) 1463 The attributes of this class are defined as follows: 1465 The pcimValidityConditionName attribute is used to define a user- 1466 friendly name of this condition, and may be used as a naming attribute 1467 if desired. This attribute is defined as follows: 1469 ( 1470 NAME 'pcimValidityConditionName' 1471 DESC 'A user-friendly name for identifying an instance of 1472 a pcimRuleValidityAssociation entry.' 1473 EQUALITY caseIgnoreMatch 1474 ORDERING caseIgnoreOrderingMatch 1475 SUBSTR caseIgnoreSubstringsMatch 1476 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1477 SINGLE-VALUE 1478 ) 1480 The pcimTimePeriodConditionDN attribute is a DN that references a 1481 reusable time period condition. It is defined as follows: 1483 ( 1484 NAME 'pcimTimePeriodConditionDN' 1485 DESC 'A reference to a reusable policy time period 1486 condition.' 1487 EQUALITY distinguishedNameMatch 1488 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1489 SINGLE-VALUE 1490 ) 1492 A DIT content rule could be written to enable an instance of 1493 pcimRuleValidityAssociation to have attached to it an instance of the 1494 auxiliary class pcimTPCAuxClass, or one of its subclasses. This would be 1495 used to formalize the semantics of the PolicyRuleValidityPeriod 1496 aggregation [1]. 1498 Similarly, three separate DIT structure rules could be written. Each of 1499 these DIT structure rules would refer to a specific name form that 1500 defined two important semantics. First, each name form would identify 1501 one of the three possible naming attributes (i.e., 1502 pcimValidityConditionName, cn, and orderedCIMKeys) for the 1503 pcimRuleValidityAssociation object class. Second, each name form would 1504 require that an instance of the pcimRuleValidityAssociation class have 1505 as its superior an instance of the pcimRule class. This structure rule 1506 SHOULD also include a superiorStructureRule (see Note 2 at the beginning 1507 of section 5). 1509 5.6. The Class pcimRuleActionAssociation 1511 This class contains an attribute to represent the one property of the 1512 PCIM PolicyActionInPolicyRule association, ActionOrder. This property is 1513 used to specify an order for executing the actions associated with a 1514 policy rule. Instances of this class are related to an instance of 1515 pcimRule via DIT containment. The actions themselves are represented by 1516 auxiliary subclasses of the auxiliary class pcimActionAuxClass. 1518 These auxiliary classes are attached directly to instances of 1519 pcimRuleActionAssociation for rule-specific policy actions. For a 1520 reusable policy action, the pcimAction auxiliary subclass is attached to 1521 an instance of the class pcimPolicyInstance (which is presumably 1522 associated with a pcimRepository by DIT containment), and the 1523 pcimActionDN attribute (of this class) is used to reference the reusable 1524 pcimCondition instance. 1526 The class definition is as follows: 1528 ( NAME 'pcimRuleActionAssociation' 1529 DESC 'This class contains attributes characterizing the 1530 relationship between a policy rule and one of its 1531 policy actions.' 1532 SUP pcimPolicy 1533 MUST ( pcimActionOrder ) 1534 MAY ( pcimActionName $ pcimActionDN ) 1535 ) 1537 The pcimActionName attribute is used to define a user-friendly name of 1538 this action, and may be used as a naming attribute if desired. This 1539 attribute is defined as follows: 1541 ( 1542 NAME 'pcimActionName' 1543 DESC 'A user-friendly name for a policy action.' 1544 EQUALITY caseIgnoreMatch 1545 ORDERING caseIgnoreOrderingMatch 1546 SUBSTR caseIgnoreSubstringsMatch 1547 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1548 SINGLE-VALUE 1549 ) 1551 The pcimActionOrder attribute is an unsigned integer that is used to 1552 indicate the relative position of an action in a sequence of actions 1553 that are associated with a given policy rule. When this number is 1554 positive, it indicates a place in the sequence of actions to be 1555 performed, with smaller values indicating earlier positions in the 1556 sequence. If the value is zero, then this indicates that the order is 1557 irrelevant. Note that if two or more actions have the same non-zero 1558 value, they may be performed in any order as long as they are each 1559 performed in the correct place in the overall sequence of actions. This 1560 attribute is defined as follows: 1562 ( 1563 NAME 'pcimActionOrder' 1564 DESC 'An integer indicating the relative order of an action 1565 in the context of a policy rule.' 1566 EQUALITY integerMatch 1567 ORDERING integerOrderingMatch 1568 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1569 SINGLE-VALUE 1570 ) 1572 Note: if the value of the pcimActionOrder field is negative, then it 1573 SHOULD be treated as an error and any policy rule that refers to such an 1574 entry SHOULD be treated as being disabled. 1576 The pcimActionDN attribute is a DN that references a reusable policy 1577 action. It is defined as follows: 1579 ( 1580 NAME 'pcimActionDN' 1581 DESC 'A DN that references a reusable policy action.' 1582 EQUALITY distinguishedNameMatch 1583 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1584 SINGLE-VALUE 1585 ) 1587 A DIT content rule could be written to enable an instance of 1588 pcimRuleActionAssociation to have attached to it an instance of the 1589 auxiliary class pcimActionAuxClass, or one of its subclasses. This would 1590 be used to formalize the semantics of the PolicyActionInPolicyRule 1591 association. Specifically, this would be used to represent a rule- 1592 specific policy action [1]. 1594 Similarly, three separate DIT structure rules could be written. Each of 1595 these DIT structure rules would refer to a specific name form that 1596 defined two important semantics. First, each name form would identify 1597 one of the three possible naming attributes (i.e., pcimActionName, cn, 1598 and orderedCIMKeys) for the pcimRuleActionAssociation object class. 1599 Second, each name form would require that an instance of the 1600 pcimRuleActionAssociation class have as its superior an instance of the 1601 pcimRule class. This structure rule should also include a 1602 superiorStructureRule (see Note 2 at the beginning of section 5). 1604 5.7. The Auxiliary Class pcimConditionAuxClass 1606 The purpose of a policy condition is to determine whether or not the set 1607 of actions (contained in the pcimRule that the condition applies to) 1608 should be executed or not. This class defines the basic organizational 1609 semantics of a policy condition, as specified in [1]. Subclasses of this 1610 auxiliary class can be attached to instances of three other classes in 1611 the PCLS. When a subclass of this class is attached to an instance of 1612 pcimRuleConditionAssociation, or to an instance of pcimRule, it 1613 represents a rule-specific policy condition. When a subclass of this 1614 class is attached to an instance of pcimPolicyInstance, it represents a 1615 reusable policy condition. 1617 Since all of the classes to which subclasses of this auxiliary class may 1618 be attached are derived from the pcimPolicy class, the attributes of 1619 pcimPolicy will already be defined for the entries to which these 1620 subclasses attach. Thus, this class is derived directly from "top". 1622 The class definition is as follows: 1624 ( NAME 'pcimConditionAuxClass' 1625 DESC 'A class representing a condition to be evaluated in 1626 conjunction with a policy rule.' 1627 SUP top 1628 AUXILIARY 1629 ) 1631 5.8. The Auxiliary Class pcimTPCAuxClass 1633 The PCIM defines a time period class, PolicyTimePeriodCondition, to 1634 provide a means of representing the time periods during which a policy 1635 rule is valid, i.e., active. It also defines an aggregation, 1636 PolicyRuleValidityPeriod, so that time periods can be associated with a 1637 PolicyRule. The LDAP mapping also provides two classes, one for the 1638 time condition itself, and one for the aggregation. 1640 In the PCIM, the time period class is named PolicyTimePeriodCondition. 1641 However, the resulting name of the auxiliary class in this mapping 1642 (pcimTimePeriodConditionAuxClass) exceeds the length of a name that some 1643 directories can store. Therefore, the name has been shortened to 1644 pcimTPCAuxClass. 1646 The class definition is as follows: 1648 ( NAME 'pcimTPCAuxClass' 1649 DESC 'This provides the capability of enabling or disabling 1650 a policy rule according to a predetermined schedule.' 1651 SUP pcimConditionAuxClass 1652 AUXILIARY 1653 MAY ( pcimTPCTime $ pcimTPCMonthOfYearMask $ 1654 pcimTPCDayOfMonthMask $ pcimTPCDayOfWeekMask $ 1655 pcimTPCTimeOfDayMask $ pcimTPCLocalOrUtcTime ) 1656 ) 1658 The attributes of the pcimTPCAuxClass are defined as follows. 1660 The pcimTPCTime attribute represents the time period that a policy rule 1661 is enabled for. This attribute is defined as a string in [1] with a 1662 special format which defines a time period with a starting date and an 1663 ending date separated by a forward slash (�/�), as follows: 1665 yyyymmddThhmmss/yyyymmddThhmmss 1667 where the first date and time may be replaced with the string 1668 "THISANDPRIOR" or the second date and time may be replaced with the 1669 string "THISANDFUTURE". This attribute is defined as follows: 1671 ( 1672 NAME 'pcimTPCTime' 1673 DESC 'The start and end times on which a policy rule is 1674 valid.' 1675 EQUALITY caseIgnoreMatch 1676 ORDERING caseIgnoreOrderingMatch 1677 SUBSTR caseIgnoreSubstringsMatch 1678 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1679 SINGLE-VALUE 1680 ) 1682 The value of this attribute SHOULD be checked against its defined format 1683 (�yyyymmddThhmmss/yyyymmddThhmmss�, where the first and second date 1684 strings may be replaced with the strings �THISANDPRIOR� and 1685 �THISANDFUTURE�). If the value of this attribute does not conform to 1686 this syntax, then this SHOULD be considered an error and the policy rule 1687 SHOULD be treated as being disabled. 1689 The next four attributes (pcimTPCMonthOfYearMask, pcimTPCDayOfMonthMask, 1690 pcimTPCDayOfWeekMask, and pcimTPCTimeOfDayMask) are all defined as octet 1691 strings in [1]. However, the semantics of each of these attributes are 1692 contained in bit strings of various fixed lengths. Therefore, the PCLS 1693 uses a syntax of Bit String to represent each of them. The definition of 1694 these four attributes are as follows. 1696 The pcimTPCMonthOfYearMask attribute defines a 12-bit mask identifying 1697 the months of the year in which a policy rule is valid. The format is a 1698 bit string of length 12, representing the months of the year from 1699 January through December. The definition of this attribute is as 1700 follows: 1702 ( 1703 NAME 'pcimTPCMonthOfYearMask' 1704 DESC 'This identifies the valid months of the year for a 1705 policy rule using a 12-bit string that represents the 1706 months of the year from January through December.' 1707 EQUALITY bitStringMatch 1708 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1709 SINGLE-VALUE 1710 ) 1712 The value of this attribute SHOULD be checked against its defined 1713 format. If the value of this attribute does not conform to this syntax, 1714 then this SHOULD be considered an error and the policy rule SHOULD be 1715 treated as being disabled. 1717 The pcimTPCMonthOfDayMask attribute defines a mask identifying the days 1718 of the month on which a policy rule is valid. The format is a bit string 1719 of length 62. The first 31 positions represent the days of the month in 1720 ascending order, from day 1 to day 31. The next 31 positions represent 1721 the days of the month in descending order, from the last day to the day 1722 31 days from the end. The definition of this attribute is as follows: 1724 ( 1725 NAME 'pcimTPCDayOfMonthMask' 1726 DESC 'This identifies the valid days of the month for a 1727 policy rule using a 62-bit string. The first 31 1728 positions represent the days of the month in ascending 1729 order, and the next 31 positions represent the days of 1730 the month in descending order.' 1731 EQUALITY bitStringMatch 1732 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1733 SINGLE-VALUE 1734 ) 1736 The value of this attribute SHOULD be checked against its defined 1737 format. If the value of this attribute does not conform to this syntax, 1738 then this SHOULD be considered an error and the policy rule SHOULD be 1739 treated as being disabled. 1741 The pcimTPCDayOfWeekMask attribute defines a mask identifying the days 1742 of the week on which a policy rule is valid. The format is a bit string 1743 of length 7, representing the days of the week from Sunday through 1744 Saturday. The definition of this attribute is as follows: 1746 ( 1747 NAME 'pcimTPCDayOfWeekMask' 1748 DESC 'This identifies the valid days of the week for a 1749 policy rule using a 7-bit string. This represents 1750 the days of the week from Sunday through Saturday.' 1751 EQUALITY bitStringMatch 1752 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1753 SINGLE-VALUE 1754 ) 1756 The value of this attribute SHOULD be checked against its defined 1757 format. If the value of this attribute does not conform to this syntax, 1758 then this SHOULD be considered an error and the policy rule SHOULD be 1759 treated as being disabled. 1761 The pcimTPCTimeOfDayMask attribute defines the range of times at which a 1762 policy rule is valid. If the second time is earlier than the first, then 1763 the interval spans midnight. The format of the string is 1764 Thhmmss/Thhmmss. The definition of this attribute is as follows: 1766 ( 1767 NAME 'pcimTPCTimeOfDayMask' 1768 DESC 'This identifies the valid range of times for a policy 1769 using the format Thhmmss/Thhmmss.' 1770 EQUALITY caseIgnoreMatch 1771 ORDERING caseIgnoreOrderingMatch 1772 SUBSTR caseIgnoreSubstringsMatch 1773 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 1774 SINGLE-VALUE 1775 ) 1777 The value of this attribute SHOULD be checked against its defined 1778 format. If the value of this attribute does not conform to this syntax, 1779 then this SHOULD be considered an error and the policy rule SHOULD be 1780 treated as being disabled. 1782 Finally, the pcimTPCLocalOrUtcTime attribute is used to choose between 1783 local or UTC time representation. This is mapped as a simple integer 1784 syntax, with the value of 1 representing local time and the value of 2 1785 representing UTC time. The definition of this attribute is as follows: 1787 ( 1788 NAME 'pcimTPCLocalOrUtcTime' 1789 DESC 'This defines whether the times in this instance 1790 represent local (value=1) times or UTC (value=2) 1791 times.' 1792 EQUALITY integerMatch 1793 ORDERING integerOrderingMatch 1794 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1795 SINGLE-VALUE 1796 ) 1798 Note: if the value of the pcimTPCLocalOrUtcTime is not 1 or 2, then this 1799 SHOULD be considered an error and the policy rule SHOULD be disabled. 1801 5.9. The Auxiliary Class pcimConditionVendorAuxClass 1803 This class provides a general extension mechanism for representing 1804 policy conditions that have not been modeled with specific properties. 1805 Instead, its two properties are used to define the content and format of 1806 the condition, as explained below. This class is intended for vendor- 1807 specific extensions that are not amenable to using pcimCondition; 1808 standardized extensions SHOULD NOT use this class. 1810 The class definition is as follows: 1812 ( NAME 'pcimConditionVendorAuxClass' 1813 DESC 'A class that defines a registered means to describe a 1814 policy condition.' 1815 SUP pcimConditionAuxClass 1816 AUXILIARY 1817 MAY ( pcimVendorConstraintData $ 1818 pcimVendorConstraintEncoding ) 1819 ) 1821 The pcimVendorConstraintData attribute is a multi-valued attribute. It 1822 provides a general mechanism for representing policy conditions that 1823 have not been modeled as specific attributes. This information is 1824 encoded in a set of octet strings. The format of the octet strings is 1825 identified by the OID stored in the pcimVendorConstraintEncoding 1826 attribute. This attribute is defined as follows: 1828 ( 1829 NAME 'pcimVendorConstraintData' 1830 DESC 'Mechanism for representing constraints that have not 1831 been modeled as specific attributes. Their format is 1832 identified by the OID stored in the attribute 1833 pcimVendorConstraintEncoding.' 1834 EQUALITY octetStringMatch 1835 ORDERING octetStringOrderingMatch 1836 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1837 ) 1839 The pcimVendorConstraintEncoding attribute is used to identify the 1840 format and semantics for the pcimVendorConstraintData attribute. This 1841 attribute is defined as follows: 1843 ( 1844 NAME 'pcimVendorConstraintEncoding' 1845 DESC 'An OID identifying the format and semantics for the 1846 pcimVendorConstraintData for this instance.' 1847 EQUALITY objectIdentifierMatch 1848 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1849 SINGLE-VALUE 1850 ) 1852 5.10. The Auxiliary Class pcimActionAuxClass 1854 The purpose of a policy action is to execute one or more operations that 1855 will affect network traffic and/or systems, devices, etc. in order to 1856 achieve a desired policy state. This class is used to represent an 1857 action to be performed as a result of a policy rule whose condition 1858 clause was satisfied. 1860 Subclasses of this auxiliary class can be attached to instances of three 1861 other classes in the PCLS. When a subclass of this class is attached to 1862 an instance of pcimRuleActionAssociation, or to an instance of pcimRule, 1863 it represents a rule-specific policy action. When a subclass of this 1864 class is attached to an instance of pcimPolicyInstance, it represents a 1865 reusable policy action. 1867 Since all of the classes to which subclasses of this auxiliary class may 1868 be attached are derived from the pcimPolicy class, the attributes of the 1869 pcimPolicy class will already be defined for the entries to which these 1870 subclasses attach. Thus, this class is derived directly from "top". 1872 The class definition is as follows: 1874 ( NAME 'pcimActionAuxClass' 1875 DESC 'A class representing an action to be performed as a 1876 result of a policy rule.' 1877 SUP top 1878 AUXILIARY 1879 ) 1881 5.11. The Auxiliary Class pcimActionVendorAuxClass 1883 The purpose of this class is to provide a general extension mechanism 1884 for representing policy actions that have not been modeled with specific 1885 properties. Instead, its two properties are used to define the content 1886 and format of the action, as explained below. 1888 As its name suggests, this class is intended for vendor-specific 1889 extensions that are not amenable to using the standard pcimAction class. 1890 Standardized extensions SHOULD NOT use this class. 1892 The class definition is as follows: 1894 ( NAME 'pcimActionVendorAuxClass' 1895 DESC 'A class that defines a registered means to describe a 1896 policy action.' 1897 SUP pcimActionAuxClass 1898 AUXILIARY 1899 MAY ( pcimVendorActionData $ pcimVendorActionEncoding ) 1900 ) 1902 The pcimVendorActionData attribute is a multi-valued attribute. It 1903 provides a general mechanism for representing policy actions that have 1904 not been modeled as specific attributes. This information is encoded in 1905 a set of octet strings. The format of the octet strings is identified by 1906 the OID stored in the pcimVendorActionEncoding attribute. This attribute 1907 is defined as follows: 1909 ( 1910 NAME 'pcimVendorActionData' 1911 DESC ' Mechanism for representing policy actions that have 1912 not been modeled as specific attributes. Their format 1913 is identified by the OID stored in the attribute 1914 pcimVendorActionEncoding.' 1915 EQUALITY octetStringMatch 1916 ORDERING octetStringOrderingMatch 1917 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 1918 ) 1920 The pcimVendorActionEncoding attribute is used to identify the format 1921 and semantics for the pcimVendorActionData attribute. This attribute is 1922 defined as follows: 1924 ( 1925 NAME 'pcimVendorActionEncoding' 1926 DESC 'An OID identifying the format and semantics for the 1927 pcimVendorActionData attribute of this instance.' 1928 EQUALITY objectIdentifierMatch 1929 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1930 SINGLE-VALUE 1931 ) 1933 5.12. The Class pcimPolicyInstance 1935 This class is not defined in the PCIM. Its role is to serve as a 1936 structural class to which auxiliary classes representing policy 1937 information are attached when the information is reusable. For 1938 auxiliary classes representing policy conditions and policy actions, 1939 there are alternative structural classes that may be used. See Section 1940 4.4 for a complete discussion of reusable policy conditions and actions, 1941 and of the role that this class plays in how they are represented. 1943 The class definition is as follows: 1945 ( NAME 'pcimPolicyInstance' 1946 DESC 'A structural class to which aux classes containing 1947 reusable policy information can be attached.' 1948 SUP pcimPolicy 1949 MAY ( pcimPolicyInstanceName ) 1950 ) 1952 The pcimPolicyInstanceName attribute is used to define a user-friendly 1953 name of this class, and may be used as a naming attribute if desired. It 1954 is defined as follows: 1956 ( NAME 'pcimPolicyInstanceName' 1957 DESC 'The user-friendly name of this policy instance.' 1958 EQUALITY caseIgnoreMatch 1959 ORDERING caseIgnoreOrderingMatch 1960 SUBSTR caseIgnoreSubstringsMatch 1961 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1962 SINGLE-VALUE 1963 ) 1965 A DIT content rule could be written to enable an instance of 1966 pcimPolicyInstance to have attached to it either instances of one or 1967 more of the auxiliary object classes pcimConditionAuxClass and 1968 pcimActionAuxClass. Since these semantics do not include specifying any 1969 properties, the content rule would not need to specify any attributes. 1970 Note that other content rules could be defined to enable other policy- 1971 related auxiliary classes to be attached to pcimPolicyInstance. 1973 Similarly, three separate DIT structure rules could be written. Each of 1974 these DIT structure rules would refer to a specific name form that 1975 defined two important semantics. First, each name form would identify 1976 one of the three possible naming attributes (i.e., 1977 pcimPolicyInstanceName, cn, and orderedCIMKeys) for this object class. 1978 Second, each name form would require that an instance of the 1979 pcimPolicyInstance class have as its superior an instance of the 1980 pcimRepository class. This structure rule SHOULD also include a 1981 superiorStructureRule (see Note 2 at the beginning of section 5). 1983 5.13. The Auxiliary Class pcimElementAuxClass 1985 This class introduces no additional attributes, beyond those defined in 1986 the class pcimPolicy from which it is derived. Its role is to "tag" an 1987 instance of a class defined outside the realm of policy information as 1988 represented by PCIM as being nevertheless relevant to a policy 1989 specification. This tagging can potentially take place at two levels: 1991 - Every instance to which pcimElementAuxClass is attached becomes 1992 an instance of the class pcimPolicy, since pcimElementAuxClass is a 1993 subclass of pcimPolicy. Searching for object class="pcimPolicy" 1994 will return the instance. (As noted earlier, this approach does 1995 NOT work for some directory implementations. To accommodate these 1996 implementations, policy-related entries SHOULD be tagged with the 1997 pcimKeyword "POLICY".) 1999 - With the pcimKeywords attribute that it inherits from pcimPolicy, 2000 an instance to which pcimElementAuxClass is attached can be 2001 tagged as being relevant to a particular type or category of 2002 policy information, using standard keywords, administrator-defined 2003 keywords, or both. 2005 The class definition is as follows: 2007 ( NAME 'pcimElementAuxClass' 2008 DESC 'An auxiliary class used to tag instances of classes 2009 defined outside the realm of policy as relevant to a 2010 particular policy specification.' 2011 SUP pcimPolicy 2012 AUXILIARY 2013 ) 2015 5.14. The Three Policy Repository Classes 2017 These classes provide a container for reusable policy information, such 2018 as reusable policy conditions and/or reusable policy actions. This 2019 document is concerned with mapping just the properties that appear in 2020 these classes. Conceptually, this may be thought of as a special 2021 location in the DIT where policy information may reside. 2023 To maximize flexibility, the pcimRepository class is defined as 2024 abstract. A subclass pcimRepositoryAuxClass provides for auxiliary 2025 attachment to another entry, while a structural subclass 2026 pcimRepositoryInstance is available to represent a policy repository as 2027 a standalone entry. 2029 The definition for the pcimRepository class is as follows: 2031 ( NAME 'pcimRepository' 2032 DESC 'A container for reusable policy information.' 2033 SUP dlm1AdminDomain 2034 ABSTRACT 2035 MAY ( pcimRepositoryName ) 2036 ) 2038 The pcimRepositoryName attribute is used to define a user-friendly name 2039 of this class, and may be used as a naming attribute if desired. It is 2040 defined as follows: 2042 ( NAME 'pcimRepositoryName' 2043 DESC 'The user-friendly name of this policy repository.' 2044 EQUALITY caseIgnoreMatch 2045 ORDERING caseIgnoreOrderingMatch 2046 SUBSTR caseIgnoreSubstringsMatch 2047 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 2048 SINGLE-VALUE 2049 ) 2051 The two subclasses of pcimRepository are defined as follows. First, the 2052 pcimRepositoryAuxClass is an auxiliary class that can be used to 2053 aggregate reusable policy information. It is defined as follows: 2055 ( NAME 'pcimRepositoryAuxClass' 2056 DESC 'An auxiliary class that can be used to aggregate 2057 reusable policy information.' 2058 SUP pcimRepository 2059 AUXILIARY 2060 ) 2062 In cases where structural classes are needed instead of an auxiliary 2063 class, the pcimRepositoryInstance class is a structural class that can 2064 be used to aggregate reusable policy information. It is defined as 2065 follows: 2067 ( NAME 'pcimRepositoryInstance' 2068 DESC 'A structural class that can be used to aggregate 2069 reusable policy information.' 2070 SUP pcimRepository 2071 STRUCTURAL 2072 ) 2074 Three separate DIT structure rules could be written for this class. Each 2075 of these DIT structure rules would refer to a specific name form that 2076 enabled an instance of the pcimRepository class to be named under any 2077 superior using one of the three possible naming attributes (i.e., 2078 pcimRepositoryName, cn, and orderedCIMKeys). This structure rule SHOULD 2079 also include a superiorStructureRule (see Note 2 at the beginning of 2080 section 5). 2082 5.15. The Auxiliary Class pcimSubtreesPtrAuxClass 2084 This auxiliary class provides a single, multi-valued attribute that 2085 references a set of objects that are at the root of DIT subtrees 2086 containing policy-related information. By attaching this attribute to 2087 instances of various other classes, a policy administrator has a 2088 flexible way of providing an entry point into the directory that allows 2089 a client to locate and retrieve the policy information relevant to it. 2091 It is intended that these entries are placed in the DIT such that well- 2092 known DNs can be used to reference a well-known structural entry that 2093 has the pcimSubtreesPtrAuxClass attached to it. In effect, this defines 2094 a set of entry points. Each of these entry points can contain and/or 2095 reference all related policy entries for any well-known policy domains. 2096 The pcimSubtreesPtrAuxClass functions as a tag to identify portions of 2097 the DIT that contain policy information. 2099 This object does not provide the semantic linkages between individual 2100 policy objects, such as those between a policy group and the policy 2101 rules that belong to it. Its only role is to enable efficient bulk 2102 retrieval of policy-related objects, as described in Section 4.5. 2104 Once the objects have been retrieved, a directory client can determine 2105 the semantic linkages by following references contained in multi-valued 2106 attributes, such as pcimRulesAuxContainedSet. 2108 Since policy-related objects will often be included in the DIT subtree 2109 beneath an object to which this auxiliary class is attached, a client 2110 SHOULD request the policy-related objects from the subtree under the 2111 object with these references at the same time that it requests the 2112 references themselves. 2114 Since clients are expected to behave in this way, the policy 2115 administrator SHOULD make sure that this subtree does not contain so 2116 many objects unrelated to policy that an initial search done in this way 2117 results in a performance problem. The pcimSubtreesPtrAuxClass SHOULD 2118 NOT be attached to the partition root for a large directory partition 2119 containing a relatively few number of policy-related objects along with 2120 a large number of objects unrelated to policy (again, �policy� here 2121 refers to the PCIM, not the X.501, definition and use of �policy�). A 2122 better approach would be to introduce a container object immediately 2123 below the partition root, attach pcimSubtreesPtrAuxClass to this 2124 container object, and then place all of the policy-related objects in 2125 that subtree. 2127 The class definition is as follows: 2129 ( NAME 'pcimSubtreesPtrAuxClass' 2130 DESC 'An auxiliary class providing DN references to roots of 2131 DIT subtrees containing policy-related objects.' 2132 SUP top 2133 AUXILIARY 2134 MAY ( pcimSubtreesAuxContainedSet ) 2135 ) 2137 The attribute pcimSubtreesAuxContainedSet provides an unordered set of 2138 DN references to instances of one or more objects under which policy- 2139 related information is present. The objects referenced may or may not 2140 themselves contain policy-related information. The attribute definition 2141 is as follows: 2143 ( 2144 NAME 'pcimSubtreesAuxContainedSet' 2145 DESC 'DNs of objects that serve as roots for DIT subtrees 2146 containing policy-related objects.' 2147 EQUALITY distinguishedNameMatch 2148 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2149 ) 2151 Note that the cn attribute does NOT need to be defined for this class. 2152 This is because an auxiliary class is used as a means to collect common 2153 attributes and treat them as properties of an object. A good analogy is 2154 a #include file, except that since an auxiliary class is a class, all 2155 the benefits of a class (e.g., inheritance) can be applied to an 2156 auxiliary class. 2158 5.16. The Auxiliary Class pcimGroupContainmentAuxClass 2160 This auxiliary class provides a single, multi-valued attribute that 2161 references a set of pcimGroups. By attaching this attribute to 2162 instances of various other classes, a policy administrator has a 2163 flexible way of providing an entry point into the directory that allows 2164 a client to locate and retrieve the pcimGroups relevant to it. 2166 As is the case with pcimRules, a policy administrator might have several 2167 different references to a pcimGroup in the overall directory structure. 2168 The pcimGroupContainmentAuxClass is the mechanism that makes it possible 2169 for the policy administrator to define all these different references. 2171 The class definition is as follows: 2173 ( NAME 'pcimGroupContainmentAuxClass' 2174 DESC 'An auxiliary class used to bind pcimGroups to an 2175 appropriate container object.' 2176 SUP top 2177 AUXILIARY 2178 MAY ( pcimGroupsAuxContainedSet ) 2179 ) 2181 The attribute pcimGroupsAuxContainedSet provides an unordered set of 2182 references to instances of one or more pcimGroups associated with the 2183 instance of a structural class to which this attribute has been 2184 appended. 2186 The attribute definition is as follows: 2188 ( 2189 NAME 'pcimGroupsAuxContainedSet' 2190 DESC 'DNs of pcimGroups associated in some way with the 2191 instance to which this attribute has been appended.' 2192 EQUALITY distinguishedNameMatch 2193 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2194 ) 2196 Note that the cn attribute does NOT have to be defined for this class 2197 for the same reasons as those given for the pcimSubtreesPtrAuxClass in 2198 section 5.15. 2200 5.17. The Auxiliary Class pcimRuleContainmentAuxClass 2202 This auxiliary class provides a single, multi-valued attribute that 2203 references a set of pcimRules. By attaching this attribute to instances 2204 of various other classes, a policy administrator has a flexible way of 2205 providing an entry point into the directory that allows a client to 2206 locate and retrieve the pcimRules relevant to it. 2208 A policy administrator might have several different references to a 2209 pcimRule in the overall directory structure. For example, there might 2210 be references to all pcimRules for traffic originating in a particular 2211 subnet from a directory entry that represents that subnet. At the same 2212 time, there might be references to all pcimRules related to a particular 2213 DiffServ setting from an instance of a pcimGroup explicitly introduced 2214 as a container for DiffServ-related pcimRules. The 2215 pcimRuleContainmentAuxClass is the mechanism that makes it possible for 2216 the policy administrator to define all these separate references. 2218 The class definition is as follows: 2220 ( NAME 'pcimRuleContainmentAuxClass' 2221 DESC 'An auxiliary class used to bind pcimRules to an 2222 appropriate container object.' 2223 SUP top 2224 AUXILIARY 2225 MAY ( pcimRulesAuxContainedSet ) 2226 ) 2228 The attribute pcimRulesAuxContainedSet provides an unordered set of 2229 references to one or more instances of pcimRules associated with the 2230 instance of a structural class to which this attribute has been 2231 appended. The attribute definition is as follows: 2233 ( 2234 NAME 'pcimRulesAuxContainedSet' 2235 DESC 'DNs of pcimRules associated in some way with the 2236 instance to which this attribute has been appended.' 2237 EQUALITY distinguishedNameMatch 2238 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2239 ) 2241 The cn attribute does NOT have to be defined for this class for the same 2242 reasons as those given for the pcimSubtreesPtrAuxClass in section 5.15. 2244 6. Extending the Classes Defined in This Document 2246 The following subsections provide general guidance on how to create a 2247 domain-specific schema derived from this document, discuss how the 2248 vendor classes in the PCLS should be used, and explain how 2249 policyTimePeriodConditions are related to other policy conditions. 2251 6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 2253 In Section 4.4, there is a discussion of how, by representing policy 2254 conditions and policy actions as auxiliary classes in a schema, the 2255 flexibility is retained to instantiate a particular condition or action 2256 as either rule-specific or reusable. This flexibility is lost if a 2257 condition or action class is defined as structural rather than 2258 auxiliary. For standardized schemata, this document specifies that 2259 domain-specific information MUST be expressed in auxiliary subclasses of 2260 pcimConditionAuxClass and pcimActionAuxClass. It is RECOMMENDED that 2261 non-standardized schemata follow this practice as well. 2263 6.2. Using the Vendor Policy Attributes 2265 As discussed Section 5.9, the attributes pcimVendorConstraintData and 2266 pcimVendorConstraintEncoding are included in the 2267 pcimConditionVendorAuxClass to provide a mechanism for representing 2268 vendor-specific policy conditions that are not amenable to being 2269 represented with the pcimCondition class (or its subclasses). The 2270 attributes pcimVendorActionData and pcimVendorActionEncoding in the 2271 pcimActionVendorAuxClass class play the same role with respect to 2272 actions. This enables interoperability between different vendors who 2273 could not otherwise interoperate. 2275 For example, imagine a network composed of access devices from vendor A, 2276 edge and core devices from vendor B, and a policy server from vendor C. 2277 It is desirable for this policy server to be able to configure and 2278 manage all of the devices from vendors A and B. Unfortunately, these 2279 devices will in general have little in common (e.g., different 2280 mechanisms, different ways for controlling those mechanisms, different 2281 operating systems, different commands, and so forth). The extension 2282 conditions provide a way for vendor-specific commands to be encoded as 2283 octet strings, so that a single policy server can commonly manage 2284 devices from different vendors. 2286 6.3. Using Time Validity Periods 2288 Time validity periods are defined as an auxiliary subclass of 2289 pcimConditionAuxClass, called pcimTPCAuxClass. This is to allow their 2290 inclusion in the AND/OR condition definitions for a pcimRule. Care 2291 should be taken not to subclass pcimTPCAuxClass to add domain-specific 2292 condition properties. 2294 For example, it would be incorrect to add IPsec- or QoS-specific 2295 condition properties to the pcimTPCAuxClass class, just because IPsec or 2296 QoS includes time in its condition definition. The correct subclassing 2297 would be to create IPsec or QoS-specific subclasses of 2298 pcimConditionAuxClass and then combine instances of these domain- 2299 specific condition classes with the appropriate validity period 2300 criteria. This is accomplished using the AND/OR association capabilities 2301 for policy conditions in pcimRules. 2303 7. Security Considerations 2305 The PCLS, presented in this document, provides a mapping of the object- 2306 oriented model for describing policy information (PCIM) into a data 2307 model that forms the basic framework for describing the structure of 2308 policy data, in the case where the policy repository takes the form of 2309 an LDAP-accessible directory. 2311 PCLS is not intended to represent any particular system design or 2312 implementation. PCLS is not directly useable in a real world system, 2313 without the discipline-specific mappings that are works in progress in 2314 the Policy Framework Working Group of the IETF. 2316 These other derivative documents, which use PCIM and its discipline- 2317 specific extensions as a base, will need to convey more specific 2318 security considerations (refer to RFC3060 for more information.) 2320 The reason that PCLS, as defined here, is not representative of any 2321 real-world system, is that its object classes were designed to be 2322 independent of any specific discipline, or policy domain. For example, 2323 DiffServ and IPsec represent two different policy domains. Each document 2324 that extends PCIM to one of these domains will derive subclasses from 2325 the classes and relationships defined in PCIM, in order to represent 2326 extensions of a generic model to cover specific technical domains. 2328 PCIM-derived documents will thus subclass the PCIM classes into classes 2329 specific to each technical policy domain (QOS, IPsec, etc.), which will, 2330 in turn, be mapped, to directory-specific schemata consistent with the 2331 PCLS documented here. 2333 Even though discipline-specific security requirements are not 2334 appropriate for PCLS, specific security requirements MUST be defined for 2335 each operational real-world application of PCIM. Just as there will be 2336 a wide range of operational, real-world systems using PCIM, there will 2337 also be a wide range of security requirements for these systems. Some 2338 operational, real-world systems that are deployed using PCLS may have 2339 extensive security requirements that impact nearly all object classes 2340 utilized by such a system, while other systems' security requirements 2341 might have very little impact. 2343 The derivative documents, discussed above, will create the context for 2344 applying operational, real-world, system-level security requirements 2345 against the various models that derive from PCIM, consistent with PCLS. 2347 In some real-world scenarios, the values associated with certain 2348 properties, within certain instantiated object classes, may represent 2349 information associated with scarce, and/or costly (and therefore 2350 valuable) resources. It may be the case that these values must not be 2351 disclosed to, or manipulated by, unauthorized parties. 2353 Since this document forms the basis for the representation of a policy 2354 data model in a specific format (an LDAP-accessible directory), it is 2355 herein appropriate to reference the data model-specific tools and 2356 mechanisms that are available for achieving the authentication and 2357 authorization implicit in a requirement that restricts read and/or read- 2358 write access to these values stored in a directory. 2360 LDAP-specific authentication and authorization tools and mechanisms are 2361 found in the following standards track documents, which are appropriate 2362 for application to the management of security applied to policy data 2363 models stored in an LDAP-accessible directory: 2365 - RFC 2829 (Authentication Methods for LDAP) 2366 - RFC 2830 (Lightweight Directory Access Protocol (v3): Extension 2367 for Transport Layer Security) 2369 Any identified security requirements that are not dealt with in the 2370 appropriate discipline-specific information model documents, or in this 2371 document, MUST be dealt with in the derivative data model documents 2372 which are specific to each discipline. 2374 8. Intellectual Property 2376 The IETF takes no position regarding the validity or scope of any 2377 intellectual property or other rights that might be claimed to pertain 2378 to the implementation or use of the technology described in this 2379 document or the extent to which any license under such rights might or 2380 might not be available; neither does it represent that it has made any 2381 effort to identify any such rights. Information on the IETF's 2382 procedures with respect to rights in standards-track and standards- 2383 related documentation can be found in BCP-11. 2385 Copies of claims of rights made available for publication and any 2386 assurances of licenses to be made available, or the result of an attempt 2387 made to obtain a general license or permission for the use of such 2388 proprietary rights by implementers or users of this specification can be 2389 obtained from the IETF Secretariat. 2391 The IETF invites any interested party to bring to its attention any 2392 copyrights, patents or patent applications, or other proprietary rights 2393 that may cover technology that may be required to practice this 2394 standard. Please address the information to the IETF Executive 2395 Director. 2397 9. Acknowledgments 2399 We would like to thank Kurt Zeilenga, Roland Hedburg, and Steven Legg 2400 for doing a review of this document and making many helpful suggestions 2401 and corrections. 2403 Several of the policy classes in this model first appeared in early IETF 2404 drafts on IPsec policy and QoS policy. The authors of these drafts were 2405 Partha Bhattacharya, Rob Adams, William Dixon, Roy Pereira, Raju Rajan, 2406 Jean-Christophe Martin, Sanjay Kamat, Michael See, Rajiv Chaudhury, 2407 Dinesh Verma, George Powers, and Raj Yavatkar. 2409 This document is closely aligned with the work being done in the 2410 Distributed Management Task Force (DMTF) Policy and Networks working 2411 groups. We would especially like to thank Lee Rafalow, Glenn Waters, 2412 David Black, Michael Richardson, Mark Stevens, David Jones, Hugh Mahon, 2413 Yoram Snir, and Yoram Ramberg for their helpful comments. 2415 10. References 2417 [1] Moore, B., and E. Ellesson, J. Strassner, A. Westerinen "Policy 2418 Core Information Model -- Version 1 Specification", RFC 3060, 2419 February 2001. 2421 [2] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight 2422 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2423 2252, December 1997. 2425 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2426 Levels", BCP 14, RFC 2119, March 1997. 2428 [4] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 2429 Standards Process", BCP 11, RFC 2028, October 1996. 2431 [5] The Directory: Models. ITU-T Recommendation X.501, 2001. 2433 [6] Strassner, J., policy architecture BOF presentation, 42nd IETF 2434 Meeting, Chicago, Illinois, October 1998. Minutes of this BOF are 2435 available at the following location: 2436 http://www.ietf.org/proceedings/98aug/index.html. 2438 [7] DMTF web site, http://www.dmtf.org. 2440 [8] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for 2441 Policy-based Admission Control", RFC 2753, January 2000. 2443 [9] Distributed Management Task Force, Inc., "Common Information 2444 Model (CIM) Specification", Version 2.2, June 14, 1999. This 2445 document is available on the following DMTF web page: 2446 http://www.dmtf.org/standards/cim_spec_v22/ 2448 [10] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the 2449 CIM v2.5 Core Information Model", June 5, 2001. This document 2450 is available on the following DMTF web page: 2451 http://www.dmtf.org/var/release/DEN/DSP0123.pdf 2453 [11] Wahl, M., " A Summary of the X.500(96) User Schema for use with 2454 LDAPv3", RFC 2256, December 1997. 2456 [12] The Directory: Selected Attribute Types. ITU-T Recommendation 2457 X.520, 2001. 2459 [13] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, �Authentication 2460 Methods for LDAP�, RFC 2829, May 2000 2462 [14] J. Hodges, R. Morgan, M. Wahl, �Lightweight Directory Access 2463 Protocol (v3): Extension for Transport Layer Security�, RFC 2830, 2464 May 2000. 2466 [15] K. Zeilenga, ed., �LDAPv3: A Collection of User Schema�, 2467 2469 11. Authors' Addresses 2471 John Strassner 2472 Intelliden Corporation 2473 90 South Cascade Avenue 2474 Colorado Springs, CO 80903 2475 Phone: +1.719.785.0648 2476 Fax: +1.719.785.0644 2477 E-mail: john.strassner@intelliden.com 2479 Ed Ellesson 2480 LongBoard, Inc. 2481 2505 Meridian Pkwy, #100 2482 Durham, NC 27713 2483 Phone: +1 919-361-3230 2484 E-mail: eellesson@lboard.com 2486 Bob Moore 2487 IBM Corporation, BRQA/502 2488 4205 S. Miami Blvd. 2489 Research Triangle Park, NC 27709 2490 Phone: +1 919-254-4436 2491 Fax: +1 919-254-6243 2492 E-mail: remoore@us.ibm.com 2494 Ryan Moats 2495 Lemur Networks, Inc. 2496 15621 Drexel Circle 2497 Omaha, NE 68135 2498 Phone: +1-402-894-9456 2499 E-mail: rmoats@lemurnetworks.net 2501 12. Full Copyright Statement 2503 Copyright (C) The Internet Society (2001). All Rights Reserved. 2505 This document and translations of it may be copied and furnished to 2506 others, and derivative works that comment on or otherwise explain it or 2507 assist in its implementation may be prepared, copied, published and 2508 distributed, in whole or in part, without restriction of any kind, 2509 provided that the above copyright notice and this paragraph are included 2510 on all such copies and derivative works. However, this document itself 2511 may not be modified in any way, such as by removing the copyright notice 2512 or references to the Internet Society or other Internet organizations, 2513 except as needed for the purpose of developing Internet standards in 2514 which case the procedures for copyrights defined in the Internet 2515 Standards process must be followed, or as required to translate it into 2516 languages other than English. 2518 The limited permissions granted above are perpetual and will not be 2519 revoked by the Internet Society or its successors or assigns. 2521 This document and the information contained herein is provided on an "AS 2522 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2523 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2524 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2525 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2526 FITNESS FOR A PARTICULAR PURPOSE. 2528 13. Appendix: Constructing the Value of orderedCIMKeys 2530 This appendix is non-normative, and is included in this document as a 2531 guide to implementers that wish to exchange information between CIM 2532 schemata and LDAP schemata. 2534 Within a CIM name space, the naming is basically flat; all instances are 2535 identified by the values of their key properties, and each combination 2536 of key values must be unique. A limited form of hierarchical naming is 2537 available in CIM, however, by using weak associations: since a weak 2538 association involves propagation of key properties and their values from 2539 the superior object to the subordinate one, the subordinate object can 2540 be thought of as being named "under" the superior object. Once they 2541 have been propagated, however, propagated key properties and their 2542 values function in exactly the same way that native key properties and 2543 their values do in identifying a CIM instance. 2545 The CIM mapping document [10] introduces a special attribute, 2546 orderedCIMKeys, to help map from the CIM_ManagedElement class to the 2547 LDAP class dlm1ManagedElement. This attribute SHOULD only be used in an 2548 environment where it is necessary to map between an LDAP-accessible 2549 directory and a CIM repository. For an LDAP environment, other LDAP 2550 naming attributes are defined (i.e., cn and a class-specific naming 2551 attribute) that SHOULD be used instead. 2553 The role of orderedCIMKeys is to represent the information necessary to 2554 correlate an entry in an LDAP-accessible directory with an instance in a 2555 CIM name space. Depending on how naming of CIM-related entries is 2556 handled in an LDAP directory, the value of orderedCIMKeys represents one 2557 of two things: 2559 - If the DIT hierarchy does not mirror the "weakness hierarchy" of 2560 the CIM name space, then orderedCIMKeys represents all the 2561 keys of the CIM instance, both native and propagated. 2562 - If the DIT hierarchy does mirror the "weakness hierarchy" of the 2563 CIM name space, then orderedCIMKeys may represent either all the 2564 keys of the instance, or only the native keys. 2566 Regardless of which of these alternatives is taken, the syntax of 2567 orderedCIMKeys is the same - a DirectoryString of the form 2569 .=[,=]* 2571 where the = elements are ordered by the names of the key 2572 properties, according to the collating sequence for US ASCII. The only 2573 spaces allowed in the DirectoryString are those that fall within a 2574 element. As with alphabetizing the key properties, the goal of 2575 suppressing the spaces is once again to make the results of string 2576 operations predictable. 2578 The values of the elements are derived from the various CIM 2579 syntaxes according to a grammar specified in [9].