idnits 2.17.1 draft-ietf-policy-core-schema-06.txt: -(2048): 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 is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 48 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 49 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 230 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([Policy], [10]), 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 259 has weird spacing: '...case is not s...' == Line 1989 has weird spacing: '...ository direc...' == Line 2042 has weird spacing: '... server will ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1999) is 8928 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Policy' on line 86 == Unused Reference: '6' is defined on line 2116, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2123, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2126, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2140, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2143, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2028 (ref. '6') (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 2252 (ref. '7') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' == Outdated reference: A later version (-08) exists of draft-ietf-policy-core-info-model-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. '11') -- Possible downref: Normative reference to a draft: ref. '12' == Outdated reference: A later version (-02) exists of draft-ietf-policy-req-01 -- Possible downref: Normative reference to a draft: ref. '13' -- No information found for draft-ietf-qos-policy-schema - is the name correct? -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-02) exists of draft-moats-ldap-dereference-match-01 -- Possible downref: Normative reference to a draft: ref. '16' Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Policy Framework Working Group J. Strassner 2 Internet-draft Cisco Systems 3 Category: Standards Track E. Ellesson 4 B. Moore 5 IBM Corporation 6 Ryan Moats 7 AT&T 8 November 1999 10 Policy Framework LDAP Core Schema 11 draft-ietf-policy-core-schema-06.txt 12 November 04, 1999 13:59 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (1999). All Rights Reserved. 38 Abstract 40 This document takes as its starting point the object-oriented 41 information model for representing policy information currently under 42 joint development in the Service Level Agreements (SLA) Policy working 43 group of the Distributed Management Task Force (DMTF) and in the 44 IETF's Policy Framework working group. The IETF document defining 45 this information model is the "Policy Framework Core Information 46 Model" [10]. This model defines two hierarchies of object classes: 47 structural classes representing policy information and control of 48 policies, and relationship classes that indicate how instances of the 49 structural classes are related to each other. In general, both of 50 these class hierarchies will need to be mapped to a particular data 51 store. 53 This draft defines the mapping of these information model classes to a 54 directory that uses LDAPv3 as its access protocol. When mapping to an 55 LDAP schema, the structural classes can be mapped more or less 56 directly. The relationship hierarchy, however, must be mapped to a 57 form suitable for directory implementation. Since this mapping of the 58 relationship classes could be done in a number of different ways, 59 there is the risk of non-interoperable implementations. To avoid this 60 possibility, this document provides a single mapping that all 61 implementations using an LDAP directory as their policy repository 62 SHALL use. 64 Classes are also added to the LDAP schema to improve the performance 65 of a client's interactions with an LDAP server when the client is 66 retrieving large amounts of policy-related information. These classes 67 exist only to optimize LDAP retrievals: there are no classes in the 68 information model that correspond to them. 70 The LDAP schema described in this document consists of six very 71 general classes: policy (an abstract class), policyGroup, policyRule, 72 policyConditionAuxClass, policyTimePeriodConditionAuxClass, and 73 policyActionAuxClass. The schema also contains two less general 74 classes: vendorPolicyConditionAuxClass and 75 vendorPolicyActionAuxClass. To achieve the mapping of the information 76 model's relationships, the schema contains two auxiliary classes: 77 policyGroupContainmentAuxClass and policyRuleContainmentAuxClass. 78 Capturing the distinction between rule-specific and reusable policy 79 conditions and policy actions introduces five other classes: 80 policyRuleConditionAssociation, policyRuleActionAssociation, 81 policyConditionInstance, policyActionInstance, and policyRepository. 82 Finally, the schema includes two classes policySubtreesPtrAuxClass and 83 policyElementAuxClass for optimizing LDAP retrievals. In all, 84 therefore, the schema contains 17 classes. 86 Within the context of this document, the term "Core [Policy] Schema" 87 is used to refer to the LDAP class definitions it contains. 89 Table of Contents 90 1. Introduction......................................................3 91 2. The Policy Core Information Model.................................5 92 3. Inheritance Hierarchy for the LDAP Core Policy Schema.............5 93 4. General Discussion of Mapping the Information Model to LDAP.......6 94 4.1. Summary of Class and Relationship Mappings...................7 95 4.2. Naming Attributes in the Core Schema.........................9 96 4.3. Rule-Specific and Reusable Conditions and Actions...........10 97 4.4. Condition Subjects and Targets..............................12 98 4.5. Location and Retrieval of Policy Objects in the Directory...14 99 4.5.1. Aliases and Other DIT-Optimization Techniques.............17 100 5. Class Definitions................................................18 101 5.1. The Abstract Class "policy".................................18 102 5.2. The Class policyGroup.......................................19 103 5.3. The Class policyRule........................................21 104 5.4. The Class policyRuleConditionAssociation....................24 105 5.5. The Class policyRuleActionAssociation.......................26 106 5.6. The Auxiliary Class policyConditionAuxClass.................28 107 5.7. The Auxiliary Class policyTimePeriodConditionAuxClass.......29 108 5.8. The Auxiliary Class vendorPolicyConditionAuxClass...........30 109 5.9. The Auxiliary Class policyActionAuxClass....................31 110 5.10. The Auxiliary Class vendorPolicyActionAuxClass.............31 111 5.11. The Class policyConditionInstance..........................32 112 5.12. The Class policyActionInstance.............................33 113 5.13. The Auxiliary Class policyElementAuxClass..................35 114 5.14. The Class policyRepository.................................35 115 5.15. The Auxiliary Class policySubtreesPtrAuxClass..............37 116 5.15.1. The Attribute policySubtreesAuxContainedSet..............38 117 5.16. The Auxiliary Class policyGroupContainmentAuxClass.........38 118 5.16.1. The Attribute policyGroupsAuxContainedSet................39 119 5.17. The Auxiliary Class policyRuleContainmentAuxClass..........39 120 5.17.1. The Attribute policyRulesAuxContainedSet.................40 121 6. Extending the Core Schema........................................40 122 6.1. Subclassing policyCondition and policyAction................40 123 6.2. Using the Vendor Policy Encoding Attributes.................40 124 6.3. Using Time Validity Periods.................................41 125 7. Security Considerations..........................................41 126 8. Intellectual Property............................................43 127 9. Acknowledgments..................................................43 128 10. References......................................................44 129 11. Authors' Addresses..............................................45 130 12. Full Copyright Statement........................................45 131 13. Appendix: Constructing the Value of the cimName Attribute......46 133 1. Introduction 135 This document takes as its starting point the object-oriented 136 information model for representing policy information currently under 137 joint development in the Service Level Agreements working group of the 138 Distributed Management Task Force (DMTF) and in the IETF's Policy 139 Framework working group. The IETF document defining this information 140 model is the "Policy Framework Core Information Model" [10]. This 141 model defines two hierarchies of object classes: structural classes 142 representing policy information and control of policies, and 143 relationship classes that indicate how instances of the structural 144 classes are related to each other. In general, both of these class 145 hierarchies will need to be mapped to a particular data store. 147 This draft defines the mapping of these information model classes to a 148 directory that uses LDAPv3 as its access protocol. Two types of 149 mappings are involved: 151 o For the structural classes in the information model, the mapping is 152 basically one-for-one: information model classes map to LDAP 153 classes, information model properties map to LDAP attributes. 155 o For the relationship classes in the information model, different 156 mappings are possible. In this document the information model's 157 relationship classes and their properties are mapped in three ways: 158 to LDAP auxiliary classes, to attributes representing DN pointers, 159 and to containment in the Directory Information Tree (DIT). 161 Implementations that use an LDAP directory as their policy repository 162 SHALL use the LDAP policy schema defined in this document. The use of 163 the information model defined in reference [10] as the starting point 164 enables the schema and the relationship class hierarchy to be 165 extensible, such that other types of policy repositories, such as 166 relational databases, can also use this information. 168 This document fits into the overall framework for representing, 169 deploying, and managing policies being developed by the Policy 170 Framework Working Group. The initial work to define this framework is 171 in reference [1]. Current work appears in references [12] through 172 [15]. More specifically, this document builds on the core policy 173 classes first introduced in references [2] and [3]. It also draws on 174 the work done for the Directory-enabled Networks (DEN) specification, 175 reference [4]. Work on the DEN specification by the DEN Ad-Hoc 176 Working Group itself has been completed. Further work to standardize 177 the models contained in it will be the responsibility of selected 178 working groups of the Common Information Model (CIM) effort in the 179 Distributed Management Task Force (DMTF). Standardization of the core 180 policy model in the DMTF is the responsibility of the SLA Policy 181 working group. 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119, reference 186 [5]. 188 2. The Policy Core Information Model 190 This document contains an LDAP schema representing the Policy Core 191 Information Model, which is defined in the companion document "Policy 192 Framework Core Information Model" [10]. Other documents may 193 subsequently be produced, with mappings of this same Core Information 194 Model to other storage technologies. Since the detailed semantics of 195 the Core Policy classes appear only in reference [10], that document 196 is a prerequisite for reading and understanding this document. 198 3. Inheritance Hierarchy for the LDAP Core Policy Schema 200 The following diagram illustrates the class hierarchy for the LDAP 201 Core Policy Schema classes: 203 top 204 | 205 +--policy (abstract) 206 | | 207 | +--policyGroup (structural) 208 | | 209 | +--policyRule (structural) 210 | | 211 | +--policyRuleConditionAssociation (structural) 212 | | 213 | +--policyRuleActionAssociation (structural) 214 | | 215 | +--policyConditionInstance (structural) 216 | | 217 | +--policyActionInstance (structural) 218 | | 219 | +--policyElementAuxClass (auxiliary) 220 | 221 +--policyConditionAuxClass (auxiliary) 222 | | 223 | +---policyTimePeriodConditionAuxClass (auxiliary) 224 | | 225 | +---vendorPolicyConditionAuxClass (auxiliary) 226 | 227 +--policyActionAuxClass (auxiliary) 228 | | 229 | +---vendorPolicyActionAuxClass (auxiliary) 230 | 231 +--policyRepository (structural) 232 | 233 +--policySubtreesPtrAuxClass (auxiliary) 234 | 235 +--policyGroupContainmentAuxClass (auxiliary) 236 | 237 +--policyRuleContainmentAuxClass (auxiliary) 239 Figure 1. LDAP Class Inheritance Hierarchy for the Core Policy 240 Schema 242 4. General Discussion of Mapping the Information Model to LDAP 244 The classes described in Section 5 below contain certain optimizations 245 for a directory that uses LDAP as its access protocol. One example of 246 this is the use of auxiliary classes to represent some of the 247 relationships defined in the information model. Other data stores 248 might need to implement these relationships differently. A second 249 example is the introduction of classes specifically designed to 250 optimize retrieval of large amounts of policy-related data from a 251 directory. This section discusses some general topics related to the 252 mapping from the information model to LDAP. 254 4.1. Summary of Class and Relationship Mappings 256 Eight of the classes in the LDAP Core Policy Schema come directly from 257 corresponding classes in the information model. Note that names of 258 classes begin with an upper case character in the information model 259 (although for CIM in particular, case is not significant in class and 260 property names), but with a lower case character in LDAP. 262 +---------------------------+-----------------------------------+ 263 | Information Model | LDAP Class | 264 +---------------------------+-----------------------------------+ 265 +---------------------------+-----------------------------------+ 266 | Policy | policy | 267 +---------------------------+-----------------------------------+ 268 | PolicyGroup | policyGroup | 269 +---------------------------+-----------------------------------+ 270 | PolicyRule | policyRule | 271 +---------------------------+-----------------------------------+ 272 | PolicyCondition | policyConditionAuxClass | 273 +---------------------------+-----------------------------------+ 274 | PolicyAction | policyActionAuxClass | 275 +---------------------------+-----------------------------------+ 276 | VendorPolicyCondition | vendorPolicyConditionAuxClass | 277 +---------------------------+-----------------------------------+ 278 | VendorPolicyAction | vendorPolicyActionAuxClass | 279 +---------------------------+-----------------------------------+ 280 | PolicyTimePeriodCondition | policyTimePeriodConditionAuxClass | 281 +---------------------------+-----------------------------------+ 282 Figure 2. Mapping of Information Model Classes to LDAP 284 The relationships in the information model map to DN-pointer 285 attributes or to Directory Information Tree (DIT) containment in LDAP. 286 Two of the DN-pointer attributes appear in auxiliary classes, which 287 allows each of them to represent several relationships from the 288 information model. 290 +--------------------------------+-----------------------------------+ 291 | Information Model Relationship | LDAP Attribute / Class | 292 +--------------------------------+-----------------------------------+ 293 +--------------------------------+-----------------------------------+ 294 | ResourceManagerCollectionPolicy| policyGroupsAuxContainedSet in | 295 | Group | policyGroupContainmentAuxClass | 296 +--------------------------------+-----------------------------------+ 297 | ResourceManagerPolicyGroup | policyGroupsAuxContainedSet in | 298 | | policyGroupContainmentAuxClass | 299 +--------------------------------+-----------------------------------+ 300 | PolicyGroupInPolicyGroup | policyGroupsAuxContainedSet in | 301 | | policyGroupContainmentAuxClass | 302 +--------------------------------+-----------------------------------+ 303 | ResourceManagerCollectionPolicy| policyRulesAuxContainedSet in | 304 | Rule | policyRuleContainmentAuxClass | 305 +--------------------------------+-----------------------------------+ 306 | ResourceManagerPolicyRule | policyRulesAuxContainedSet in | 307 | | policyRuleContainmentAuxClass | 308 +--------------------------------+-----------------------------------+ 309 | PolicyRuleInPolicyGroup | policyRulesAuxContainedSet in | 310 | | policyRuleContainmentAuxClass | 311 +--------------------------------+-----------------------------------+ 312 | ConditionInPolicyRule | DIT containment | 313 | | [+ policyConditionDN in | 314 | | policyRuleConditionAssociation] | 315 +--------------------------------+-----------------------------------+ 316 | ConditionSubject | conditionSubject in | 317 | | policyConditionAuxClass | 318 +--------------------------------+-----------------------------------+ 319 | ConditionTarget | conditionTarget in | 320 | | policyConditionAuxClass | 321 +--------------------------------+-----------------------------------+ 322 | ActionInPolicyRule | DIT containment | 323 | | [+ policyActionDN in | 324 | | policyRuleActionAssociation] | 325 +--------------------------------+-----------------------------------+ 326 | PolicyRuleValidityPeriod | policyRuleValidityPeriodList in | 327 | | policyRule | 328 +--------------------------------+-----------------------------------+ 329 | ConditionInPolicyRepository | DIT containment | 330 +--------------------------------+-----------------------------------+ 331 | ActionInPolicyRepository | DIT containment | 332 +--------------------------------+-----------------------------------+ 333 Figure 3. Mapping of Information Model Relationships to LDAP 335 Of the remaining classes in the LDAP Core Schema, two 336 (policyElementAuxClass, and policySubtreesPtrAuxClass) are included to 337 make navigation through the DIT and retrieval of the entries found 338 there more efficient. This topic is discussed in Section 4.4 below. 340 The remaining five classes in the LDAP Core Schema, 341 policyRuleConditionAssociation, policyRuleActionAssociation, 342 policyConditionInstance, policyActionInstance, and policyRepository 343 are all involved with the representation of policy conditions and 344 policy actions in an LDAP directory. This topic is discussed in 345 Section 4.3 below. 347 4.2. Naming Attributes in the Core Schema 349 Instances in a directory are identified by distinguished names (DNs), 350 which provide the same type of hierarchical organization that a file 351 system provides in a computer system. A distinguished name is a 352 sequence of relative distinguished names (RDNs), where an RDN provides 353 a unique identifier for an instance within the context of its 354 immediate superior, in the same way that a filename provides a unique 355 identifier for a file within the context of the folder in which it 356 resides. 358 To preserve maximum naming flexibility for policy administrators, each 359 of the structural classes defined in this schema has its own naming 360 attribute. (The naming attribute policyConditionName is used in two 361 structural class: policyRuleConditionAssociation and 362 policyConditionInstance. As discussed below in Section 4.3, these are 363 the two structural classes to which the auxiliary class 364 policyConditionAuxClass may be attached. The naming attribute 365 policyActionName is similarly associated with two structural classes.) 366 Since the naming attributes are different, a policy administrator can, 367 by using these attributes, guarantee that there will be no name 368 collisions between instances of different classes, even if the same 369 VALUE is assigned to the instances' respective naming attributes. 371 The X.500 attribute commonName (cn) is included as a MAY attribute in 372 the abstract class policy, and thus by inheritance in all of its 373 subclasses. In X.500, commonName typically functions as an RDN 374 attribute, for naming instances of such classes as X.500's person. 376 Finally, for implementations that expect to map between CIM and LDAP 377 representations of policy information, a second MAY attribute, 378 cimName, is also included in the abstract class "policy". The value 379 of this attribute is derived algorithmically from the values of two 380 properties that are already present in a CIM policy instance. See the 381 appendix of this document for a complete description of the algorithm. 383 Each of the Core Schema classes thus has three attributes suitable for 384 naming: cn, its own class-specific attribute, and cimName. Any of 385 these attributes MAY be used for naming an instance of a Core Schema 386 class. Consequently, implementations MUST be able to accommodate 387 instances named in any of these ways. 389 Note that since they are required ("MUST") attributes, the class- 390 specific naming attributes are always present in instances of their 391 respective classes, even if they are not being used for naming the 392 instances. In these cases the class-specific naming attributes may be 393 used for other purposes. Note also that "cn", the class-specific 394 naming attribute, and cimName SHOULD NOT be used together to form a 395 multi-part RDN, since support for multi-part RDNs is limited among 396 existing directory implementations. 398 4.3. Rule-Specific and Reusable Conditions and Actions 400 The Core Information Model [10] distinguishes between two types of 401 policy conditions and policy actions: ones associated with a single 402 policy rule, and ones that are reusable, in the sense that they may be 403 associated with more than one policy rule. There is no inherent 404 difference between a rule-specific condition or action and a reusable 405 one. There are, however, differences in how they are treated in a 406 policy repository. For example, it's natural to make the access 407 permissions for a rule-specific condition or action identical to those 408 for the rule itself. It's also natural for a rule-specific condition 409 or action to be removed from the policy repository at the same time 410 the rule is. With reusable conditions and actions, on the other hand, 411 access permissions and existence criteria must be expressible without 412 reference to a policy rule. 414 The preceding paragraph does not contain an exhaustive list of the 415 ways in which reusable and rule-specific conditions should be treated 416 differently. Its purpose is merely to justify making a semantic 417 distinction between rule-specific and reusable, and then reflecting 418 this distinction in the policy repository itself. 420 When the policy repository is realized in an LDAP-accessible 421 directory, the distinction between rule-specific and reusable 422 conditions and actions is realized via DIT containment. Figure 4 423 illustrates a policy rule Rule1 with one rule-specific condition CA 424 and one rule-specific action AB. Because the condition and action are 425 specific to Rule1, the auxiliary classes ca and ab that represent them 426 are attached, respectively, to the structural classes CA and AB. 427 These structural classes represent not the condition ca and action ab 428 themselves, but rather Rule1's ASSOCIATION to ca and ab. 430 Note that the existence dependency of a rule-specific condition or 431 action on its policy rule follows in this case from the semantics of 432 DNs. Note also that for directory implementations supporting subtree- 433 based access permissions, it's easy to indicate that parties with 434 access to Rule1 also have access to its condition and action. 436 +-----+ 437 |Rule1| 438 | | 439 +-----+ 440 * * 441 * * 442 **** **** 443 * * 444 * * 445 +-----+ +-----+ 446 |CA+ca| |AB+ab| 447 +-----+ +-----+ 449 +------------------------------+ 450 |LEGEND: | 451 | ***** DIT containment | 452 | + auxiliary attachment | 453 +------------------------------+ 455 Figure 4. Rule-Specific Policy Conditions and Actions 457 Figure 5 illustrates the same policy rule Rule1, but this time its 458 condition and action are reusable. The association classes CA and AB 459 are still present, and they are still DIT contained under Rule1. But 460 rather than having the auxiliary classes ca and ab attached to 461 themselves, CA and AB now contain DN pointers to other entries to 462 which these auxiliary classes are attached. These other entries, CIA 463 and AIB, are DIT contained under RepositoryX, which is an instance of 464 the class policyRepository. Because they are named under an instance 465 of policyRepository, ca and ab are clearly identified as reusable. 467 +-----+ +-------------+ 468 |Rule1| | RepositoryX | 469 | | | | 470 +-----+ +-------------+ 471 * * * * 472 * * * * 473 **** **** * * 474 * * * * 475 * +--+ * * 476 * |AB| +------+ * 477 * | -|-------->|AIB+ab| * 478 +--+ +--+ +------+ * 479 |CA| +------+ 480 | -|------------------------->|CIA+ca| 481 +--+ +------+ 483 +------------------------------+ 484 |LEGEND: | 485 | ***** DIT containment | 486 | + auxiliary attachment | 487 | ----> DN pointer | 488 +------------------------------+ 490 Figure 5. Reusable Policy Conditions and Actions 492 The classes policyConditionAuxClass and policyActionAuxClass do not 493 themselves represent actual conditions and actions: these are 494 introduced in their subclasses. What policyConditionAuxClass and 495 policyActionAuxClass do introduce are the semantics of being a policy 496 condition or a policy action. These are the semantics that all the 497 subclasses of policyCondition and policyAction inherit. Among these 498 semantics are those of representing either a rule-specific or a 499 reusable policy condition or policy action. 501 In order to preserve the ability to represent either a rule-specific 502 or a reusable condition or action, all the subclasses of 503 policyCondition and policyAction MUST also be auxiliary classes. 505 4.4. Condition Subjects and Targets 507 While it is not universally true, policy conditions often involve 508 three different types of roles: 510 o A subject seeking access to a target resource; 512 o A target resource to which a subject is seeking access; 514 o A resource manager responsible for managing access to the target 515 resource and/or managing some service (e.g., QoS) associated with 516 access to the target resource. 518 Some examples will help to clarify these types of roles. When a user 519 on the Internet wishes to communicate with a host located behind an 520 enterprise's firewall, the subject is the user, the target is the 521 host, and the resource manager is the firewall. Similarly, when a 522 user wishes to read a file, the subject is the user, the target is the 523 file, and the resource manager is the file manager of the system where 524 the file resides. 526 Sometimes these roles must be given a slightly different meaning in 527 order for them to apply. For example, if a router is either remarking 528 packets or giving them differential treatment based on the values in 529 the 5-tuples in their headers, we can say that the subject is (the 530 resource identified by) the source address and port number, the target 531 is (the resource identified by) the destination address and port 532 number, and the resource manager is the marking service on router 533 making the decisions. Here the subject isn't seeking access to the 534 target per se; the goal, instead, is to have a certain QoS for 535 communications between the subject and the target, where the subject's 536 right to communicate with the target is assumed to have already been 537 established. 539 In the CIM model, the PolicyCondition class has two optional 540 associations with the ManagedElement class: ConditionSubject and 541 ConditionTarget. These associations are optional for two reasons. 542 First, a particular condition may not have a subject, a target, or 543 both. Storage backups, for example, might be triggered whenever a 544 storage device reaches 90% of its capacity. The device approaching 545 its capacity is naturally regarded as the target of this rule, but 546 these is no subject in this case. 548 Secondly, a subject and/or a target for a policy condition may be 549 identified via properties of the PolicyCondition class itself, rather 550 than by reference to objects external to the policy condition. Thus 551 in the QoS example cited above, the subject and target might be 552 identified by comparing the values from a packet's header against 553 those in a Packet5Tuple property defined in an IP-specific subclass of 554 PolicyCondition. This would eliminate the need for object references 555 to additional objects representing the policy condition's subject and 556 target. The tradeoffs between a normalized representation of subjects 557 and targets and a denormalized one must be considered in each 558 application of the Core Model to a specific discipline. 560 In this document, the two associations ConditionSubject and 561 ConditionTarget are represented by two optional, multi-valued DN 562 pointers in the class policyCondition. Exactly what to do with an 563 entry reached via one of these pointers must be specified in a 564 subclass of PolicyCondition. 566 4.5. Location and Retrieval of Policy Objects in the Directory 568 When a Policy Consumer goes to an LDAP directory to retrieve the 569 policy object instances relevant to the Policy Targets it serves, it 570 is faced with two related problems: 572 o How does it locate and retrieve the directory entries that apply to 573 its Policy Targets? These entries may include instances of the 574 Core Schema classes, instances of domain-specific subclasses of 575 these classes, and instances of other classes modeling such 576 resources as user groups, interfaces, and address ranges. 578 o How does it retrieve the directory entries it needs in an efficient 579 manner, so that retrieval of policy information from the directory 580 does not become a roadblock to scalability? There are two facets 581 to this efficiency: retrieving only the relevant directory 582 entries, and retrieving these entries using as few LDAP calls as 583 possible. 585 The placement of objects in the Directory Information Tree (DIT) 586 involves considerations other than how the policy-related objects will 587 be retrieved by a Policy Consumer. Consequently, all that the Core 588 Schema can do is to provide a "toolkit" of classes to assist the 589 policy administrator as the DIT is being designed and built. A Policy 590 Consumer SHOULD be able to take advantage of any tools that the policy 591 administrator is able to build into the DIT, but it MUST be able to 592 use a less efficient means of retrieval if that is all it has 593 available to it. 595 The basic idea behind the LDAP optimization classes is a simple one: 596 make it possible for a Policy Consumer to retrieve all the policy- 597 related objects it needs, and only those objects, using as few LDAP 598 calls as possible. An important assumption underlying this approach 599 is that the policy administrator has sufficient control over the 600 underlying DIT structure to define subtrees for storing policy 601 information. If the policy administrator does not have this level of 602 control over DIT structure, a Policy Consumer can still retrieve the 603 policy-related objects it needs individually. But it will require 604 more LDAP access operations to do the retrieval in this way. 606 Figure 6 illustrates how LDAP optimization is accomplished. 608 +-----+ 609 ---------------->| A | 610 DN pointer to | | DN pointers to subtrees +---+ 611 starting object +-----+ +------------------------->| C | 612 | o--+----+ +---+ +---+ 613 | o--+------------->| B | / \ 614 +-----+ +---+ / \ 615 / \ / \ / ... \ 616 / \ / \ 617 / \ / ... \ 619 Figure 6. Using policySubtreesPtrAuxClass to Locate Policies 621 The Policy Consumer is configured initially with a DN pointer to some 622 entry in the DIT. The structural class of this entry is not 623 important; the Policy Consumer is interested only in the 624 policySubtreesPtrAuxClass attached to it. This auxiliary class 625 contains a multi-valued attribute with DN pointers to objects that 626 anchor subtrees containing policy-related objects of interest to the 627 Policy Consumer. Since policySubtreesPtrAuxClass is an auxiliary 628 class, it can be attached to an entry that the Policy Consumer would 629 need to access anyway - perhaps an entry containing initial 630 configuration settings for the Policy Consumer, or for a Policy Target 631 that uses the Policy Consumer. 633 Once it has retrieved the DN pointers, the Policy Consumer will direct 634 to each of the objects identified by them an LDAP request that all 635 entries in its subtree be evaluated against the selection criteria 636 specified in the request. The LDAP-enabled directory then returns all 637 entries in that subtree that satisfy the specified criteria. 639 The selection criteria always specify that object class = "policy". 640 Since all classes representing policy rules, policy conditions, and 641 policy actions, both in the Core Schema and in any domain-specific 642 schema derived from it, are subclasses of the abstract class policy, 643 this criterion evaluates to TRUE for all instances of these classes. 644 To accommodate special cases where a Policy Consumer needs to retrieve 645 objects that are not inherently policy-related (for example, an IP 646 address range object pointed to by a subclass of policyAction 647 representing the DHCP action "assign from this address range), the 648 auxiliary class policyElementAuxClass can be used to "tag" an entry, 649 so that it will be found by the selection criterion "object class = 650 policy". 652 The approach described in the preceding paragraph will not work for 653 certain directory implementations, because these implementations do 654 not support matching of auxiliary classes in the objectClass 655 attribute. For environments where these implementations are expected 656 to be present, the "tagging" of entries as relevant to policy can be 657 accomplished by inserting the special value "POLICY" into the list of 658 values contained in the policyKeywords attribute. 660 If a Policy Consumer needs only a subset of the policy-related objects 661 in the indicated subtrees, then it can be configured with additional 662 selection criteria based on the policyKeywords attribute defined in 663 the policy class. This attribute supports both standardized and 664 administrator-defined values. Thus a Policy Consumer could be 665 configured to request only those policy-related objects containing the 666 keywords "DHCP" and "Eastern US". 668 To optimize what is expected to be a typical case, the initial request 669 from the client includes not only the object to which its "seed" DN 670 pointer points, but also the subtree contained under this object. The 671 filter for searching this subtree is whatever the client is going to 672 use later to search the other subtrees: "object class = policy", 673 presence of the keyword "POLICY", or presence of a more specific 674 policyKeyword. 676 Returning to the example in Figure 6, we see that in the best case, a 677 Policy Consumer can get all the policy-related objects it needs, and 678 only these objects, with exactly three LDAP requests: one to its 679 starting object A to get the pointers to B and C, as well as the 680 policy-related objects it needs from the subtree under A, and then one 681 each to B and C to get all the policy-related objects that pass the 682 selection criteria with which it was configured. Once it has 683 retrieved all of these objects, the Policy Consumer can then traverse 684 their various DN pointers locally to understand the semantic 685 relationships among them. The Policy Consumer should also be prepared 686 to find a pointer to another subtree attached to any of the objects it 687 retrieves, and to follow this pointer first, before it follows any of 688 the semantically significant pointers it has received. This recursion 689 permits a structured approach to identifying related policies. In 690 Figure 6, for example, if the subtree under B includes departmental 691 policies and the one under C includes divisional policies, then there 692 might be a pointer from the subtree under C to an object D that roots 693 the subtree of corporate-level policies. 695 Since a Policy Consumer has no guarantee that the entity that 696 populates the directory won't use the policySubtreesPtrAuxClass, a 697 Policy Consumer SHOULD understand this class, SHOULD be capable of 698 retrieving and processing the entries in the subtrees it points to, 699 and SHOULD be capable of doing all of this recursively. The same 700 requirements apply to any other entity needing to retrieve policy 701 information from the directory. Thus a Policy Management Tool that 702 retrieves policy entries from the directory in order to perform 703 validation and conflict detection SHOULD also understand and be 704 capable of using the policySubtreesPtrAuxClass. All of these 705 requirements are "SHOULD"s rather than "MUST"s because an LDAP client 706 that doesn't implement them can still access and retrieve the 707 directory entries it needs . The process of doing so will just be 708 less efficient than it would have been if the client had implemented 709 these optimizations. 711 When it is serving as a tool for creating policy entries in the 712 directory, a Policy Management Tool SHOULD support creation of 713 policySubtreePtrAuxClass entries and their DN pointers. 715 4.5.1. Aliases and Other DIT-Optimization Techniques 717 Additional flexibility in DIT structure is available to the policy 718 administrator via LDAP aliasing. Figure 7 illustrates this 719 flexibility. 721 +-----+ 722 ---------------->| A | 723 DN pointer to | | DN pointers to subtrees +---+ 724 starting object +-----+ +------------------------->| C | 725 | o--+----+ +---+ +---+ 726 | o--+------------->| B | / \ 727 +-----+ +---+ / \ 728 / \ / \ / ... \ 729 / \ / \ 730 / \ / \ 731 +---+ / +------+ \ 732 | X |<***************************|aliasX| 733 +---+ +------+ 735 Figure 7. Addition of an Alias Object 737 Even if it is necessary to store a policy entry X in a directory 738 location separate from the other policy entries, batch retrieval using 739 policy subtrees can still be done. The administrator simply inserts 740 into one of the subtrees of policy entries an alias entry aliasX 741 pointing to the outlying entry X. When the Policy Consumer requests 742 all entries in the subtree under B, a response will be returned for 743 entry X, just as responses are returned for all the (non-alias) 744 entries that actually are in the subtree. 746 Since resolution of an alias to its true entry is handled entirely by 747 the LDAP directory, and is invisible to directory clients, Policy 748 Consumers need not do anything extra to support aliases. A Policy 749 Management Tool MAY make available to a policy administrator the 750 ability to create alias entries like the one in Figure 7. 752 In addition to aliases, there are several other techniques for 753 managing the placement of entries in the DIT and their retrieval by 754 directory clients. Among these other techniques are referrals, LDAP 755 URLs, attributes like seeAlso, and the extensible matching rule for 756 dereferencing DN pointers discussed in reference [16]. Discussion of 757 how these other techniques might be applied to policy-related entries 758 in a directory is outside the scope of this document. 760 5. Class Definitions 762 The semantics for the LDAP classes mapped directly from the 763 information model are detailed in reference [10]. Consequently, all 764 that this document presents for these classes is a bare specification 765 of the LDAP classes and attributes. More details are provided for the 766 attributes listed above in Figure 3, which realize in LDAP the 767 relationships defined in the information model. Finally, the classes 768 that exist only in the LDAP Core Schema are documented fully in this 769 document. 771 The formal language for specifying the classes, attributes, and DIT 772 structure and content rules is that defined in reference [7]. 774 Note: all attribute, object class, and name form OIDs, and all 775 structure rule integers, are place holders, and syntax OIDs in 776 definitions have been replaced by names for clarity. 778 5.1. The Abstract Class "policy" 780 The abstract class "policy" is a direct mapping of the abstract class 781 Policy from the Core Information Model. Four of the properties in 782 Policy map directly to attributes in the class "policy". The 783 remaining attribute of "policy" is constructed algorithmically from 784 two of the properties of the CIM class Policy. 786 NOTE: In the CIM model, the abstract class Policy is actually derived 787 from another abstract class, ManagedElement. The CIM class Policy 788 inherits the properties Caption and Description from ManagedElement, 789 but since the mapping of ManagedElement to an LDAP class falls outside 790 the scope of this document, these properties are mapped to 791 corresponding attributes of "policy" here. Similarly, the algorithm 792 for generating a value for the attribute cimName from the CIM 793 properties NamePath and SuperiorPath is specified here (in the 794 appendix), even though strictly speaking it belongs to the mapping of 795 ManagedElement. 797 The class value "policy" is also used as the mechanism for identifying 798 policy-related instances in the Directory Information Tree. An 799 instance of any class may be "tagged" with this class value by 800 attaching to it the auxiliary class policyElementAuxClass. 802 The class definition is as follows: 804 ( NAME 'policy' 805 DESC 'An abstract class with five attributes for describing 806 a policy-related instance.' 807 SUP top 808 ABSTRACT 809 MAY (cn $ cimName $ caption $ description $ policyKeywords) 810 ) 812 The attributes "cn" and "description" are defined in X.520. The 813 remaining two attributes are defined as: 815 ( NAME 'cimName' 816 DESC 'For mapping from CIM, a string constructed by taking 817 the string difference between the CIM properties 818 NamePath and SuperiorPath. See the Appendix to this 819 document for more on this algorithm, including an 820 example.' 821 SYNTAX IA5String 822 EQUALITY caseExactIA5Match 823 SINGLE-VALUE 824 ) 826 ( NAME 'caption' 827 DESC 'A one-line description of this policy-related object.' 828 SYNTAX IA5String 829 EQUALITY caseExactIA5Match 830 SINGLE-VALUE 831 ) 833 ( NAME 'policyKeywords' 834 DESC 'A set of keywords to assist directory clients in 835 locating the policy objects applicable to them. Each 836 value of the multi-valued attribute contains a single 837 keyword. Standard keyword values are listed in the 838 Policy Core Information Model document.' 839 SYNTAX IA5String 840 EQUALITY caseExactIA5Match 841 ) 843 5.2. The Class policyGroup 845 The class definition for policyGroup is as follows. Note that this 846 class definition does not include attributes to realize the 847 PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from 848 the object model, since a policyGroup object points to instances of 849 policyGroup and policyRule via, respectively, the pointer in 850 policyGroupContainmentAuxClass and the pointer in 851 policyRuleContainmentAuxClass. 853 ( NAME 'policyGroup' 854 DESC 'A container for either a set of related policyRules or 855 a set of related policyGroups.' 856 SUP policy 857 MUST (policyGroupName) 858 ) 860 The following DIT content rule indicates that an instance of 861 policyGroup may have attached to it either DN pointers to one or more 862 other policyGroups, or DN pointers to one or more policyRules. 864 ( 865 NAME 'policyGroupContentRule' 866 DESC 'shows what auxiliary classes go with this object' 867 AUX (policyGroupContainmentAuxClass $ 868 policyRuleContainmentAuxClass) 869 ) 871 The following DIT structure rules indicate that an instance of 872 policyGroup may be named under any superior, using any of its three 873 naming attributes. 875 NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule 876 are named within the scope of ("are weak to" in the CIM jargon) an 877 instance of the CIM class System, or one of its subclasses. The most 878 natural way to map a weak relationship of this type is to DIT 879 structure rules specifying that an instance of policyGroup or 880 policyRule is subordinate to an object representing a CIM System. 881 Since, however, the mapping of CIM's System class to an LDAP class 882 falls outside the scope of this document, the DIT structure rules that 883 follow do not constrain the superiors under which an instance of 884 PolicyGroup may be named. 886 ( NAME 'policyGroupNameForm1' 887 OC policyGroup 888 MUST (cn) 889 ) 891 ( NAME 'policyGroupStructuralRule1' 892 FORM policyGroupNameForm1 893 ) 895 ( NAME 'policyGroupNameForm2' 896 OC policyGroup 897 MUST (policyGroupName) 898 ) 900 ( NAME 'policyGroupStructuralRule2' 901 FORM policyGroupNameForm2 902 ) 904 ( NAME 'policyGroupNameForm3' 905 OC policyGroup 906 MUST (cimName) 907 ) 909 ( NAME 'policyGroupStructuralRule3' 910 FORM policyGroupNameForm3 911 ) 913 The one attribute of policyGroup is defined as: 915 ( NAME 'policyGroupName' 916 DESC 'The user-friendly name of this policy group.' 917 SYNTAX IA5String 918 EQUALITY caseExactIA5Match 919 SINGLE-VALUE 920 ) 922 5.3. The Class policyRule 924 This class represents the "If Condition then Action" semantics 925 associated with a policy. The conditions and actions associated with 926 a policy rule are modeled, respectively, with auxiliary subclasses of 927 the auxiliary classes policyConditionAuxClass and 928 policyActionAuxClass. Each of these auxiliary subclasses is attached 929 to an instance of one of two structural classes. A subclass of 930 policyConditionAuxClass is attached either to an instance of 931 policyRuleConditionAssociation or to an instance of 932 policyConditionInstance. Similarly, a subclass of 933 policyActionAuxClass is attached either to an instance of 934 policyRuleActionAssociation or to an instance of policyActionInstance. 936 Of the eight attributes in the policyRule class, seven are mapped 937 directly from corresponding properties in the information model. The 938 eighth attribute, policyRuleValidityPeriodList, realizes the 939 PolicyRuleValidityPeriod association from the information model. 940 Since this association has no "extra" properties (besides those that 941 tie the association to its associated objects), the attribute 942 policyRuleValidityPeriodList is simply a multi-valued DN pointer. 943 (Relationships in the information model can have "extra" properties 944 because CIM represents relationships as classes. See Sections 5.4 and 945 5.5 for examples of "extra" properties and how they are mapped to 946 LDAP.) This attribute provides an unordered set of DN pointers to one 947 or more instances of the policyTimePeriodConditionAuxClass, indicating 948 when the policy rule is scheduled to be active and when it is 949 scheduled to be inactive. A policy rule is scheduled to be active if 950 it is active according to AT LEAST ONE of the 951 policyTimePeriodConditionAuxClass instances pointed to by this 952 attribute. 954 The ConditionInPolicyRule and ActionInPolicyRule associations, 955 however, have additional properties: ActionInPolicyRule has an 956 integer to sequence the actions, and ConditionInPolicyRule has an 957 integer to group the conditions, and a Boolean to specify whether a 958 condition is to be negated. In the Core Schema, these extra 959 association properties are represented as attributes of two classes 960 introduced specifically to model the associations: 961 policyRuleConditionAssociation and policyRuleActionAssociation, 962 defined, respectively, in Sections 5.4 and 5.5. Thus they do not 963 appear as attributes of the class policyRule. 965 The class definition of policyRule is as follows: 967 ( NAME 'policyRule' 968 DESC 'The central class for representing the "If Condition 969 then Action" semantics associated with a policy rule.' 970 SUP policy 971 MUST (policyRuleName) 972 MAY (policyRuleEnabled $ policyRuleConditionListType $ 973 policyRuleValidityPeriodList $ policyRuleUsage $ 974 policyRulePriority $ policyRuleMandatory $ 975 policyRuleSequencedActions) 976 ) 978 The following DIT structure rules indicate that an instance of 979 policyRule may be named under any superior, using any of its three 980 naming attributes. 982 NOTE: In the CIM model, instances of both PolicyGroup and PolicyRule 983 are named within the scope of ("are weak to" in the CIM jargon) an 984 instance of the CIM class System, or one of its subclasses. The most 985 natural way to map a weak relationship of this type is to DIT 986 structure rules specifying that an instance of policyGroup or 987 policyRule is subordinate to an object representing a CIM System. 988 Since, however, the mapping of CIM's System class to an LDAP class 989 falls outside the scope of this document, the DIT structure rules that 990 follow do not constrain the superiors under which an instance of 991 PolicyRule may be named. 993 ( NAME 'policyRuleNameForm1' 994 OC policyRule 995 MUST (cn) 996 ) 998 ( NAME 'policyRuleStructuralRule1' 999 FORM policyRuleNameForm1 1000 ) 1002 ( NAME 'policyRuleNameForm2' 1003 OC policyRule 1004 MUST (policyRuleName) 1005 ) 1007 ( NAME 'policyRuleStructuralRule2' 1008 FORM policyRuleNameForm2 1009 ) 1010 ( NAME 'policyRuleNameForm3' 1011 OC policyRule 1012 MUST (cimName) 1013 ) 1015 ( NAME 'policyRuleStructuralRule3' 1016 FORM policyRuleNameForm3 1017 ) 1019 The attributes of policyRule are defined as follows: 1021 ( NAME 'policyRuleName' 1022 DESC 'The user-friendly name of this policy rule.' 1023 SYNTAX IA5String 1024 EQUALITY caseExactIA5Match 1025 SINGLE-VALUE 1026 ) 1028 ( NAME 'policyRuleEnabled' 1029 DESC 'An enumeration indicating whether a policy rule is 1030 administratively enabled, administratively disabled, or 1031 enabled for debug mode. The defined values for this 1032 attribute are enabled(1), disabled(2), and 1033 enabledForDebug(3).' 1034 SYNTAX INTEGER 1035 EQUALITY integerMatch 1036 SINGLE-VALUE 1037 ) 1039 ( NAME 'policyRuleConditionListType' 1040 DESC 'Indicates whether the list of policy conditions 1041 associated with this policy rule is in disjunctive 1042 normal form (DNF) or conjunctive normal form (CNF). 1043 Defined values are DNF(1) and CNF(2).' 1044 SYNTAX INTEGER 1045 EQUALITY integerMatch 1046 SINGLE-VALUE 1047 ) 1049 ( NAME 'policyRuleValidityPeriodList' 1050 DESC 'Distinguished names of policyTimePeriodConditions that 1051 determine when the policyRule is scheduled to be active 1052 / inactive. No order is implied.' 1053 SYNTAX DN 1054 EQUALITY distinguishedNameMatch 1055 ) 1057 ( NAME 'policyRuleUsage' 1058 DESC 'This attribute is used to provide guidelines on how 1059 this policy should be used.' 1060 SYNTAX DirectoryString 1061 EQUALITY caseIgnoreMatch 1062 SINGLE-VALUE 1063 ) 1065 ( NAME 'policyRulePriority' 1066 DESC 'A non-negative integer for prioritizing this policyRule 1067 relative to other policyRules. A larger value indicates 1068 a higher priority.' 1069 SYNTAX INTEGER 1070 EQUALITY integerMatch 1071 SINGLE-VALUE 1072 ) 1073 ( NAME 'policyRuleMandatory' 1074 DESC 'A flag indicating that the evaluation of the 1075 policyConditions and execution of policyActions (if the 1076 condition list evaluates to True) is required.' 1077 SYNTAX Boolean 1078 EQUALITY booleanMatch 1079 SINGLE-VALUE 1080 ) 1082 ( NAME 'policyRuleSequencedActions' 1083 DESC 'An enumeration indicating how to interpret the action 1084 ordering indicated via the policyRuleActionList 1085 attribute. The defined values for this attribute are 1086 mandatory(1), recommended(2), and dontCare(3).' 1087 SYNTAX INTEGER 1088 EQUALITY integerMatch 1089 ) 1091 5.4. The Class policyRuleConditionAssociation 1093 This class contains attributes to represent the "extra" properties of 1094 the information model's ConditionInPolicyRule association. Instances 1095 of this class are related to an instance of policyRule via DIT 1096 containment. The policy conditions themselves are represented by 1097 auxiliary subclasses of the auxiliary class policyConditionAuxClass. 1098 These auxiliary classes are attached directly to instances of 1099 policyRuleConditionAssociation for rule-specific policy conditions. 1100 For a reusable policy condition, the auxiliary class is attached to an 1101 instance of the class policyConditionInstance, and there is a DN 1102 pointer to this instance from the instance of 1103 policyRuleConditionAssociation. 1105 The class definition is as follows: 1107 ( NAME 'policyRuleConditionAssociation' 1108 DESC 'The class contains attributes characterizing the 1109 relationship between a policy rule and one of its 1110 policy conditions.' 1111 SUP policy 1112 MUST (policyConditionGroupNumber $ policyConditionNegated $ 1113 policyConditionName) 1114 MAY (policyConditionDN) 1115 ) 1117 The following DIT content rule indicates that an instance of 1118 policyRuleConditionAssociation may have attached to it the auxiliary 1119 class policyConditionAuxClass, or one of its subclasses. This 1120 combination represents a rule-specific policy condition. 1122 ( 1123 NAME 'policyRuleConditionAssociationContentRule' 1124 DESC 'shows what auxiliary classes go with this object' 1125 AUX (policyConditionAuxClass) 1126 ) 1128 The following DIT structure rules indicate that an instance of 1129 policyRuleConditionAssociation may be named under an instance of 1130 policyRule, where each of these instances may be named using any of 1131 their three naming attributes. 1133 ( NAME 'policyRuleConditionAssociationNameForm1' 1134 OC policyRuleConditionAssociation 1135 MUST (cn) 1136 ) 1138 ( NAME 'policyRuleConditionAssociationStructuralRule1' 1139 FORM policyRuleConditionAssociationNameForm1 1140 SUP 1141 ) 1143 ( NAME 'policyRuleConditionAssociationNameForm2' 1144 OC policyRuleConditionAssociation 1145 MUST (policyConditionName) 1146 ) 1148 ( NAME 'policyRuleConditionAssociationStructuralRule2' 1149 FORM policyRuleConditionAssociationNameForm2 1150 SUP 1151 ) 1152 ( NAME 'policyRuleConditionAssociationNameForm3' 1153 OC policyRuleConditionAssociation 1154 MUST (cimName) 1155 ) 1157 ( NAME 'policyRuleConditionAssociationStructuralRule3' 1158 FORM policyRuleConditionAssociationNameForm3 1159 SUP 1160 ) 1162 The attributes of policyRuleConditionAssociation are defined as 1163 follows. Note that the class-specific naming attribute 1164 policyConditionName is also used in the class policyConditionInstance, 1165 where it identifies a reusable policy condition. 1167 ( 1168 NAME 'policyConditionName' 1169 DESC 'A user-friendly name for a policy condition.' 1170 SYNTAX IA5String 1171 EQUALITY caseExactIA5Match 1172 SINGLE-VALUE 1173 ) 1174 ( 1175 NAME 'policyConditionGroupNumber' 1176 DESC 'The number of the group to which a policy condition 1177 belongs. These groups are used to form the DNF or 1178 CNF expression associated with a policy rule. 1179 SYNTAX INTEGER 1180 EQUALITY integerMatch 1181 SINGLE-VALUE 1182 ) 1184 ( 1185 NAME 'policyConditionNegated' 1186 DESC 'Indicates whether a policy condition is negated in 1187 the DNF or CNF expression associated with a policy 1188 rule. The value TRUE indicates that a condition is 1189 negated' 1190 SYNTAX Boolean 1191 EQUALITY booleanMatch 1192 SINGLE-VALUE 1193 ) 1195 ( 1196 NAME 'policyConditionDN' 1197 DESC 'A DN pointer to a reusable policy condition.' 1198 SYNTAX DN 1199 EQUALITY distinguishedNameMatch 1200 SINGLE-VALUE 1201 ) 1203 5.5. The Class policyRuleActionAssociation 1205 This class contains an attribute to represent the one "extra" property 1206 of the information model's ActionInPolicyRule association, which makes 1207 it possible to specify an order for executing the actions associated 1208 with a policy rule. Instances of this class are related to an 1209 instance of policyRule via DIT containment. The actions themselves 1210 are represented by auxiliary subclasses of the auxiliary class 1211 policyActionAuxClass. These auxiliary classes are attached directly 1212 to instances of policyRuleActionAssociation for rule-specific policy 1213 actions. For a reusable policy action, the auxiliary class is 1214 attached to an instance of the class policyActionInstance, and there 1215 is a DN pointer to this instance from the instance of 1216 policyRuleActionAssociation. 1218 The class definition is as follows: 1220 ( NAME 'policyRuleActionAssociation' 1221 DESC 'The class contains an attribute that represents an 1222 execution order for an action in the context of a 1223 policy rule.' 1224 SUP policy 1225 MUST (policyActionOrder $ 1226 policyActionName) 1227 MAY (policyActionDN) 1228 ) 1230 The following DIT content rule indicates that an instance of 1231 policyRuleActionAssociation may have attached to it the auxiliary 1232 class policyActionAuxClass, or one of its subclasses. This 1233 combination represents a rule-specific policy action. 1235 ( 1236 NAME 'policyRuleActionAssociationContentRule' 1237 DESC 'shows what auxiliary classes go with this object' 1238 AUX (policyActionAuxClass) 1239 ) 1241 The following DIT structure rules indicate that an instance of 1242 policyRuleActionAssociation may be named under an instance of 1243 policyRule, where each of these instances may be named using any of 1244 their three naming attributes. 1246 ( NAME 'policyRuleActionAssociationNameForm1' 1247 OC policyRuleActionAssociation 1248 MUST (cn) 1249 ) 1251 ( NAME 'policyRuleActionAssociationStructuralRule1' 1252 FORM policyRuleActionAssociationNameForm1 1253 SUP 1254 ) 1256 ( NAME 'policyRuleActionAssociationNameForm2' 1257 OC policyRuleActionAssociation 1258 MUST (policyActionName) 1259 ) 1261 ( NAME 'policyRuleActionAssociationStructuralRule2' 1262 FORM policyRuleActionAssociationNameForm2 1263 SUP 1264 ) 1266 ( NAME 'policyRuleActionAssociationNameForm3' 1267 OC policyRuleActionAssociation 1268 MUST (cimName) 1269 ) 1271 ( NAME 'policyRuleActionAssociationStructuralRule3' 1272 FORM policyRuleActionAssociationNameForm3 1273 SUP 1274 ) 1276 The attributes of policyRuleActionAssociation are defined as follows. 1277 Note that the class-specific naming attribute policyActionName is also 1278 used in the class policyActionInstance, where it identifies a reusable 1279 policy action. 1281 ( 1282 NAME 'policyActionName' 1283 DESC 'A user-friendly name for a policy action.' 1284 SYNTAX IA5String 1285 EQUALITY caseExactIA5Match 1286 SINGLE-VALUE 1287 ) 1289 ( 1290 NAME 'policyActionOrder' 1291 DESC 'An integer indicating the relative order of an action 1292 in the context of a policy rule. 1293 SYNTAX INTEGER 1294 EQUALITY integerMatch 1295 SINGLE-VALUE 1296 ) 1298 ( 1299 NAME 'policyActionDN' 1300 DESC 'A DN pointer to a reusable policy action.' 1301 SYNTAX DN 1302 EQUALITY distinguishedNameMatch 1303 SINGLE-VALUE 1304 ) 1306 5.6. The Auxiliary Class policyConditionAuxClass 1308 The purpose of a policy condition is to determine whether or not the 1309 set of actions (contained in the policyRule that the condition applies 1310 to) should be executed or not. This auxiliary class can be attached 1311 to instances of two other classes in the Core Policy Schema. When it 1312 is attached to an instance of policyConditionAssociation, it 1313 represents a rule-specific policy condition. When it is attached to 1314 an instance of policyConditionInstance, it represents a reusable 1315 policy condition. 1317 Since both of the classes to which this auxiliary class may be 1318 attached are derived from "policy", the attributes of "policy" will 1319 already be defined for the entries to which this class attaches. Thus 1320 this class is derived directly from "top". 1322 The class definition is as follows: 1324 ( NAME 'policyConditionAuxClass' 1325 DESC 'A class representing a condition to be evaluated in 1326 conjunction with a policy rule.' 1328 SUP top 1329 AUXILIARY 1330 ) 1332 5.7. The Auxiliary Class policyTimePeriodConditionAuxClass 1334 This class provides a means of representing the time periods during 1335 which a policy rule is valid, i.e., active. The class definition is 1336 as follows. Note that instances of this class are named with the 1337 attributes cn and policyConditionName that they inherit, respectively, 1338 from policy and from policyCondition. 1340 ( NAME 'policyTimePeriodConditionAuxClass' 1341 DESC 'A class that provides the capability of enabling / 1342 disabling a policy rule according to a predetermined 1343 schedule.' 1344 SUP policyConditionAuxClass 1345 AUXILIARY 1346 MAY (ptpConditionTime $ ptpConditionMonthOfYearMask $ 1347 ptpConditionDayOfMonthMask $ ptpConditionDayOfWeekMask $ 1348 ptpConditionTimeOfDayMask $ ptpConditionTimeZone) 1349 ) 1351 The attributes of policyTimePeriodConditionAuxClass are defined as 1352 follows: 1354 ( 1355 NAME 'ptpConditionTime' 1356 DESC 'The range of calendar dates on which a policy rule is 1357 valid. The format of the string is 1358 [yyyymmddhhmmss]:[yyyymmddhhmmss]' 1359 SYNTAX PrintableString 1360 EQUALITY caseIgnoreMatch 1361 SINGLE-VALUE 1362 ) 1364 ( 1365 NAME 'ptpConditionMonthOfYearMask' 1366 DESC 'A mask identifying the months of the year in which a 1367 policy rule is valid. The format is a string of 12 1368 ASCII "0"s and "1"s, representing the months of the 1369 year from January through December.' 1370 SYNTAX PrintableString 1371 EQUALITY caseIgnoreMatch 1372 SINGLE-VALUE 1373 ) 1375 ( 1376 NAME 'ptpConditionDayOfMonthMask' 1377 DESC 'A mask identifying the days of the month on which a 1378 policy rule is valid. The format is a string of 62 1379 ASCII "0"s and "1"s. The first 31 positions represent 1380 the days of the month in ascending order, from day 1 to 1381 day 31. The next 31 positions represent the days of 1382 the month in descending order, from the last day to the 1383 day 31 days from the end.' 1384 SYNTAX PrintableString 1385 EQUALITY caseIgnoreMatch 1386 SINGLE-VALUE 1387 ) 1389 ( 1390 NAME 'ptpConditionDayOfWeekMask' 1391 DESC 'A mask identifying the days of the week on which a 1392 policy rule is valid. The format is a string of seven 1393 ASCII "0"s and "1"s, representing the days of the week 1394 from Sunday through Saturday.' 1395 SYNTAX PrintableString 1396 EQUALITY caseIgnoreMatch 1397 SINGLE-VALUE 1398 ) 1400 ( 1401 NAME 'ptpConditionTimeOfDayMask' 1402 DESC 'The range of times at which a policy rule is valid. If 1403 the second time is earlier than the first, then the 1404 interval spans midnight. The format of the string is 1405 hhmmss:hhmmss' 1406 SYNTAX PrintableString 1407 EQUALITY caseIgnoreMatch 1408 ) 1410 ( 1411 NAME 'ptpConditionTimeZone' 1412 DESC 'The definition of the time zone for the 1413 policyTimePeriodConditionAuxClass. The format of 1414 the string is either "Z" (UTC) or <"+"|"-">' 1415 SYNTAX PrintableString 1416 EQUALITY caseIgnoreMatch 1417 SINGLE-VALUE 1418 ) 1420 5.8. The Auxiliary Class vendorPolicyConditionAuxClass 1422 The class definition is as follows: 1424 ( NAME 'vendorPolicyConditionAuxClass' 1425 DESC 'A class that defines a registered means to describe a 1426 policy condition.' 1427 SUP policyConditionAuxClass 1428 AUXILIARY 1429 MAY (vendorPolicyConstraintData $ 1430 vendorPolicyConstraintEncoding) 1431 ) 1433 The attribute definitions for vendorPolicyCondition are as follows: 1435 ( 1436 NAME 'vendorPolicyConstraintData' 1437 DESC 'Escape mechanism for representing constraints that have 1438 not been modeled as specific attributes. The format of 1439 the values is identified by the OID stored in the 1440 attribute vendorPolicyConstraintEncoding.' 1441 SYNTAX OctetString 1442 EQUALITY octetStringMatch 1443 ) 1445 ( 1446 NAME 'vendorPolicyConstraintEncoding' 1447 DESC 'An OID identifying the format and semantics for this 1448 instance"s vendorPolicyConstraintData attribute.' 1449 SYNTAX OID 1450 EQUALITY objectIdentifierMatch 1451 SINGLE-VALUE 1452 ) 1454 5.9. The Auxiliary Class policyActionAuxClass 1456 The purpose of a policy action is to execute one or more operations 1457 that will affect network traffic and/or systems, devices, etc. in 1458 order to achieve a desired policy state. This auxiliary class can be 1459 attached to instances of two other classes in the Core Policy Schema. 1460 When it is attached to an instance of policyActionAssociation, it 1461 represents a rule-specific policy action. When it is attached to an 1462 instance of policyActionInstance, it represents a reusable policy 1463 action. 1465 Since both of the classes to which this auxiliary class may be 1466 attached are derived from "policy", the attributes of "policy" will 1467 already be defined for the entries to which this class attaches. Thus 1468 this class is derived directly from "top". 1470 The class definition is as follows: 1472 ( NAME 'policyActionAuxClass' 1473 DESC 'A class representing an action to be performed as a 1474 result of a policy rule.' 1475 SUP top 1476 AUXILIARY 1477 ) 1479 5.10. The Auxiliary Class vendorPolicyActionAuxClass 1481 The class definition is as follows: 1483 ( NAME 'vendorPolicyActionAuxClass' 1484 DESC 'A class that defines a registered means to describe a 1485 policy action.' 1486 SUP policyActionAuxClass 1487 AUXILIARY 1488 MAY (vendorPolicyActionData $ vendorPolicyActionEncoding) 1489 ) 1491 The attribute definitions for vendorPolicyActionAuxClass are as 1492 follows: 1494 ( 1495 NAME 'vendorPolicyActionData' 1496 DESC 'Escape mechanism for representing actions that have not 1497 been modeled as specific attributes. The format of the 1498 values is identified by the OID stored in the attribute 1499 vendorPolicyActionEncoding.' 1500 SYNTAX OctetString 1501 EQUALITY octetStringMatch 1502 ) 1504 ( 1505 NAME 'vendorPolicyActionEncoding' 1506 DESC 'An OID identifying the format and semantics for this 1507 instance"s vendorPolicyActionData attribute.' 1508 SYNTAX OID 1509 EQUALITY objectIdentifierMatch 1510 SINGLE-VALUE 1511 ) 1513 5.11. The Class policyConditionInstance 1515 The role of this class in the Core Schema is to serve as the 1516 structural class to which the auxiliary class policyCondition is 1517 attached to form a reusable policy condition. See Section 4.3 for a 1518 complete discussion of reusable policy conditions and the role that 1519 this class plays in how they are represented. 1521 In addition to the cn attribute it inherits from "policy", this class 1522 uses the naming attribute policyConditionName, which was defined above 1523 in Section 5.4. 1525 The class definition is as follows: 1527 ( NAME 'policyConditionInstance' 1528 DESC 'A structural class that contains a reusable policy 1529 condition.' 1530 SUP policy 1531 MUST (policyConditionName) 1532 ) 1534 The following DIT content rule indicates that an instance of 1535 policyConditionInstance may have attached to it an instance of the 1536 auxiliary class policyCondition. 1538 ( 1539 NAME 'policyConditionInstanceContentRule' 1540 DESC 'shows what auxiliary classes go with this class' 1541 AUX (policyConditionAuxClass) 1542 ) 1544 The following DIT structure rules indicate that an instance of 1545 policyConditionInstance may be named under an instance of 1546 policyRepository, using any of its three naming attributes. 1548 ( NAME 'policyConditionInstanceNameForm1' 1549 OC policyConditionInstance 1550 MUST (cn) 1551 ) 1553 ( NAME 'policyConditionInstanceStructuralRule1' 1554 FORM policyConditionInstanceNameForm1 1555 SUP 1556 ) 1558 ( NAME 'policyConditionInstanceNameForm2' 1559 OC policyConditionInstance 1560 MUST (policyConditionName) 1561 ) 1563 ( NAME 'policyConditionInstanceStructuralRule2' 1564 FORM policyConditionInstanceNameForm2 1565 SUP 1566 ) 1568 ( NAME 'policyConditionInstanceNameForm3' 1569 OC policyConditionInstance 1570 MUST (cimName) 1571 ) 1573 ( NAME 'policyConditionInstanceStructuralRule3' 1574 FORM policyConditionInstanceNameForm3 1575 SUP 1576 ) 1578 5.12. The Class policyActionInstance 1580 The role of this class in the Core Schema is to serve as the 1581 structural class to which the auxiliary class policyAction is attached 1582 to form a reusable policy action. See Section 4.3 for a complete 1583 discussion of reusable policy actions and the role that this class 1584 plays in how they are represented. 1586 In addition to the cn attribute it inherits from "policy", this class 1587 uses the naming attribute policyActionName, which was defined above in 1588 Section 5.5. 1590 The class definition is as follows: 1592 ( NAME 'policyActionInstance' 1593 DESC 'A structural class that contains a reusable policy 1594 action.' 1595 SUP policy 1596 MUST (policyActionName) 1597 ) 1599 The following DIT content rule indicates that an instance of 1600 policyActionInstance may have attached to it an instance of the 1601 auxiliary class policyAction. 1603 ( 1604 NAME 'policyActionInstanceContentRule' 1605 DESC 'shows what auxiliary classes go with this class' 1606 AUX (policyActionAuxClass) 1607 ) 1609 The following DIT structure rules indicate that an instance of 1610 policyActionInstance may be named under an instance of 1611 policyRepository, using any of its three naming attributes. 1613 ( NAME 'policyActionInstanceNameForm1' 1614 OC policyActionInstance 1615 MUST (cn) 1616 ) 1618 ( NAME 'policyActionInstanceStructuralRule1' 1619 FORM policyActionInstanceNameForm1 1620 SUP 1621 ) 1623 ( NAME 'policyActionInstanceNameForm2' 1624 OC policyActionInstance 1625 MUST (policyActionName) 1626 ) 1628 ( NAME 'policyActionInstanceStructuralRule2' 1629 FORM policyActionInstanceNameForm2 1630 SUP 1631 ) 1632 ( NAME 'policyActionInstanceNameForm3' 1633 OC policyActionInstance 1634 MUST (cimName) 1635 ) 1637 ( NAME 'policyActionInstanceStructuralRule3' 1638 FORM policyActionInstanceNameForm3 1639 SUP 1640 ) 1642 5.13. The Auxiliary Class policyElementAuxClass 1644 This class introduces no additional attributes, beyond those defined 1645 in the class "policy" from which it is derived. Its role is to "tag" 1646 an instance of a class defined outside the realm of policy as being 1647 nevertheless relevant to a policy specification. This tagging can 1648 potentially take place at two levels: 1650 o Every instance to which policyElementAuxClass is attached becomes 1651 an instance of the class "policy", since policyElementAuxClass is a 1652 subclass of "policy". Thus a DIT search with the filter 1653 "objectClass=policy" will return the instance. (As noted earlier, 1654 this approach does not work for some directory implementations. To 1655 accommodate these implementations, policy-related entries SHOULD be 1656 tagged with the keyword "POLICY".) 1658 o With the policyKeywords attribute that it inherits from "policy", 1659 an instance to which policyElementAuxClass is attached can be 1660 tagged as being relevant to a particular type or category of 1661 policy, using standard keywords, administrator-defined keywords, or 1662 both. 1664 The class definition is as follows: 1666 ( NAME 'policyElementAuxClass' 1667 DESC 'An auxiliary class used to tag instances of classes 1668 defined outside the realm of policy as relevant to a 1669 particular policy specification.' 1670 SUP policy 1671 AUXILIARY 1672 ) 1674 5.14. The Class policyRepository 1676 This class provides a container for reusable policy information, such 1677 as reusable policy conditions and/or reusable policy actions. 1679 The class definition is as follows: 1681 ( NAME 'policyRepository' 1682 DESC 'A container for reusable information.' 1683 SUP top 1684 MUST (policyRepositoryName) 1685 MAY(cn $ cimName) 1686 ) 1688 The following DIT structure rules indicate that an instance of 1689 policyRepository may be named under any superior, using any of its 1690 three naming attributes. 1692 ( NAME 'policyRepositoryNameForm1' 1693 OC policyRepository 1694 MUST (cn) 1695 ) 1697 ( NAME 'policyRepositoryStructuralRule1' 1698 FORM policyRepositoryNameForm1 1699 ) 1701 ( NAME 'policyRepositoryNameForm2' 1702 OC policyRepository 1703 MUST (policyRepositoryName) 1704 ) 1706 ( NAME 'policyRepositoryStructuralRule2' 1707 FORM policyRepositoryNameForm2 1708 ) 1710 ( NAME 'policyRepositoryNameForm3' 1711 OC policyRepository 1712 MUST (cimName) 1713 ) 1715 ( NAME 'policyRepositoryStructuralRule3' 1716 FORM policyRepositoryNameForm3 1717 ) 1719 The two attributes of policyRepository are defined as follows. Note 1720 that the cimName attribute defined here is the same attribute that was 1721 defined earlier for the "policy" class. 1723 ( NAME 'policyRepositoryName' 1724 DESC 'The user-friendly name of this policy repository.' 1725 SYNTAX IA5String 1726 EQUALITY caseExactIA5Match 1727 SINGLE-VALUE 1728 ) 1730 ( NAME 'cimName' 1731 DESC 'For mapping from CIM, a string constructed by taking 1732 the string difference between the CIM properties 1733 NamePath and SuperiorPath. See the Appendix to this 1734 document for more on this algorithm, including an 1735 example.' 1737 SYNTAX IA5String 1738 EQUALITY caseExactIA5Match 1739 SINGLE-VALUE 1740 ) 1742 5.15. The Auxiliary Class policySubtreesPtrAuxClass 1744 This auxiliary class provides a single, multi-valued attribute that 1745 points to a set of objects that are at the root of DIT subtrees 1746 containing policy-related information. By attaching this attribute to 1747 instances of various other classes, a policy administrator has a 1748 flexible way of providing an entry point into the directory that 1749 allows a client to locate and retrieve the policy information relevant 1750 to it. 1752 These entries may be placed in the DIT such that a well-known DN can 1753 be used by placing the structural entry (e.g. container) with the 1754 policySubtreesPtrAuxClass attached thereto in the root of the 1755 directory suffix. In this case, the subtree entry point can contain 1756 and/or point to all related policy entries for any well-known policy 1757 disciplines. Similarly, the subtree entry point may be placed in the 1758 DIT such that the Policy Consumer's starting point is a subtree with 1759 policy-related entries that are dependent on a hierarchically-related 1760 set of subtrees (e.g., region, division, corporate). In this latter 1761 case, DNs may be provided to the Policy Consumers via SNMP or other 1762 techniques. 1764 This object does not provide the semantic linkages between individual 1765 policy objects, such as those between a policy group and the policy 1766 rules that belong to it. Its only role is to enable efficient bulk 1767 retrieval of policy-related objects, as described in Section 4.4. 1768 Once the objects have been retrieved, a directory client can determine 1769 the semantic linkages by following DN pointers such as 1770 policyRulesAuxContainedSet locally. 1772 Since policy-related objects will often be included in the DIT subtree 1773 beneath an object to which this auxiliary class is attached, a client 1774 SHOULD request the policy-related objects from the subtree under the 1775 object with these pointers at the same time that it requests the 1776 pointers themselves. 1778 Since clients are expected to behave in this way, the policy 1779 administrator SHOULD make sure that this subtree does not contain so 1780 many objects unrelated to policy that an initial search done in this 1781 way results in a performance problem. For example, 1782 policySubtreesPtrAuxClass SHOULD NOT be attached to the partition root 1783 for a large directory partition containing a relatively few policy- 1784 related objects along with a large number of objects unrelated to 1785 policy. A better approach would be to introduce a container object 1786 immediately below the partition root, attach policySubtreesPtrAuxClass 1787 to this container object, and then place the policy-related objects in 1788 the subtree under it. 1790 The class definition is as follows: 1792 ( NAME 'policySubtreesPtrAuxClass' 1793 DESC 'An auxiliary class providing DN pointers to roots of 1794 DIT subtrees containing policy-related objects.' 1795 SUP top 1796 AUXILIARY 1797 MAY (policySubtreesAuxContainedSet) 1798 ) 1800 5.15.1. The Attribute policySubtreesAuxContainedSet 1802 This attribute provides an unordered set of DN pointers to one or more 1803 objects under which policy-related information is present. The 1804 objects pointed to may or may not themselves contain policy-related 1805 information. 1807 The attribute definition is as follows: 1809 ( 1810 NAME 'policySubtreesAuxContainedSet' 1811 DESC 'Distinguished names of objects that serve as roots for 1812 DIT subtrees containing policy-related objects. No 1813 order is implied.' 1814 SYNTAX DN 1815 EQUALITY distinguishedNameMatch 1816 ) 1818 5.16. The Auxiliary Class policyGroupContainmentAuxClass 1820 This auxiliary class provides a single, multi-valued attribute that 1821 points to a set of policyGroups. By attaching this attribute to 1822 instances of various other classes, a policy administrator has a 1823 flexible way of providing an entry point into the directory that 1824 allows a client to locate and retrieve the policyGroups relevant to 1825 it. 1827 As is the case with policyRules, a policy administrator might have 1828 several different pointers to a policyGroup in the overall directory 1829 structure. The policyGroupContainmentAuxClass is the mechanism that 1830 makes it possible for the policy administrator to define all these 1831 pointers. 1833 The class definition is as follows: 1835 ( NAME 'policyGroupContainmentAuxClass' 1836 DESC 'An auxiliary class used to bind policyGroups to an 1837 appropriate container object.' 1838 SUP top 1839 AUXILIARY 1840 MAY (policyGroupsAuxContainedSet) 1842 ) 1844 5.16.1. The Attribute policyGroupsAuxContainedSet 1846 This attribute provides an unordered set of DN pointers to one or more 1847 policyGroups associated with the instance of a structural class to 1848 which this attribute has been appended. The attribute definition is 1849 as follows: 1851 ( 1852 NAME 'policyGroupsAuxContainedSet' 1853 DESC 'Distinguished names of policyGroups associated in some 1854 way with the instance to which this attribute has been 1855 appended. No order is implied.' 1856 SYNTAX DN 1857 EQUALITY distinguishedNameMatch 1858 ) 1860 5.17. The Auxiliary Class policyRuleContainmentAuxClass 1862 This auxiliary class provides a single, multi-valued attribute that 1863 points to a set of policyRules. By attaching this attribute to 1864 instances of various other classes, a policy administrator has a 1865 flexible way of providing an entry point into the directory that 1866 allows a client to locate and retrieve the policyRules relevant to it. 1868 A policy administrator might have several different pointers to a 1869 policyRule in the overall directory structure. For example, there 1870 might be pointers to all policyRules for traffic originating in a 1871 particular subnet from a directory entry that represents that subnet. 1872 At the same time, there might be pointers to all policyRules related 1873 to a particular DiffServ setting from an instance of a policyGroup 1874 explicitly introduced as a container for DiffServ-related policyRules. 1875 The policyRuleContainmentAuxClass is the mechanism that makes it 1876 possible for the policy administrator to define all these pointers. 1878 Note that the cn attribute does NOT need to be defined for this class. 1879 This is because an auxiliary class is used as a means to collect 1880 common attributes and treat them as properties of an object. A good 1881 analogy is a #include file, except that since an auxiliary class is a 1882 class, all the benefits of a class (e.g., inheritance) can be applied 1883 to an auxiliary class. 1885 The class definition is as follows: 1887 ( NAME 'policyRuleContainmentAuxClass' 1888 DESC 'An auxiliary class used to bind policyRules to an 1889 appropriate container object.' 1890 SUP top 1891 AUXILIARY 1892 MAY (policyRulesAuxContainedSet) 1893 ) 1895 5.17.1. The Attribute policyRulesAuxContainedSet 1897 This attribute provides an unordered set of DN pointers to one or more 1898 policyRules associated with the instance of a structural class to 1899 which this attribute has been appended. The attribute definition is: 1901 ( 1902 NAME 'policyRulesAuxContainedSet' 1903 DESC 'Distinguished names of policyRules associated in some 1904 way with the instance to which this attribute has been 1905 appended. No order is implied.' 1906 SYNTAX DN 1907 EQUALITY distinguishedNameMatch 1908 ) 1910 6. Extending the Core Schema 1912 The following subsections provide general guidance on how to create a 1913 domain-specific schema derived from the Core Schema, discuss how the 1914 vendor classes in the Core Schema should be used, and explain how 1915 policyTimePeriodConditions are related to other policy conditions. 1917 6.1. Subclassing policyCondition and policyAction 1919 In Section 4.3 above, there is a discussion of how, by representing 1920 policy conditions and policy actions as auxiliary classes in a schema, 1921 the flexibility is retained to instantiate a particular condition or 1922 action as either rule-specific or reusable. This flexibility is lost 1923 if a condition or action class is defined as structural rather than 1924 auxiliary. For standardized schemata, this document specifies that 1925 domain-specific information MUST be expressed in auxiliary subclasses 1926 of policyCondition and policyAction. It is RECOMMENDED that non- 1927 standardized schemata follow this practice as well. 1929 6.2. Using the Vendor Policy Encoding Attributes 1931 As discussed Section 5.8 "The Class vendorPolicyConditionAuxClass", 1932 the attributes vendorPolicyConstraintData and 1933 vendorPolicyConstraintEncoding are included in 1934 vendorPolicyConditionAuxClass to provide an escape mechanism for 1935 representing "exceptional" policy conditions. The attributes 1936 vendorPolicyActionData and vendorPolicyActionEncoding in 1937 vendorPolicyActionAuxClass class play the same role with respect to 1938 actions. This enables interoperability between different vendors. 1940 For example, imagine a network composed of access devices from vendor 1941 A, edge and core devices from vendor B, and a policy server from 1942 vendor C. It is desirable for this policy server to be able to 1943 configure and manage all of the devices from vendors A and B. 1944 Unfortunately, these devices will in general have little in common 1945 (e.g., different mechanisms, different ways for controlling those 1946 mechanisms, different operating systems, different commands, and so 1947 forth). The escape conditions provide a way for vendor-specific 1948 commands to be encoded as OctetStrings, so that devices from different 1949 vendors can be commonly managed by a single policy server. 1951 6.3. Using Time Validity Periods 1953 Time validity periods are defined as a subclass of policyCondition, 1954 called policyTimePeriodCondition. This is to allow their inclusion in 1955 the AND/OR condition definitions for a policyRule. Care should be 1956 taken not to subclass policyTimePeriodCondition to add domain-specific 1957 condition properties. For example, it would be incorrect to add 1958 IPSec- or QoS-specific condition properties to the 1959 policyTimePeriodCondition class, just because IPSec or QoS includes 1960 time in its condition definition. The correct subclassing would be to 1961 create IPSec or QoS-specific subclasses of policyCondition and then 1962 combine instances of these domain-specific condition classes with the 1963 validity period criteria. This is accomplished using the AND/OR 1964 association capabilities for policyConditions in policyRules. 1966 7. Security Considerations 1968 o General: See reference [10]. 1970 o Users: See reference [10]. 1972 o Administrators of Schema: In general, most LDAP-accessible 1973 directories do not permit old or out-of-date schemas, or schema 1974 elements to be deleted. Instead, they are rendered inactive. This 1975 makes it that much more important to get it right the first time on 1976 an operational system, in order to avoid complex inactive schema 1977 artifacts from lying about in the operational directory. The good 1978 news is that it is expected that large network operators will 1979 change schema design infrequently, and, when they do, the schema 1980 creation changes will be tested on an off-line copy of the 1981 directory before the operational directory is updated. Typically, 1982 a small group of directory schema administrators will be authorized 1983 to make these changes in a service provider or enterprise 1984 environment. The ability to maintain audit trails is also required 1985 here. 1987 o Administrators of Schema Content (Directory Entries): This group 1988 requires authorization to load values (entries) into a policy 1989 repository directory schema, i.e. read/write access. An audit 1990 trail capability is also required here. 1992 o Applications and Policy Consumers: These entities must be 1993 authorized for read-only access to the policy repository directory, 1994 so that they may acquire policy for the purposes of passing it to 1995 their respective enforcement entities. 1997 o Security Disciplines: 1999 o Audit Trail (Non-repudiation): In general, standardizing 2000 mechanisms for non-repudiation is outside the scope of the IETF; 2001 however, we can certainly document the need for this function in 2002 systems which maintain and distribute policy. The dependency for 2003 support of this function is on the implementers of these systems, 2004 and not on any specific standards for implementation. The 2005 requirement for a policy system is that a minimum level of 2006 auditing via an auditing facility must be provided. Logging 2007 should be enabled. This working group will not specify what this 2008 minimal auditing function consists of. 2010 o Access Control/Authorization: Access Control List (ACL) 2011 functionality must be provided. Standards for directories which 2012 use LDAPv3 as an access mechanism are still being worked on in 2013 the LDAPext working group, as of this writing. The two 2014 administrative sets of users documented above will form the basis 2015 for two administrative use cases which require support. 2017 o Authentication: In the LDAP-accessible directory case, both TLS 2018 and Kerboros are acceptable for authentication. Existing LDAP 2019 implementations provide these functions within the context of the 2020 BIND request, which is adequate. We advise against using weaker 2021 mechanisms, such as clear text and HTTP Digest. Mutual 2022 authentication is recommended. The LDAPv3 protocol supports 2023 this, but implementations vary in the functionality that they 2024 support. 2026 o Integrity/Privacy: In the LDAP-accessible directory case, TLS 2027 is acceptable for encryption and data integrity on the wire. If 2028 physical or virtual access to the policy repository is in 2029 question, it may also be necessary to encrypt the policy data as 2030 it is stored on the file system; however, specification of 2031 mechanisms for this purpose are outside the scope of this 2032 working group. In any case, we recommend that the physical 2033 server be located in a physically secure environment. 2035 In the case of Policy Consumer-to-Policy Target communications, the 2036 use of IPSEC is recommended for providing confidentiality, data 2037 origin authentication, integrity and replay prevention. See 2038 reference [11]. 2040 o Denial of Service: We recommend the use of multiple policy 2041 repository directories, such that a denial of service attack on any 2042 one directory server will not make all policy data inaccessible to 2043 legitimate users. However, this still leaves a denial of service 2044 attack exposure. Our belief is that the use of a policy schema, in 2045 a centrally administered but physically distributed policy 2046 directory, does not increase the risk of denial of service attacks; 2047 however, such attacks are still possible. If executed 2048 successfully, such an attack could prevent Policy Consumer�s from 2049 accessing a policy repository, and thus prevent them from acquiring 2050 new policy. In such a case, the Policy Consumers, and associated 2051 Policy Targets would continue operating under the policies in force 2052 before the denial of service attack was launched. Note that 2053 exposure of policy systems to denial of service attacks is not any 2054 greater than the exposure of DNS with DNSSEC in place. 2056 o Other LDAP-accessible Directory Schema Considerations: 2058 o Replication: Replication among directory copies across servers 2059 should also be protected. Replicating over connections secured 2060 by SSL or IPSEC is recommended. 2062 8. Intellectual Property 2064 The IETF takes no position regarding the validity or scope of any 2065 intellectual property or other rights that might be claimed to pertain 2066 to the implementation or use of the technology described in this 2067 document or the extent to which any license under such rights might or 2068 might not be available; neither does it represent that it has made any 2069 effort to identify any such rights. Information on the IETF's 2070 procedures with respect to rights in standards-track and standards- 2071 related documentation can be found in BCP-11. 2073 Copies of claims of rights made available for publication and any 2074 assurances of licenses to be made available, or the result of an 2075 attempt made to obtain a general license or permission for the use of 2076 such proprietary rights by implementers or users of this specification 2077 can be obtained from the IETF Secretariat. 2079 The IETF invites any interested party to bring to its attention any 2080 copyrights, patents or patent applications, or other proprietary 2081 rights which may cover technology that may be required to practice 2082 this standard. Please address the information to the IETF Executive 2083 Director. 2085 9. Acknowledgments 2087 This document is closely aligned with the work being done in the 2088 Distributed Management Task Force (DMTF) Service Level Agreements and 2089 Networks working groups. As noted, the Core Schema described here was 2090 initially defined in references [2] and [3]. We would especially like 2091 to thank Raju Rajan, Sanjay Kamat, Andrea Westerinen, Lee Rafalow, Raj 2092 Yavatkar, Glenn Waters, David Black, Michael Richardson, Mark Stevens, 2093 David Jones, and Hugh Mahon for their helpful comments. 2095 10. References 2097 [1] Strassner, J., and E. Ellesson, "Terminology for describing network 2098 policy and services", draft-ietf-policy-terms-00.txt, June 1999. 2100 [2] Bhattacharya, P., and R. Adams, W. Dixon, R. Pereira, R. Rajan, "An 2101 LDAP Schema for Configuration and Administration of IPSec based 2102 Virtual Private Networks (VPNs)", Internet-Draft work in progress, 2103 October 1998 2105 [3] Rajan, R., and J. C. Martin, S. Kamat, M. See, R. Chaudhury, D. 2106 Verma, G. Powers, R. Yavatkar, "Schema for Differentiated Services 2107 and Integrated Services in Networks", Internet-Draft work in 2108 progress, October 1998 2110 [4] Strassner, J. and S. Judd, "Directory-Enabled Networks", version 2111 3.0c5 (August 1998). 2113 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2114 Levels", BCP 14, RFC 2119, March 1997. 2116 [6] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 2117 Standards Process", BCP 11, RFC 2028, October 1996. 2119 [7] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight 2120 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2121 2252, December 1997. 2123 [8] Strassner, J., policy architecture BOF presentation, 42nd IETF 2124 Meeting, Chicago, Illinois, October, 1998 2126 [9] DMTF web site, http://www.dmtf.org. 2128 [10] Moore, B., and E. Ellesson, J. Strassner, "Policy Framework Core 2129 Information Model", draft-ietf-policy-core-info-model-02.txt, 2130 October 1999. 2132 [11] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for 2133 Policy-based Admission Control", draft-ietf-rap-framework-03.txt, 2134 June 1999. 2136 [12] Stevens, M., and W. Weiss, H. Mahon, B. Moore, J. Strassner, G. 2137 Waters, A. Westerinen, J. Wheeler, "Policy Framework", draft-ietf- 2138 policy-framework-00.txt, September, 1999. 2140 [13] Mahon, H., "Requirements for a Policy Management System", draft- 2141 ietf-policy-req-01.txt, October 1999. 2143 [14] Snir, Y., and Y. Ramberg, J. Strassner, "QoS Policy Framework 2144 Information Model", draft-ietf-qos-policy-schema-01.txt, October 2145 1999. 2147 [15] Weiss, W., and J. Strassner, A. Westerinen, "Terminology for 2148 describing network policy and services", draft-weiss-policy-device- 2149 qos-model-00.txt, June 1999. 2151 [16] Moats, R., and J. Maziarski, J. Strassner, "Extensible Match Rule 2152 to Dereference Pointers", draft-moats-ldap-dereference-match-01.txt 2153 October 1999. 2155 11. Authors' Addresses 2157 John Strassner 2158 Cisco Systems, Bldg 15 2159 170 West Tasman Drive 2160 San Jose, CA 95134 2161 Phone: +1 408-527-1069 2162 Fax: +1 408-527-1722 2163 E-mail: johns@cisco.com 2165 Ed Ellesson 2166 IBM Corporation / Tivoli, JDGA/501 2167 4205 S. Miami Blvd. 2168 Research Triangle Park, NC 27709 2169 Phone: +1 919-254-4115 2170 Fax: +1 919-254-6243 2171 E-mail: ellesson@tivoli.com 2173 Bob Moore 2174 IBM Corporation, BRQA/502 2175 4205 S. Miami Blvd. 2176 Research Triangle Park, NC 27709 2177 Phone: +1 919-254-4436 2178 Fax: +1 919-254-6243 2179 E-mail: remoore@us.ibm.com 2181 Ryan Moats 2182 15621 Drexel Circle 2183 Omaha, NE 68135 2184 USA 2185 E-mail: jayhawk@att.com 2187 12. Full Copyright Statement 2189 Copyright (C) The Internet Society (1999). All Rights Reserved. 2191 This document and translations of it may be copied and furnished to 2192 others, and derivative works that comment on or otherwise explain it 2193 or assist in its implementation may be prepared, copied, published and 2194 distributed, in whole or in part, without restriction of any kind, 2195 provided that the above copyright notice and this paragraph are 2196 included on all such copies and derivative works. However, this 2197 document itself may not be modified in any way, such as by removing 2198 the copyright notice or references to the Internet Society or other 2199 Internet organizations, except as needed for the purpose of developing 2200 Internet standards in which case the procedures for copyrights defined 2201 in the Internet Standards process must be followed, or as required to 2202 translate it into languages other than English. 2204 The limited permissions granted above are perpetual and will not be 2205 revoked by the Internet Society or its successors or assigns. 2207 This document and the information contained herein is provided on an 2208 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2209 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2210 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2211 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2212 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2214 13. Appendix: Constructing the Value of the cimName Attribute 2216 Within a CIM name space, the naming is basically flat; all instances 2217 are identified by the values of their key properties, and each 2218 combination of key values must be unique. A limited form of 2219 hierarchical naming is available in CIM by using weak relationships: 2220 since a weak relationship involves propagation of key properties and 2221 their values from the superior object to the subordinate one, the 2222 subordinate object can be thought of as being named "under" the 2223 superior object. Weak relationships are inflexible, however, because 2224 they force all instances of a class to be named in exactly the same 2225 way. For classes like PolicyCondition and PolicyAction, there needs 2226 to be a way to make a class weak to two other classes, so that a 2227 particular instance of PolicyCondition can be named within the scope 2228 either of a PolicyRule (if it's a rule-specific condition) or of a 2229 PolicyRepository (if it's a reusable condition). 2231 To add flexible hierarchical naming to CIM's mostly flat name space, 2232 two CIM properties are introduced in the abstract class 2233 ManagedElement: NamePath and SuperiorPath. SuperiorPath holds a 2234 string that identifies the CIM object serving as the superior (that 2235 is, the naming context) for the object that contains SuperiorPath. 2236 The value of NamePath is just a longer string combining first the 2237 information from SuperiorPath that identifies the superior object, and 2238 then the information from this object that identifies it within the 2239 context of its superior. 2241 SuperiorPath and NamePath share the same syntax - a NamePath is just 2242 longer than a SuperiorPath. Exact details are still being worked out 2243 in the DMTF, but here are the current syntax specifications: 2245 propvalpair := = 2246 classproplist := .[,]* 2247 NamePath := [;]* 2248 SuperiorPath := [;]* 2250 In both NamePath and SuperiorPath, the s are ordered by 2251 name scoping hierarchy; in a , the s are 2252 ordered alphabetically. Ordering the s within a 2253 makes it possible to do simple string matches on 2254 NamePath and SuperiorPath. The order of the s in a 2255 NamePath or SuperiorPath represents the hierarchy of name scopes. 2256 Spaces are suppressed between s and s, but 2257 not within convert2string(propertyvalue) results; the goal once again 2258 is to make the results of string operations predictable. 2260 The convert2string grammar is as follows: 2262 string => string 2263 boolean => "True" | "False" 2264 uintX => normal text mapping 2265 sintX => normal text mapping 2266 realX => <> 2267 datetime => directory generalized time string 2269 Let's look at two examples. In the first example there is a reusable 2270 PolicyCondition named "MyCondition" that lives in a policy repository 2271 named "MyRepository". This condition is an instance of a subclass of 2272 PolicyCondition named QosPolicyCondition. Since PolicyRepository is a 2273 subclass of System (in CIM), "MyRepository" has global naming scope. 2274 In CIM, "MyCondition" would be identified by three keys: 2276 SuperiorPath = "PolicyRepository.CCN=""PolicyRepository", 2277 PolicyRepositoryName=""MyRepository""" 2278 CCN="QosPolicyCondition" 2279 PolicyConditionName="MyCondition" 2281 The value of the non-key property NamePath for "MyCondition" would 2282 just be the value of SuperiorPath extended with the object's other 2283 keys: 2285 NamePath = "PolicyRepository.CCN=""PolicyRepository", 2286 PolicyRepositoryName=""MyRepository""; 2287 PolicyCondition.CCN=""QosPolicyCondition"", 2288 PolicyConditionName=""MyCondition""" 2290 Mapping to LDAP now, the value of the attribute cimName for 2291 "MyCondition" is the string difference (NamePath minus SuperiorPath), 2292 that is, 2293 "PolicyRepository.CCN=""PolicyRepository", 2294 PolicyRepositoryName=""MyRepository""; 2295 PolicyCondition.CCN=""QosPolicyCondition"", 2296 PolicyConditionName=""MyCondition""" 2298 minus 2300 "PolicyRepository.CCN=""PolicyRepository", 2301 PolicyRepositoryName=""MyRepository""" 2303 which equals 2305 "PolicyCondition.CCN=""QosPolicyCondition"", 2306 PolicyConditionName=""MyCondition""" 2308 In CIM, I might have a second policy condition in "MyRepository", also 2309 named "MyCondition", but it would have to instantiate a different 2310 subclass of PolicyCondition, such as BgpPolicyCondition. Assuming that 2311 the name hierarchy in CIM was mapped to DIT containment in LDAP, the 2312 entries representing these two policy conditions would both be named 2313 (that is, DIT contained) under the entry representing "MyRepository". 2314 Thus they could not be named with the policyCondition attribute, 2315 because they share the same value for this attribute: "MyCondition". 2316 With cimName, however, there is no collision. The RDN for the first 2317 condition is 2319 cimName="PolicyCondition.CCN=""QosPolicyCondition"", 2320 PolicyConditionName=""MyCondition""" 2322 while that for the second is 2324 cimName="PolicyCondition.CCN=""BgpPolicyCondition"", 2325 PolicyConditionName=""MyCondition""" 2327 For the second example, assume that "MyCondition" is a rule-specific 2328 policy condition attached to a policy rule named "MyRule". "MyRule", 2329 in turn, is named within the scope of a system named "MySystem". In 2330 CIM, "MyCondition" would once again be identified by three keys, but 2331 the value of SuperiorPath would be different: 2333 SuperiorPath = "System.CCN=""System"",Name=""MySystem""; 2334 PolicyRule.CCN=""PolicyRule", 2335 PolicyRuleName=""MyRule""" 2336 CCN="QosPolicyCondition" 2337 PolicyConditionName="MyCondition" 2339 The value of the non-key property NamePath for "MyCondition" is built 2340 up in the same way it was in the first example: 2342 NamePath = "System.CCN=""System"",Name=""MySystem""; 2343 PolicyRule.CCN=""PolicyRule", 2344 PolicyRuleName=""MyRule""; 2345 PolicyCondition.CCN=""QosPolicyCondition"", 2346 PolicyConditionName=""MyCondition""" 2348 We map to LDAP as we did before: the value of the cimName is the 2349 string difference (NamePath minus SuperiorPath), that is, 2351 "System.CCN=""System"",Name=""MySystem""; 2352 PolicyRule.CCN=""PolicyRule", 2353 PolicyRuleName=""MyRule""; 2354 PolicyCondition.CCN=""QosPolicyCondition"", 2355 PolicyConditionName=""MyCondition""" 2357 minus 2359 "System.CCN=""System"",Name=""MySystem""; 2360 PolicyRule.CCN=""PolicyRule", 2361 PolicyRuleName=""MyRule""" 2363 which equals 2365 "PolicyCondition.CCN=""QosPolicyCondition"", 2366 PolicyConditionName=""MyCondition""" 2368 It's fine for this rule-specific policy condition to have the same RDN 2369 value as the reusable one from the first example, because the two are 2370 named under different superiors in the DIT. 2372 The DMTF is currently considering how widely to apply these techniques 2373 for naming CIM objects and for mapping the objects to LDAP. 2375 EDITOR'S NOTE: The preceding discussion assumes that the DMTF will in 2376 fact approve the addition of SuperiorPath and NamePath to 2377 ManagedElement. The dependency, though, applies only to the way in 2378 which I have documented the process of creating a string for the 2379 cimName attribute. If the DMTF rejects SuperiorPath and NamePath 2380 properties, then the discussion can be recast in terms of building up 2381 the cimName string from an object's CIM class and from its key 2382 properties. The contents of the resulting string will be exactly the 2383 same as those of a string constructed according to the procedure 2384 described in this appendix.