idnits 2.17.1 draft-ietf-policy-core-schema-05.txt: -(1847): 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 39 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 40 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 202 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 255 has weird spacing: '...case is not s...' == Line 1788 has weird spacing: '...ository direc...' == Line 1841 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 (October 1999) is 8959 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 84 == Unused Reference: '6' is defined on line 1917, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1924, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1927, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1941, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1944, 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-01 ** 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-00 -- 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-00 -- 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 October 1999 8 Policy Framework LDAP Core Schema 9 draft-ietf-policy-core-schema-05.txt 10 October 05, 1999 15:16 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 Abstract 38 This document takes as its starting point the object-oriented 39 information model for representing policy information currently under 40 joint development in the Service Level Agreements (SLA) Policy working 41 group of the Distributed Management Task Force (DMTF) and in the 42 IETF's Policy Framework working group. The IETF document defining 43 this information model is the "Policy Framework Core Information 44 Model" [10]. This model defines two hierarchies of object classes: 45 structural classes representing policy information and control of 46 policies, and relationship classes that indicate how instances of the 47 structural classes are related to each other. In general, both of 48 these class hierarchies will need to be mapped to a particular data 49 store. 51 This draft defines the mapping of these information model classes to a 52 directory that uses LDAPv3 as its access protocol. When mapping to an 53 LDAP schema, the structural classes can be mapped more or less 54 directly. The relationship hierarchy, however, must be mapped to a 55 form suitable for directory implementation. Since this mapping of the 56 relationship classes could be done in a number of different ways, 57 there is the risk of non-interoperable implementations. To avoid this 58 possibility, this document provides a single mapping that all 59 implementations using an LDAP directory as their policy repository 60 SHALL use. 62 Classes are also added to the LDAP schema to improve the performance 63 of a client's interactions with an LDAP server when the client is 64 retrieving large amounts of policy-related information. These classes 65 exist only to optimize LDAP retrievals: there are no classes in the 66 information model that correspond to them. 68 The LDAP schema described in this document consists of six very 69 general classes: policy (an abstract class), policyGroup, policyRule, 70 policyConditionAuxClass, policyTimePeriodConditionAuxClass, and 71 policyActionAuxClass. The schema also contains two less general 72 classes: vendorPolicyConditionAuxClass and 73 vendorPolicyActionAuxClass. To achieve the mapping of the information 74 model's relationships, the schema contains two auxiliary classes: 75 policyGroupContainmentAuxClass and policyRuleContainmentAuxClass. 76 Capturing the distinction between rule-specific and reusable policy 77 conditions and policy actions introduces five other classes: 78 policyRuleConditionAssociation, policyRuleActionAssociation, 79 policyConditionInstance, policyActionInstance, and policyRepository. 80 Finally, the schema includes two classes policySubtreesPtrAuxClass and 81 policyElementAuxClass for optimizing LDAP retrievals. In all, 82 therefore, the schema contains 17 classes. 84 Within the context of this document, the term "Core [Policy] Schema" 85 is used to refer to the LDAP class definitions it contains. 87 Table of Contents 88 1. Introduction......................................................3 89 2. The Policy Core Information Model.................................4 90 3. Inheritance Hierarchy for the LDAP Core Policy Schema.............5 91 4. General Discussion of Mapping the Information Model to LDAP.......6 92 4.1. Summary of Class and Relationship Mappings...................6 93 4.2. Naming Attributes in the Core Schema.........................7 94 4.3. Rule-Specific and Reusable Conditions and Actions............8 95 4.4. Location and Retrieval of Policy Objects in the Directory...10 96 4.4.1. Aliases and Other DIT-Optimization Techniques.............13 97 5. Class Definitions................................................14 98 5.1. The Abstract Class "policy".................................15 99 5.2. The Class policyGroup.......................................15 100 5.3. The Class policyRule........................................17 101 5.4. The Class policyRuleConditionAssociation....................20 102 5.5. The Class policyRuleActionAssociation.......................22 103 5.6. The Class policyConditionAuxClass...........................24 104 5.7. The Class policyTimePeriodConditionAuxClass.................24 105 5.8. The Class vendorPolicyConditionAuxClass.....................26 106 5.9. The Class policyActionAuxClass..............................26 107 5.10. The Class vendorPolicyActionAuxClass.......................27 108 5.11. The Class policyConditionInstance..........................27 109 5.12. The Class policyActionInstance.............................29 110 5.13. The Auxiliary Class policyElementAuxClass..................30 111 5.14. The Class policyRepository.................................30 112 5.15. The Auxiliary Class policySubtreesPtrAuxClass..............31 113 5.15.1. The Attribute policySubtreesAuxContainedSet..............32 114 5.16. The Auxiliary Class policyGroupContainmentAuxClass.........33 115 5.16.1. The Attribute policyGroupsAuxContainedSet................33 116 5.17. The Auxiliary Class policyRuleContainmentAuxClass..........34 117 5.17.1. The Attribute policyRulesAuxContainedSet.................34 118 6. Extending the Core Schema........................................35 119 6.1. Subclassing policyCondition and policyAction................35 120 6.2. Using the Vendor Policy Encoding Attributes.................35 121 6.3. Using Time Validity Periods.................................35 122 7. Security Considerations..........................................36 123 8. Intellectual Property............................................38 124 9. Acknowledgments..................................................38 125 10. References......................................................38 126 11. Authors' Addresses..............................................39 127 12. Full Copyright Statement........................................40 129 1. Introduction 131 This document takes as its starting point the object-oriented 132 information model for representing policy information currently under 133 joint development in the Service Level Agreements working group of the 134 Distributed Management Task Force (DMTF) and in the IETF's Policy 135 Framework working group. The IETF document defining this information 136 model is the "Policy Framework Core Information Model" [10]. This 137 model defines two hierarchies of object classes: structural classes 138 representing policy information and control of policies, and 139 relationship classes that indicate how instances of the structural 140 classes are related to each other. In general, both of these class 141 hierarchies will need to be mapped to a particular data store. 143 This draft defines the mapping of these information model classes to a 144 directory that uses LDAPv3 as its access protocol. Two types of 145 mappings are involved: 147 o For the structural classes in the information model, the mapping is 148 basically one-for-one: information model classes map to LDAP 149 classes, information model properties map to LDAP attributes. 151 o For the relationship classes in the information model, different 152 mappings are possible. In this document the information model's 153 relationship classes and their properties are mapped in three ways: 154 to LDAP auxiliary classes, to attributes representing DN pointers, 155 and to containment in the Directory Information Tree (DIT). 157 Implementations that use an LDAP directory as their policy repository 158 SHALL use the LDAP policy schema defined in this document. The use of 159 the information model defined in reference [10] as the starting point 160 enables the schema and the relationship class hierarchy to be 161 extensible, such that other types of policy repositories, such as 162 relational databases, can also use this information. 164 This document fits into the overall framework for representing, 165 deploying, and managing policies being developed by the Policy 166 Framework Working Group. The initial work to define this framework is 167 in reference [1]. Current work appears in references [12] through 168 [15]. More specifically, this document builds on the core policy 169 classes first introduced in references [2] and [3]. It also draws on 170 the work done for the Directory-enabled Networks (DEN) specification, 171 reference [4]. Work on the DEN specification by the DEN Ad-Hoc 172 Working Group itself has been completed. Further work to standardize 173 the models contained in it will be the responsibility of selected 174 working groups of the Common Information Model (CIM) effort in the 175 Distributed Management Task Force (DMTF). Standardization of the core 176 policy model in the DMTF is the responsibility of the SLA Policy 177 working group. 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119, reference 182 [5]. 184 2. The Policy Core Information Model 186 This document contains an LDAP schema representing the Policy Core 187 Information Model, which is defined in the companion document "Policy 188 Framework Core Information Model" [10]. Other documents may 189 subsequently be produced, with mappings of this same Core Information 190 Model to other storage technologies. Since the detailed semantics of 191 the Core Policy classes appear only in reference [10], that document 192 is a prerequisite for reading and understanding this document. 194 3. Inheritance Hierarchy for the LDAP Core Policy Schema 196 The following diagram illustrates the class hierarchy for the LDAP 197 Core Policy Schema classes: 199 top 200 | 201 +--policy (abstract) 202 | | 203 | +--policyGroup (structural) 204 | | 205 | +--policyRule (structural) 206 | | 207 | +--policyRuleConditionAssociation (structural) 208 | | 209 | +--policyRuleActionAssociation (structural) 210 | | 211 | +--policyConditionInstance (structural) 212 | | 213 | +--policyActionInstance (structural) 214 | | 215 | +--policyElementAuxClass (auxiliary) 216 | 217 +--policyConditionAuxClass (auxiliary) 218 | | 219 | +---policyTimePeriodConditionAuxClass (auxiliary) 220 | | 221 | +---vendorPolicyConditionAuxClass (auxiliary) 222 | 223 +--policyActionAuxClass (auxiliary) 224 | | 225 | +---vendorPolicyActionAuxClass (auxiliary) 226 | 227 +--policyRepository (structural) 228 | 229 +--policySubtreesPtrAuxClass (auxiliary) 230 | 231 +--policyGroupContainmentAuxClass (auxiliary) 232 | 233 +--policyRuleContainmentAuxClass (auxiliary) 235 Figure 1. LDAP Class Inheritance Hierarchy for the Core Policy 236 Schema 238 4. General Discussion of Mapping the Information Model to LDAP 240 The classes described in Section 5 below contain certain optimizations 241 for a directory that uses LDAP as its access protocol. One example of 242 this is the use of auxiliary classes to represent some of the 243 relationships defined in the information model. Other data stores 244 might need to implement these relationships differently. A second 245 example is the introduction of classes specifically designed to 246 optimize retrieval of large amounts of policy-related data from a 247 directory. This section discusses some general topics related to the 248 mapping from the information model to LDAP. 250 4.1. Summary of Class and Relationship Mappings 252 Eight of the classes in the LDAP Core Policy Schema come directly from 253 corresponding classes in the information model. Note that names of 254 classes begin with an upper case character in the information model 255 (although for CIM in particular, case is not significant in class and 256 property names), but with a lower case character in LDAP. 258 +---------------------------+-----------------------------------+ 259 | Information Model | LDAP Class | 260 +---------------------------+-----------------------------------+ 261 +---------------------------+-----------------------------------+ 262 | Policy | policy | 263 +---------------------------+-----------------------------------+ 264 | PolicyGroup | policyGroup | 265 +---------------------------+-----------------------------------+ 266 | PolicyRule | policyRule | 267 +---------------------------+-----------------------------------+ 268 | PolicyCondition | policyConditionAuxClass | 269 +---------------------------+-----------------------------------+ 270 | PolicyAction | policyActionAuxClass | 271 +---------------------------+-----------------------------------+ 272 | VendorPolicyCondition | vendorPolicyConditionAuxClass | 273 +---------------------------+-----------------------------------+ 274 | VendorPolicyAction | vendorPolicyActionAuxClass | 275 +---------------------------+-----------------------------------+ 276 | PolicyTimePeriodCondition | policyTimePeriodConditionAuxClass | 277 +---------------------------+-----------------------------------+ 278 Figure 2. Mapping of Information Model Classes to LDAP 280 The relationships in the information model map to DN-pointer 281 attributes or to Directory Information Tree (DIT) containment in LDAP. 282 Two of the DN-pointer attributes appear in auxiliary classes, which 283 allows each of them to represent several relationships from the 284 information model. 286 +--------------------------------+-----------------------------------+ 287 | Information Model Relationship | LDAP Attribute / Class | 288 +--------------------------------+-----------------------------------+ 289 +--------------------------------+-----------------------------------+ 290 | GroupJurisdiction | policyGroupsAuxContainedSet in | 291 | | policyGroupContainmentAuxClass | 292 +--------------------------------+-----------------------------------+ 293 | PolicyGroupInPolicyGroup | policyGroupsAuxContainedSet in | 294 | | policyGroupContainmentAuxClass | 295 +--------------------------------+-----------------------------------+ 296 | RuleJurisdiction | policyRulesAuxContainedSet in | 297 | | policyRuleContainmentAuxClass | 298 +--------------------------------+-----------------------------------+ 299 | PolicyRuleInPolicyGroup | policyRulesAuxContainedSet in | 300 | | policyRuleContainmentAuxClass | 301 +--------------------------------+-----------------------------------+ 302 | ConditionInPolicyRule | DIT containment | 303 | | [+ policyConditionDN in | 304 | | policyRuleConditionAssociation] | 305 +--------------------------------+-----------------------------------+ 306 | ActionInPolicyRule | DIT containment | 307 | | [+ policyActionDN in | 308 | | policyRuleActionAssociation] | 309 +--------------------------------+-----------------------------------+ 310 | PolicyRuleValidityPeriod | policyRuleValidityPeriodList in | 311 | | policyRule | 312 +--------------------------------+-----------------------------------+ 313 | ConditionInAdminDomain | DIT containment | 314 +--------------------------------+-----------------------------------+ 315 | ActionInAdminDomain | DIT containment | 316 +--------------------------------+-----------------------------------+ 317 Figure 3. Mapping of Information Model Relationships to LDAP 319 Of the remaining classes in the LDAP Core Schema, two 320 (policyElementAuxClass, and policySubtreesPtrAuxClass) are included to 321 make navigation through the DIT and retrieval of the entries found 322 there more efficient. This topic is discussed in Section 4.4 below. 324 The remaining five classes in the LDAP Core Schema, 325 policyRuleConditionAssociation, policyRuleActionAssociation, 326 policyConditionInstance, policyActionInstance, and policyRepository 327 are all involved with the representation of policy conditions and 328 policy actions in an LDAP directory. This topic is discussed in 329 Section 4.3 below. 331 4.2. Naming Attributes in the Core Schema 333 Instances in a directory are identified by distinguished names (DNs), 334 which provide the same type of hierarchical organization that a file 335 system provides in a computer system. A distinguished name is a 336 sequence of relative distinguished names (RDNs), where an RDN provides 337 a unique identifier for an instance within the context of its 338 immediate superior, in the same way that a filename provides a unique 339 identifier for a file within the context of the folder in which it 340 resides. 342 To preserve maximum naming flexibility for policy administrators, each 343 of the structural classes defined in this schema has its own naming 344 attribute. (The naming attribute policyConditionName is used in two 345 structural class: policyRuleConditionAssociation and 346 policyConditionInstance. As discussed below in Section 4.3, these are 347 the two structural classes to which the auxiliary class 348 policyConditionAuxClass may be attached. The naming attribute 349 policyActionName is similarly associated with two structural classes.) 350 Since the naming attributes are different, a policy administrator can, 351 by using these attributes, guarantee that there will be no name 352 collisions between instances of different classes, even if the same 353 VALUE is assigned to the instances' respective naming attributes. 355 The X.500 attribute commonName (cn) is included as a MAY attribute in 356 the abstract class policy, and thus by inheritance in all of its 357 subclasses. In X.500, commonName typically functions as an RDN 358 attribute, for naming instances of such classes as X.500's person. 360 Each of the Core Schema classes thus has two attributes suitable for 361 naming: cn and its own class-specific attribute. Either of these 362 attributes MAY be used for naming an instance of a Core Schema class. 363 Consequently, implementations MUST be able to accommodate instances 364 named in either of these ways. 366 Note that since they are required ("MUST") attributes, the class- 367 specific naming attributes are always present in instances of their 368 respective classes, even if they are not being used for naming the 369 instances. In these cases the class-specific naming attributes may be 370 used for other purposes. Note that "cn" and a class-specific naming 371 attribute SHOULD NOT be used together to form a multi-part RDN, since 372 support for multi-part RDNs is limited among existing directory 373 implementations. 375 4.3. Rule-Specific and Reusable Conditions and Actions 377 The Core Information Model [10] distinguishes between two types of 378 policy conditions and policy actions: ones associated with a single 379 policy rule, and ones that are reusable, in the sense that they may be 380 associated with more than one policy rule. There is no inherent 381 difference between a rule-specific condition or action and a reusable 382 one. There are, however, differences in how they are treated in a 383 policy repository. For example, it's natural to make the access 384 permissions for a rule-specific condition or action identical to those 385 for the rule itself. It's also natural for a rule-specific condition 386 or action to be removed from the policy repository at the same time 387 the rule is. With reusable conditions and actions, on the other hand, 388 access permissions and existence criteria must be expressible without 389 reference to a policy rule. 391 The preceding paragraph does not contain an exhaustive list of the 392 ways in which reusable and rule-specific conditions should be treated 393 differently. Its purpose is merely to justify making a semantic 394 distinction between rule-specific and reusable, and then reflecting 395 this distinction in the policy repository itself. 397 When the policy repository is realized in an LDAP-accessible 398 directory, the distinction between rule-specific and reusable 399 conditions and actions is realized via DIT containment. Figure 4 400 illustrates a policy rule Rule1 with one rule-specific condition CA 401 and one rule-specific action AB. Because the condition and action are 402 specific to Rule1, the auxiliary classes ca and ab that represent them 403 are attached, respectively, to the structural classes CA and AB. 404 These structural classes represent not the condition ca and action ab 405 themselves, but rather Rule1's ASSOCIATION to ca and ab. 407 Note that the existence dependency of a rule-specific condition or 408 action on its policy rule follows in this case from the semantics of 409 DNs. Note also that for directory implementations supporting subtree- 410 based access permissions, it's easy to indicate that parties with 411 access to Rule1 also have access to its condition and action. 413 +-----+ 414 |Rule1| 415 | | 416 +-----+ 417 * * 418 * * 419 **** **** 420 * * 421 * * 422 +-----+ +-----+ 423 |CA+ca| |AB+ab| 424 +-----+ +-----+ 426 +------------------------------+ 427 |LEGEND: | 428 | ***** DIT containment | 429 | + auxiliary attachment | 430 +------------------------------+ 432 Figure 4. Rule-Specific Policy Conditions and Actions 434 Figure 5 illustrates the same policy rule Rule1, but this time its 435 condition and action are reusable. The association classes CA and AB 436 are still present, and they are still DIT contained under Rule1. But 437 rather than having the auxiliary classes ca and ab attached to 438 themselves, CA and AB now contain DN pointers to other entries to 439 which these auxiliary classes are attached. These other entries, CIA 440 and AIB, are DIT contained under RepositoryX, which is an instance of 441 the class policyRepository. Because they are named under an instance 442 of policyRepository, ca and ab are clearly identified as reusable. 444 +-----+ +-------------+ 445 |Rule1| | RepositoryX | 446 | | | | 447 +-----+ +-------------+ 448 * * * * 449 * * * * 450 **** **** * * 451 * * * * 452 * +--+ * * 453 * |AB| +------+ * 454 * | -|-------->|AIB+ab| * 455 +--+ +--+ +------+ * 456 |CA| +------+ 457 | -|------------------------->|CIA+ca| 458 +--+ +------+ 460 +------------------------------+ 461 |LEGEND: | 462 | ***** DIT containment | 463 | + auxiliary attachment | 464 | ----> DN pointer | 465 +------------------------------+ 467 Figure 5. Reusable Policy Conditions and Actions 469 The classes policyConditionAuxClass and policyActionAuxClass do not 470 themselves represent actual conditions and actions: these are 471 introduced in their subclasses. What policyConditionAuxClass and 472 policyActionAuxClass do introduce are the semantics of being a policy 473 condition or a policy action. These are the semantics that all the 474 subclasses of policyCondition and policyAction inherit. Among these 475 semantics are those of representing either a rule-specific or a 476 reusable policy condition or policy action. 478 In order to preserve the ability to represent either a rule-specific 479 or a reusable condition or action, all the subclasses of 480 policyCondition and policyAction MUST also be auxiliary classes. 482 4.4. Location and Retrieval of Policy Objects in the Directory 484 When a Policy Consumer goes to an LDAP directory to retrieve the 485 policy object instances relevant to the Policy Targets it serves, it 486 is faced with two related problems: 488 o How does it locate and retrieve the directory entries that apply to 489 its Policy Targets? These entries may include instances of the 490 Core Schema classes, instances of domain-specific subclasses of 491 these classes, and instances of other classes modeling such 492 resources as user groups, interfaces, and address ranges. 494 o How does it retrieve the directory entries it needs in an efficient 495 manner, so that retrieval of policy information from the directory 496 does not become a roadblock to scalability? There are two facets 497 to this efficiency: retrieving only the relevant directory 498 entries, and retrieving these entries using as few LDAP calls as 499 possible. 501 The placement of objects in the Directory Information Tree (DIT) 502 involves considerations other than how the policy-related objects will 503 be retrieved by a Policy Consumer. Consequently, all that the Core 504 Schema can do is to provide a "toolkit" of classes to assist the 505 policy administrator as the DIT is being designed and built. A Policy 506 Consumer SHOULD be able to take advantage of any tools that the policy 507 administrator is able to build into the DIT, but it MUST be able to 508 use a less efficient means of retrieval if that is all it has 509 available to it. 511 The basic idea behind the LDAP optimization classes is a simple one: 512 make it possible for a Policy Consumer to retrieve all the policy- 513 related objects it needs, and only those objects, using as few LDAP 514 calls as possible. An important assumption underlying this approach 515 is that the policy administrator has sufficient control over the 516 underlying DIT structure to define subtrees for storing policy 517 information. If the policy administrator does not have this level of 518 control over DIT structure, a Policy Consumer can still retrieve the 519 policy-related objects it needs individually. But it will require 520 more LDAP access operations to do the retrieval in this way. 522 Figure 6 illustrates how LDAP optimization is accomplished. 524 +-----+ 525 ---------------->| A | 526 DN pointer to | | DN pointers to subtrees +---+ 527 starting object +-----+ +------------------------->| C | 528 | o--+----+ +---+ +---+ 529 | o--+------------->| B | / \ 530 +-----+ +---+ / \ 531 / \ / \ / ... \ 532 / \ / \ 533 / \ / ... \ 535 Figure 6. Using a policyContainer Object to Scope Policies 537 The Policy Consumer is configured initially with a DN pointer to some 538 entry in the DIT. The structural class of this entry is not 539 important; the Policy Consumer is interested only in the 540 policySubtreesPtrAuxClass attached to it. This auxiliary class 541 contains a multi-valued attribute with DN pointers to objects that 542 anchor subtrees containing policy-related objects of interest to the 543 Policy Consumer. Since policySubtreesPtrAuxClass is an auxiliary 544 class, it can be attached to an entry that the Policy Consumer would 545 need to access anyway - perhaps an entry containing initial 546 configuration settings for the Policy Consumer, or for a Policy Target 547 that uses the Policy Consumer. 549 Once it has retrieved the DN pointers, the Policy Consumer will direct 550 to each of the objects identified by them an LDAP request that all 551 entries in its subtree be evaluated against the selection criteria 552 specified in the request. The LDAP-enabled directory then returns all 553 entries in that subtree that satisfy the specified criteria. 555 The selection criteria always specify that object class = "policy". 556 Since all classes representing policy rules, policy conditions, and 557 policy actions, both in the Core Schema and in any domain-specific 558 schema derived from it, are subclasses of the abstract class policy, 559 this criterion evaluates to TRUE for all instances of these classes. 560 To accommodate special cases where a Policy Consumer needs to retrieve 561 objects that are not inherently policy-related (for example, an IP 562 address range object pointed to by a subclass of policyAction 563 representing the DHCP action "assign from this address range), the 564 auxiliary class policyElementAuxClass can be used to "tag" an entry, 565 so that it will be found by the selection criterion "object class = 566 policy". 568 The approach described in the preceding paragraph will not work for 569 certain directory implementations, because these implementations do 570 not support matching of auxiliary classes in the objectClass 571 attribute. For environments where these implementations are expected 572 to be present, the "tagging" of entries as relevant to policy can be 573 accomplished by inserting the special value "POLICY" into the list of 574 values contained in the policyKeywords attribute. 576 If a Policy Consumer needs only a subset of the policy-related objects 577 in the indicated subtrees, then it can be configured with additional 578 selection criteria based on the policyKeywords attribute defined in 579 the policy class. This attribute supports both standardized and 580 administrator-defined values. Thus a Policy Consumer could be 581 configured to request only those policy-related objects containing the 582 keywords "DHCP" and "Eastern US". 584 To optimize what is expected to be a typical case, the initial request 585 from the client includes not only the object to which its "seed" DN 586 pointer points, but also the subtree contained under this object. The 587 filter for searching this subtree is whatever the client is going to 588 use later to search the other subtrees: "object class = policy", 589 presence of the keyword "POLICY", or presence of a more specific 590 policyKeyword. 592 Returning to the example in Figure 6, we see that in the best case, a 593 Policy Consumer can get all the policy-related objects it needs, and 594 only these objects, with exactly three LDAP requests: one to its 595 starting object A to get the pointers to B and C, as well as the 596 policy-related objects it needs from the subtree under A, and then one 597 each to B and C to get all the policy-related objects that pass the 598 selection criteria with which it was configured. Once it has 599 retrieved all of these objects, the Policy Consumer can then traverse 600 their various DN pointers locally to understand the semantic 601 relationships among them. The Policy Consumer should also be prepared 602 to find a pointer to another subtree attached to any of the objects it 603 retrieves, and to follow this pointer first, before it follows any of 604 the semantically significant pointers it has received. This recursion 605 permits a structured approach to identifying related policies. In 606 Figure 6, for example, if the subtree under B includes departmental 607 policies and the one under C includes divisional policies, then there 608 might be a pointer from the subtree under C to an object D that roots 609 the subtree of corporate-level policies. 611 Since a Policy Consumer has no guarantee that the entity that 612 populates the directory won't use the policySubtreesPtrAuxClass, a 613 Policy Consumer SHOULD understand this class, SHOULD be capable of 614 retrieving and processing the entries in the subtrees it points to, 615 and SHOULD be capable of doing all of this recursively. The same 616 requirements apply to any other entity needing to retrieve policy 617 information from the directory. Thus a Policy Management Tool that 618 retrieves policy entries from the directory in order to perform 619 validation and conflict detection SHOULD also understand and be 620 capable of using the policySubtreesPtrAuxClass. All of these 621 requirements are "SHOULD"s rather than "MUST"s because an LDAP client 622 that doesn't implement them can still access and retrieve the 623 directory entries it needs . The process of doing so will just be 624 less efficient than it would have been if the client had implemented 625 these optimizations. 627 When it is serving as a tool for creating policy entries in the 628 directory, a Policy Management Tool SHOULD support creation of 629 policySubtreePtrAuxClass entries and their DN pointers. 631 4.4.1. Aliases and Other DIT-Optimization Techniques 633 Additional flexibility in DIT structure is available to the policy 634 administrator via LDAP aliasing. Figure 7 illustrates this 635 flexibility. 637 +-----+ 638 ---------------->| A | 639 DN pointer to | | DN pointers to subtrees +---+ 640 starting object +-----+ +------------------------->| C | 641 | o--+----+ +---+ +---+ 642 | o--+------------->| B | / \ 643 +-----+ +---+ / \ 644 / \ / \ / ... \ 645 / \ / \ 646 / \ / \ 647 +---+ / +------+ \ 648 | X |<***************************|aliasX| 649 +---+ +------+ 651 Figure 7. Addition of an Alias Object 653 Even if it is necessary to store a policy entry X in a directory 654 location separate from the other policy entries, batch retrieval using 655 policy subtrees can still be done. The administrator simply inserts 656 into one of the subtrees of policy entries an alias entry aliasX 657 pointing to the outlying entry X. When the Policy Consumer requests 658 all entries in the subtree under B, a response will be returned for 659 entry X, just as responses are returned for all the (non-alias) 660 entries that actually are in the subtree. 662 Since resolution of an alias to its true entry is handled entirely by 663 the LDAP directory, and is invisible to directory clients, Policy 664 Consumers need not do anything extra to support aliases. A Policy 665 Management Tool MAY make available to a policy administrator the 666 ability to create alias entries like the one in Figure 7. 668 In addition to aliases, there are several other techniques for 669 managing the placement of entries in the DIT and their retrieval by 670 directory clients. Among these other techniques are referrals, LDAP 671 URLs, attributes like seeAlso, and the extensible matching rule for 672 dereferencing DN pointers discussed in reference [16]. Discussion of 673 how these other techniques might be applied to policy-related entries 674 in a directory is outside the scope of this document. 676 5. Class Definitions 678 The semantics for the LDAP classes mapped directly from the 679 information model are detailed in reference [10]. Consequently, all 680 that this document presents for these classes is a bare specification 681 of the LDAP classes and attributes. More details are provided for the 682 attributes listed above in Figure 3, which realize in LDAP the 683 relationships defined in the information model. Finally, the classes 684 that exist only in the LDAP Core Schema are documented fully in this 685 document. 687 The formal language for specifying the classes, attributes, and DIT 688 structure and content rules is that defined in reference [7]. 690 5.1. The Abstract Class "policy" 692 The abstract class "policy" is a direct mapping of the abstract class 693 Policy from the Core Information Model. The four properties in Policy 694 map directly to attributes in the class "policy". 696 The class value "policy" is also used as the mechanism for identifying 697 policy-related instances in the Directory Information Tree. An 698 instance of any class may be "tagged" with this class value by 699 attaching to it the auxiliary class policyElementAuxClass. 701 The class definition is as follows: 703 ( NAME 'policy' 704 DESC 'An abstract class with four attributes for describing 705 a policy-related instance.' 706 SUP top 707 ABSTRACT 708 MAY (cn $ caption $ description $ policyKeywords) 709 ) 711 The attributes "cn" and "description" are defined in X.520. The 712 remaining two attributes are defined as: 714 ( NAME 'caption' 715 DESC 'A one-line description of this policy-related object.' 716 SYNTAX IA5String 717 EQUALITY caseExactIA5Match 718 SINGLE-VALUE 719 ) 721 ( NAME 'policyKeywords' 722 DESC 'A set of keywords to assist directory clients in 723 locating the policy objects applicable to them. Each 724 value of the multi-valued attribute contains a single 725 keyword. Standard keyword values are listed in the 726 Policy Core Information Model document.' 727 SYNTAX IA5String 728 EQUALITY caseExactIA5Match 729 ) 731 5.2. The Class policyGroup 733 The class definition for policyGroup is as follows. Note that this 734 class definition does not include attributes to realize the 735 PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations from 736 the object model, since a policyGroup object points to instances of 737 policyGroup and policyRule via, respectively, the pointer in 738 policyGroupContainmentAuxClass and the pointer in 739 policyRuleContainmentAuxClass. 741 ( NAME 'policyGroup' 742 DESC 'A container for either a set of related policyRules or 743 a set of related policyGroups.' 744 SUP policy 745 MUST (policyGroupName) 746 ) 748 The following DIT content rule indicates that an instance of 749 policyGroup may have attached to it either DN pointers to one or more 750 other policyGroups, or DN pointers to one or more policyRules. 752 ( 753 NAME 'policyGroupContentRule' 754 DESC 'shows what auxiliary classes go with this object' 755 AUX (policyGroupContainmentAuxClass $ 756 policyRuleContainmentAuxClass) 757 ) 759 The following DIT structure rules indicate that an instance of 760 policyGroup may be named under any superior, using either the cn or 761 the policyGroupName attribute. 763 ( NAME 'policyGroupNameForm1' 764 OC policyGroup 765 MUST (cn) 766 ) 768 ( 1 NAME 'policyGroupStructuralRule1' 769 FORM policyGroupNameForm1 770 ) 772 ( NAME 'policyGroupNameForm2' 773 OC policyGroup 774 MUST (policyGroupName) 775 ) 777 ( 2 NAME 'policyGroupStructuralRule2' 778 FORM policyGroupNameForm2 779 ) 781 The one attribute of policyGroup is defined as: 783 ( NAME 'policyGroupName' 784 DESC 'The user-friendly name of this policy group.' 785 SYNTAX IA5String 786 EQUALITY caseExactIA5Match 787 SINGLE-VALUE 789 ) 791 5.3. The Class policyRule 793 This class represents the "If Condition then Action" semantics 794 associated with a policy. The conditions and actions associated with 795 a policy rule are modeled, respectively, with auxiliary subclasses of 796 the auxiliary classes policyConditionAuxClass and 797 policyActionAuxClass. Each of these auxiliary subclasses is attached 798 to an instance of one of two structural classes. A subclass of 799 policyConditionAuxClass is attached either to an instance of 800 policyRuleConditionAssociation or to an instance of 801 policyConditionInstance. Similarly, a subclass of 802 policyActionAuxClass is attached either to an instance of 803 policyRuleActionAssociation or to an instance of policyActionInstance. 805 Of the eight attributes in the policyRule class, seven are mapped 806 directly from corresponding properties in the information model. The 807 eighth attribute, policyRuleValidityPeriodList, realizes the 808 PolicyRuleValidityPeriod association from the information model. 809 Since this association has no "extra" properties (besides those that 810 tie the association to its associated objects), the attribute 811 policyRuleValidityPeriodList is simply a multi-valued DN pointer. 812 (Relationships in the information model can have "extra" properties 813 because CIM represents relationships as classes. See Sections 5.4 and 814 5.5 for examples of "extra" properties and how they are mapped to 815 LDAP.) This attribute provides an unordered set of DN pointers to one 816 or more instances of the policyTimePeriodConditionAuxClass, indicating 817 when the policy rule is scheduled to be active and when it is 818 scheduled to be inactive. A policy rule is scheduled to be active if 819 it is active according to AT LEAST ONE of the 820 policyTimePeriodConditionAuxClass instances pointed to by this 821 attribute. 823 The ConditionInPolicyRule and ActionInPolicyRule associations, 824 however, have additional properties: ActionInPolicyRule has an 825 integer to sequence the actions, and ConditionInPolicyRule has an 826 integer to group the conditions, and a Boolean to specify whether a 827 condition is to be negated. In the Core Schema, these extra 828 association properties are represented as attributes of two classes 829 introduced specifically to model the associations: 830 policyRuleConditionAssociation and policyRuleActionAssociation, 831 defined, respectively, in Sections 5.4 and 5.5. Thus they do not 832 appear as attributes of the class policyRule. 834 The class definition of policyRule is as follows: 836 ( NAME 'policyRule' 837 DESC 'The central class for representing the "If Condition 838 then Action" semantics associated with a policy rule.' 839 SUP policy 840 MUST (policyRuleName) 841 MAY (policyRuleEnabled $ policyRuleConditionListType $ 842 policyRuleValidityPeriodList $ policyRuleUsage $ 843 policyRulePriority $ policyRuleMandatory $ 844 policyRuleSequencedActions) 845 ) 847 The following DIT structure rules indicate that an instance of 848 policyRule may be named under an instance of policyGroup, where each 849 of these instances may be named using either cn or their respective 850 class-specific naming attributes. 852 EDITOR'S NOTE: This restriction that an instance of policyRule may be 853 named only under an instance of policyGroup is new -- it came in with 854 Ryan's ABNF. It's easy enough to change it to say that an instance of 855 policyRule can be named under anything, to allow for the case of a 856 deployment with so few rules that the grouping provided by policyGroup 857 is not needed. We just have to decide which way we want it. 859 ( NAME 'policyRuleNameForm1' 860 OC policyRule 861 MUST (cn) 862 ) 864 ( 3 NAME 'policyRuleStructuralRule1' 865 FORM policyRuleNameForm1 866 SUP 1 2 867 ) 869 ( NAME 'policyRuleNameForm2' 870 OC policyRule 871 MUST (policyRuleName) 872 ) 874 ( 4 NAME 'policyRuleStructuralRule2' 875 FORM policyRuleNameForm2 876 SUP 1 2 877 ) 879 The attributes of policyRule are defined as follows: 881 ( NAME 'policyRuleName' 882 DESC 'The user-friendly name of this policy rule.' 883 SYNTAX IA5String 884 EQUALITY caseExactIA5Match 885 SINGLE-VALUE 886 ) 888 ( NAME 'policyRuleEnabled' 889 DESC 'An enumeration indicating whether a policy rule is 890 administratively enabled, administratively disabled, or 891 enabled for debug mode. The defined values for this 892 attribute are enabled(1), disabled(2), and 893 enabledForDebug(3).' 894 SYNTAX INTEGER 895 EQUALITY integerMatch 896 SINGLE-VALUE 897 ) 899 ( NAME 'policyRuleConditionListType' 900 DESC 'Indicates whether the list of policy conditions 901 associated with this policy rule is in disjunctive 902 normal form (DNF) or conjunctive normal form (CNF). 903 Defined values are DNF(1) and CNF(2).' 904 SYNTAX INTEGER 905 EQUALITY integerMatch 906 SINGLE-VALUE 907 ) 909 ( NAME 'policyRuleValidityPeriodList' 910 DESC 'Distinguished names of policyTimePeriodConditions that 911 determine when the policyRule is scheduled to be active 912 / inactive. No order is implied.' 913 SYNTAX DN 914 EQUALITY distinguishedNameMatch 915 ) 917 ( NAME 'policyRuleUsage' 918 DESC 'This attribute is used to provide guidelines on how 919 this policy should be used.' 920 SYNTAX DirectoryString 921 EQUALITY caseIgnoreMatch 922 SINGLE-VALUE 923 ) 925 ( NAME 'policyRulePriority' 926 DESC 'A non-negative integer for prioritizing this policyRule 927 relative to other policyRules. A larger value indicates 928 a higher priority.' 929 SYNTAX INTEGER 930 EQUALITY integerMatch 931 SINGLE-VALUE 932 ) 934 ( NAME 'policyRuleMandatory' 935 DESC 'A flag indicating that the evaluation of the 936 policyConditions and execution of policyActions (if the 937 condition list evaluates to True) is required.' 938 SYNTAX Boolean 939 EQUALITY booleanMatch 940 SINGLE-VALUE 941 ) 943 ( NAME 'policyRuleSequencedActions' 944 DESC 'An enumeration indicating how to interpret the action 945 ordering indicated via the policyRuleActionList 946 attribute. The defined values for this attribute are 947 mandatory(1), recommended(2), and dontCare(3).' 948 SYNTAX INTEGER 949 EQUALITY integerMatch 950 ) 952 5.4. The Class policyRuleConditionAssociation 954 This class contains attributes to represent the "extra" properties of 955 the information model's ConditionInPolicyRule association. Instances 956 of this class are related to an instance of policyRule via DIT 957 containment. The policy conditions themselves are represented by 958 auxiliary subclasses of the auxiliary class policyConditionAuxClass. 959 These auxiliary classes are attached directly to instances of 960 policyRuleConditionAssociation for rule-specific policy conditions. 961 For a reusable policy condition, the auxiliary class is attached to an 962 instance of the class policyConditionInstance, and there is a DN 963 pointer to this instance from the instance of 964 policyRuleConditionAssociation. 966 The class definition is as follows: 968 ( NAME 'policyRuleConditionAssociation' 969 DESC 'The class contains attributes characterizing the 970 relationship between a policy rule and one of its 971 policy conditions.' 972 SUP policy 973 MUST (policyConditionGroupNumber $ policyConditionNegated $ 974 policyConditionName) 975 MAY (policyConditionDN) 976 ) 978 The following DIT content rule indicates that an instance of 979 policyRuleConditionAssociation may have attached to it the auxiliary 980 class policyConditionAuxClass, or one of its subclasses. This 981 combination represents a rule-specific policy condition. 983 ( 984 NAME 'policyRuleConditionAssociationContentRule' 985 DESC 'shows what auxiliary classes go with this object' 986 AUX (policyConditionAuxClass) 987 ) 989 The following DIT structure rules indicate that an instance of 990 policyRuleConditionAssociation may be named under an instance of 991 policyRule, where each of these instances may be named using either cn 992 or their respective class-specific naming attributes. 994 ( NAME 'policyRuleConditionAssociationNameForm1' 995 OC policyRuleConditionAssociation 996 MUST (cn) 997 ) 999 ( 5 NAME 'policyRuleConditionAssociationStructuralRule1' 1000 FORM policyRuleConditionAssociationNameForm1 1001 SUP 3 4 1002 ) 1004 ( NAME 'policyRuleConditionAssociationNameForm2' 1005 OC policyRuleConditionAssociation 1006 MUST (policyConditionName) 1007 ) 1009 ( 6 NAME 'policyRuleConditionAssociationStructuralRule2' 1010 FORM policyRuleConditionAssociationNameForm2 1011 SUP 3 4 1012 ) 1014 The attributes of policyRuleConditionAssociation are defined as 1015 follows. Note that the class-specific naming attribute 1016 policyConditionName is also used in the class policyConditionInstance, 1017 where it identifies a reusable policy condition. 1019 ( 1020 NAME 'policyConditionName' 1021 DESC 'A user-friendly name for a policy condition.' 1022 SYNTAX IA5String 1023 EQUALITY caseExactIA5Match 1024 SINGLE-VALUE 1025 ) 1027 ( 1028 NAME 'policyConditionGroupNumber' 1029 DESC 'The number of the group to which a policy condition 1030 belongs. These groups are used to form the DNF or 1031 CNF expression associated with a policy rule. 1032 SYNTAX INTEGER 1033 EQUALITY integerMatch 1034 SINGLE-VALUE 1035 ) 1037 ( 1038 NAME 'policyConditionNegated' 1039 DESC 'Indicates whether a policy condition is negated in 1040 the DNF or CNF expression associated with a policy 1041 rule. The value TRUE indicates that a condition is 1042 negated' 1043 SYNTAX Boolean 1044 EQUALITY booleanMatch 1045 SINGLE-VALUE 1046 ) 1047 ( 1048 NAME 'policyConditionDN' 1049 DESC 'A DN pointer to a reusable policy condition.' 1050 SYNTAX DN 1051 EQUALITY distinguishedNameMatch 1052 SINGLE-VALUE 1053 ) 1055 5.5. The Class policyRuleActionAssociation 1057 This class contains an attribute to represent the one "extra" property 1058 of the information model's ActionInPolicyRule association, which makes 1059 it possible to specify an order for executing the actions associated 1060 with a policy rule. Instances of this class are related to an 1061 instance of policyRule via DIT containment. The actions themselves 1062 are represented by auxiliary subclasses of the auxiliary class 1063 policyActionAuxClass. These auxiliary classes are attached directly 1064 to instances of policyRuleActionAssociation for rule-specific policy 1065 actions. For a reusable policy action, the auxiliary class is 1066 attached to an instance of the class policyActionInstance, and there 1067 is a DN pointer to this instance from the instance of 1068 policyRuleActionAssociation. 1070 The class definition is as follows: 1072 ( NAME 'policyRuleActionAssociation' 1073 DESC 'The class contains an attribute that represents an 1074 execution order for an action in the context of a 1075 policy rule.' 1076 SUP policy 1077 MUST (policyActionOrder $ 1078 policyActionName) 1079 MAY (policyActionDN) 1080 ) 1082 The following DIT content rule indicates that an instance of 1083 policyRuleActionAssociation may have attached to it the auxiliary 1084 class policyActionAuxClass, or one of its subclasses. This 1085 combination represents a rule-specific policy action. 1087 ( 1088 NAME 'policyRuleActionAssociationContentRule' 1089 DESC 'shows what auxiliary classes go with this object' 1090 AUX (policyActionAuxClass) 1091 ) 1093 The following DIT structure rules indicate that an instance of 1094 policyRuleActionAssociation may be named under an instance of 1095 policyRule, where each of these instances may be named using either cn 1096 or their respective class-specific naming attributes. 1098 ( NAME 'policyRuleActionAssociationNameForm1' 1099 OC policyRuleActionAssociation 1100 MUST (cn) 1101 ) 1103 ( 7 NAME 'policyRuleActionAssociationStructuralRule1' 1104 FORM policyRuleActionAssociationNameForm1 1105 SUP 3 4 1106 ) 1108 ( NAME 'policyRuleActionAssociationNameForm2' 1109 OC policyRuleActionAssociation 1110 MUST (policyActionName) 1111 ) 1113 ( 8 NAME 'policyRuleActionAssociationStructuralRule2' 1114 FORM policyRuleActionAssociationNameForm2 1115 SUP 3 4 1116 ) 1118 The attributes of policyRuleActionAssociation are defined as follows. 1119 Note that the class-specific naming attribute policyActionName is also 1120 used in the class policyActionInstance, where it identifies a reusable 1121 policy action. 1123 ( 1124 NAME 'policyActionName' 1125 DESC 'A user-friendly name for a policy action.' 1126 SYNTAX IA5String 1127 EQUALITY caseExactIA5Match 1128 SINGLE-VALUE 1129 ) 1131 ( 1132 NAME 'policyActionOrder' 1133 DESC 'An integer indicating the relative order of an action 1134 in the context of a policy rule. 1135 SYNTAX INTEGER 1136 EQUALITY integerMatch 1137 SINGLE-VALUE 1138 ) 1140 ( 1141 NAME 'policyActionDN' 1142 DESC 'A DN pointer to a reusable policy action.' 1143 SYNTAX DN 1144 EQUALITY distinguishedNameMatch 1145 SINGLE-VALUE 1146 ) 1148 5.6. The Class policyConditionAuxClass 1150 The purpose of a policy condition is to determine whether or not the 1151 set of actions (contained in the policyRule that the condition applies 1152 to) should be executed or not. This auxiliary class can be attached 1153 to instances of two other classes in the Core Policy Schema. When it 1154 is attached to an instance of policyConditionAssociation, it 1155 represents a rule-specific policy condition. When it is attached to 1156 an instance of policyConditionInstance, it represents a reusable 1157 policy condition. 1159 Since both of the classes to which this auxiliary class may be 1160 attached are derived from "policy", the attributes of "policy" will 1161 already be defined for the entries to which this class attaches. Thus 1162 this class is derived directly from "top". 1164 The class definition is as follows: 1166 ( NAME 'policyConditionAuxClass' 1167 DESC 'A class representing a condition to be evaluated in 1168 conjunction with a policy rule.' 1169 SUP top 1170 AUXILIARY 1171 ) 1173 5.7. The Class policyTimePeriodConditionAuxClass 1175 This class provides a means of representing the time periods during 1176 which a policy rule is valid, i.e., active. The class definition is 1177 as follows. Note that instances of this class are named with the 1178 attributes cn and policyConditionName that they inherit, respectively, 1179 from policy and from policyCondition. 1181 ( NAME 'policyTimePeriodConditionAuxClass' 1182 DESC 'A class that provides the capability of enabling / 1183 disabling a policy rule according to a predetermined 1184 schedule.' 1185 SUP policyConditionAuxClass 1186 AUXILIARY 1187 MAY (ptpConditionTime $ ptpConditionMonthOfYearMask $ 1188 ptpConditionDayOfMonthMask $ ptpConditionDayOfWeekMask $ 1189 ptpConditionTimeOfDayMask $ ptpConditionTimeZone) 1190 ) 1192 The attributes of policyTimePeriodConditionAuxClass are defined as 1193 follows: 1195 ( 1196 NAME 'ptpConditionTime' 1197 DESC 'The range of calendar dates on which a policy rule is 1198 valid. The format of the string is 1200 [yyyymmddhhmmss]:[yyyymmddhhmmss]' 1201 SYNTAX PrintableString 1202 EQUALITY caseIgnoreMatch 1203 SINGLE-VALUE 1204 ) 1206 ( 1207 NAME 'ptpConditionMonthOfYearMask' 1208 DESC 'A mask identifying the months of the year in which a 1209 policy rule is valid. The format is a string of 12 1210 ASCII '0's and '1's, representing the months of the 1211 year from January through December.' 1212 SYNTAX PrintableString 1213 EQUALITY caseIgnoreMatch 1214 SINGLE-VALUE 1215 ) 1217 ( 1218 NAME 'ptpConditionDayOfMonthMask' 1219 DESC 'A mask identifying the days of the month on which a 1220 policy rule is valid. The format is a string of 31 1221 ASCII '0's and '1's.' 1222 SYNTAX PrintableString 1223 EQUALITY caseIgnoreMatch 1224 SINGLE-VALUE 1225 ) 1227 ( 1228 NAME 'ptpConditionDayOfWeekMask' 1229 DESC 'A mask identifying the days of the week on which a 1230 policy rule is valid. The format is a string of seven 1231 ASCII '0's and '1's, representing the days of the week 1232 from Sunday through Saturday.' 1233 SYNTAX PrintableString 1234 EQUALITY caseIgnoreMatch 1235 SINGLE-VALUE 1236 ) 1238 ( 1239 NAME 'ptpConditionTimeOfDayMask' 1240 DESC 'The range of times at which a policy rule is valid. If 1241 the second time is earlier than the first, then the 1242 interval spans midnight. The format of the string is 1243 hhmmss:hhmmss' 1244 SYNTAX PrintableString 1245 EQUALITY caseIgnoreMatch 1246 ) 1248 ( 1249 NAME 'ptpConditionTimeZone' 1250 DESC 'The definition of the time zone for the 1251 policyTimePeriodConditionAuxClass. The format of 1252 the string is either 'Z' (UTC) or <'+'|'-'>' 1253 SYNTAX PrintableString 1254 EQUALITY caseIgnoreMatch 1255 SINGLE-VALUE 1256 ) 1258 5.8. The Class vendorPolicyConditionAuxClass 1260 The class definition is as follows: 1262 ( NAME 'vendorPolicyConditionAuxClass' 1263 DESC 'A class that defines a registered means to describe a 1264 policy condition.' 1265 SUP policyConditionAuxClass 1266 AUXILIARY 1267 MAY (vendorPolicyConstraintData $ 1268 vendorPolicyConstraintEncoding) 1269 ) 1271 The attribute definitions for vendorPolicyCondition are as follows: 1273 ( 1274 NAME 'vendorPolicyConstraintData' 1275 DESC 'Escape mechanism for representing constraints that have 1276 not been modeled as specific attributes. The format of 1277 the values is identified by the OID stored in the 1278 attribute vendorPolicyConstraintEncoding.' 1279 SYNTAX OctetString 1280 EQUALITY octetStringMatch 1281 ) 1283 ( 1284 NAME 'vendorPolicyConstraintEncoding' 1285 DESC 'An OID identifying the format and semantics for this 1286 instance"s vendorPolicyConstraintData attribute.' 1287 SYNTAX OID 1288 EQUALITY objectIdentifierMatch 1289 SINGLE-VALUE 1290 ) 1292 5.9. The Class policyActionAuxClass 1294 The purpose of a policy action is to execute one or more operations 1295 that will affect network traffic and/or systems, devices, etc. in 1296 order to achieve a desired policy state. This auxiliary class can be 1297 attached to instances of two other classes in the Core Policy Schema. 1298 When it is attached to an instance of policyActionAssociation, it 1299 represents a rule-specific policy action. When it is attached to an 1300 instance of policyActionInstance, it represents a reusable policy 1301 action. 1303 Since both of the classes to which this auxiliary class may be 1304 attached are derived from "policy", the attributes of "policy" will 1305 already be defined for the entries to which this class attaches. Thus 1306 this class is derived directly from "top". 1308 The class definition is as follows: 1310 ( NAME 'policyActionAuxClass' 1311 DESC 'A class representing an action to be performed as a 1312 result of a policy rule.' 1313 SUP top 1314 AUXILIARY 1315 ) 1317 5.10. The Class vendorPolicyActionAuxClass 1319 The class definition is as follows: 1321 ( NAME 'vendorPolicyActionAuxClass' 1322 DESC 'A class that defines a registered means to describe a 1323 policy action.' 1324 SUP policyActionAuxClass 1325 AUXILIARY 1326 MAY (vendorPolicyActionData $ vendorPolicyActionEncoding) 1327 ) 1329 The attribute definitions for vendorPolicyActionAuxClass are as 1330 follows: 1332 ( 1333 NAME 'vendorPolicyActionData' 1334 DESC 'Escape mechanism for representing actions that have not 1335 been modeled as specific attributes. The format of the 1336 values is identified by the OID stored in the attribute 1337 vendorPolicyActionEncoding.' 1338 SYNTAX OctetString 1339 EQUALITY octetStringMatch 1340 ) 1342 ( 1343 NAME 'vendorPolicyActionEncoding' 1344 DESC 'An OID identifying the format and semantics for this 1345 instance"s vendorPolicyActionData attribute.' 1346 SYNTAX OID 1347 EQUALITY objectIdentifierMatch 1348 SINGLE-VALUE 1349 ) 1351 5.11. The Class policyConditionInstance 1353 The role of this class in the Core Schema is to serve as the 1354 structural class to which the auxiliary class policyCondition is 1355 attached to form a reusable policy condition. See Section 4.3 for a 1356 complete discussion of reusable policy conditions and the role that 1357 this class plays in how they are represented. 1359 In addition to the cn attribute it inherits from "policy", this class 1360 uses the naming attribute policyConditionName, which was defined above 1361 in Section 5.4. 1363 The class definition is as follows: 1365 ( NAME 'policyConditionInstance' 1366 DESC 'A structural class that contains a reusable policy 1367 condition.' 1368 SUP policy 1369 MUST (policyConditionName) 1370 ) 1372 The following DIT content rule indicates that an instance of 1373 policyConditionInstance may have attached to it an instance of the 1374 auxiliary class policyCondition. 1376 ( 1377 NAME 'policyConditionInstanceContentRule' 1378 DESC 'shows what auxiliary classes go with this class' 1379 AUX (policyConditionAuxClass) 1380 ) 1382 The following DIT structure rules indicate that an instance of 1383 policyConditionInstance may be named under an instance of 1384 policyRepository, using either cn or its class-specific naming 1385 attribute policyConditionName. 1387 ( NAME 'policyConditionInstanceNameForm1' 1388 OC policyConditionInstance 1389 MUST (cn) 1390 ) 1392 ( 9 NAME 'policyConditionInstanceStructuralRule1' 1393 FORM policyConditionInstanceNameForm1 1394 SUP 13 14 1395 ) 1397 ( NAME 'policyConditionInstanceNameForm2' 1398 OC policyConditionInstance 1399 MUST (policyConditionName) 1400 ) 1402 ( 10 NAME 'policyConditionInstanceStructuralRule2' 1403 FORM policyConditionInstanceNameForm2 1404 SUP 13 14 1406 ) 1408 5.12. The Class policyActionInstance 1410 The role of this class in the Core Schema is to serve as the 1411 structural class to which the auxiliary class policyAction is attached 1412 to form a reusable policy action. See Section 4.3 for a complete 1413 discussion of reusable policy actions and the role that this class 1414 plays in how they are represented. 1416 In addition to the cn attribute it inherits from "policy", this class 1417 uses the naming attribute policyActionName, which was defined above in 1418 Section 5.5. 1420 The class definition is as follows: 1422 ( NAME 'policyActionInstance' 1423 DESC 'A structural class that contains a reusable policy 1424 action.' 1425 SUP policy 1426 MUST (policyActionName) 1427 ) 1429 The following DIT content rule indicates that an instance of 1430 policyActionInstance may have attached to it an instance of the 1431 auxiliary class policyAction. 1433 ( 1434 NAME 'policyActionInstanceContentRule' 1435 DESC 'shows what auxiliary classes go with this class' 1436 AUX (policyActionAuxClass) 1437 ) 1439 The following DIT structure rules indicate that an instance of 1440 policyActionInstance may be named under an instance of 1441 policyRepository, using either cn or its class-specific naming 1442 attribute policyActionName. 1444 ( NAME 'policyActionInstanceNameForm1' 1445 OC policyActionInstance 1446 MUST (cn) 1447 ) 1449 ( 11 NAME 'policyActionInstanceStructuralRule1' 1450 FORM policyActionInstanceNameForm1 1451 SUP 13 14 1452 ) 1454 ( NAME 'policyActionInstanceNameForm2' 1455 OC policyActionInstance 1456 MUST (policyActionName) 1457 ) 1459 ( 12 NAME 'policyActionInstanceStructuralRule2' 1460 FORM policyActionInstanceNameForm2 1461 SUP 13 14 1462 ) 1464 5.13. The Auxiliary Class policyElementAuxClass 1466 This class introduces no additional attributes, beyond those defined 1467 in the class "policy" from which it is derived. Its role is to "tag" 1468 an instance of a class defined outside the realm of policy as being 1469 nevertheless relevant to a policy specification. This tagging can 1470 potentially take place at two levels: 1472 o Every instance to which policyElementAuxClass is attached becomes 1473 an instance of the class "policy", since policyElementAuxClass is a 1474 subclass of "policy". Thus a DIT search with the filter 1475 "objectClass=policy" will return the instance. (As noted earlier, 1476 this approach does not work for some directory implementations. To 1477 accommodate these implementations, policy-related entries SHOULD be 1478 tagged with the keyword "POLICY".) 1480 o With the policyKeywords attribute that it inherits from "policy", 1481 an instance to which policyElementAuxClass is attached can be 1482 tagged as being relevant to a particular type or category of 1483 policy, using standard keywords, administrator-defined keywords, or 1484 both. 1486 The class definition is as follows: 1488 ( NAME 'policyElementAuxClass' 1489 DESC 'An auxiliary class used to tag instances of classes 1490 defined outside the realm of policy as relevant to a 1491 particular policy specification.' 1492 SUP policy 1493 AUXILIARY 1494 ) 1496 5.14. The Class policyRepository 1498 This class provides a container for reusable policy information, such 1499 as reusable policy conditions and/or reusable policy actions. 1501 The class definition is as follows: 1503 ( NAME 'policyRepository' 1504 DESC 'A container for reusable information.' 1505 SUP top 1506 MUST (policyRepositoryName) 1507 MAY(cn) 1509 ) 1511 The following DIT structure rules indicate that an instance of 1512 policyRepository may be named under any superior, using either the cn 1513 or the policyRepositoryName attribute. 1515 ( NAME 'policyRepositoryNameForm1' 1516 OC policyRepository 1517 MUST (cn) 1518 ) 1520 ( 13 NAME 'policyRepositoryStructuralRule1' 1521 FORM policyRepositoryNameForm1 1522 ) 1524 ( NAME 'policyRepositoryNameForm2' 1525 OC policyRepository 1526 MUST (policyRepositoryName) 1527 ) 1529 ( 14 NAME 'policyRepositoryStructuralRule2' 1530 FORM policyRepositoryNameForm2 1531 ) 1533 The one attribute of policyRepository is defined as: 1535 ( NAME 'policyRepositoryName' 1536 DESC 'The user-friendly name of this policy repository.' 1537 SYNTAX IA5String 1538 EQUALITY caseExactIA5Match 1539 SINGLE-VALUE 1540 ) 1542 5.15. The Auxiliary Class policySubtreesPtrAuxClass 1544 This auxiliary class provides a single, multi-valued attribute that 1545 points to a set of objects that are at the root of DIT subtrees 1546 containing policy-related information. By attaching this attribute to 1547 instances of various other classes, a policy administrator has a 1548 flexible way of providing an entry point into the directory that 1549 allows a client to locate and retrieve the policy information relevant 1550 to it. 1552 These entries may be placed in the DIT such that a well-known DN can 1553 be used by placing the structural entry (e.g. container) with the 1554 policySubtreesPtrAuxClass attached thereto in the root of the 1555 directory suffix. In this case, the subtree entry point can contain 1556 and/or point to all related policy entries for any well-known policy 1557 disciplines. Similarly, the subtree entry point may be placed in the 1558 DIT such that the Policy Consumer's starting point is a subtree with 1559 policy-related entries that are dependent on a hierarchically-related 1560 set of subtrees (e.g., region, division, corporate). In this latter 1561 case, DNs may be provided to the Policy Consumers via SNMP or other 1562 techniques. 1564 This object does not provide the semantic linkages between individual 1565 policy objects, such as those between a policy group and the policy 1566 rules that belong to it. Its only role is to enable efficient bulk 1567 retrieval of policy-related objects, as described in Section 4.4. 1568 Once the objects have been retrieved, a directory client can determine 1569 the semantic linkages by following DN pointers such as 1570 policyRulesAuxContainedSet locally. 1572 Since policy-related objects will often be included in the DIT subtree 1573 beneath an object to which this auxiliary class is attached, a client 1574 SHOULD request the policy-related objects from the subtree under the 1575 object with these pointers at the same time that it requests the 1576 pointers themselves. 1578 Since clients are expected to behave in this way, the policy 1579 administrator SHOULD make sure that this subtree does not contain so 1580 many objects unrelated to policy that an initial search done in this 1581 way results in a performance problem. For example, 1582 policySubtreesPtrAuxClass SHOULD NOT be attached to the partition root 1583 for a large directory partition containing a relatively few policy- 1584 related objects along with a large number of objects unrelated to 1585 policy. A better approach would be to introduce a container object 1586 immediately below the partition root, attach policySubtreesPtrAuxClass 1587 to this container object, and then place the policy-related objects in 1588 the subtree under it. 1590 The class definition is as follows: 1592 ( NAME 'policySubtreesPtrAuxClass' 1593 DESC 'An auxiliary class providing DN pointers to roots of 1594 DIT subtrees containing policy-related objects.' 1595 SUP top 1596 AUXILIARY 1597 MAY (policySubtreesAuxContainedSet) 1598 ) 1600 5.15.1. The Attribute policySubtreesAuxContainedSet 1602 This attribute provides an unordered set of DN pointers to one or more 1603 objects under which policy-related information is present. The 1604 objects pointed to may or may not themselves contain policy-related 1605 information. 1607 The attribute definition is as follows: 1609 ( 1610 NAME 'policySubtreesAuxContainedSet' 1611 DESC 'Distinguished names of objects that serve as roots for 1612 DIT subtrees containing policy-related objects. No 1613 order is implied.' 1614 SYNTAX DN 1615 EQUALITY distinguishedNameMatch 1616 ) 1618 5.16. The Auxiliary Class policyGroupContainmentAuxClass 1620 This auxiliary class provides a single, multi-valued attribute that 1621 points to a set of policyGroups. By attaching this attribute to 1622 instances of various other classes, a policy administrator has a 1623 flexible way of providing an entry point into the directory that 1624 allows a client to locate and retrieve the policyGroups relevant to 1625 it. 1627 As is the case with policyRules, a policy administrator might have 1628 several different pointers to a policyGroup in the overall directory 1629 structure. The policyGroupContainmentAuxClass is the mechanism that 1630 makes it possible for the policy administrator to define all these 1631 pointers. 1633 The class definition is as follows: 1635 ( NAME 'policyGroupContainmentAuxClass' 1636 DESC 'An auxiliary class used to bind policyGroups to an 1637 appropriate container object.' 1638 SUP top 1639 AUXILIARY 1640 MAY (policyGroupsAuxContainedSet) 1641 ) 1643 5.16.1. The Attribute policyGroupsAuxContainedSet 1645 This attribute provides an unordered set of DN pointers to one or more 1646 policyGroups associated with the instance of a structural class to 1647 which this attribute has been appended. The attribute definition is 1648 as follows: 1650 ( 1651 NAME 'policyGroupsAuxContainedSet' 1652 DESC 'Distinguished names of policyGroups associated in some 1653 way with the instance to which this attribute has been 1654 appended. No order is implied.' 1655 SYNTAX DN 1656 EQUALITY distinguishedNameMatch 1657 ) 1659 5.17. The Auxiliary Class policyRuleContainmentAuxClass 1661 This auxiliary class provides a single, multi-valued attribute that 1662 points to a set of policyRules. By attaching this attribute to 1663 instances of various other classes, a policy administrator has a 1664 flexible way of providing an entry point into the directory that 1665 allows a client to locate and retrieve the policyRules relevant to it. 1667 A policy administrator might have several different pointers to a 1668 policyRule in the overall directory structure. For example, there 1669 might be pointers to all policyRules for traffic originating in a 1670 particular subnet from a directory entry that represents that subnet. 1671 At the same time, there might be pointers to all policyRules related 1672 to a particular DiffServ setting from an instance of a policyGroup 1673 explicitly introduced as a container for DiffServ-related policyRules. 1674 The policyRuleContainmentAuxClass is the mechanism that makes it 1675 possible for the policy administrator to define all these pointers. 1677 Note that the cn attribute does NOT need to be defined for this class. 1678 This is because an auxiliary class is used as a means to collect 1679 common attributes and treat them as properties of an object. A good 1680 analogy is a #include file, except that since an auxiliary class is a 1681 class, all the benefits of a class (e.g., inheritance) can be applied 1682 to an auxiliary class. 1684 The class definition is as follows: 1686 ( NAME 'policyRuleContainmentAuxClass' 1687 DESC 'An auxiliary class used to bind policyRules to an 1688 appropriate container object.' 1689 SUP top 1690 AUXILIARY 1691 MAY (policyRulesAuxContainedSet) 1692 ) 1694 5.17.1. The Attribute policyRulesAuxContainedSet 1696 This attribute provides an unordered set of DN pointers to one or more 1697 policyRules associated with the instance of a structural class to 1698 which this attribute has been appended. The attribute definition is: 1700 ( 1701 NAME 'policyRulesAuxContainedSet' 1702 DESC 'Distinguished names of policyRules associated in some 1703 way with the instance to which this attribute has been 1704 appended. No order is implied.' 1705 SYNTAX DN 1706 EQUALITY distinguishedNameMatch 1707 ) 1709 6. Extending the Core Schema 1711 The following subsections provide general guidance on how to create a 1712 domain-specific schema derived from the Core Schema, discuss how the 1713 vendor classes in the Core Schema should be used, and explain how 1714 policyTimePeriodConditions are related to other policy conditions. 1716 6.1. Subclassing policyCondition and policyAction 1718 In Section 4.3 above, there is a discussion of how, by representing 1719 policy conditions and policy actions as auxiliary classes in a schema, 1720 the flexibility is retained to instantiate a particular condition or 1721 action as either rule-specific or reusable. This flexibility is lost 1722 if a condition or action class is defined as structural rather than 1723 auxiliary. For standardized schemata, this document specifies that 1724 domain-specific information MUST be expressed in auxiliary subclasses 1725 of policyCondition and policyAction. It is RECOMMENDED that non- 1726 standardized schemata follow this practice as well. 1728 6.2. Using the Vendor Policy Encoding Attributes 1730 As discussed Section 5.8 "The Class vendorPolicyConditionAuxClass", 1731 the attributes vendorPolicyConstraintData and 1732 vendorPolicyConstraintEncoding are included in 1733 vendorPolicyConditionAuxClass to provide an escape mechanism for 1734 representing "exceptional" policy conditions. The attributes 1735 vendorPolicyActionData and vendorPolicyActionEncoding in 1736 vendorPolicyActionAuxClass class play the same role with respect to 1737 actions. This enables interoperability between different vendors. 1739 For example, imagine a network composed of access devices from vendor 1740 A, edge and core devices from vendor B, and a policy server from 1741 vendor C. It is desirable for this policy server to be able to 1742 configure and manage all of the devices from vendors A and B. 1743 Unfortunately, these devices will in general have little in common 1744 (e.g., different mechanisms, different ways for controlling those 1745 mechanisms, different operating systems, different commands, and so 1746 forth). The escape conditions provide a way for vendor-specific 1747 commands to be encoded as OctetStrings, so that devices from different 1748 vendors can be commonly managed by a single policy server. 1750 6.3. Using Time Validity Periods 1752 Time validity periods are defined as a subclass of policyCondition, 1753 called policyTimePeriodCondition. This is to allow their inclusion in 1754 the AND/OR condition definitions for a policyRule. Care should be 1755 taken not to subclass policyTimePeriodCondition to add domain-specific 1756 condition properties. For example, it would be incorrect to add 1757 IPSec- or QoS-specific condition properties to the 1758 policyTimePeriodCondition class, just because IPSec or QoS includes 1759 time in its condition definition. The correct subclassing would be to 1760 create IPSec or QoS-specific subclasses of policyCondition and then 1761 combine instances of these domain-specific condition classes with the 1762 validity period criteria. This is accomplished using the AND/OR 1763 association capabilities for policyConditions in policyRules. 1765 7. Security Considerations 1767 o General: See reference [10]. 1769 o Users: See reference [10]. 1771 o Administrators of Schema: In general, most LDAP-accessible 1772 directories do not permit old or out-of-date schemas, or schema 1773 elements to be deleted. Instead, they are rendered inactive. This 1774 makes it that much more important to get it right the first time on 1775 an operational system, in order to avoid complex inactive schema 1776 artifacts from lying about in the operational directory. The good 1777 news is that it is expected that large network operators will 1778 change schema design infrequently, and, when they do, the schema 1779 creation changes will be tested on an off-line copy of the 1780 directory before the operational directory is updated. Typically, 1781 a small group of directory schema administrators will be authorized 1782 to make these changes in a service provider or enterprise 1783 environment. The ability to maintain audit trails is also required 1784 here. 1786 o Administrators of Schema Content (Directory Entries): This group 1787 requires authorization to load values (entries) into a policy 1788 repository directory schema, i.e. read/write access. An audit 1789 trail capability is also required here. 1791 o Applications and Policy Consumers: These entities must be 1792 authorized for read-only access to the policy repository directory, 1793 so that they may acquire policy for the purposes of passing it to 1794 their respective enforcement entities. 1796 o Security Disciplines: 1798 o Audit Trail (Non-repudiation): In general, standardizing 1799 mechanisms for non-repudiation is outside the scope of the IETF; 1800 however, we can certainly document the need for this function in 1801 systems which maintain and distribute policy. The dependency for 1802 support of this function is on the implementers of these systems, 1803 and not on any specific standards for implementation. The 1804 requirement for a policy system is that a minimum level of 1805 auditing via an auditing facility must be provided. Logging 1806 should be enabled. This working group will not specify what this 1807 minimal auditing function consists of. 1809 o Access Control/Authorization: Access Control List (ACL) 1810 functionality must be provided. Standards for directories which 1811 use LDAPv3 as an access mechanism are still being worked on in 1812 the LDAPext working group, as of this writing. The two 1813 administrative sets of users documented above will form the basis 1814 for two administrative use cases which require support. 1816 o Authentication: In the LDAP-accessible directory case, both TLS 1817 and Kerboros are acceptable for authentication. Existing LDAP 1818 implementations provide these functions within the context of the 1819 BIND request, which is adequate. We advise against using weaker 1820 mechanisms, such as clear text and HTTP Digest. Mutual 1821 authentication is recommended. The LDAPv3 protocol supports 1822 this, but implementations vary in the functionality that they 1823 support. 1825 o Integrity/Privacy: In the LDAP-accessible directory case, TLS 1826 is acceptable for encryption and data integrity on the wire. If 1827 physical or virtual access to the policy repository is in 1828 question, it may also be necessary to encrypt the policy data as 1829 it is stored on the file system; however, specification of 1830 mechanisms for this purpose are outside the scope of this 1831 working group. In any case, we recommend that the physical 1832 server be located in a physically secure environment. 1834 In the case of Policy Consumer-to-Policy Target communications, the 1835 use of IPSEC is recommended for providing confidentiality, data 1836 origin authentication, integrity and replay prevention. See 1837 reference [11]. 1839 o Denial of Service: We recommend the use of multiple policy 1840 repository directories, such that a denial of service attack on any 1841 one directory server will not make all policy data inaccessible to 1842 legitimate users. However, this still leaves a denial of service 1843 attack exposure. Our belief is that the use of a policy schema, in 1844 a centrally administered but physically distributed policy 1845 directory, does not increase the risk of denial of service attacks; 1846 however, such attacks are still possible. If executed 1847 successfully, such an attack could prevent Policy Consumer�s from 1848 accessing a policy repository, and thus prevent them from acquiring 1849 new policy. In such a case, the Policy Consumers, and associated 1850 Policy Targets would continue operating under the policies in force 1851 before the denial of service attack was launched. Note that 1852 exposure of policy systems to denial of service attacks is not any 1853 greater than the exposure of DNS with DNSSEC in place. 1855 o Other LDAP-accessible Directory Schema Considerations: 1857 o Replication: Replication among directory copies across servers 1858 should also be protected. Replicating over connections secured 1859 by SSL or IPSEC is recommended. 1861 8. Intellectual Property 1863 The IETF takes no position regarding the validity or scope of any 1864 intellectual property or other rights that might be claimed to pertain 1865 to the implementation or use of the technology described in this 1866 document or the extent to which any license under such rights might or 1867 might not be available; neither does it represent that it has made any 1868 effort to identify any such rights. Information on the IETF's 1869 procedures with respect to rights in standards-track and standards- 1870 related documentation can be found in BCP-11. 1872 Copies of claims of rights made available for publication and any 1873 assurances of licenses to be made available, or the result of an 1874 attempt made to obtain a general license or permission for the use of 1875 such proprietary rights by implementers or users of this specification 1876 can be obtained from the IETF Secretariat. 1878 The IETF invites any interested party to bring to its attention any 1879 copyrights, patents or patent applications, or other proprietary 1880 rights which may cover technology that may be required to practice 1881 this standard. Please address the information to the IETF Executive 1882 Director. 1884 9. Acknowledgments 1886 This document is closely aligned with the work being done in the 1887 Distributed Management Task Force (DMTF) Service Level Agreements and 1888 Networks working groups. As noted, the Core Schema described here was 1889 initially defined in references [2] and [3]. We would especially like 1890 to thank Raju Rajan, Sanjay Kamat, Andrea Westerinen, Lee Rafalow, Raj 1891 Yavatkar, Glenn Waters, David Black, Michael Richardson, Mark Stevens, 1892 David Jones, and Hugh Mahon for their helpful comments. Special 1893 thanks also to Ryan Moats, for providing the ABNF representation of 1894 the Core Policy Schema. 1896 10. References 1898 [1] Strassner, J., and E. Ellesson, "Terminology for describing network 1899 policy and services", draft-ietf-policy-terms-00.txt, June 1999. 1901 [2] Bhattacharya, P., and R. Adams, W. Dixon, R. Pereira, R. Rajan, "An 1902 LDAP Schema for Configuration and Administration of IPSec based 1903 Virtual Private Networks (VPNs)", Internet-Draft work in progress, 1904 October 1998 1906 [3] Rajan, R., and J. C. Martin, S. Kamat, M. See, R. Chaudhury, D. 1907 Verma, G. Powers, R. Yavatkar, "Schema for Differentiated Services 1908 and Integrated Services in Networks", Internet-Draft work in 1909 progress, October 1998 1911 [4] Strassner, J. and S. Judd, "Directory-Enabled Networks", version 1912 3.0c5 (August 1998). 1914 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1915 Levels", BCP 14, RFC 2119, March 1997. 1917 [6] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 1918 Standards Process", BCP 11, RFC 2028, October 1996. 1920 [7] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight 1921 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 1922 2252, December 1997. 1924 [8] Strassner, J., policy architecture BOF presentation, 42nd IETF 1925 Meeting, Chicago, Illinois, October, 1998 1927 [9] DMTF web site, http://www.dmtf.org. 1929 [10] Moore, B., and E. Ellesson, J. Strassner, "Policy Framework Core 1930 Information Model", draft-ietf-policy-core-info-model-01.txt, 1931 October 1999. 1933 [11] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for 1934 Policy-based Admission Control", draft-ietf-rap-framework-03.txt, 1935 June 1999. 1937 [12] Stevens, M., and W. Weiss, H. Mahon, B. Moore, J. Strassner, G. 1938 Waters, A. Westerinen, J. Wheeler, "Policy Framework", draft-ietf- 1939 policy-framework-00.txt, September, 1999. 1941 [13] Mahon, H., "Requirements for a Policy Management System", draft- 1942 ietf-policy-req-00.txt, September 1999. 1944 [14] Snir, Y., and Y. Ramberg, J. Strassner, "QoS Policy Framework 1945 Information Model", draft-ietf-qos-policy-schema-01.txt, September 1946 1999. 1948 [15] Weiss, W., and J. Strassner, A. Westerinen, "Terminology for 1949 describing network policy and services", draft-weiss-policy-device- 1950 qos-model-00.txt, June 1999. 1952 [16] Moats, R., and J. Maziarski, J. Strassner, "Extensible Match Rule 1953 to Dereference Pointers", draft-moats-ldap-dereference-match-00.txt 1954 June 1999. 1956 11. Authors' Addresses 1958 John Strassner 1959 Cisco Systems, Bldg 15 1960 170 West Tasman Drive 1961 San Jose, CA 95134 1962 Phone: +1 408-527-1069 1963 Fax: +1 408-527-1722 1964 E-mail: johns@cisco.com 1966 Ed Ellesson 1967 IBM Corporation, JDGA/501 1968 4205 S. Miami Blvd. 1969 Research Triangle Park, NC 27709 1970 Phone: +1 919-254-4115 1971 Fax: +1 919-254-6243 1972 E-mail: ellesson@raleigh.ibm.com 1974 Bob Moore 1975 IBM Corporation, JDGA/501 1976 4205 S. Miami Blvd. 1977 Research Triangle Park, NC 27709 1978 Phone: +1 919-254-4436 1979 Fax: +1 919-254-6243 1980 E-mail: remoore@us.ibm.com 1982 12. Full Copyright Statement 1984 Copyright (C) The Internet Society (1999). All Rights Reserved. 1986 This document and translations of it may be copied and furnished to 1987 others, and derivative works that comment on or otherwise explain it 1988 or assist in its implementation may be prepared, copied, published and 1989 distributed, in whole or in part, without restriction of any kind, 1990 provided that the above copyright notice and this paragraph are 1991 included on all such copies and derivative works. However, this 1992 document itself may not be modified in any way, such as by removing 1993 the copyright notice or references to the Internet Society or other 1994 Internet organizations, except as needed for the purpose of developing 1995 Internet standards in which case the procedures for copyrights defined 1996 in the Internet Standards process must be followed, or as required to 1997 translate it into languages other than English. 1999 The limited permissions granted above are perpetual and will not be 2000 revoked by the Internet Society or its successors or assigns. 2002 This document and the information contained herein is provided on an 2003 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2004 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2005 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2006 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2007 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.