idnits 2.17.1 draft-ietf-policy-core-schema-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Policy]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 491 has weird spacing: '... or polic...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Security and denial of service considerations are not explicitly considered in this memo, as they are appropriate for the underlying policy architecture. However, the policy architecture must be secure as far as the following aspects are concerned. First, the mechanisms proposed under the framework must minimize theft and denial of service threats. Second, it must be ensured that the entities (such as PEPs and PDPs) involved in policy control can verify each other's identity and establish necessary trust before communicating. The schema defined in this document MUST not compromise either of these goals. -- 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 (May 1999) is 9112 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 79 == Unused Reference: '6' is defined on line 2429, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2432, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-strassner-policy-terms-00 -- 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 2253 (ref. '7') (Obsoleted by RFC 4510, RFC 4514) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Strassner 2 Internet-draft Cisco Systems 3 Category: Standards Track E. Ellesson 4 B. Moore 5 IBM Corporation 6 May 1999 8 Policy Framework Core Information Model 9 draft-ietf-policy-core-schema-03.txt 10 May 17, 1999 15:02 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (1999). All Rights Reserved. 37 Abstract 39 This document takes as its starting point the object-oriented 40 information model for representing policy information currently under 41 development as part of the Common Information Model (CIM) activity in 42 the Desktop Management Task Force (DMTF). This CIM model defines two 43 hierarchies of object classes: structural classes representing 44 policy information and control of policies, and relationship classes 45 that indicate how instances of the structural classes are related to 46 each other. In general, both of these class hierarchies will need to 47 be mapped to a particular data store. 49 This draft defines the mapping of these DMTF-defined CIM classes to a 50 directory that uses LDAPv3 as its access protocol. When mapping to an 51 LDAP schema, the structural classes can be mapped more or less 52 directly. The relationship hierarchy, however, must be mapped to a 53 form suitable for directory implementation. Since this mapping of the 54 relationship classes could be done in a number of different ways, 55 there is the risk of non-interoperable implementations. To avoid 56 this possibility, this document provides a single mapping that all 57 implementations using an LDAP directory as their policy repository 58 SHALL use. 60 Classes are also added to the LDAP schema to improve the performance 61 of a client's interactions with an LDAP server when the client is 62 retrieving large amounts of policy-related information. These 63 classes exist only to optimize LDAP retrievals: there are no classes 64 in the CIM model that correspond to them. 66 The LDAP schema described in this document consists of six very 67 general classes: policy (an abstract class), policyGroup, policyRule, 68 policyCondition, policyTimePeriodCondition, and policyAction. The 69 schema also contains two less general classes: vendorPolicyCondition 70 and vendorPolicyAction. To achieve the mapping of the CIM 71 relationships, the schema contains two auxiliary classes: 72 policyGroupContainmentAuxClass and policyRuleContainmentAuxClass. 73 Finally, the schema includes two classes policySubtreesPtrAuxClass 74 and policyElement for optimizing LDAP retrievals, and a structural 75 class policyInstance for attaching auxiliary classes representing 76 policy conditions and policy actions. In all, therefore, the schema 77 contains 13 classes. 79 Within the context of this document, the term "Core [Policy] Schema" 80 is used to refer to the LDAP class definitions it contains. 82 Table of Contents 83 1. Introduction.....................................................4 84 2. Modeling Policies................................................6 85 2.1. Policy Scope................................................8 86 3. Overview of the Schema...........................................8 87 3.1. Relationships...............................................9 88 3.2. Associations...............................................10 89 3.3. Aggregations...............................................10 90 3.4. Key Relationships in the CIM Policy Model..................10 91 4. Inheritance Hierarchy for the LDAP Core Policy Schema...........12 92 5. General Discussion of the CIM-to-LDAP Mapping...................13 93 5.1. Summary of Class and Relationship Mappings.................13 94 5.2. Naming Attributes in the Core Schema.......................15 95 5.3. Flexibility Gained through Auxiliary Classes...............16 96 5.4. Location and Retrieval of Policy Objects in the Directory..17 97 5.4.1. Aliases..................................................19 98 6. Class Definitions...............................................20 99 6.1. The Abstract Class policy..................................20 100 6.1.1. The Attribute commonName (cn)............................21 101 6.1.2. The Attribute caption....................................21 102 6.1.3. The Attribute description................................21 103 6.1.4. The Attribute policyKeywords.............................22 104 6.2. The Class policyGroup......................................22 105 6.2.1. The Attribute policyGroupName............................24 106 6.3. The Class policyRule.......................................24 107 6.3.1. The Attribute policyRuleName.............................26 108 6.3.2. The Attribute policyRuleEnabled..........................26 109 6.3.3. The Attribute policyRuleConditionListType................27 110 6.3.4. The Attribute policyRuleConditionList....................27 111 6.3.5. The Attribute policyRuleActionList.......................29 112 6.3.6. The Attribute policyRuleValidityPeriodList...............30 113 6.3.7. The Attribute policyRuleUsage............................30 114 6.3.8. The Attribute policyRulePriority.........................31 115 6.3.9. The Attribute policyRuleMandatory........................31 116 6.3.10. The Attribute policyRuleSequencedActions................32 117 6.4. The Class policyCondition..................................32 118 6.4.1. The Attribute policyConditionName........................34 119 6.5. The Class policyTimePeriodCondition........................34 120 6.5.1. The Attribute ptpConditionTime...........................36 121 6.5.2. The Attribute ptpConditionMonthOfYearMask................36 122 6.5.3. The Attribute ptpConditionDayOfMonthMask.................37 123 6.5.4. The Attribute ptpConditionDayOfWeekMask..................37 124 6.5.5. The Attribute ptpConditionTimeOfDayMask..................38 125 6.5.6. The Attribute ptpConditionTimeZone.......................39 126 6.6. The Class vendorPolicyCondition............................39 127 6.6.1. The Attribute vendorPolicyConstraintData.................40 128 6.6.2. The Attribute vendorPolicyConstraintEncoding.............41 129 6.7. The Class policyAction.....................................41 130 6.7.1. The Attribute policyActionName...........................41 131 6.8. The Class vendorPolicyAction...............................42 132 6.8.1. The Attribute vendorPolicyActionData.....................42 133 6.8.2. The Attribute vendorPolicyActionEncoding.................43 134 6.9. The Class policyInstance...................................43 135 6.10. The Auxiliary Class policyElement.........................44 136 6.11. The Auxiliary Class policySubtreesPtrAuxClass.............44 137 6.11.1. The Attribute policySubtreesAuxContainedSet.............45 138 6.12. The Auxiliary Class policyGroupContainmentAuxClass........46 139 6.12.1. The Attribute policyGroupsAuxContainedSet...............46 140 6.13. The Auxiliary Class policyRuleContainmentAuxClass.........46 141 6.13.1. The Attribute policyRulesAuxContainedSet................47 142 7. Extending the Core Schema.......................................48 143 7.1. Subclassing policyCondition and policyAction...............48 144 7.2. Using the Vendor Policy Encoding Attributes................48 145 7.3. Using Time Validity Periods................................49 146 8. Security Considerations.........................................49 147 9. Intellectual Property...........................................49 148 10. Acknowledgments................................................50 149 11. References.....................................................50 150 12. Authors' Addresses.............................................51 151 13. Full Copyright Statement.......................................51 152 14. Appendix A - Guidelines for Construction of DNs................52 154 1. Introduction 156 This document takes as its starting point the object-oriented 157 information model for representing policy information currently under 158 development as part of the Common Information Model (CIM) activity in 159 the Desktop Management Task Force (DMTF). This CIM model defines two 160 hierarchies of object classes: structural classes representing policy 161 information and control of policies, and relationship classes that 162 indicate how instances of the structural classes are related to each 163 other. In general, both of these class hierarchies will need to be 164 mapped to a particular data store. 166 This draft defines the mapping of these DMTF-defined CIM classes to a 167 directory that uses LDAPv3 as its access protocol. Two types of 168 mappings are involved: 170 o For the structural classes in the CIM model, the mapping is 171 basically one-for-one: CIM classes map to LDAP classes, CIM 172 properties map to LDAP attributes. 174 o For the relationship classes in the CIM model, different mappings 175 are possible. In this document the CIM relationship classes and 176 their properties are mapped in three ways: to LDAP auxiliary 177 classes, to attributes representing DN pointers, and to "composite" 178 attributes representing DN pointers with additional data elements. 180 Implementations that use an LDAP directory as their policy repository 181 SHALL use the LDAP policy schema defined in this document. The use 182 of the CIM information model as the starting point enables the schema 183 and the relationship class hierarchy to be extensible, such that 184 other types of policy repositories, such as relational databases, can 185 also use this information. 187 These policy classes and their relationships are sufficiently generic 188 to allow them to represent policies related to anything. However, it 189 is expected that their initial application will be for representing 190 policies related to QoS (DiffServ and IntServ) and to IPSec. Policy 191 models for application-specific areas such as these may extend the 192 Core Schema in several ways. The preferred way is to use the 193 policyGroup, policyRule, and policyTimePeriodCondition classes 194 directly, as a foundation for representing and communicating policy 195 information. Then, specific subclasses derived from policyCondition 196 and policyAction can capture application-specific definitions of 197 conditions and actions of policies. These subclasses of 198 policyCondition and policyAction MUST be defined as auxiliary 199 classes, so that they can be used to form both simple and complex 200 policy rules, as described below in Section 5.3. 202 Two subclasses, vendorPolicyCondition and vendorPolicyAction, are 203 also included in this document, to provide a standard escape 204 mechanism for vendor-specific extensions to the Core Policy Schema. 206 This document fits into the overall framework for representing, 207 deploying, and managing policies being developed by the Policy 208 Framework Working Group. The initial work to define this framework 209 is in reference [1]. More specifically, this document builds on the 210 core policy classes first introduced in references [2] and [3]. It 211 also draws on the work done for the Directory-enabled Networks (DEN) 212 specification, reference [4]. Work on the DEN specification by the 213 DEN Ad-Hoc Working Group itself has been completed. Further work to 214 standardize the models contained in it will be the responsibility of 215 selected working groups of the CIM effort in the Desktop Management 216 Task Force (DMTF). Standardization of the core policy model is the 217 responsibility of the SLA Policy working group. 219 This document is organized in the following manner: 221 o Section 2 provides a general overview of policies and how they are 222 modeled. 224 o Section 3 takes a brief look at the DMTF's CIM policy classes and 225 relationships. The complete CIM policy definitions are available 226 on the DMTF's web site; see reference [9]. 228 o The remainder of the document presents the mapping of the CIM 229 policy classes and relationships into an LDAP schema. 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 233 document are to be interpreted as described in RFC 2119, reference 234 [5]. 236 2. Modeling Policies 238 The classes comprising the Core Policy Schema are intended to serve 239 as an extensible class hierarchy (through specialization) for 240 defining policy objects that enable application developers, network 241 administrators, and policy administrators to represent policies of 242 different types. 244 One way to think of a policy-controlled network is to first model the 245 network as a state machine and then use policy to control which state 246 a policy-controlled device should be in or is allowed to be in at any 247 given time. Given this approach, policy is applied using a set of 248 policy rules. Each policy rule consists of a set of conditions and a 249 set of actions. Policy rules may be aggregated into policy groups. 250 These groups may be nested, to represent a hierarchy of policies. 252 The set of conditions associated with a policy rule specifies when 253 the policy rule is applicable. The set of conditions can be expressed 254 as either an ORed set of ANDed sets of condition statements or an 255 ANDed set of ORed sets of statements. Individual condition statements 256 can also be negated. These combinations are termed, respectively, 257 Disjunctive Normal Form (DNF) and Conjunctive Normal Form (CNF) for 258 the conditions. Please note that it is explicitly NOT a goal of this 259 specification to represent more complicated conditions (such as those 260 that may be found in a procedural language) at this time. 262 If the set of conditions associated with a policy rule evaluates to 263 TRUE, then a set of actions that either maintain the current state of 264 the object or transition the object to a new state may be executed. 265 For the set of actions associated with a policy rule, it is possible 266 to specify an order of execution, as well as an indication of whether 267 the order is required or merely recommended. It is also possible to 268 indicate that the order in which the actions are executed does not 269 matter. 271 Policy rules themselves can be prioritized. One common reason for 272 doing this is to express an overall policy that has a general case 273 with a few specific exceptions. 275 For example, a general QoS policy rule might specify that traffic 276 originating from members of the engineering group is to get Bronze 277 Service. A second policy rule might express an exception: traffic 278 originating from John, a specific member of the engineering group, is 279 to get Gold Service. Since traffic originating from John satisfies 280 the conditions of both policy rules, and since the actions associated 281 with the two rules are incompatible, a priority needs to be 282 established. By giving the second rule (the exception) a higher 283 priority than the first rule (the general case), a policy 284 administrator can get the desired effect: traffic originating from 285 John gets Gold Service, and traffic originating from all the other 286 members of the engineering group gets Bronze Service. 288 Policies can either be used in a stand-alone fashion or aggregated 289 into policy groups to perform more elaborate functions. Stand-alone 290 policies are called policy rules. Policy groups are aggregations of 291 policy rules, or aggregations of policy groups, but not both. Policy 292 groups can model intricate interactions between objects that have 293 complex interdependencies. Examples of this include a sophisticated 294 user logon policy that sets up application access, security, and 295 reconfigures network connections based on a combination of user 296 identity, network location, logon method and time of day. A policy 297 group represents a unit of reusability and manageability in that its 298 management is handled by an identifiable group of administrators and 299 its policy rules apply equally to the scope of the policy group. 301 Stand-alone policies are those that can be expressed in a simple 302 statement. They can be represented effectively in schemata or MIBs. 303 Examples of this are VLAN assignments, simple YES/NO QoS requests, 304 and IP address allocations. A specific design goal of this schema is 305 to support both stand-alone and aggregated policies. 307 Policy groups and rules can be classified by their purpose and 308 intent. This classification is useful in querying or grouping policy 309 rules. It indicates whether the policy is used to motivate when or 310 how an action occurs, or to characterize services (that can then be 311 used, for example, to bind clients to network services). Describing 312 each of these concepts in more detail, 314 o Motivational Policies are solely targeted at whether or how a 315 policy's goal is accomplished. Configuration and Usage Policies 316 are specific kinds of Motivational Policies. Another example is 317 the scheduling of file backup based on disk write activity from 318 8am to 3pm, M-F. 320 o Configuration Policies define the default (or generic) setup of a 321 managed entity (for example, a network service). Examples of 322 Configuration Policies are the setup of a network forwarding 323 service or a network-hosted print queue. 325 o Installation Policies define what can and cannot be put on a 326 system or component, as well as the configuration of the 327 mechanisms that perform the install. Installation policies 328 typically represent specific administrative permissions, and can 329 also represent dependencies between different components (e.g., 330 to complete the installation of component A, components B and C 331 must be previously successfully installed or uninstalled). 333 o Error and Event Policies. For example, if a device fails between 334 8am and 9pm, call the system administrator, else call the Help 335 Desk. 337 o Usage Policies control the selection and configuration of 338 entities based on specific "usage" data. Configuration Policies 339 can be modified or simply re-applied by Usage Policies. Examples 340 of Usage Policies include upgrading network forwarding services 341 after a user is verified to be a member of a "gold" service 342 group, or reconfiguring a printer to be able to handle the next 343 job in its queue. 345 o Security Policies deal with verifying that the client is actually 346 who the client purports to be, permitting or denying access to 347 resources, selecting and applying appropriate authentication 348 mechanisms, and performing accounting and auditing of resources. 350 o Service Policies characterize network and other services (not use 351 them). For example, all wide-area backbone interfaces shall use a 352 specific type of queuing. 354 Service policies describe services available in the network. 355 Usage policies describe the particular binding of a client of the 356 network to services available in the network. 358 These categories are represented in the Core Schema by special values 359 defined for the policyKeywords attribute of the abstract class 360 policy. 362 2.1. Policy Scope 364 Policies represent business goals and objectives. A translation must 365 be made between these goals and objectives and their realization in 366 the network. An example of this could be a Service Level Agreement 367 (SLA), and its objectives and metrics (Service Level Objectives, or 368 SLOs), that are used to specify services that the network will 369 provide for a given client [8]. The SLA will usually be written in 370 high-level business terminology. SLOs address more specific metrics 371 in support of the SLA. These high-level descriptions of network 372 services and metrics must be translated into lower-level, but also 373 vendor- and device-independent specifications. The Core Schema 374 classes are intended to serve as the foundation for these vendor- and 375 device-independent specifications. 377 It is envisioned that the definition of policy in this draft is 378 generic in nature and is applicable to Quality of Service (QoS), to 379 non-QoS networking applications (e.g., DHCP and IPSEC), and to non- 380 networking applications (e.g., backup policies, auditing access, 381 etc.). 383 3. Overview of the Schema 385 The following diagram provides an overview of the five central 386 classes comprising the CIM core policy schema, and their 387 relationships to each other. Note that the abstract class Policy and 388 the two extension classes VendorPolicyCondition and 389 VendorPolicyAction are not shown. 391 (various other CIM classes) 392 ^ 0..n ^ 0..n 393 * * 394 * RuleJurisdiction * GroupJurisdiction 395 * * 396 * ******************** 397 * * 398 * * ************** 399 * * * * 400 * * 0..n * * ContainedPolicyGroup 401 * * +------v------+ * 402 * ****> PolicyGroup <****** 403 * 0..n| | 0..n 404 * +------^------+ 405 * 0..n * 406 * * ContainedPolicyRule 407 * 0..n * 408 * +------v------+ 409 * | | 410 * | PolicyRule | 411 * | | ContainedPolicyCondition 412 *******> <**************************** 413 0..n | | 0..n * 414 | | * 0..n 415 | | +---------v------------+ 416 | | | PolicyCondition | 417 | | +----------------------+ 418 | | PolicyRuleValidityPeriod ^ 419 | <****************** I 420 | | 0..n * I 421 | | * 0..n ^ 422 | | +----v----------------------+ 423 | | | PolicyTimePeriodCondition | 424 | | +---------------------------+ 425 | | 426 | | ContainedPolicyAction 427 | <***************************** 428 | | 0..n * 429 | | * 0..n 430 | | +----------v-----------+ 431 | | | PolicyAction | 432 +-------------+ +----------------------+ 434 Figure 1. Overview of the CIM Policy Classes and Their 435 Relationships 437 3.1. Relationships 439 Relationships are a central feature of information models. A 440 relationship represents a physical or conceptual connection between 441 objects. CIM and DEN define the general concept of an association 442 between two (or more) objects. Two types of associations are 443 aggregations (which express whole-part relationships) and other 444 relationships, such as those that express dependency. Both are used 445 in this model. 447 3.2. Associations 449 An association is a class that contains two or more references, where 450 each reference identifies another object. An association is defined 451 using a class. Associations can be defined between classes without 452 affecting any of the related classes. That is, addition of an 453 association does not affect the interface of the related classes. 455 3.3. Aggregations 457 An aggregation is a strong form of an association. An aggregation is 458 usually used to represent a "whole-part" relationship. This type of 459 relationship defines the containment relationship between a system 460 and the components that make up the system. Aggregation often 461 implies, but does not require, that the aggregated objects have 462 mutual dependencies. 464 3.4. Key Relationships in the CIM Policy Model 466 The following relationships are shown in the preceding figure: 468 o The ContainedPolicyGroup relationship enables policy groups to be 469 nested. This is critical for scalability and manageability, as it 470 enables complex policies to be constructed from multiple simpler 471 policies for administrative convenience. For example, a policy 472 group representing policies for the US might have nested within 473 it policy groups for the Eastern and Western US. 475 In the LDAP schema, the ContainedPolicyGroup relationship is 476 mapped to the policyGroupsAuxContainedSet attribute in the 477 auxiliary class policyGroupContainmentAuxClass. (Other data 478 stores may define a different mapping). This attribute enables a 479 policyGroup to identify another policyGroup as its offspring. 481 o A policy group may aggregate one or more policy rules, via the 482 ContainedPolicyRule relationship. Grouping of policy rules into a 483 policy group is again for administrative convenience; a policy 484 rule may also be used by itself, without belonging to a policy 485 group. In the LDAP schema, the ContainedPolicyRule relationship 486 is mapped to the policyRulesAuxContainedSet attribute in the 487 auxiliary class policyRuleContainmentAuxClass. 489 o A policy group or policy rule may also be aggregated by an 490 instance of any class to which the policyGroupContainmentAuxClass 491 or policyRuleContainmentAuxClass class has been attached. Again, 492 this is for administrative convenience. If the directory entry 493 to which the policyGroupContainmentAuxClass or 494 policyRuleContainmentAuxClass has been attached is a policy 495 group, then the pointer in the auxiliary class realizes one of 496 the relationships discussed above; a separate attribute is not 497 needed in the policyGroup class. If the directory entry is 498 something other than a policy group, then the pointer in the 499 auxiliary class realizes a Jurisdiction relationship from the CIM 500 model. 502 o A policy rule aggregates zero or more instances of the 503 PolicyCondition class, via the ContainedPolicyCondition 504 association. A policy rule that aggregates zero policy 505 conditions is not a valid rule -- it may, for example, be in the 506 process of being entered into the policy repository. A policy 507 rule has no effect until it is valid. The conditions aggregated 508 by a policy rule are grouped into two levels of lists: either an 509 ORed set of ANDed sets of conditions (DNF, the default) or an 510 ANDed set of ORed sets of conditions (CNF). Individual 511 conditions in these lists may be negated. The attribute 512 PolicyRuleConditionListType specifies which of these two grouping 513 schemes applies to a particular PolicyRule. 515 Since conditions may be defined explicitly in a subclass of 516 PolicyRule, the AND/OR mechanism to combine these conditions with 517 other (associated) PolicyConditions MUST be specified by the 518 PolicyRule's subclass. 520 In either case, the conditions are used to determine whether to 521 perform the actions associated with the PolicyRule. 523 o One or more policy time periods may be among the conditions 524 associated with a policy rule via the ContainedPolicyCondition 525 association. In this case, the time periods are simply 526 additional conditions to be evaluated along with any other 527 conditions specified for the rule. 529 o A different relationship between a policy rule and a policy time 530 period is represented by the PolicyRuleValidityPeriod 531 association: scheduled activation and deactivation of the policy 532 rule. If a policy rule is associated with multiple policy time 533 periods via this association, then the rule is active if at least 534 one of the time periods indicates that it is active. (In other 535 words, the time periods are ORed to determine whether the rule is 536 active.) A policy time period may be aggregated by multiple 537 policy rules. A rule that does not point to a policy time period 538 via this association is, from the point of view of scheduling, 539 always active. It may, however, be inactive for other reasons. 541 Time periods are a general concept that can be used in other 542 applications. However, they are mentioned explicitly here in this 543 specification since they are frequently used in policy 544 applications. 546 o A policy rule may aggregate zero or more policy actions. A 547 policy rule that aggregates zero policy actions is not a valid 548 rule -- it may, for example, be in the process of being entered 549 into the policy repository. A policy rule has no effect until it 550 is valid. The actions associated with a PolicyRule may be given 551 a required order, a recommended order, or no order at all. For 552 actions represented as separate objects, the 553 ContainedPolicyAction aggregation can be used to express an 554 order. For actions defined explicitly in a subclass of 555 PolicyRule, the ordering mechanism must be specified in the 556 subclass definition. 558 4. Inheritance Hierarchy for the LDAP Core Policy Schema 560 The following diagram illustrates the class hierarchy for the LDAP 561 policy schema classes: 563 top 564 | 565 +--policy (abstract) 566 | | 567 | +---policyGroup (structural) 568 | | 569 | +---policyRule (structural) 570 | | 571 | +---policyCondition (auxiliary) 572 | | | 573 | | +---policyTimePeriodCondition (auxiliary) 574 | | | 575 | | +---vendorPolicyCondition (auxiliary) 576 | | 577 | +---policyAction (auxiliary) 578 | | | 579 | | +---vendorPolicyAction (auxiliary) 580 | | 581 | +--policyInstance (structural) 582 | | 583 | +--policyElement (auxiliary) 584 | 585 +--policySubtreesPtrAuxClass (auxiliary) 586 | 587 +--policyGroupContainmentAuxClass (auxiliary) 588 | 589 +--policyRuleContainmentAuxClass (auxiliary) 591 Figure 2. LDAP Class Inheritance Hierarchy for the Core Policy 592 Schema 594 5. General Discussion of the CIM-to-LDAP Mapping 596 The classes described in Section 6 below contain certain 597 optimizations for a directory that uses LDAP as its access protocol. 598 One example of this is the use of auxiliary classes to represent CIM 599 relationships. Other data stores might need to implement these 600 relationships differently. A second example is the introduction of 601 classes specifically designed to optimize retrieval of large amounts 602 of policy-related data from a directory. This section discusses some 603 general topics related to the mapping from CIM to LDAP. 605 5.1. Summary of Class and Relationship Mappings 607 Eight of the classes in the LDAP Core Policy Schema come directly 608 from corresponding CIM classes. Note that names of classes begin 609 with an upper case character in CIM, but with a lower case character 610 in LDAP. 612 +---------------------------+---------------------------+ 613 | CIM Class | LDAP Class | 614 +---------------------------+---------------------------+ 615 +---------------------------+---------------------------+ 616 | Policy | policy | 617 +---------------------------+---------------------------+ 618 | PolicyGroup | policyGroup | 619 +---------------------------+---------------------------+ 620 | PolicyRule | policyRule | 621 +---------------------------+---------------------------+ 622 | PolicyCondition | policyCondition | 623 +---------------------------+---------------------------+ 624 | PolicyAction | policyAction | 625 +---------------------------+---------------------------+ 626 | VendorPolicyCondition | vendorPolicyCondition | 627 +---------------------------+---------------------------+ 628 | VendorPolicyAction | vendorPolicyAction | 629 +---------------------------+---------------------------+ 630 | PolicyTimePeriodCondition | policyTimePeriodCondition | 631 +---------------------------+---------------------------+ 632 Figure 3. Mapping of CIM Structural Classes to LDAP 634 The relationships in the CIM model map to pointer attributes in LDAP. 635 Two of these attributes appear in auxiliary classes, which allows 636 each of them to represent several CIM associations. 638 +--------------------------+---------------------------------+ 639 | CIM Relationship | LDAP Attribute / Class | 640 +--------------------------+---------------------------------+ 641 +--------------------------+---------------------------------+ 642 | GroupJurisdiction | policyGroupsAuxContainedSet in | 643 | | policyGroupContainmentAuxClass | 644 +--------------------------+---------------------------------+ 645 | ContainedPolicyGroup | policyGroupsAuxContainedSet in | 646 | | policyGroupContainmentAuxClass | 647 +--------------------------+---------------------------------+ 648 | RuleJurisdiction | policyRulesAuxContainedSet in | 649 | | policyRuleContainmentAuxClass | 650 +--------------------------+---------------------------------+ 651 | ContainedPolicyRule | policyRulesAuxContainedSet in | 652 | | policyRuleContainmentAuxClass | 653 +--------------------------+---------------------------------+ 654 | ContainedPolicyCondition | policyRuleConditionList in | 655 | | policyRule | 656 +--------------------------+---------------------------------+ 657 | ContainedPolicyAction | policyRuleActionList in | 658 | | policyRule | 659 +--------------------------+---------------------------------+ 660 | PolicyRuleValidityPeriod | policyRuleValidityPeriodList in | 661 | | policyRule | 662 +--------------------------+---------------------------------+ 663 Figure 4. Mapping of CIM Relationships to LDAP 664 The remaining classes in the LDAP Core Schema (policyInstance, 665 policyElement, and policySubtreesPtrAuxClass) are all included to 666 make navigation through the Directory Information Tree (DIT) and 667 retrieval of the entries found there more efficient. This topic is 668 discussed in Section 5.4 below. 670 5.2. Naming Attributes in the Core Schema 672 Instances in a directory are identified by distinguished names (DNs), 673 which provide the same type of hierarchical organization that a file 674 system provides in a computer system. A distinguished name is a 675 sequence of relative distinguished names (RDNs), where an RDN 676 provides a unique identifier for an instance within the context of 677 its immediate superior, in the same way that a filename provides a 678 unique identifier for a file within the context of the folder in 679 which it resides. 681 To preserve maximum naming flexibility for policy administrators, 682 each of the structural classes defined in this schema has its own 683 naming attribute. (The structural class policyInstance gets its 684 naming attribute from one of two auxiliary classes defined in the 685 schema: either policyConditionName from the auxiliary class 686 policyCondition, or policyActionName from the auxiliary class 687 policyAction.) Since the naming attributes are different, a policy 688 administrator can, by using these attributes, guarantee that there 689 will be no name collisions between instances of different classes, 690 even if the same VALUE is assigned to the instances' respective 691 naming attributes. 693 The X.500 attribute commonName (cn) is included as a MAY attribute in 694 the abstract class policy, and thus by inheritance in policyGroup, 695 policyRule, policyCondition, policyAction, policyInstance, 696 policyElement, and all of their subclasses. In X.500 commonName 697 typically functions as an RDN attribute, for naming instances of such 698 classes as X.500's person. It has a different role in the Core 699 Schema, however: to hold a short, human-friendly text string to be 700 displayed on a user interface. 702 To avoid the interoperability problems that could arise if different 703 implementations took different approaches to naming their policy- 704 related instances, the following constraints apply: 706 o A management tool or other entity that creates policy-related 707 instances SHOULD NOT use the commonName (cn) attribute for naming 708 these instances, that is, SHOULD NOT use cn as the attribute for an 709 instance's final RDN. 711 o A PDP or other entity that retrieves policy-related instances 712 SHOULD NOT take any action that presupposes these instances are 713 named with the commonName (cn) attribute. 715 5.3. Flexibility Gained through Auxiliary Classes 717 A key feature of the Core Schema is the use of auxiliary classes for 718 modeling policy conditions and policy actions. These auxiliary 719 classes make it possible to model a policy rule in two different 720 ways: 722 o Simple Policy Rule: The conditions and/or the actions for the rule 723 are attached to the rule object itself. 725 o Complex Policy Rule: The conditions and/or the actions for the 726 rule are attached to instances of the structural class 727 policyInstance, and these instances are pointed to by one of three 728 attributes in the policy rule object - policyRuleConditionList, 729 policyRuleActionList, or policyRuleValidityPeriodList (for the 730 special case of a policyTimePeriodCondition object). 732 The simple/complex distinction for a policy rule is not all or 733 nothing. A policy rule may have its conditions attached to itself 734 and its actions attached to instances of policyInstance, or it may 735 have its actions attached to itself and its conditions attached to 736 instances of policyInstance. However, it SHALL NOT have either its 737 conditions or its actions attached both to itself and to instances of 738 policyInstance, with one exception: a policy rule may point to its 739 validity periods with the policyRuleValidityPeriodList attribute, but 740 have its other conditions attached to itself. 742 The tradeoffs between simple and complex policy rules are between the 743 efficiency of simple rules and the flexibility and greater potential 744 for reuse of complex rules. With a simple policy rule, the semantic 745 options are limited: 747 o All conditions are ANDed together. This combination can be 748 represented in two ways in the DNF / CNF expressions 749 characteristic of policy conditions: as a DNF expression with a 750 single AND group, or as a CNF expression with multiple single- 751 condition OR groups. The first of these is arbitrarily chosen as 752 the representation for the ANDed conditions in a simple policy 753 rule. 755 o If multiple actions are included, no order can be specified for 756 them. 758 Thus if a policy administrator needs to combine conditions in some 759 other way, or if there is a set of actions that must be ordered, then 760 the only option is to use a complex policy rule. The cost of a 761 complex rule lies in the overhead of following DN pointers from the 762 rule object to condition and/or action objects. Section 5.4 below 763 describes a technique for minimizing this overhead, by making the 764 following of these pointers a local operation for a PDP. 766 Note that whether a policy condition or policy action is represented 767 as simple or complex has no effect on the relationship cardinality 768 between the condition or action and the policy rule that aggregates 769 it. 771 The classes policyCondition and policyAction do not themselves 772 represent actual conditions and actions: these are introduced in 773 subclasses of policyCondition and policyAction. What policyCondition 774 and policyAction do introduce, in addition to the naming attributes 775 policyConditionName and policyActionName, are the semantics of being 776 a policy condition or a policy action. These are the semantics that 777 all the subclasses of policyCondition and policyAction inherit. 778 Among these semantics are those of being an object to which, 779 respectively, the policyRuleConditionList and policyRuleActionList 780 attributes may point. 782 In order to preserve the flexibility of attaching either to 783 policyRule or to policyInstance, all the subclasses of 784 policyCondition and policyAction MUST also be auxiliary classes. 786 5.4. Location and Retrieval of Policy Objects in the Directory 788 When a PDP goes to an LDAP directory to retrieve the policy object 789 instances relevant to the PEPs it serves, it is faced with two 790 related problems: 792 o How does it locate and retrieve the directory entries that apply to 793 its PEPs? These entries may include instances of the Core Schema 794 classes, instances of domain-specific subclasses of these classes, 795 and instances of other classes modeling such resources as user 796 groups, interfaces, and address ranges. 798 o How does it retrieve the directory entries it needs in an efficient 799 manner, so that retrieval of policy information from the directory 800 does not become a roadblock to scaleability? There are two facets 801 to this efficiency: retrieving only the relevant directory 802 entries, and retrieving these entries using as few LDAP calls as 803 possible. 805 The placement of objects in the Directory Information Tree (DIT) 806 involves considerations other than how the policy-related objects 807 will be retrieved by a PDP. Consequently, all that the Core Schema 808 can do is to provide a "toolkit" of classes to assist the policy 809 administrator as the DIT is being designed and built. A PDP must be 810 able to take advantage of any tools that the policy administrator is 811 able to build into the DIT, but also able to use a less efficient 812 means of retrieval if that is all it has available to it. 814 The basic idea behind the LDAP optimization classes is a simple one: 815 make it possible for a PDP to retrieve all the policy-related objects 816 it needs, and only those objects, using as few LDAP calls as 817 possible. Figure 5 illustrates how these goals can be accomplished. 819 +-----+ 820 ---------------->| A | 821 DN pointer to | | DN pointers to subtrees +---+ 822 starting object +-----+ +------------------------->| C | 823 | o--+----+ +---+ +---+ 824 | o--+------------->| B | / \ 825 +-----+ +---+ / \ 826 / \ / ... \ 827 / \ 828 / ... \ 830 Figure 5. Using a policyContainer Object to Scope Policies 832 The PDP is configured initially with a DN pointer to some entry in 833 the DIT. The structural class of this entry is not important; the 834 PDP is interested only in the policySubtreesPtrAuxClass attached to 835 it. This auxiliary class contains a multi-valued attribute with DN 836 pointers to objects that anchor subtrees containing policy-related 837 objects of interest to the PDP. Since policySubtreesPtrAuxClass is 838 an auxiliary class, it can be attached to an entry that the PDP would 839 need to access anyway - perhaps an entry containing initial 840 configuration settings for the PDP, or for a PEP that uses the PDP. 842 Once it has retrieved the DN pointers, the PDP will direct to each of 843 the objects identified by them an LDAP request that all entries in 844 its subtree be evaluated against the selection criteria specified in 845 the request. The LDAP-enabled directory then,returns all entries in 846 that subtree that satisfy the specified criteria. 848 The selection criteria always specify that object class = "policy". 849 Since all classes representing policy rules, policy conditions, and 850 policy actions, both in the Core Schema and in any domain-specific 851 schema derived from it, are subclasses of the abstract class policy, 852 this criterion evaluates to TRUE for all instances of these classes. 853 To accommodate special cases where a PDP needs to retrieve objects 854 that are not inherently policy-related (for example, an IP address 855 range object pointed to by a subclass of policyAction representing 856 the DHCP action "assign from this address range), the auxiliary class 857 policyElement can be used to "tag" an entry, so that it will be found 858 by the selection criterion "object class = policy". 860 The approach described in the preceding paragraph will not work for 861 certain directory implementations, because these implementations do 862 not support matching of auxiliary classes in the objectClass 863 attribute. For environments where these implementations are expected 864 to be present, the "tagging" of entries as relevant to policy can be 865 accomplished by inserting the special value "POLICY" into the list of 866 values contained in the policyKeywords attribute. 868 In a PDP needs only a subset of the policy-related objects in the 869 indicated subtrees, then it can be configured with additional 870 selection criteria based on the policyKeywords attribute defined in 871 the policy class. This attribute supports both standardized and 872 administrator-defined values. Thus a PDP could be configured to 873 request only those policy-related objects containing the keywords 874 "DHCP" and "Eastern US". 876 Returning to the example in Figure 5, we see that in the best case, a 877 PDP can get all the policy-related objects it needs, and only these 878 objects, with exactly three LDAP requests: one to its starting 879 object to get the pointers to B and C, and then one each to B and C 880 to get all the policy-related objects that pass the selection 881 criteria with which it was configured. Once it has retrieved all of 882 these objects, the PDP can then traverse their various DN pointers 883 locally to understand the semantic relationships among them. The PDP 884 must also be prepared to find a pointer to another subtree attached 885 to any of the objects it retrieves, and to follow this pointer first, 886 before it follows any of the semantically significant pointers it has 887 received. This recursion permits a structured approach to 888 identifying related policies. In Figure 5, for example, if the 889 subtree under B includes departmental policies and the one under C 890 includes divisional policies, then there might be a pointer from the 891 subtree under C to an object D that roots the subtree of corporate- 892 level policies. 894 Since a PDP has no guarantee that the entity that populates the 895 directory won't use the policySubtreesPtrAuxClass, a PDP MUST 896 understand this class, MUST be capable of retrieving and processing 897 the entries in the subtrees it points to, and MUST be capable of 898 doing all of this recursively. The same requirements apply to any 899 other entity needing to retrieve policy information from the 900 directory. Thus a Policy Management Tool that retrieves policy 901 entries from the directory in order to perform validation and 902 conflict detection MUST also understand and be capable of using the 903 policySubtreesPtrAuxClass. 905 When it is serving as a tool for creating policy entries in the 906 directory, a Policy Management Tool SHOULD support creation of 907 policySubtreePrtAuxClass entries and their DN pointers. 909 5.4.1. Aliases 911 Additional flexibility in DIT structure is available to the policy 912 administrator via LDAP aliasing. Figure 6 illustrates this 913 flexibility. 915 +-----+ 916 ---------------->| A | 917 DN pointer to | | DN pointers to subtrees +---+ 918 starting object +-----+ +------------------------->| C | 919 | o--+----+ +---+ +---+ 920 | o--+------------->| B | / \ 921 +-----+ +---+ / \ 922 / \ / ... \ 923 / \ 924 / \ 925 +---+ / +------+ \ 926 | X |<********|aliasX| 927 +---+ +------+ 929 Figure 6. Addition of an Alias Object 931 Even if it is necessary to store a policy entry X in a directory 932 location separate from the other policy entries, batch retrieval 933 using policy subtrees can still be done. The administrator simply 934 inserts into one of the subtrees of policy entries an alias entry 935 aliasX pointing to the outlying entry X. When the PDP requests all 936 entries in the subtree under B, a response will be returned for entry 937 X, just as responses are returned for all the (non-alias) entries 938 that actually are in the subtree. 940 Since resolution of an alias to its true entry is handled entirely by 941 the LDAP directory, and is invisible to directory clients, PDPs need 942 not do anything extra to support aliases. A Policy Management Tool 943 MAY make available to a policy administrator the ability to create 944 alias entries like the one in Figure 6. 946 6. Class Definitions 948 6.1. The Abstract Class policy 950 The abstract class policy collects four attributes that may be 951 included in instances of any of the Core Policy classes (or their 952 subclasses). The class value "policy" is also used as the mechanism 953 for identifying policy-related instances in the Directory Information 954 Tree. An instance of any class may be "tagged" with this class value 955 by attaching to it the auxiliary class policyElement. 957 The class definition is as follows: 959 NAME policy 960 DESCRIPTION An abstract class with four attributes for 961 describing a policy-related instance. 962 DERIVED FROM top 963 TYPE abstract 964 AUXILIARY CLASSES none 965 OID 966 MAY cn caption description policyKeywords 968 6.1.1. The Attribute commonName (cn) 970 The cn, or commonName, attribute is an X.500 attribute. It specifies 971 one or more user-friendly names (typically only one name) by which an 972 object is commonly known, names that conform to the naming 973 conventions of the country or culture with which the object is 974 associated. A commonName may be ambiguous by itself, so it is 975 typically used in a limited scope (such as an organization). 977 Unlike X.500, the Core Policy Schema specifies that the commonName 978 attribute SHOULD NOT be used for forming the final RDN in the 979 Distinguished Name of a policy-related instance. 981 NAME cn 982 DESCRIPTION A user-friendly name of a policy-related object. 983 SYNTAX DirectoryString 984 OID 2.4.5.3 985 EQUALITY caseIgnoreMatch 986 MULTI-VALUED 988 6.1.2. The Attribute caption 990 This attribute corresponds to the Caption attribute defined in CIM. 991 It provides a place for a one-line description of an entry. 993 NAME caption 994 DESCRIPTION A one-line description of this policy-related 995 object. 996 SYNTAX IA5String 997 OID 998 EQUALITY caseExactIA5Match 999 SINGLE-VALUED 1001 6.1.3. The Attribute description 1003 This attribute corresponds to the Description attribute defined in 1004 CIM. It provides a place for a longer description than that provided 1005 by the caption attribute. 1007 NAME description 1008 DESCRIPTION A long description of this policy-related object. 1009 SYNTAX IA5String 1010 OID 1011 EQUALITY caseExactIA5Match 1012 SINGLE-VALUED 1014 6.1.4. The Attribute policyKeywords 1016 This attribute provides a set of one or more keywords that a policy 1017 administrator may define to assist directory clients in locating the 1018 policy objects applicable to them. Keywords are of one of two types: 1020 Keywords defined in this document, or in documents that define 1021 subclasses of the classes defined in this document. These keywords 1022 provide a vendor-independent, installation-independent way of 1023 identifying and locating policy objects. 1025 Installation-dependent keywords for identifying and locating policy 1026 objects. Examples include "Engineering", "Billing", and "Review in 1027 December 1999". 1029 This document defines the following keywords for identifying policy 1030 objects: "UNKNOWN", "CONFIGURATION", "USAGE", "SECURITY", "SERVICE", 1031 "MOTIVATIONAL", "INSTALLATION", and "EVENT". These concepts were 1032 defined in Section 2. In addition to these, the keyword "POLICY" is 1033 defined, to serve as a tag for policy-related entries when a 1034 directory implementation does not support matching on auxiliary 1035 classes in the objectClass attribute. 1037 Documents that define subclasses of the Core Schema classes should 1038 define additional keywords to identify policy objects associated with 1039 instances of these subclasses. By convention, keywords defined in 1040 conjunction with class definitions are in uppercase. Installation- 1041 defined keywords can be in any case. 1043 The attribute definition is as follows: 1045 NAME policyKeywords 1046 DESCRIPTION A set of keywords to assist directory clients in 1047 locating the policy objects applicable to them. 1048 SYNTAX IA5String 1049 OID 1050 EQUALITY caseExactIA5Match 1051 MULTI-VALUED 1053 6.2. The Class policyGroup 1055 This class is a generalized aggregation container. It enables either 1056 policyRules or policyGroups, but not both, to be aggregated in a 1057 single container. Loops, including the degenerate case of a 1058 policyGroup that contains itself, are not allowed when policyGroups 1059 contain other policyGroups. 1061 PolicyGroups and their nesting capabilities are shown in Figure 7 1062 below. Note that a policyGroup can nest other policyGroups, and there 1063 is no restriction on the depth of the nesting in sibling 1064 policyGroups. 1066 +---------------------------------------------------+ 1067 | policyGroup | 1068 | | 1069 | +--------------------+ +-----------------+ | 1070 | | policyGroup A | | policyGroup X | | 1071 | | | | | | 1072 | | +----------------+ | ooo | | | 1073 | | | policyGroup A1 | | | | | 1074 | | +----------------+ | | | | 1075 | +--------------------+ +-----------------+ | 1076 +---------------------------------------------------+ 1078 Figure 7. Overview of the policyGroup class 1080 As a simple example, think of the highest level policyGroup shown in 1081 Figure 7 above as a logon policy for US employees of a company. This 1082 policyGroup may be called USEmployeeLogonPolicy, and may aggregate 1083 several policyGroups that provide specialized rules per location. 1084 Hence, policyGroup A in Figure 5 above may define logon rules for 1085 employees on the West Coast, while another policyGroup might define 1086 logon rules for the Midwest (e.g., policyGroup X), and so forth. 1088 Note also that the depth of each policyGroup does not need to be the 1089 same. Thus, the WestCoast policyGroup might have several additional 1090 layers of policyGroups defined for any of several reasons (different 1091 locales, number of subnets, etc.). The policyRules are therefore 1092 contained at n levels from the USEmployeeLogonPolicyGroup. Compare 1093 this to the Midwest policyGroup (policyGroup X), which might directly 1094 contain policyRules. 1096 The class definition for policyGroup is as follows. Note that this 1097 class definition does not include attributes to realize the 1098 ContainedPolicyRule and ContainedPolicyGroup associations from the 1099 object model, since a policyGroup object points to instances of 1100 policyGroup and policyRule via, respectively, the pointer in 1101 policyGroupContainmentAuxClass and the pointer in 1102 policyRuleContainmentAuxClass. 1104 NAME policyGroup 1105 DESCRIPTION A container for either a set of related 1106 policyRules or a set of related policyGroups. 1107 DERIVED FROM top 1108 TYPE structural 1109 AUXILIARY CLASSES policyGroupContainmentAuxClass, 1110 policyRuleContainmentAuxClass 1111 POSSIBLE SUPERIORS container, organization, organizationalUnit, 1112 policyGroup 1114 OID 1115 MUST policyGroupName 1117 6.2.1. The Attribute policyGroupName 1119 This attribute provides a user-friendly name for a policy group, and 1120 is normally what will be displayed to the end-user as the name of 1121 this class. It is defined as follows: 1123 NAME policyGroupName 1124 DESCRIPTION The user-friendly name of this policy group. 1125 SYNTAX IA5String 1126 OID 1127 EQUALITY caseExactIA5Match 1128 SINGLE-VALUED 1130 6.3. The Class policyRule 1132 This class represents the "If Condition then Action" semantics 1133 associated with a policy. A policyRule condition, in the most 1134 general sense, is represented as either an ORed set of ANDed 1135 conditions (Disjunctive Normal Form, or DNF) or an ANDed set of ORed 1136 conditions (Conjunctive Normal Form, or CNF). Individual conditions 1137 may either be negated (NOT C) or unnegated (C). The actions 1138 specified by a policyRule are to be performed if and only if the 1139 policyRule condition (whether it is represented in DNF or CNF) 1140 evaluates to TRUE. 1142 The conditions and actions associated with a policy rule are modeled, 1143 respectively, with auxiliary subclasses of the classes 1144 policyCondition and policyAction. These auxiliary classes are 1145 attached either to an instance of policyRule itself, or to an 1146 instance of the structural class policyInstance identified by a DN 1147 pointer in an instance of policyRule. 1149 As discussed above in section 3, a policy rule may also be associated 1150 with one or more policy time periods, indicating the schedule 1151 according to which the policy rule is active and inactive. 1153 A policy rule is illustrated conceptually in Figure 8. below. 1155 +------------------------------------------------+ 1156 | policyRule | 1157 | | 1158 | +--------------------+ +-----------------+ | 1159 | | policyCondition(s) | | policyAction(s) | | 1160 | +--------------------+ +-----------------+ | 1161 | | 1162 | +------------------------------+ | 1163 | | policyTimePeriodCondition(s) | | 1164 | +------------------------------+ | 1165 +------------------------------------------------+ 1167 Figure 8. Overview of the policyRule Class 1169 The policyRule class uses the attribute policyRuleConditionListType, 1170 to indicate whether the conditions for the rule are in DNF or CNF. 1171 The DN pointers from a policyRule to its associated policyConditions 1172 also contain an integer to partition the referenced conditions into 1173 one or more sets, and a plus ('+') or minus ('-') character to 1174 indicate whether the referenced condition is negated. An example 1175 shows how the attribute, the grouping integer, and the '+' / '-' 1176 provide a unique representation of a set of conditions in either DNF 1177 or CNF. 1179 Suppose we have pointers to five policyConditions from an instance of 1180 policyRule, grouped as follows: 1182 (C1: groupNumber = 1: unnegated, 1183 C2: groupNumber = 1: negated, 1184 C3: groupNumber = 1: unnegated, 1185 C4: groupNumber = 2: unnegated, 1186 C5: groupNumber = 2: unnegated) 1188 If policyRuleConditionListType = DNF, then the overall condition for 1189 the policyRule is: 1191 (C1 AND (NOT C2) AND C3) OR (C4 AND C5) 1193 On the other hand, if policyRuleConditionListType = CNF, then the 1194 overall condition for the policyRule is: 1196 (C1 OR (NOT C2) OR C3) AND (C4 OR C5) 1198 In both cases, there is an unambiguous specification of the overall 1199 condition that is tested to determine whether to perform the actions 1200 associated with the policyRule. This class also contains several 1201 attributes designed to help directory clients locate the policy rules 1202 applicable to them. The class definition is as follows: 1204 NAME policyRule 1205 DESCRIPTION The central class for representing the "If 1206 Condition then Action" semantics associated with a 1207 policy rule. 1208 DERIVED FROM top 1209 TYPE structural 1210 AUXILIARY CLASSES none 1211 POSSIBLE SUPERIORS policyGroup 1212 OID 1213 MUST policyRuleName 1214 MAY policyRuleEnabled policyRuleConditionListType 1215 policyRuleConditionList policyRuleActionList 1216 policyRuleValidityPeriodList policyRuleUsage 1217 policyRulePriority policyRuleMandatory 1218 policyRuleSequencedActions 1220 6.3.1. The Attribute policyRuleName 1222 This attribute provides a user-friendly name for a policy rule. The 1223 attribute definition is as follows: 1225 NAME policyRuleName 1226 DESCRIPTION The user-friendly name of this policy rule. 1227 SYNTAX IA5String 1228 OID 1229 EQUALITY caseExactIA5Match 1230 SINGLE-VALUED 1232 6.3.2. The Attribute policyRuleEnabled 1234 This attribute indicates whether a policy rule is currently enabled, 1235 from an ADMINISTRATIVE point of view. Its purpose is to allow a 1236 policy administrator to enable or disable a policy rule without 1237 having to add it to, or remove it from, the directory. 1239 The attribute also supports the value 'enabledForDebug'. When the 1240 attribute has this value, the Policy Decision Point is being told to 1241 evaluate the conditions for the policy rule, but not to perform the 1242 actions if the conditions evaluate to TRUE. This value serves as a 1243 debug vehicle when attempting to determine what policies would 1244 execute in a particular scenario, without taking any actions to 1245 change state during the debugging. 1247 The attribute definition is as follows: 1249 NAME policyRuleEnabled 1250 DESCRIPTION A flag indicating whether this policy rule is 1251 enabled from an administrative point of view. 1252 SYNTAX INTEGER 1253 OID 1254 EQUALITY integerMatch 1255 SINGLE-VALUED 1256 DEFAULT VALUE enabled(1) 1258 The defined values for this attribute are enabled(1), disabled(2), 1259 and enabledForDebug(3). 1261 6.3.3. The Attribute policyRuleConditionListType 1263 This attribute is used to specify whether the list of policy 1264 conditions associated with this policy rule is in disjunctive normal 1265 form (DNF) or conjunctive normal form (CNF). If this attribute is 1266 not present, the list type defaults to DNF. The attribute definition 1267 is as follows: 1269 NAME policyRuleConditionListType 1270 DESCRIPTION Indicates whether the list of policy conditions 1271 associated with this policy rule is in disjunctive 1272 normal form (DNF) or conjunctive normal form 1273 (CNF). Defined values are 'DNF (1)' and 'CNF 1274 (2)'. 1275 SYNTAX INTEGER 1276 OID 1277 EQUALITY integerMatch 1278 SINGLE-VALUED 1279 DEFAULT VALUE 1 (DNF) 1281 6.3.4. The Attribute policyRuleConditionList 1283 This attribute provides an unordered list of DN pointers that 1284 identify a set of policy conditions associated with this policy rule. 1285 There is an integer associated with each pointer, to provide the 1286 grouping of the conditions into first-level groups for the DNF or CNF 1287 representation of the overall policyRule condition. In addition, 1288 each pointer has associated with it a plus ('+') or minus ('-') to 1289 indicate whether the condition is negated: the '+' indicates that 1290 the condition is not negated, and the '-' indicates that it is 1291 negated. To accommodate this grouping, the syntax of this attribute 1292 is a string of the form 'groupNumber:+|-:DN'. 1294 Existing matching rules are built to operate on a single data type. 1295 This attribute is conceptually composed of three data types, an 1296 Integer (groupNumber), an enumeration ('+' or '-'), and a 1297 DistinguishedName (DN). There are three ways to address this. 1299 Collapse the three attribute types into a single structured 1300 DirectoryString with the format 'groupNumber:+|-:DN'. This approach 1301 has the advantage of not requiring any new support in the directory 1302 server implementations, since these servers already support a 1303 DirectoryString matching rule. Its disadvantage is that a 1304 DirectoryString match works somewhat differently from a DN match with 1305 respect to subtleties such as preserving versus ignoring versus 1306 removing repeated whitespace characters. Thus DNs that would match 1307 with the distinguishedNameMatch matching rule might fail to be found 1308 as substrings of 'groupNumber:+|-:DN' strings by the DirectoryString 1309 matching rules, or vice versa. 1311 Define a new syntax ':<+|->:', with its own matching 1312 rules. With this approach, the matching problems introduced by the 1313 DirectoryString could be avoided, since the new type would have its 1314 own matching rules. The disadvantage of defining a new type in this 1315 way is that a directory server must add new code that recognizes the 1316 type and implements its matching rules. A directory server would 1317 thus be unable to support the Core Policy Schema until it had added 1318 this new code. 1320 Use three objects in the directory to represent the three data types, 1321 and relate the objects with the Families of Entries model currently 1322 being discussed in the LDAP Extensions working group. This approach 1323 has the same problem as the previous one: without the addition of new 1324 code to support Families of Entries, a directory server would be 1325 unable to support the Core Policy Schema at all. There is also the 1326 additional complication here, that the Families of Entries model 1327 itself may take some time to reach approved status in the LDAP 1328 Extensions (LDAPEXT) working group. 1330 For now, this document will move forward with the 'groupNumber:+|- 1331 :DN' structured DirectoryString approach for mapping 1332 ContainedPolicyCondition, as well as with an analogous 'n:DN' 1333 approach for mapping ContainedPolicyAction. To minimize problems 1334 arising from differences in matching rules, this document will 1335 provide a series of guidelines for constructing DNs that behave 1336 identically with respect to the DirectoryString matching rules and 1337 the distinguishedNameMatch. These guidelines are in Appendix A. Note 1338 that even if the DNs are chosen so that the matching rules behave the 1339 same, automatic processes such as "Modify RDN" that count on finding 1340 objects with the DistinguishedName syntax will not find attributes 1341 with the structured-string syntaxes. 1343 The attribute definition is as follows: 1345 NAME policyRuleConditionList 1346 DESCRIPTION An unordered list of strings of the form 1347 'groupNumber:+|-:DN', indicating a set of policy 1348 conditions that determine when the policyRule is 1349 applicable. 1350 SYNTAX DirectoryString 1351 OID 1352 EQUALITY caseIgnoreSubstringsMatch 1353 MULTI-VALUED 1354 FORMAT groupNumber:+|-:DN 1356 6.3.5. The Attribute policyRuleActionList 1358 This attribute provides an unordered list of strings of the form 1359 'n:DN' that identify a set of policy actions associated with this 1360 policy rule. (See section 6.3.4 for a discussion of the issues 1361 surrounding the use of a syntax of this type.) When 'n' is a 1362 positive integer, it indicates a place in the sequence of actions to 1363 be performed, with smaller integers indicating earlier positions in 1364 the sequence. The special value '0' indicates "don't care". If two 1365 or more actions have the same non-zero sequence number, they may be 1366 performed in any order, but they must all be performed at the 1367 appropriate place in the overall action sequence. 1369 A series of examples will make ordering of actions clearer: 1371 o If all actions have the same sequence number, regardless of 1372 whether it is '0' or non-zero, any order is acceptable. 1374 o The values 1376 1:DN-A 1377 2:DN-B 1378 1:DN-C 1379 3:DN-D 1381 indicate two acceptable orders: A,C,B,D or C,A,B,D, since A and 1382 C can be performed in either order, but only at the '1' position. 1384 o The values 1386 0:DN-A 1387 2:DN-B 1388 3:DN-C 1389 3:DN-D 1391 require that B,C, and D occur either as B,C,D or as B,D,C. 1392 Action A may appear at any point relative to B,C, and D. Thus 1393 the complete set of acceptable orders is: A,B,C,D; B,A,C,D; 1394 B,C,A,D; B,C,D,A; A,B,D,C; B,A,D,C; B,D,A,C; B,D,C,A. 1396 o Note that the non-zero sequence numbers need not start with '1', 1397 and they need not be consecutive. All that matters is their 1398 relative magnitude. 1400 This attribute indicates the actions of a policyRule and their order 1401 (or absence of order). However, another attribute, 1402 policyRuleSequencedActions, indicates whether the indicated order is 1403 required, recommended, or not to be used at all. 1405 All actions specified in the policyRuleActionList will be executed as 1406 long as the overall policy condition as defined by the 1407 policyRuleConditionListType and policyRuleConditionList attributes 1408 evaluates to TRUE. 1410 The attribute definition is as follows: 1412 NAME policyRuleActionList 1413 DESCRIPTION An unordered list of strings of the form 'n:DN', 1414 indicating an ordered set of policy actions to be 1415 performed if the associated condition(s) of the 1416 policyRule evaluates to true. 1417 SYNTAX DirectoryString 1418 OID 1419 EQUALITY caseIgnoreSubstringsMatch 1420 MULTI-VALUED 1421 FORMAT n:DN 1423 6.3.6. The Attribute policyRuleValidityPeriodList 1425 This attribute provides an unordered set of DN pointers to one or 1426 more policyTimePeriodConditions, indicating when the policy rule is 1427 scheduled to be active and when it is scheduled to be inactive. The 1428 rule is scheduled to be active if it is active according to AT LEAST 1429 ONE of the policyTimePeriodConditions pointed to by this attribute. 1431 The attribute definition is: 1433 NAME policyRuleValidityPeriodList 1434 DESCRIPTION Distinguished names of policyTimePeriodConditions 1435 that determine when the policyRule is scheduled to 1436 be active / inactive. No order is implied. 1437 SYNTAX DN 1438 OID 1439 EQUALITY distinguishedNameMatch 1440 MULTI-VALUED 1442 6.3.7. The Attribute policyRuleUsage 1444 This attribute is a free-form string that recommends how this policy 1445 should be used. The attribute definition is as follows: 1447 NAME policyRuleUsage 1448 DESCRIPTION This attribute is used to provide guidelines on 1449 how this policy should be used. 1450 SYNTAX DirectoryString 1451 OID 1452 EQUALITY caseIgnoreMatch 1453 SINGLE-VALUED 1455 6.3.8. The Attribute policyRulePriority 1457 This attribute provides a non-negative integer for prioritizing 1458 policy rules relative to each other. For policy rules that have this 1459 attribute, larger integer values indicate higher priority. Since one 1460 purpose of this attribute is to allow specific, ad hoc policy rules 1461 to temporarily override established policy rules, an instance that 1462 has this attribute set has a higher priority than all instances that 1463 lack it. 1465 Prioritization among policy rules provides a simple and efficient 1466 mechanism for resolving policy conflicts. 1468 The attribute definition is as follows: 1470 NAME policyRulePriority 1471 DESCRIPTION A non-negative integer for prioritizing this 1472 policyRule relative to other policyRules. A 1473 larger value indicates a higher priority. 1474 SYNTAX INTEGER 1475 OID 1476 EQUALITY integerMatch 1477 SINGLE-VALUED 1478 DEFAULT VALUE 0 1480 6.3.9. The Attribute policyRuleMandatory 1482 This attribute indicates whether evaluation (and possibly action 1483 execution) of a policyRule is mandatory or not. Its concept is 1484 similar to the ability to mark packets for delivery or possible 1485 discard, based on network traffic and device load. 1487 The evaluation of a policyRule MUST be attempted if the 1488 policyRuleMandatory attribute value is True. If the 1489 policyRuleMandatory attribute value of a policyRule is False, then 1490 the evaluation of the rule is "best effort" and MAY be ignored. 1492 The attribute definition is as follows: 1494 NAME policyRuleMandatory 1495 DESCRIPTION A flag indicating that the evaluation of the 1496 policyConditions and execution of policyActions 1497 (if the condition list evaluates to True) is 1498 required. 1499 SYNTAX Boolean 1500 OID 1501 EQUALITY booleanMatch 1502 SINGLE-VALUED 1503 DEFAULT VALUE TRUE 1505 6.3.10. The Attribute policyRuleSequencedActions 1507 This attribute gives a policy administrator a way of specifying how 1508 the ordering of the policy actions associated with this policyRule is 1509 to be interpreted. Three values are supported: 1511 o mandatory (1): Do the actions in the indicated order, or don't 1512 do them at all. 1514 o recommended (2): Do the actions in the indicated order if you 1515 can, but if you can't do them in this order, do them in another 1516 order if you can. 1518 o dontCare (3): Do them -- I don't care about the order. 1520 When error / event reporting is addressed for the Policy Framework, 1521 suitable codes will be defined for reporting that a set of actions 1522 could not be performed in an order specified as mandatory (and thus 1523 were not performed at all), that a set of actions could not be 1524 performed in a recommended order (and moreover could not be performed 1525 in any order), or that a set of actions could not be performed in a 1526 recommended order (but were performed in a different order). The 1527 attribute definition is as follows: 1529 NAME policyRuleSequencedActions 1530 DESCRIPTION An enumeration indicating how to interpret the 1531 action ordering indicated via the 1532 policyRuleActionList attribute. 1533 SYNTAX INTEGER 1534 OID 1535 EQUALITY integerMatch 1536 SINGLE-VALUED 1537 DEFAULT VALUE 3 1539 The defined values for this attribute are mandatory(1), 1540 recommended(2), and dontCare(3). 1542 6.4. The Class policyCondition 1544 The purpose of a policy condition is to determine whether or not the 1545 set of actions (contained in the policyRule that the condition 1546 applies to) should be executed or not. For the purposes of the Core 1547 Policy Schema, all that matters about an individual policyCondition 1548 is that it evaluates to TRUE or FALSE. (The individual 1549 policyConditions associated with a policyRule are combined to form a 1550 compound expression in either DNF or CNF, but this is accomplished 1551 via the groupNumber component of the policyRuleConditionList string 1552 and by the policyRuleConditionListType attribute, both of which are 1553 discussed above.) A logical structure WITHIN an individual 1554 policyCondition may also be introduced, but this would have to be 1555 done in a subclass of policyCondition. 1557 +---------------------------------------------------------------+ 1558 | Policy Conditions in DNF | 1559 | +-------------------------+ +-----------------------+ | 1560 | | AND list | | AND list | | 1561 | | +-------------------+ | | +-----------------+ | | 1562 | | | policyCondition | | | | policyCondition | | | 1563 | | +-------------------+ | | +-----------------+ | | 1564 | | +-------------------+ | | +-----------------+ | | 1565 | | | policyCondition | | ... | | policyCondition | | | 1566 | | +-------------------+ | ORed | +-----------------+ | | 1567 | | ... | | ... | | 1568 | | ANDed | | ANDed | | 1569 | | +-------------------+ | | +-----------------+ | | 1570 | | | policyCondition | | | | policyCondition | | | 1571 | | +-------------------+ | | +-----------------+ | | 1572 | +-------------------------+ +-----------------------+ | 1573 +---------------------------------------------------------------+ 1575 Figure 9. Overview of Policy Conditions in DNF 1577 This figure illustrates that when policy conditions are in DNF, there 1578 are one or more sets of conditions that are ANDed together to form 1579 AND lists. An AND list evaluates to TRUE if and only if all of its 1580 constituent conditions evaluate to TRUE. The overall condition then 1581 evaluates to TRUE if and only if at least one of its constituent AND 1582 lists evaluates to TRUE. 1584 +---------------------------------------------------------------+ 1585 | Policy Conditions in CNF | 1586 | +-------------------------+ +-----------------------+ | 1587 | | OR list | | OR list | | 1588 | | +-------------------+ | | +-----------------+ | | 1589 | | | policyCondition | | | | policyCondition | | | 1590 | | +-------------------+ | | +-----------------+ | | 1591 | | +-------------------+ | | +-----------------+ | | 1592 | | | policyCondition | | ... | | policyCondition | | | 1593 | | +-------------------+ | ANDed | +-----------------+ | | 1594 | | ... | | ... | | 1595 | | ORed | | ORed | | 1596 | | +-------------------+ | | +-----------------+ | | 1597 | | | policyCondition | | | | policyCondition | | | 1598 | | +-------------------+ | | +-----------------+ | | 1599 | +-------------------------+ +-----------------------+ | 1600 +---------------------------------------------------------------+ 1602 Figure 10. Overview of Policy Conditions in CNF 1603 In this figure, the policy conditions are in CNF. Consequently, 1604 there are one or more OR lists, each of which evaluates to TRUE if 1605 and only if at least one of its constituent conditions evaluates to 1606 TRUE. The overall condition then evaluates to TRUE if and only if 1607 ALL of its constituent OR lists evaluate to TRUE. The class 1608 definition is as follows: 1610 NAME policyCondition 1611 DESCRIPTION A class representing a condition to be evaluated 1612 in conjunction with a policy rule. 1613 DERIVED FROM top 1614 TYPE auxiliary 1615 AUXILIARY CLASSES none 1616 POSSIBLE SUPERIORS policyRule 1617 OID 1618 MUST policyConditionName 1619 MAY 1621 6.4.1. The Attribute policyConditionName 1623 This attribute provides a user-friendly name for a policy condition. 1624 The attribute definition is as follows: 1626 NAME policyConditionName 1627 DESCRIPTION The user-friendly name of this policy condition. 1628 SYNTAX IA5String 1629 OID 1630 EQUALITY caseExactIA5Match 1631 SINGLE-VALUED 1633 6.5. The Class policyTimePeriodCondition 1635 This class provides a means of representing the time periods during 1636 which a policy rule is valid, i.e., active. At all times that fall 1637 outside these time periods, the policy rule has no effect. A policy 1638 rule is treated as valid at all times if it does not specify a 1639 policyTimePeriodCondition. 1641 In some cases a PDP may need to perform certain setup / cleanup 1642 actions when a policy rule becomes active / inactive. For example, 1643 sessions that were established while a policy rule was active might 1644 need to be taken down when the rule becomes inactive. In other 1645 cases, however, such sessions might be left up: in this case, the 1646 effect of deactivating the policy rule would just be to prevent the 1647 establishment of new sessions. Any such setup / cleanup behaviors on 1648 validity period transitions must be specified in a subclass of 1649 policyRule. If such behaviors need to be under the control of the 1650 policy administrator, then a mechanism to allow this control must 1651 also be specified in the subclass. 1653 policyTimePeriodCondition is defined as a subclass of 1654 policyCondition. This is to allow the inclusion of time-based 1655 criteria in the AND/OR condition definitions for a policyRule. 1657 Instances of this class may have up to five attributes identifying 1658 time periods at different levels. The values of all the attributes 1659 present in an instance are ANDed together to determine the validity 1660 period(s) for the instance. For example, an instance with an overall 1661 validity range of January 1, 1999 through December 31, 1999; a month 1662 mask of "001100000000" (March and April); a day-of-the-week mask of 1663 "0000100" (Fridays); and a time of day range of 0800 through 1600 1664 would represent the following time periods: 1666 Friday, March 5, 1999, from 0800 through 1600; 1667 Friday, March 12, 1999, from 0800 through 1600; 1668 Friday, March 19, 1999, from 0800 through 1600; 1669 Friday, March 26, 1999, from 0800 through 1600; 1670 Friday, April 2, 1999, from 0800 through 1600; 1671 Friday, April 9, 1999, from 0800 through 1600; 1672 Friday, April 16, 1999, from 0800 through 1600; 1673 Friday, April 23, 1999, from 0800 through 1600; 1674 Friday, April 30, 1999, from 0800 through 1600. 1676 Attributes not present in an instance of policyTimePeriodCondition 1677 are implicitly treated as having their value "always enabled". Thus, 1678 in the example above, the day-of-the-month mask is not present, and 1679 so the validity period for the instance implicitly includes a day-of- 1680 the-month mask containing 31 1's. If we apply this "missing 1681 attribute" rule to its fullest, we see that there is a second way to 1682 indicate that a policy rule is always enabled: have it point to an 1683 instance of policyTimePeriodCondition whose only attributes are its 1684 naming attributes. 1686 The class definition is as follows. Note that instances of this 1687 class are named with the attributes cn and policyConditionName that 1688 they inherit from policyCondition. 1690 NAME policyTimePeriodCondition 1691 DESCRIPTION A class that provides the capability of enabling / 1692 disabling a policy rule according to a pre- 1693 determined schedule. 1694 DERIVED FROM policyCondition 1695 TYPE auxiliary 1696 AUXILIARY CLASSES none 1697 POSSIBLE SUPERIORS policyRule 1698 OID 1699 MUST 1700 MAY ptpConditionTime ptpConditionMonthOfYearMask 1701 ptpConditionDayOfMonthMask 1702 ptpConditionDayOfWeekMask 1703 ptpConditionTimeOfDayMask ptpConditionTimeZone 1705 6.5.1. The Attribute ptpConditionTime 1707 This attribute identifies an overall range of calendar dates and 1708 times over which a policy rule is valid. It is formatted as a string 1709 consisting of a start date and time, then a colon (':'), and followed 1710 by an end date and time. The first date indicates the beginning of 1711 the range, while the second date indicates the end. Thus, the second 1712 date and time must be later than the first. Dates are expressed as 1713 substrings of the form "yyyymmddhhmmss". For example: 1715 19990101080000:19990131120000 1717 January 1, 1999, 0800 through January 31, 1999, noon 1719 The attribute definition is as follows: 1721 NAME ptpConditionTime 1722 DESCRIPTION The range of calendar dates on which a policy rule 1723 is valid. 1724 SYNTAX PrintableString 1725 OID 1726 EQUALITY caseIgnoreMatch 1727 SINGLE-VALUED 1728 FORMAT yyyymmddhhmmss:yyyymmddhhmmss 1730 6.5.2. The Attribute ptpConditionMonthOfYearMask 1732 The purpose of this attribute is to refine the definition of the 1733 valid time period that is defined by the ptpConditionTime attribute 1734 by explicitly specifying which months the policy is valid for. These 1735 attributes work together, with the ptpConditionTime used to specify 1736 the overall time period that the policy is valid for, and the 1737 ptpConditionMonthOfYearMask used to pick out which months of that 1738 time period the policy is valid for. 1740 This attribute is formatted as a string containing 12 ASCII '0's and 1741 '1's, where the '1's identify the months (beginning with January) in 1742 which the policy rule is valid. The value "000010010000", for 1743 example, indicates that a policy rule is valid only in the months May 1744 and August. 1746 If this attribute is omitted, then the policy assumes that it is 1747 valid for all twelve months. The attribute definition is as follows: 1749 NAME ptpConditionMonthOfYearMask 1750 DESCRIPTION A mask identifying the months of the year in which 1751 a policy rule is valid. 1752 SYNTAX Printable String 1753 OID 1754 EQUALITY caseIgnoreMatch 1755 SINGLE-VALUED 1756 FORMAT A string of 12 ASCII '0's and '1's. 1758 6.5.3. The Attribute ptpConditionDayOfMonthMask 1760 The purpose of this attribute is to refine the definition of the 1761 valid time period that is defined by the ptpConditionTime attribute 1762 by explicitly specifying which days of the month the policy is valid 1763 for. These attributes work together, with the ptpConditionTime used 1764 to specify the overall time period that the policy is valid for, and 1765 the ptpConditionDayOfMonthMask used to pick out which days of the 1766 month that time period the policy is valid for. 1768 This attribute is formatted as a string containing 31 ASCII '0's and 1769 '1's, where the '1's identify the days of the month (beginning with 1770 day 1 and going up through day 31) on which the policy rule is valid. 1771 The value "1110000000000000000000000000000", for example, indicates 1772 that a policy rule is valid only on the first three days of each 1773 month. For months with fewer than 31 days, the digits corresponding 1774 to days that the months do not have are ignored. The attribute 1775 definition is as follows: 1777 NAME ptpConditionDayOfMonthMask 1778 DESCRIPTION A mask identifying the days of the month on which 1779 a policy rule is valid. 1780 SYNTAX PrintableString 1781 OID 1782 EQUALITY caseIgnoreMatch 1783 SINGLE-VALUED 1784 FORMAT A string of 31 ASCII '0's and '1's. 1786 6.5.4. The Attribute ptpConditionDayOfWeekMask 1788 The purpose of this attribute is to refine the definition of the 1789 valid time period that is defined by the ptpConditionTime attribute 1790 by explicitly specifying which days of the week the policy is valid 1791 for. These attributes work together, with the ptpConditionTime used 1792 to specify the overall time period that the policy is valid for, and 1793 the ptpConditionDayOfWeekMask used to pick out which days of the week 1794 of that time period the policy is valid for. 1796 This attribute is formatted as a string containing 7 ASCII '0's and 1797 '1's, where the '1's identify the days of the week (beginning with 1798 Monday and going up through Sunday) on which the policy rule is 1799 valid. The value "1111100", for example, indicates that a policy rule 1800 is valid Monday through Friday. 1802 The attribute definition is as follows: 1804 NAME ptpConditionDayOfWeekMask 1805 DESCRIPTION A mask identifying the days of the week on which a 1806 policy rule is valid. 1807 SYNTAX PrintableString 1808 OID 1809 EQUALITY caseIgnoreMatch 1810 SINGLE-VALUED 1811 FORMAT A string of 7 ASCII '0's and '1's. 1813 6.5.5. The Attribute ptpConditionTimeOfDayMask 1815 The purpose of this attribute is to refine the definition of the 1816 valid time period that is defined by the ptpConditionTime attribute 1817 by explicitly specifying a range of times in a day the policy is 1818 valid for. These attributes work together, with the ptpConditionTime 1819 used to specify the overall time period that the policy is valid for, 1820 and the ptpConditionTimeOfDayMask used to pick out which range of 1821 time periods in a given day of the week of that time period the 1822 policy is valid for. 1824 This attribute is formatted as a string containing two times, 1825 separated by a colon (':'). The first time indicates the beginning 1826 of the range, while the second time indicates the end. Times are 1827 expressed as substrings of the form "hhmmss". 1829 The second substring always identifies a later time than the first 1830 substring. To allow for ranges that span midnight, however, the 1831 value of the second string may be smaller than the value of the first 1832 substring. Thus, "080000:210000" identifies the range from 0800 1833 until 2100, while "210000:080000" identifies the range from 2100 1834 until 0800 of the following day. 1836 When a range spans midnight, it by definition includes parts of two 1837 successive days. When one of these days is also selected by either 1838 the ptpConditionMonthOfYearMask, ptpConditionDayOfMonthMask, and/or 1839 ptpConditionDayOfWeekMask, but the other day is not, then the policy 1840 is active only during the portion of the range that falls on the 1841 selected day. For example, if the range extends from 2100 until 1842 0800, and the day of week mask selects Monday and Tuesday, then the 1843 policy is active during the following three intervals: 1845 From midnight Sunday until 0800 Monday; 1846 From 2100 Monday until 0800 Tuesday; 1847 From 2100 Tuesday until 21:59:59 Tuesday. 1849 The attribute definition is as follows: 1851 NAME ptpConditionTimeOfDayMask 1852 DESCRIPTION The range of times at which a policy rule is 1853 valid. If the second time is earlier than the 1854 first, then the interval spans midnight. 1855 SYNTAX Printable String 1856 OID 1857 EQUALITY caseIgnoreMatch 1858 SINGLE-VALUED 1859 FORMAT hhmmss:hhmmss[:] 1861 6.5.6. The Attribute ptpConditionTimeZone 1863 This attribute is used to explicitly define a time zone for use by 1864 the ptpConditionTime and the various Mask attributes. If this 1865 attribute is NULL, then local time (at the location where the 1866 policyRule is enforced -- in other words, at the Policy Enforcement 1867 Point) is assumed. 1869 This attribute specifies time in UTC, using an offset indicator. The 1870 UTC offset indicator is either a 'Z', indicating UTC, or a substring 1871 of the following form: 1873 '+' or '-' direction from UTC: '+' = east, '-' = west 1875 hh hours from UTC (00..13) 1877 mm minutes from UTC (00..59) 1879 The attribute definition is as follows: 1881 NAME ptpConditionTimeZone 1882 DESCRIPTION The definition of the time zone for the 1883 policyTimePeriodCondition. 1884 SYNTAX PrintableString 1885 OID 1886 EQUALITY caseIgnoreMatch 1887 SINGLE-VALUED 1888 FORMAT either 'Z' (UTC) or {'+' | '-'}'hhmm' 1890 6.6. The Class vendorPolicyCondition 1892 The purpose of this class is to provide a general escape mechanism 1893 for representing policy conditions that have not been modeled with 1894 specific attributes. Instead, the two attributes 1895 vendorPolicyConstraintData and vendorPolicyConstraintEncoding are 1896 used to define the content and format of the condition, as explained 1897 below. 1899 As its name suggests, this class is intended for vendor-specific 1900 extensions to the Core Policy Schema. Standardized extensions are 1901 not expected to use this class. 1903 The class definition is as follows: 1905 NAME vendorPolicyCondition 1906 DESCRIPTION A class that defines a registered means to 1907 describe a policy condition. 1908 DERIVED FROM policyCondition 1909 TYPE auxiliary 1910 AUXILIARY CLASSES none 1911 POSSIBLE SUPERIORS policyRule 1912 OID 1913 MUST vendorPolicyConstraintData 1914 vendorPolicyConstraintEncoding 1915 MAY 1917 6.6.1. The Attribute vendorPolicyConstraintData 1919 This attribute provides a general escape mechanism for representing 1920 policy conditions that have not been modeled with specific 1921 attributes. The format of the OctetString is left unspecified in 1922 this definition. It is determined by the OID value stored in the 1923 attribute vendorPolicyConstraintEncoding. Since 1924 vendorPolicyConstraintEncoding is single-valued, all the values of 1925 vendorPolicyConstraintData share the same format and semantics. 1927 A policy decision point can readily determine whether it supports the 1928 values stored in an instance of vendorPolicyConstraintData by 1929 checking the OID value from vendorPolicyConstraintEncoding against 1930 the set of OIDs it recognizes. The action for the policy decision 1931 point to take in case it does not recognize the format of this data 1932 could itself be modeled as a policy rule, governing the behavior of 1933 the policy decision point. 1935 The attribute definition is as follows: 1937 NAME vendorPolicyConstraintData 1938 DESCRIPTION Escape mechanism for representing constraints that 1939 have not been modeled as specific attributes. The 1940 format of the values is identified by the OID 1941 stored in the attribute 1942 vendorPolicyConstraintEncoding. 1943 SYNTAX OctetString 1944 OID 1945 EQUALITY octetStringMatch 1946 MULTI-VALUED 1948 6.6.2. The Attribute vendorPolicyConstraintEncoding 1950 This attribute identifies the encoding and semantics of the values of 1951 vendorPolicyConstraintData in this instance. The value of this 1952 attribute is a single OID. 1954 The attribute definition is as follows: 1956 NAME vendorPolicyConstraintEncoding 1957 DESCRIPTION An OID identifying the format and semantics for 1958 this instance's vendorPolicyConstraintData 1959 attribute. 1960 SYNTAX OID 1961 OID 1962 EQUALITY objectIdentifierMatch 1963 SINGLE-VALUED 1965 6.7. The Class policyAction 1967 The purpose of a policy action is to execute one or more operations 1968 that will affect network traffic and/or systems, devices, etc. in 1969 order to achieve a desired policy state. This (new) policy state 1970 provides one or more (new) behaviors. A policy action ordinarily 1971 changes the configuration of one or more elements. 1973 A policyRule contains one or more policy actions. Unlike a condition, 1974 however, only one list of policy actions is contained in a 1975 policyRule. A policy administrator can assign an order to the actions 1976 associated with a policyRule, complete with an indication of whether 1977 the indicated order is mandatory, recommended, or of no significance. 1979 The actions associated with a policyRule are executed if and only if 1980 the overall condition(s) of the policyRule evaluates to TRUE. 1982 The class definition is as follows: 1984 NAME policyAction 1985 DESCRIPTION A class representing an action to be performed as 1986 a result of a policy rule. 1987 DERIVED FROM top 1988 TYPE auxiliary 1989 AUXILIARY CLASSES none 1990 POSSIBLE SUPERIORS policyRule 1991 OID 1992 MUST policyActionName 1993 MAY 1995 6.7.1. The Attribute policyActionName 1997 This attribute provides a user-friendly name for a policy action. 1999 The attribute definition is as follows: 2001 NAME policyActionName 2002 DESCRIPTION The user-friendly name of this policy action. 2003 SYNTAX IA5String 2004 OID 2005 EQUALITY caseExactIA5Match 2006 SINGLE-VALUED 2008 6.8. The Class vendorPolicyAction 2010 The purpose of this class is to provide a general escape mechanism 2011 for representing policy actions that have not been modeled with 2012 specific attributes. Instead, the two attributes 2013 vendorPolicyActionData and vendorPolicyActionEncoding are used to 2014 define the content and format of the condition, as explained below. 2016 As its name suggests, this class is intended for vendor-specific 2017 extensions to the Core Policy Schema. Standardized extensions are 2018 not expected to use this class. 2020 The class definition is as follows: 2022 NAME vendorPolicyAction 2023 DESCRIPTION A class that defines a registered means to 2024 describe a policy action. 2025 DERIVED FROM policyAction 2026 TYPE auxiliary 2027 AUXILIARY CLASSES none 2028 POSSIBLE SUPERIORS policyRule 2029 OID 2030 MUST vendorPolicyActionData vendorPolicyActionEncoding 2031 MAY 2033 6.8.1. The Attribute vendorPolicyActionData 2035 This attribute provides a general escape mechanism for representing 2036 policy actions that have not been modeled with specific attributes. 2037 The format of the OctetString is left unspecified in this definition. 2038 It is determined by the OID value stored in the attribute 2039 vendorPolicyActionEncoding. Since vendorPolicyActionEncoding is 2040 single-valued, all the values of vendorPolicyActionData share the 2041 same format and semantics. 2043 A policy decision point can readily determine whether it supports the 2044 values stored in an instance of vendorPolicyActionData, by checking 2045 the OID value from vendorPolicyActionEncoding against the set of OIDs 2046 it recognizes. The action for the policy decision point to take in 2047 case it does not recognize the format of this data could itself be 2048 modeled as a policy rule, governing the behavior of the policy 2049 decision point. 2051 The attribute definition is as follows: 2053 NAME vendorPolicyActionData 2054 DESCRIPTION Escape mechanism for representing actions that 2055 have not been modeled as specific attributes. The 2056 format of the values is identified by the OID 2057 stored in the attribute 2058 vendorPolicyActionEncoding. 2059 SYNTAX OctetString 2060 OID 2061 EQUALITY octetStringMatch 2062 MULTI-VALUED 2064 6.8.2. The Attribute vendorPolicyActionEncoding 2066 This attribute identifies the encoding and semantics of the values of 2067 vendorPolicyActionData in this instance. The value of this attribute 2068 is a single OID. 2070 The attribute definition is as follows: 2072 NAME vendorPolicyActionEncoding 2073 DESCRIPTION An OID identifying the format and semantics for 2074 this instance's vendorPolicyActionData attribute. 2075 SYNTAX OID 2076 OID 2077 EQUALITY objectIdentifierMatch 2078 SINGLE-VALUED 2080 6.9. The Class policyInstance 2082 This class introduces no additional attributes, beyond those defined 2083 in the class policy from which it is derived. Its role in the Core 2084 Schema is to serve as the structural class to which the auxiliary 2085 classes policyCondition and policyAction may be attached when the 2086 complex policy rule structure is required. With its attached 2087 auxiliary class, an instance of policyInstance represents a single 2088 policy condition or a single policy action, but not both. 2090 An instance of this class is named by an attribute it acquires via an 2091 attached auxiliary class. In the Core Schema, the naming attributes 2092 available for this purpose are policyConditionName and 2093 policyActionName. 2095 The class definition is as follows: 2097 NAME policyInstance 2098 DESCRIPTION A structural class to which the auxiliary classes 2099 policyCondition and policyAction may be attached, 2100 when the complex policy rule structure is 2101 required. 2102 DERIVED FROM policy 2103 TYPE structural 2104 AUXILIARY CLASSES policyCondition, policyAction 2105 OID 2107 6.10. The Auxiliary Class policyElement 2109 Like policyInstance, this class also introduces no additional 2110 attributes, beyond those defined in the class policy from which it is 2111 derived. Its role is to "tag" an instance of a class defined outside 2112 the realm of policy as being nevertheless relevant to a policy 2113 specification. This tagging can potentially take place at two 2114 levels: 2116 o Every instance to which policyElement is attached becomes an 2117 instance of the class policy, since policyElement is a subclass of 2118 policy. Thus a DIT search with the filter "objectClass=policy" 2119 will return the instance. (As noted earlier, this approach does 2120 not work for some directory implementations. To accommodate these 2121 implementations, policy-related entries SHOULD be tagged with the 2122 keyword "POLICY".) 2124 o With the policyKeywords attribute that it inherits from policy, an 2125 instance to which policyElement is attached can be tagged as being 2126 relevant to a particular type or category of policy, using standard 2127 keywords, administrator-defined keywords, or both. 2129 The class definition is as follows: 2131 NAME policyElement 2132 DESCRIPTION An auxiliary class used to tag instances of 2133 classes defined outside the realm of policy as 2134 relevant to a particular policy specification. 2135 DERIVED FROM policy 2136 TYPE auxiliary 2137 AUXILIARY CLASSES none 2138 OID 2140 6.11. The Auxiliary Class policySubtreesPtrAuxClass 2142 This auxiliary class provides a single, multi-valued attribute that 2143 points to a set of objects that are at the root of DIT subtrees 2144 containing policy-related information. By attaching this attribute 2145 to instances of various other classes, a policy administrator has a 2146 flexible way of providing an entry point into the directory that 2147 allows a client to locate and retrieve the policy information 2148 relevant to it. 2150 This object does not provide the semantic linkages between individual 2151 policy objects, such as those between a policy group and the policy 2152 rules that belong to it. Its only role is to enable efficient bulk 2153 retrieval of policy-related objects, as described in Section 5.4. 2154 Once the objects have been retrieved, a directory client can 2155 determine the semantic linkages by following DN pointers such as 2156 policyRulesAuxContainedSet locally. 2158 Since policy-related objects may or may not be included in the DIT 2159 subtree beneath an object to which this auxiliary class is attached, 2160 there is no automatic presumption that this subtree should be 2161 searched by a directory client. If this subtree does contain policy- 2162 related objects, this is indicated by including a DN pointer to this 2163 object itself in the policySubtreesAuxContainedSet attribute. 2165 The class definition is as follows: 2167 NAME policySubtreesPtrAuxClass 2168 DESCRIPTION An auxiliary class providing a DN pointer to roots 2169 of DIT subtrees contained policy-related objects. 2170 DERIVED FROM top 2171 TYPE auxiliary 2172 AUXILIARY CLASSES none 2173 OID 2174 MUST policySubtreesAuxContainedSet 2176 6.11.1. The Attribute policySubtreesAuxContainedSet 2178 This attribute provides an unordered set of DN pointers to one or 2179 more objects under which policy-related information is present. The 2180 objects pointed to may or may not themselves contain policy-related 2181 information. 2183 The attribute definition is as follows: 2185 NAME policySubtreesAuxContainedSet 2186 DESCRIPTION Distinguished names of objects that serve as roots 2187 for DIT subtrees containing policy-related 2188 objects. No order is implied. 2189 SYNTAX DN 2190 OID 2191 EQUALITY distinguishedNameMatch 2192 MULTI-VALUED 2194 6.12. The Auxiliary Class policyGroupContainmentAuxClass 2196 This auxiliary class provides a single, multi-valued attribute that 2197 points to a set of policyGroups. By attaching this attribute to 2198 instances of various other classes, a policy administrator has a 2199 flexible way of providing an entry point into the directory that 2200 allows a client to locate and retrieve the policyGroups relevant to 2201 it. 2203 As is the case with policyRules, a policy administrator might have 2204 several different pointers to a policyGroup in the overall directory 2205 structure. The policyGroupContainmentAuxClass is the mechanism that 2206 makes it possible for the policy administrator to define all these 2207 pointers. 2209 The class definition is as follows: 2211 NAME policyGroupContainmentAuxClass 2212 DESCRIPTION An auxiliary class used to bind policyGroups 2213 to an appropriate container object. 2214 DERIVED FROM top 2215 TYPE auxiliary 2216 AUXILIARY CLASSES none 2217 OID 2218 MUST policyGroupsAuxContainedSet 2220 6.12.1. The Attribute policyGroupsAuxContainedSet 2222 This attribute provides an unordered set of DN pointers to one or 2223 more policyGroups associated with the instance of a structural class 2224 to which this attribute has been appended. The attribute definition 2225 is as follows: 2227 NAME policyGroupsAuxContainedSet 2228 DESCRIPTION Distinguished names of policyGroups associated in 2229 some way with the instance to which this attribute 2230 has been appended. No order is implied. 2231 SYNTAX DN 2232 OID 2233 EQUALITY distinguishedNameMatch 2234 MULTI-VALUED 2236 6.13. The Auxiliary Class policyRuleContainmentAuxClass 2238 This auxiliary class provides a single, multi-valued attribute that 2239 points to a set of policyRules. By attaching this attribute to 2240 instances of various other classes, a policy administrator has a 2241 flexible way of providing an entry point into the directory that 2242 allows a client to locate and retrieve the policyRules relevant to 2243 it. 2245 A policy administrator might have several different pointers to a 2246 policyRule in the overall directory structure. For example, there 2247 might be pointers to all policyRules for traffic originating in a 2248 particular subnet from a directory entry that represents that subnet. 2249 At the same time, there might be pointers to all policyRules related 2250 to a particular DiffServ setting from an instance of a policyGroup 2251 explicitly introduced as a container for DiffServ-related 2252 policyRules. The policyRuleContainmentAuxClass is the mechanism that 2253 makes it possible for the policy administrator to define all these 2254 pointers. 2256 Note that the cn attribute does NOT need to be defined for this 2257 class. This is because an auxiliary class is used as a means to 2258 collect common attributes and treat them as properties of an object. 2259 A good analogy is a #include file, except that since an auxiliary 2260 class is a class, all the benefits of a class (e.g., inheritance) can 2261 be applied to an auxiliary class. 2263 The class definition is as follows: 2265 NAME policyRuleContainmentAuxClass 2266 DESCRIPTION An auxiliary class used to bind policyRules to an 2267 appropriate container object. 2268 DERIVED FROM top 2269 TYPE auxiliary 2270 AUXILIARY CLASSES none 2271 OID 2272 MUST policyRulesAuxContainedSet 2274 6.13.1. The Attribute policyRulesAuxContainedSet 2276 This attribute provides an unordered set of DN pointers to one or 2277 more policyRules associated with the instance of a structural class 2278 to which this attribute has been appended. The attribute definition 2279 is: 2281 NAME policyRulesAuxContainedSet 2282 DESCRIPTION Distinguished names of policyRules associated in 2283 some way with the instance to which this attribute 2284 has been appended. No order is implied. 2285 SYNTAX DN 2286 OID 2287 EQUALITY distinguishedNameMatch 2288 MULTI-VALUED 2290 7. Extending the Core Schema 2292 The following subsections provide general guidance on how to create a 2293 domain-specific schema derived from the Core Schema, discuss how the 2294 vendor classes in the Core Schema should be used, and explain how 2295 policyTimePeriodConditions are related to other policy conditions. 2297 7.1. Subclassing policyCondition and policyAction 2299 In Section 5.3 above, there is a discussion of how, by representing 2300 policy conditions and policy actions as auxiliary classes in a 2301 schema, the flexibility is retained to instantiate a particular 2302 policy as either a simple policy rule or a complex one. This 2303 flexibility is lost if a schema takes either of two "hard-coded" 2304 paths: 2306 o If the schema subclasses policyRule to add domain-specific 2307 characteristics that implicitly express a policy condition, a 2308 policy action, or both, then the schema supports only the simple 2309 policy rule form. 2311 o If the schema introduces structural subclasses of 2312 policyCondition, policyAction, or both, then the schema supports 2313 only the complex policy rule form. 2315 Even if the authors of a domain-specific schema can only envision one 2316 of these forms of policy rules being used when the schema is 2317 instantiated, it costs nothing extra to express the schema as 2318 auxiliary subclasses of policyCondition and policyAction. For 2319 standardized schemata, this document specifies that domain-specific 2320 information MUST be expressed in auxiliary subclasses of 2321 policyCondition and policyAction. It is RECOMMENDED that non- 2322 standardized schemata follow this practice as well. 2324 7.2. Using the Vendor Policy Encoding Attributes 2326 As discussed Section 6.6 "The Class vendorPolicyCondition", the 2327 attributes vendorPolicyConstraintData and 2328 vendorPolicyConstraintEncoding are included in the 2329 vendorPolicyCondition to provide an escape mechanism for representing 2330 "exceptional" policy conditions. The attributes 2331 vendorPolicyActionData and vendorPolicyActionEncoding in the 2332 vendorPolicyAction class play the same role with respect to actions. 2333 This enables interoperability between different vendors. 2335 For example, imagine a network composed of access devices from vendor 2336 A, edge and core devices from vendor B, and a policy server from 2337 vendor C. It is desirable for this policy server to be able to 2338 configure and manage all of the devices from vendors A and B. 2339 Unfortunately, these devices will in general have little in common 2340 (e.g., different mechanisms, different ways for controlling those 2341 mechanisms, different operating systems, different commands, and so 2342 forth). The escape conditions provide a way for vendor-specific 2343 commands to be encoded as OctetStrings, so that devices from 2344 different vendors can be commonly managed by a single policy server. 2346 7.3. Using Time Validity Periods 2348 Time validity periods are defined as a subclass of policyCondition, 2349 called policyTimePeriodCondition. This is to allow their inclusion 2350 in the AND/OR condition definitions for a policyRule. Care should be 2351 taken not to subclass policyTimePeriodCondition to add domain- 2352 specific condition properties. For example, it would be incorrect to 2353 add IPSec- or QoS-specific condition properties to the 2354 policyTimePeriodCondition class, just because IPSec or QoS includes 2355 time in its condition definition. The correct subclassing would be to 2356 create IPSec or QoS-specific subclasses of policyCondition and then 2357 combine instances of these domain-specific condition classes with the 2358 validity period criteria. This is accomplished using the AND/OR 2359 aggregation capabilities for policyConditions in policyRules. 2361 8. Security Considerations 2363 Security and denial of service considerations are not explicitly 2364 considered in this memo, as they are appropriate for the underlying 2365 policy architecture. However, the policy architecture must be secure 2366 as far as the following aspects are concerned. First, the mechanisms 2367 proposed under the framework must minimize theft and denial of 2368 service threats. Second, it must be ensured that the entities (such 2369 as PEPs and PDPs) involved in policy control can verify each other's 2370 identity and establish necessary trust before communicating. The 2371 schema defined in this document MUST not compromise either of these 2372 goals. 2374 9. Intellectual Property 2376 The IETF takes no position regarding the validity or scope of any 2377 intellectual property or other rights that might be claimed to 2378 pertain to the implementation or use of the technology described in 2379 this document or the extent to which any license under such rights 2380 might or might not be available; neither does it represent that it 2381 has made any effort to identify any such rights. Information on the 2382 IETF's procedures with respect to rights in standards-track and 2383 standards-related documentation can be found in BCP-11. 2385 Copies of claims of rights made available for publication and any 2386 assurances of licenses to be made available, or the result of an 2387 attempt made to obtain a general license or permission for the use of 2388 such proprietary rights by implementers or users of this 2389 specification can be obtained from the IETF Secretariat. 2391 The IETF invites any interested party to bring to its attention any 2392 copyrights, patents or patent applications, or other proprietary 2393 rights which may cover technology that may be required to practice 2394 this standard. Please address the information to the IETF Executive 2395 Director. 2397 10. Acknowledgments 2399 This document is closely aligned with the work being done in the 2400 Desktop Management Task Force (DMTF) Service Level Agreements and 2401 Networks working groups. As noted, the Core Schema described here 2402 was initially defined in references [2] and [3]. We would especially 2403 like to thank Raju Rajan, Sanjay Kamat, Andrea Westerinen, Lee 2404 Rafalow, Raj Yavatkar, Glenn Waters, David Black, Michael Richardson, 2405 Mark Stevens, David Jones, and Hugh Mahon for their helpful comments. 2407 11. References 2409 [1] J. Strassner and E. Ellesson, "Terminology for describing network 2410 policy and services", draft-strassner-policy-terms-00.txt, August 2411 1998. 2413 [2] Bhattacharya, P., and R. Adams, W. Dixon, R. Pereira, R. Rajan, 2414 "An LDAP Schema for Configuration and Administration of IPSec 2415 based Virtual Private Networks (VPNs)", Internet-Draft work in 2416 progress, October 1998 2418 [3] Rajan, R., and J. C. Martin, S. Kamat, M. See, R. Chaudhury, D. 2419 Verma, G. Powers, R. Yavatkar, "Schema for Differentiated Services 2420 and Integrated Services in Networks", Internet-Draft work in 2421 progress, October 1998 2423 [4] J. Strassner and S. Judd, "Directory-Enabled Networks", version 2424 3.0c5 (August 1998). 2426 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2427 Levels", BCP 14, RFC 2119, March 1997. 2429 [6] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 2430 Standards Process", BCP 11, RFC 2028, October 1996. 2432 [7] Wahl, M., and S. Kille, T. Howes, "Lightweight Directory Access 2433 Protocol (v3): UTF-8 String Representation of Distinguished 2434 Names", RFC 2253, December 1997. 2436 [8] J. Strassner, policy architecture BOF presentation, 42nd IETF 2437 Meeting, Chicago, Illinois, October, 1998 2439 [9] DMTF web site, http://www.dmtf.org. 2441 12. Authors' Addresses 2443 John Strassner 2444 Cisco Systems, Bldg 1 2445 170 West Tasman Drive 2446 San Jose, CA 95134 2447 Phone: +1 408-527-1069 2448 Fax: +1 408-527-1722 2449 E-mail: johns@cisco.com 2451 Ed Ellesson 2452 IBM Corporation, JDGA/501 2453 4205 S. Miami Blvd. 2454 Research Triangle Park, NC 27709 2455 Phone: +1 919-254-4115 2456 Fax: +1 919-254-6243 2457 E-mail: ellesson@raleigh.ibm.com 2459 Bob Moore 2460 IBM Corporation, JDGA/501 2461 4205 S. Miami Blvd. 2462 Research Triangle Park, NC 27709 2463 Phone: +1 919-254-4436 2464 Fax: +1 919-254-6243 2465 E-mail: remoore@us.ibm.com 2467 13. Full Copyright Statement 2469 Copyright (C) The Internet Society (1999). All Rights Reserved. 2471 This document and translations of it may be copied and furnished to 2472 others, and derivative works that comment on or otherwise explain it 2473 or assist in its implementation may be prepared, copied, published 2474 and distributed, in whole or in part, without restriction of any 2475 kind, provided that the above copyright notice and this paragraph are 2476 included on all such copies and derivative works. However, this 2477 document itself may not be modified in any way, such as by removing 2478 the copyright notice or references to the Internet Society or other 2479 Internet organizations, except as needed for the purpose of 2480 developing Internet standards in which case the procedures for 2481 copyrights defined in the Internet Standards process must be 2482 followed, or as required to translate it into languages other than 2483 English. 2485 The limited permissions granted above are perpetual and will not be 2486 revoked by the Internet Society or its successors or assigns. 2488 This document and the information contained herein is provided on an 2489 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2490 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2491 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2492 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2493 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2495 14. Appendix A - Guidelines for Construction of DNs 2497 To Be Provided