idnits 2.17.1 draft-ietf-policy-core-schema-02.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. == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 16) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 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 == 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 (February 1999) is 9200 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 2008, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2011, 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: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 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 (editor) 5 IBM Corporation 6 February 1999 8 Policy Framework Core Information Model 9 draft-ietf-policy-core-schema-02.txt 10 February 26, 1999 13:09 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 The LDAP schema described in this document consists of five very 61 general classes: policyGroup, policyRule, policyCondition, 62 policyTimePeriodCondition, and policyAction. The schema also 63 contains two less general classes: vendorPolicyCondition and 64 vendorPolicyAction. Finally, to achieve the mapping of the CIM 65 relationships, the schema contains two auxiliary classes: 66 policyGroupContainmentAuxClass and policyRuleContainmentAuxClass. 68 While these classes are general, they are not abstract: they can all 69 be directly instantiated. Policy solutions for specific areas, such 70 as DiffServ and IPSec, may use the policyGroup, policyRule, and 71 policyTimePeriodCondition classes, as well as the two auxiliary 72 classes, directly, while creating their own subclasses derived from 73 policyCondition and policyAction in order to represent their own 74 application-specific needs. 76 Table of Contents 78 1. Introduction....................................................4 80 2. Modeling Policies...............................................6 81 2.1. Policy Scope..................................................8 83 3. Overview of the Schema..........................................9 84 3.1. Relationships.................................................9 85 3.2. Associations.................................................10 86 3.3. Aggregations.................................................10 87 3.4. Key Relationships in the CIM Policy Model....................10 89 4. Inheritance Hierarchy for the LDAP Core Policy Schema..........12 91 5. Class Definitions for the LDAP Schema..........................12 92 5.1. Naming Attributes in the Core Schema.........................12 93 5.2. The Class policyGroup........................................13 94 5.2.1. The attribute cn...........................................14 95 5.2.2. The Attribute policyGroupName..............................14 96 5.2.3. The Attribute policyGroupKeywords..........................15 97 5.3. The Class policyGroupContainmentAuxClass.....................15 98 5.3.1. The Attribute policyGroupsAuxContainedSet..................16 99 5.4. The Class policyRuleContainmentAuxClass......................16 100 5.4.1. The Attribute policyRulesAuxContainedSet...................17 101 5.5. The Class policyRule.........................................17 102 5.5.1. The Attribute cn...........................................19 103 5.5.2. The Attribute policyRuleName...............................19 104 5.5.3. The Attribute policyRuleEnabled............................19 105 5.5.4. The Attribute policyRuleConditionListType..................20 106 5.5.5. The Attribute policyRuleConditionList......................20 107 5.5.6. The Attribute policyRuleActionList.........................22 108 5.5.7. The Attribute policyRuleValidityPeriodList.................23 109 5.5.8. The Attribute policyRuleKeywords...........................23 110 5.5.9. The Attribute policyRuleUsage..............................24 111 5.5.10. The Attribute policyRulePriority..........................24 112 5.5.11. The Attribute policyRuleMandatory.........................25 113 5.5.12. The Attribute policyRuleSequencedActions..................25 114 5.6. The Class policyTimePeriodCondition..........................26 115 5.6.1. The Attribute ptpConditionTime.............................27 116 5.6.2. The Attribute ptpConditionMonthOfYearMask..................28 117 5.6.3. The Attribute ptpConditionDayOfMonthMask...................28 118 5.6.4. The Attribute ptpConditionDayOfWeekMask....................29 119 5.6.5. The Attribute ptpConditionTimeOfDayMask....................29 120 5.6.6. The Attribute ptpConditionTimeZone.........................30 121 5.7. The Class policyCondition....................................31 122 5.7.1. The Attribute cn...........................................32 123 5.7.2. The Attribute policyConditionName..........................32 124 5.8. The Class vendorPolicyCondition..............................33 125 5.8.1. The Attribute vendorPolicyConstraintData...................33 126 5.8.2. The Attribute vendorPolicyConstraintEncoding...............34 127 5.9. The Class policyAction.......................................34 128 5.9.1. The Attribute cn...........................................35 129 5.9.2. The Attribute policyActionName.............................35 130 5.10. The Class vendorPolicyAction................................35 131 5.10.1. The Attribute vendorPolicyActionData......................36 132 5.10.2. The Attribute vendorPolicyActionEncoding..................36 134 6. Locating Policy Objects in the Directory.......................36 136 7. Extending the Core Schema......................................37 137 7.1. Subclassing policyCondition and policyAction.................37 138 7.2. Subclassing policyRule.......................................37 139 7.2.1. Refining the semantics of policyRule.......................37 140 7.2.2. Optimizing the computation of a policyRule.................38 141 7.3. Using the Vendor Policy Encoding Attributes..................38 142 7.4. Using Time Validity Periods..................................38 144 8. Security Considerations........................................39 146 9. Intellectual Property..........................................39 148 10. Acknowledgments...............................................39 150 11. References....................................................40 152 12. Authors' Addresses............................................40 154 13. Full Copyright Statement......................................41 156 14. Appendix A - Guidelines for Construction of DNs...............41 158 1. Introduction 160 This document takes as its starting point the object-oriented 161 information model for representing policy information currently under 162 development as part of the Common Information Model (CIM) activity in 163 the Desktop Management Task Force (DMTF). This CIM model defines two 164 hierarchies of object classes: structural classes representing 165 policy information and control of policies, and relationship classes 166 that indicate how instances of the structural classes are related to 167 each other. In general, both of these class hierarchies will need to 168 be mapped to a particular data store. 170 This draft defines the mapping of these DMTF-defined CIM classes to a 171 directory that uses LDAPv3 as its access protocol. Two types of 172 mappings are involved: 174 o For the structural classes in the CIM model, the mapping is 175 basically one-for-one: CIM classes map to LDAP classes, CIM 176 properties map to LDAP attributes. 178 o For the relationship classes in the CIM model, different mappings 179 are possible. In this document the CIM relationship classes and 180 their properties are mapped in three ways: to LDAP auxiliary 181 classes, to attributes representing DN pointers, and to "composite" 182 attributes representing DN pointers with additional data elements. 184 Implementations that use an LDAP directory as their policy repository 185 SHALL use the LDAP policy schema defined in this document. The use 186 of the CIM information model as the starting point enables the schema 187 and the relationship class hierarchy to be extensible, such that 188 other types of policy repositories, such as relational databases, can 189 also use this information. 191 These policy classes and their relationships are sufficiently generic 192 to allow them to represent policies related to anything. However, 193 their initial application will be for representing policies related 194 to QoS (DiffServ and IntServ) and to IPSec. Policy models for 195 application-specific areas such as these may extend the core schema 196 in several ways. The preferred way is to use the policyGroup, 197 policyRule, policyTimePeriodCondition, and 198 policyRuleContainmentAuxClass classes directly, as a foundation for 199 representing and communicating policy information. Then, specific 200 subclasses derived from policyCondition and policyAction can capture 201 application-specific definitions of conditions and actions of 202 policies. These subclasses will then fit naturally within the policy 203 framework of the above four classes. This will be explored more 204 thoroughly in Section 7.0, "Extending the Core Schema". 206 Two subclasses, vendorPolicyCondition and vendorPolicyAction, are 207 also included in this document, to provide a standard escape 208 mechanism for vendor-specific extensions to the core policy schema. 210 This document fits into the overall framework for representing, 211 deploying, and managing policies being developed by the Policy 212 Framework Working Group. The initial work to define this framework 213 is in reference [1]. More specifically, this document builds on the 214 core policy classes first introduced in references [2] and [3]. It 215 also draws on the work done for the Directory-enabled Networks (DEN) 216 specification, reference [4]. Work on the DEN specification by the 217 DEN Ad-Hoc Working Group itself has been completed. Further work to 218 standardize the models contained in it will be the responsibility of 219 selected working groups of the CIM effort in the Desktop Management 220 Task Force (DMTF). Standardization of the core policy model is the 221 responsibility of the SLA Policy working group. 223 This document is organized in the following manner: 225 o Section 2 provides a general overview of policies and how they are 226 modeled. 228 o Section 3 takes a brief look at the DMTF's CIM policy classes and 229 relationships. The complete CIM policy definitions are available 230 on the DMTF's web site; see reference [9]. 232 o The remainder of the document presents the mapping of the CIM 233 policy classes and relationships into an LDAP schema . 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 237 document are to be interpreted as described in RFC 2119, reference 238 [5]. 240 2. Modeling Policies 242 The classes comprising the Policy Framework core schema are intended 243 to serve as an extensible class hierarchy (through specialization) 244 for defining policy objects that enable application developers, 245 network administrators, and policy administrators to represent 246 policies of different types. 248 One way to think of a policy-controlled network is to first model the 249 network as a state machine and then use policy to control which state 250 a policy-controlled device should be in or is allowed to be in at any 251 given time. Given this approach, policy is applied using a set of 252 policy rules. Each policy rule consists of a set of conditions and a 253 set of actions. Policy rules may be aggregated into policy groups. 254 These groups may be nested, to represent a hierarchy of policies. 256 The set of conditions associated with a policy rule specifies when 257 the policy rule is applicable. The set of conditions can be expressed 258 as either an ORed set of ANDed sets of condition statements or an 259 ANDed set of ORed sets of statements. Individual condition statements 260 can also be negated. These combinations are termed, respectively, 261 Disjunctive Normal Form (DNF) and Conjunctive Normal Form (CNF) for 262 the conditions. Please note that it is explicitly NOT a goal of this 263 specification to represent more complicated conditions (such as those 264 that may be found in a procedural language) at this time. 266 If the set of conditions associated with a policy rule evaluates to 267 TRUE, then a set of actions that either maintain the current state of 268 the object or transition the object to a new state may be executed. 269 For the set of actions associated with a policy rule, it is possible 270 to specify an order of execution, as well as an indication of whether 271 the order is required or merely recommended. It is also possible to 272 indicate that the order in which the actions are executed does not 273 matter. 275 Policy rules themselves can be prioritized. One common reason for 276 doing this is to express an overall policy that has a general case 277 with a few specific exceptions. 279 For example, a general QoS policy rule might specify that traffic 280 originating from members of the engineering group is to get Bronze 281 Service. A second policy rule might express an exception: traffic 282 originating from John, a specific member of the engineering group, is 283 to get Gold Service. Since traffic originating from John satisfies 284 the conditions of both policy rules, and since the actions associated 285 with the two rules are incompatible, a priority needs to be 286 established. By giving the second rule (the exception) a higher 287 priority than the first rule (the general case), a policy 288 administrator can get the desired effect: traffic originating from 289 John gets Gold Service, and traffic originating from all the other 290 members of the engineering group gets Bronze Service. 292 Policies can either be used in a stand-alone fashion or aggregated 293 into policy groups to perform more elaborate functions. Stand-alone 294 policies are called policy rules. Policy groups are aggregations of 295 policy rules, or aggregations of policy groups, but not both. Policy 296 groups can model intricate interactions between objects that have 297 complex interdependencies. Examples of this include a sophisticated 298 user logon policy that sets up application access, security, and 299 reconfigures network connections based on a combination of user 300 identity, network location, logon method and time of day. A policy 301 group represents a unit of reusability and manageability in that its 302 management is handled by an identifiable group of administrators and 303 its policy rules apply equally to the scope of the policy group. 305 Stand-alone policies are those that can be expressed in a simple 306 statement. They can be represented effectively in schemas or MIBs. 307 Examples of this are VLAN assignments, simple YES/NO QoS requests, 308 and IP address allocations. A specific design goal of this schema is 309 to support both stand-alone and aggregated policies. 311 Policy groups and rules can be classified by their purpose and 312 intent. This classification is useful in querying or grouping policy 313 rules. It indicates whether the policy is used to motivate when or 314 how an action occurs, or to characterize services (that can then be 315 used, for example, to bind clients to network services). Describing 316 each of these concepts in more detail, 318 o Motivational Policies are solely targeted at whether or how a 319 policy's goal is accomplished. Configuration and Usage Policies 320 are specific kinds of Motivational Policies. Another example is 321 the scheduling of file backup based on disk write activity from 8am 322 to 3pm, M-F. 324 o Configuration Policies define the default (or generic) setup of a 325 managed entity (for example, a network service). Examples of 326 Configuration Policies are the setup of a network forwarding 327 service or a network-hosted print queue. 329 o Installation Policies define what can and cannot be put on a system 330 or component, as well as the configuration of the mechanisms that 331 perform the install. Installation policies typically represent 332 specific administrative permissions, and can also represent 333 dependencies between different components (e.g., to complete the 334 installation of component A, components B and C must be previously 335 successfully installed or uninstalled). 337 o Error and Event Policies. For example, if a device fails between 338 8am and 9pm, call the system administrator, else call the Help 339 Desk. 341 o Usage Policies control the selection and configuration of entities 342 based on specific "usage" data. Configuration Policies can be 343 modified or simply re-applied by Usage Policies. Examples of Usage 344 Policies include upgrading network forwarding services after a user 345 is verified to be a member of a "gold" service group, or 346 reconfiguring a printer to be able to handle the next job in its 347 queue. 349 o Security Policies deal with verifying that the client is actually 350 who the client purports to be, permitting or denying access to 351 resources, selecting and applying appropriate authentication 352 mechanisms, and performing accounting and auditing of resources. 354 o Service Policies characterize network and other services (not use 355 them). For example, all wide-area backbone interfaces shall use a 356 specific type of queuing. 358 Service policies describe services available in the network. Usage 359 policies describe the particular binding of a client of the network 360 to services available in the network. 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 policy schema 374 classes are intended to be used as part of the definition of this 375 specification. 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 classes that 386 comprise the CIM core schema, and their relationships to each other. 387 Note that the two extension classes VendorPolicyCondition and 388 VendorPolicyAction are not shown. 390 ************** 391 * * 392 0..n * * ContainedPolicyGroup 393 +------v------+ * 394 | PolicyGroup <****** 395 | | 0..n 396 +------^------+ 397 0..n * 398 * ContainedPolicyRule 399 0..n * 400 +-----v-------+ 401 | | 402 | PolicyRule | 403 | | ContainedPolicyCondition 404 | <**************************** 405 | | 0..n * 406 | | * 0..n 407 | | +---------v------------+ 408 | | | PolicyCondition | 409 | | +----------------------+ 410 | | PolicyRuleValidityPeriod ^ 411 | <****************** I 412 | | 0..n * I 413 | | * 0..n ^ 414 | | +----v----------------------+ 415 | | | PolicyTimePeriodCondition | 416 | | +---------------------------+ 417 | | 418 | | ContainedPolicyAction 419 | <***************************** 420 | | 0..n * 421 | | * 0..n 422 | | +----------v-----------+ 423 | | | PolicyAction | 424 +-------------+ +----------------------+ 426 Figure 1. Overview of the CIM Policy Classes and Their 427 Relationships 429 3.1. Relationships 431 Relationships are a central feature of information models. A 432 relationship represents a physical or conceptual connection between 433 objects. CIM and DEN define the general concept of an association 434 between two (or more) objects. Two types of associations are 435 aggregations (which express whole-part relationships) and other 436 relationships, such as those that express dependency. Both are used 437 in this model. 439 3.2. Associations 441 An association is a class that contains two or more references, where 442 each reference identifies another object. An association is defined 443 using a class. Associations can be defined between classes without 444 affecting any of the related classes. That is, addition of an 445 association does not affect the interface of the related classes. 447 3.3. Aggregations 449 An aggregation is a strong form of an association. An aggregation is 450 usually used to represent a "whole-part" relationship. This type of 451 relationship defines the containment relationship between a system 452 and the components that make up the system. Aggregation often 453 implies, but does not require, that the aggregated objects have 454 mutual dependencies. 456 3.4. Key Relationships in the CIM Policy Model 458 The following relationships are shown in the preceding figure: 460 o The ContainedPolicyGroup relationship enables policy groups to be 461 nested. This is critical for scalability and manageability, as it 462 enables complex policies to be constructed from multiple simpler 463 policies for administrative convenience. For example, a policy 464 group representing policies for the US might have nested within it 465 policy groups for the Eastern and Western US. 467 In the LDAP schema, the ContainedPolicyGroup relationship is mapped 468 to the policyGroupsAuxContainedSet attribute in the auxiliary class 469 policyGroupContainmentAuxClass. (Other data stores may define a 470 different mapping). This attribute enables a policyGroup to 471 identify another policyGroup as its offspring. 473 o A policy group may aggregate one or more policy rules, via the 474 ContainedPolicyRule relationship. Grouping of policy rules into a 475 policy group is again for administrative convenience; a policy rule 476 may also be used by itself, without belonging to a policy group. 478 In the LDAP schema, the ContainedPolicyRule relationship is mapped 479 to the policyRulesAuxContainedSet attribute in the auxiliary class 480 policyRuleContainmentAuxClass. 482 o A policy group or policy rule may also be aggregated by an instance 483 of any class to which the policyGroupContainmentAuxClass or 484 policyRuleContainmentAuxClass class has been attached. Again, this 485 is for administrative convenience. If the directory entry to which 486 the policyGroupContainmentAuxClass or policyRuleContainmentAuxClass 487 has been attached is a policy group, then the pointer in the 488 auxiliary class realizes one of the relationships discussed above; 489 a separate attribute is not needed in the policyGroup class. If 490 the directory entry is something other than a policy group, then 491 the pointer in the auxiliary class realizes a Jurisdiction 492 relationship from the CIM model. Note that these relationships are 493 not shown in Figure 1. 495 o A policy rule aggregates zero or more instances of the 496 PolicyCondition class, via the ContainedPolicyCondition 497 association. For all policy rules, at least one condition MUST be 498 specified, either via the ContainedPolicyCondition aggregation, or 499 defined explicitly within a subclass of PolicyRule. These 500 conditions are grouped into two levels of lists: either an ORed set 501 of ANDed sets of conditions (DNF, the default) or an ANDed set of 502 ORed sets of conditions (CNF). Individual conditions in these 503 lists may be negated. The attribute PolicyRuleConditionListType 504 specifies which of these two grouping schemes applies to a 505 particular PolicyRule. 507 Since conditions may be defined explicitly in a subclass of 508 PolicyRule, the AND/OR mechanism to combine these conditions with 509 other (associated) PolicyConditions MUST be specified by the 510 PolicyRule's subclass. 512 In either case, the conditions are used to determine whether to 513 perform the actions associated with the PolicyRule. 515 o One or more policy time periods may be among the conditions 516 associated with a policy rule via the ContainedPolicyCondition 517 association. In this case, the time periods are simply additional 518 conditions to be evaluated along with any other conditions 519 specified for the rule. 521 o A different relationship between a policy rule and a policy time 522 period is represented by the PolicyRuleValidityPeriod association: 523 scheduled activation and deactivation of the policy rule. If a 524 policy rule is associated with multiple policy time periods via 525 this association, then the rule is active if at least one of the 526 time periods indicates that it is active. (In other words, the 527 time periods are ORed to determine whether the rule is active.) A 528 policy time period may be aggregated by multiple policy rules. A 529 rule that does not point to a policy time period via this 530 association is, from the point of view of scheduling, always 531 active. It may, however, be inactive for other reasons. 533 Time periods are a general concept that can be used in other 534 applications. However, they are mentioned explicitly here in this 535 specification since they are frequently used in policy 536 applications. 538 o A policy rule may aggregate zero or more policy actions. For all 539 policy rules, at least one action MUST be specified, either via the 540 ContainedPolicyAction aggregation, or defined explicitly within a 541 subclass of PolicyRule. The actions associated with a PolicyRule 542 may be given a required order, a recommended order, or no order at 543 all. For actions represented as separate objects, the 544 ContainedPolicyAction aggregation can be used to express an order. 545 For actions defined explicitly in a subclass of PolicyRule, the 546 ordering mechanism must be specified in the subclass definition. 548 4. Inheritance Hierarchy for the LDAP Core Policy Schema 550 The following diagram illustrates the class hierarchy for the LDAP 551 policy schema classes: 553 top 554 | 555 +---policyGroup 556 | 557 +---policyGroupContainmentAuxClass 558 | 559 +---policyRuleContainmentAuxClass 560 | 561 +---policyRule 562 | 563 +---policyCondition 564 | | 565 | +---policyTimePeriodCondition 566 | | 567 | +---vendorPolicyCondition 568 | 569 +---policyAction 570 | 571 +---vendorPolicyAction 573 5. Class Definitions for the LDAP Schema 575 The classes described below contain certain optimizations for a 576 directory that uses LDAP as its access protocol. One example of this 577 is the use of an auxiliary class to represent CIM relationships. 578 Other data stores might need to implement these relationships 579 differently. 581 5.1. Naming Attributes in the Core Schema 583 Instances in a directory are identified by distinguished names (DNs), 584 which provide the same type of hierarchical organization that a file 585 system provides in a computer system. A distinguished name is a 586 sequence of relative distinguished names (RDNs), where an RDN 587 provides a unique identifier for an instance within the context of 588 its immediate superior, in the same way that a filename provides a 589 unique identifier for a file within the context of the folder in 590 which it resides. 592 To preserve maximum naming flexibility for policy administrators, 593 each of the classes defined in this schema has its own naming 594 attribute. Since the naming attributes are different, the policy 595 administrator can, by using these attributes, guarantee that there 596 will be no name collisions between instances of different classes, 597 even if the same VALUE is assigned to the instances' respective 598 naming attributes. 600 To fit in with existing DEN practice, each of the classes also has 601 the commonName (cn) attribute that can be used for naming its 602 instances. 604 5.2. The Class policyGroup 606 This class is a generalized aggregation container. It enables either 607 policyRules or policyGroups, but not both, to be aggregated in a 608 single container. Loops, including the degenerate case of a 609 policyGroup that contains itself, are not allowed when policyGroups 610 contain other policyGroups. 612 PolicyGroups and their nesting capabilities are shown in Figure 2 613 below. Note that a policyGroup can nest other policyGroups, and there 614 is no restriction on the depth of the nesting in sibling 615 policyGroups. 617 +---------------------------------------------------+ 618 | policyGroup | 619 | | 620 | +--------------------+ +-----------------+ | 621 | | policyGroup A | | policyGroup X | | 622 | | | | | | 623 | | +----------------+ | ooo | | | 624 | | | policyGroup A1 | | | | | 625 | | +----------------+ | | | | 626 | +--------------------+ +-----------------+ | 627 +---------------------------------------------------+ 629 Figure 2. Overview of the policyGroup class 631 As a simple example, think of the highest level policyGroup shown in 632 Figure 2 above as a logon policy for US employees of a company. This 633 policyGroup may be called USEmployeeLogonPolicy, and may aggregate 634 several policyGroups that provide specialized rules per location. 635 Hence, policyGroup A in Figure 2 above may define logon rules for 636 employees on the West Coast, while another policyGroup might define 637 logon rules for the Midwest (e.g., policyGroup X), and so forth. 639 Note also that the depth of each policyGroup does not need to be the 640 same. Thus, the WestCoast policyGroup might have several additional 641 layers of policyGroups defined for any of several reasons (different 642 locales, number of subnets, etc.). The policyRules are therefore 643 contained at n levels from the USEmployeeLogonPolicyGroup. Compare 644 this to the Midwest policyGroup (policyGroup X), which might directly 645 contain policyRules. 647 The class definition for policyGroup is as follows. Note that this 648 class definition does not include attributes to realize the 649 ContainedPolicyRule and ContainedPolicyGroup associations from the 650 object model, since a policyGroup object points to instances of 651 policyGroup and policyRule via, respectively, the pointer in 652 policyGroupContainmentAuxClass and the pointer in 653 policyRuleContainmentAuxClass. 655 NAME policyGroup 656 DESCRIPTION A container for either a set of related 657 policyRules or a set of related policyGroups. 658 DERIVED FROM top 659 TYPE structural 660 AUXILIARY CLASSES policyGroupContainmentAuxClass, 661 policyRuleContainmentAuxClass 662 POSSIBLE SUPERIORS container, organization, organizationalUnit, 663 policyGroup 664 OID 665 MUST cn, policyGroupName 666 MAY policyGroupKeywords 668 5.2.1. The attribute cn 670 The cn, or commonName, attribute is an X.500 attribute. It stands for 671 commonName. It specifies a user-friendly name by which the object is 672 commonly known. This name may be ambiguous by itself. This name is 673 used in a limited scope (such as an organization). It conforms to the 674 naming conventions of the country or culture with which it is 675 associated. CN is used universally in DEN as the naming attribute for 676 a class. 678 NAME cn 679 DESCRIPTION Naming attribute of this class 680 SYNTAX DirectoryString 681 OID 2.4.5.3 682 EQUALITY caseExactMatch 683 SINGLE-VALUED 685 5.2.2. The Attribute policyGroupName 687 This attribute provides a user-friendly name for a policy group, and 688 is normally what will be displayed to the end-user as the name of 689 this class. It is defined as follows: 691 NAME policyGroupName 692 DESCRIPTION The user-friendly name of this policy group. 693 SYNTAX IA5String 694 OID 695 EQUALITY caseExactIA5Match 696 SINGLE-VALUED 698 5.2.3. The Attribute policyGroupKeywords 700 This attribute provides a set of one or more keywords that a policy 701 administrator may define to assist directory clients in locating the 702 policy groups applicable to them. Keywords are of one of two types: 704 o Keywords defined in this document, or in documents that define 705 subclasses of the classes defined in this document. These keywords 706 provide a vendor-independent, installation-independent way of 707 identifying and locating policy groups. 709 o Installation-dependent keywords for identifying and locating policy 710 groups. Examples include "Engineering", "Billing", and "Review in 711 December 1999". 713 This document defines the following keywords for identifying policy 714 groups: "UNKNOWN", "CONFIGURATION", "USAGE", "SECURITY", "SERVICE", 715 "MOTIVATIONAL", "INSTALLATION", and "EVENT". These concepts were 716 defined in Section 2.0. 718 Documents that define subclasses of the Core Schema classes should 719 define additional keywords to identify policy groups associated with 720 instances of these subclasses. By convention, keywords defined in 721 conjunction with class definitions are in uppercase. Installation- 722 defined keywords can be in any case. 724 The attribute definition is as follows: 726 NAME policyGroupKeywords 727 DESCRIPTION A set of keywords to assist directory clients in 728 locating the policy groups applicable to them. 729 SYNTAX IA5String 730 OID 731 EQUALITY caseExactIA5Match 732 MULTI-VALUED 734 5.3. The Class policyGroupContainmentAuxClass 736 This auxiliary class provides a single, multi-valued attribute that 737 points to a set of policyGroups. By attaching this attribute to 738 instances of various other classes, a policy administrator has a 740 flexible way of providing an entry point into the directory that 741 allows a client to locate and retrieve the policyGroups relevant to 743 it. 745 As is the case with policyRules, a policy administrator might have 746 several different pointers to a policyGroup in the overall directory 747 structure. The policyGroupContainmentAuxClass is the mechanism that 749 makes it possible for the policy administrator to define all these 750 pointers. 752 The class definition is as follows: 754 NAME policyGroupContainmentAuxClass 755 DESCRIPTION An auxiliary class used to bind policyGroups 756 to an appropriate container object. 757 DERIVED FROM top 758 TYPE auxiliary 759 AUXILIARY CLASSES none 760 OID 761 MUST policyGroupsAuxContainedSet 763 5.3.1. The Attribute policyGroupsAuxContainedSet 765 This attribute provides an unordered set of DN pointers to one or 767 more policyGroups associated with the instance of a structural class 768 to which this attribute has been appended. The attribute definition 770 is: 772 NAME policyGroupsAuxContainedSet 773 DESCRIPTION Distinguished names of policyGroups associated in 774 some way with the instance to which this attribute 775 has been appended. No order is implied. 776 SYNTAX DN 777 OID 778 EQUALITY distinguishedNameMatch 779 MULTI-VALUED 781 5.4. The Class policyRuleContainmentAuxClass 783 This auxiliary class provides a single, multi-valued attribute that 784 points to a set of policyRules. By attaching this attribute to 785 instances of various other classes, a policy administrator has a 786 flexible way of providing an entry point into the directory that 787 allows a client to locate and retrieve the policyRules relevant to 788 it. 790 A policy administrator might have several different pointers to a 791 policyRule in the overall directory structure. For example, there 792 might be pointers to all policyRules for traffic originating in a 793 particular subnet from a directory entry that represents that subnet. 794 At the same time, there might be pointers to all policyRules related 795 to a particular DiffServ setting from an instance of a policyGroup 796 explicitly introduced as a container for DiffServ-related 797 policyRules. The policyRuleContainmentAuxClass is the mechanism that 798 makes it possible for the policy administrator to define all these 799 pointers. 801 Note that the cn attribute does NOT need to be defined for this 802 class. This is because an auxiliary class is used as a means to 803 collect common attributes and treat them as properties of an object. 804 A good analogy is a #include file, except that since an auxiliary 805 class is a class, all the benefits of a class (e.g., inheritance) can 806 be applied to an auxiliary class. 808 The class definition is as follows: 810 NAME policyRuleContainmentAuxClass 811 DESCRIPTION An auxiliary class used to bind policyRules to an 812 appropriate container object. 813 DERIVED FROM top 814 TYPE auxiliary 815 AUXILIARY CLASSES none 816 OID 817 MUST policyRulesAuxContainedSet 819 5.4.1. The Attribute policyRulesAuxContainedSet 821 This attribute provides an unordered set of DN pointers to one or 822 more policyRules associated with the instance of a structural class 823 to which this attribute has been appended. The attribute definition 824 is: 826 NAME policyRulesAuxContainedSet 827 DESCRIPTION Distinguished names of policyRules associated in 828 some way with the instance to which this attribute 829 has been appended. No order is implied. 830 SYNTAX DN 831 OID 832 EQUALITY distinguishedNameMatch 833 MULTI-VALUED 835 5.5. The Class policyRule 837 This class represents the "If Condition then Action" semantics 838 associated with a policy. A policyRule condition, in the most 839 general sense, is represented as either an ORed set of ANDed 840 conditions (Disjunctive Normal Form, or DNF) or an ANDed set of ORed 841 conditions (Conjunctive Normal Form, or CNF). Individual conditions 842 may either be negated (NOT C) or unnegated (C). The actions 843 specified by a policyRule are to be performed if and only if the 844 policyRule condition (whether it is represented in DNF or CNF) 845 evaluates to TRUE. Both the conditions and the actions are identified 846 by DN pointers and/or by specific attributes introduced in subclasses 847 of policyRule. 849 As discussed above in section 3, a policy rule may also be associated 850 with one or more policy time periods, indicating the schedule 851 according to which the policy rule is active and inactive. 853 A policy rule is illustrated conceptually in Figure 3 below. 855 +------------------------------------------------+ 856 | policyRule | 857 | | 858 | +--------------------+ +-----------------+ | 859 | | policyCondition(s) | | policyAction(s) | | 860 | +--------------------+ +-----------------+ | 861 | | 862 | +------------------------------+ | 863 | | policyTimePeriodCondition(s) | | 864 | +------------------------------+ | 865 +------------------------------------------------+ 867 Figure 3. Overview of the policyRule Class 869 The policyRule class uses the attribute policyRuleConditionListType, 870 to indicate whether the conditions for the rule are in DNF or CNF. 871 The DN pointers from a policyRule to its associated policyConditions 872 also contain an integer to partition the referenced conditions into 873 one or more sets, and a plus ('+') or minus ('-') character to 874 indicate whether the referenced condition is negated. An example 875 shows how the attribute, the grouping integer, and the '+' / '-' 876 provide a unique representation of a set of conditions in either DNF 877 or CNF. 879 Suppose we have pointers to five policyConditions from an instance of 880 policyRule, grouped as follows: 882 (C1: groupNumber = 1: unnegated, 883 C2: groupNumber = 1: negated, 884 C3: groupNumber = 1: unnegated, 885 C4: groupNumber = 2: unnegated, 886 C5: groupNumber = 2: unnegated) 888 If policyRuleConditionListType = DNF, then the overall condition for 889 the policyRule is: 891 (C1 AND (NOT C2) AND C3) OR (C4 AND C5) 893 On the other hand, if policyRuleConditionListType = CNF, then the 894 overall condition for the policyRule is: 896 (C1 OR (NOT C2) OR C3) AND (C4 OR C5) 898 In both cases, there is an unambiguous specification of the overall 899 condition that is tested to determine whether to perform the actions 900 associated with the policyRule. This class also contains several 901 attributes designed to help directory clients locate the policy rules 902 applicable to them. The class definition is as follows: 904 NAME policyRule 905 DESCRIPTION The central class for representing the "If 906 Condition then Action" semantics associated with a 907 policy rule. 908 DERIVED FROM top 909 TYPE structural 910 AUXILIARY CLASSES none 911 POSSIBLE SUPERIORS policyGroup 912 OID 913 MUST cn policyRuleName 914 MAY policyRuleEnabled policyRuleConditionListType 915 policyRuleConditionList policyRuleActionList 916 policyRuleValidityPeriodList policyRuleKeywords 917 policyRuleUsage policyRulePriority 918 policyRuleMandatory policyRuleSequencedActions 920 5.5.1. The Attribute cn 922 This is the exact same definition as in Section 5.2.1. It is included 923 in this class for the reasons enumerated there. 925 5.5.2. The Attribute policyRuleName 927 This attribute provides a user-friendly name for a policy rule. The 928 attribute definition is as follows: 930 NAME policyRuleName 931 DESCRIPTION The user-friendly name of this policy rule. 932 SYNTAX IA5String 933 OID 934 EQUALITY caseExactIA5Match 935 SINGLE-VALUED 937 5.5.3. The Attribute policyRuleEnabled 939 This attribute indicates whether a policy rule is currently enabled, 940 from an ADMINISTRATIVE point of view. Its purpose is to allow a 941 policy administrator to enable or disable a policy rule without 942 having to add it to, or remove it from, the directory. 944 The attribute also supports the value 'enabledForDebug'. When the 945 attribute has this value, the Policy Decision Point is being told to 946 evaluate the conditions for the policy rule, but not to perform the 947 actions if the conditions evaluate to TRUE. This value serves as a 948 debug vehicle when attempting to determine what policies would 949 execute in a particular scenario, without taking any actions to 950 change state during the debugging. 952 The attribute definition is as follows: 954 NAME policyRuleEnabled 955 DESCRIPTION A flag indicating whether this policy rule is 956 enabled from an administrative point of view. 957 SYNTAX INTEGER 958 OID 959 EQUALITY integerMatch 960 SINGLE-VALUED 961 DEFAULT VALUE enabled(1) 963 The defined values for this attribute are enabled(1), disabled(2), 964 and enabledForDebug(3). 966 5.5.4. The Attribute policyRuleConditionListType 968 This attribute is used to specify whether the list of policy 969 conditions associated with this policy rule is in disjunctive normal 970 form (DNF) or conjunctive normal form (CNF). If this attribute is 971 not present, the list type defaults to DNF. The attribute definition 972 is as follows: 974 NAME policyRuleConditionListType 975 DESCRIPTION Indicates whether the list of policy conditions 976 associated with this policy rule is in disjunctive 977 normal form (DNF) or conjunctive normal form 978 (CNF). Defined values are 'DNF (1)' and 'CNF 979 (2)'. 980 SYNTAX INTEGER 981 OID 982 EQUALITY integerMatch 983 SINGLE-VALUED 984 DEFAULT VALUE 1 (DNF) 986 5.5.5. The Attribute policyRuleConditionList 988 This attribute provides an unordered list of DN pointers that 989 identify a set of policy conditions associated with this policy rule. 990 There is an integer associated with each pointer, to provide the 991 grouping of the conditions into first-level groups for the DNF or CNF 992 representation of the overall policyRule condition. In addition, 993 each pointer has associated with it a plus ('+') or minus ('-') to 994 indicate whether the condition is negated: the '+' indicates that 995 the condition is not negated, and the '-' indicates that it is 996 negated. To accommodate this grouping, the syntax of this attribute 997 is a string of the form 'groupNumber:+|-:DN'. 999 Existing matching rules are built to operate on a single data type. 1000 This attribute is conceptually composed of three data types, an 1001 Integer (groupNumber), an enumeration ('+' or '-'), and a 1002 DistinguishedName (DN). There are three ways to address this. 1004 1. Collapse the three attribute types into a single structured 1005 DirectoryString with the format 'groupNumber:+|-:DN'. This 1006 approach has the advantage of not requiring any new support in the 1007 directory server implementations, since these servers already 1008 support a DirectoryString matching rule. Its disadvantage is that 1009 a DirectoryString match works somewhat differently from a DN match 1010 with respect to subtleties such as preserving versus ignoring 1011 versus removing repeated whitespace characters. Thus DNs that 1012 would match with the distinguishedNameMatch matching rule might 1013 fail to be found as substrings of 'groupNumber:+|-:DN' strings by 1014 the DirectoryString matching rules, or vice versa. 1016 2. Define a new syntax ':<+|->:', with its own matching 1017 rules. With this approach, the matching problems introduced by the 1018 DirectoryString could be avoided, since the new type would have its 1019 own matching rules. The disadvantage of defining a new type in 1020 this way is that a directory server must add new code that 1021 recognizes the type and implements its matching rules. A directory 1022 server would thus be unable to support the Core Policy Schema until 1023 it had added this new code. 1025 3. Use three objects in the directory to represent the three data 1026 types, and relate the objects with the Families of Entries model 1027 currently being discussed in the LDAP Extensions working group. 1028 This approach has the same problem as the previous one: without the 1029 addition of new code to support Families of Entries, a directory 1030 server would be unable to support the Core Policy Schema at all. 1031 There is also the additional complication here, that the Families 1032 of Entries model itself may take some time to reach approved status 1033 in the LDAP Extensions (LDAPEXT) working group. 1035 For now, this document will move forward with the 'groupNumber:+|- 1036 :DN' structured DirectoryString approach for mapping 1037 ContainedPolicyCondition, as well as with an analogous 'n:DN' 1038 approach for mapping ContainedPolicyAction. To minimize problems 1039 arising from differences in matching rules, this document will 1040 provide a series of guidelines for constructing DNs that behave 1041 identically with respect to the DirectoryString matching rules and 1042 the distinguishedNameMatch. These guidelines are in Appendix A. Note 1043 that even if the DNs are chosen so that the matching rules behave the 1044 same, automatic processes such as "Modify RDN" that count on finding 1045 objects with the DistinguishedName syntax will not find attributes 1046 with the structured-string syntaxes. 1048 The attribute definition is as follows: 1050 NAME policyRuleConditionList 1051 DESCRIPTION An unordered list of strings of the form 1052 'groupNumber:+|-:DN', indicating a set of policy 1053 conditions that determine when the policyRule is 1054 applicable. 1055 SYNTAX DirectoryString 1056 OID 1057 EQUALITY caseIgnoreSubstringsMatch 1058 MULTI-VALUED 1059 FORMAT groupNumber:+|-:DN 1061 5.5.6. The Attribute policyRuleActionList 1063 This attribute provides an unordered list of strings of the form 1064 'n:DN' that identify a set of policy actions associated with this 1065 policy rule. (See section 5.4.5 for a discussion of the issues 1066 surrounding the use of a syntax of this type.) When 'n' is a 1067 positive integer, it indicates a place in the sequence of actions to 1068 be performed, with smaller integers indicating earlier positions in 1069 the sequence. The special value '0' indicates "don't care". If two 1070 or more actions have the same non-zero sequence number, they may be 1071 performed in any order, but they must all be performed at the 1072 appropriate place in the overall action sequence. 1074 A series of examples will make ordering of actions clearer: 1076 o If all actions have the same sequence number, regardless of whether 1077 it is '0' or non-zero, any order is acceptable. 1079 o The values 1081 1:DN-A 1082 2:DN-B 1083 1:DN-C 1084 3:DN-D 1086 indicate two acceptable orders: A,C,B,D or C,A,B,D, since A and C 1087 can be performed in either order, but only at the '1' position. 1089 o The values 1091 0:DN-A 1092 2:DN-B 1093 3:DN-C 1094 3:DN-D 1096 require that B,C, and D occur either as B,C,D or as B,D,C. Action 1097 A may appear at any point relative to B,C, and D. Thus the 1098 complete set of acceptable orders is: A,B,C,D; B,A,C,D; B,C,A,D; 1099 B,C,D,A; A,B,D,C; B,A,D,C; B,D,A,C; B,D,C,A. 1101 Note that the non-zero sequence numbers need not start with '1', 1102 and they need not be consecutive. All that matters is their 1103 relative magnitude. 1105 This attribute indicates the actions of a policyRule and their order 1106 (or absence of order). However, another attribute, 1107 policyRuleSequencedActions, indicates whether the indicated order is 1108 required, recommended, or not to be used at all. 1110 All actions specified in the policyRuleActionList will be executed as 1111 long as the overall policy condition as defined by the 1112 policyRuleConditionListType and policyRuleConditionList attributes 1113 evaluates to TRUE. 1115 The attribute definition is as follows: 1117 NAME policyRuleActionList 1118 DESCRIPTION An unordered list of strings of the form 'n:DN', 1119 indicating an ordered set of policy actions to be 1120 performed if the associated condition(s) of the 1121 policyRule evaluates to true. 1122 SYNTAX DirectoryString 1123 OID 1124 EQUALITY caseIgnoreSubstringsMatch 1125 MULTI-VALUED 1126 FORMAT n:DN 1128 5.5.7. The Attribute policyRuleValidityPeriodList 1130 This attribute provides an unordered set of DN pointers to one or 1131 more policyTimePeriodConditions, indicating when the policy rule is 1132 scheduled to be active and when it is scheduled to be inactive. The 1134 rule is scheduled to be active if it is active according to AT LEAST 1135 ONE of the policyTimePeriodConditions pointed to by this attribute. 1137 The attribute definition is: 1139 NAME policyRuleValidityPeriodList 1140 DESCRIPTION Distinguished names of policyTimePeriodConditions 1141 that determine when the policyRule is scheduled to 1142 be active / inactive. No order is implied. 1143 SYNTAX DN 1144 OID 1145 EQUALITY distinguishedNameMatch 1146 MULTI-VALUED 1148 5.5.8. The Attribute policyRuleKeywords 1150 This attribute provides a set of one or more keywords that a policy 1151 administrator may define to assist directory clients in locating the 1152 policy rules applicable to them. Keywords are of one of two types: 1154 o Keywords defined in this document, or in documents that define 1155 subclasses of the classes defined in this document. These keywords 1156 provide a vendor-independent, installation-independent way of 1157 identifying and locating policy rules. 1159 o Installation-dependent keywords for identifying and locating policy 1160 rules. Examples include "Engineering", "Billing", and "Review in 1161 December 1999". 1163 This document defines the following keywords for identifying policy 1164 rules: "UNKNOWN", "CONFIGURATION", "USAGE", "SECURITY", "SERVICE", 1165 "MOTIVATIONAL", "INSTALLATION", and "EVENT". These concepts were 1166 defined in Section 2.0. 1168 Documents that define subclasses of the Core Schema classes should 1169 define additional keywords to identify policy rules associated with 1170 instances of these subclasses. By convention, keywords defined in 1171 conjunction with class definitions are in uppercase. Installation- 1172 defined keywords can be in any case. 1174 The attribute definition is as follows: 1176 NAME policyRuleKeywords 1177 DESCRIPTION A set of keywords to assist directory clients in 1178 locating the policy rules applicable to them. 1179 SYNTAX IA5String 1180 OID 1181 EQUALITY caseExactIA5Match 1182 MULTI-VALUED 1184 5.5.9. The Attribute policyRuleUsage 1186 This attribute is a free-form string that recommends how this policy 1187 should be used. The attribute definition is as follows: 1189 NAME policyRuleUsage 1190 DESCRIPTION This attribute is used to provide guidelines on 1191 how this policy should be used. 1192 SYNTAX DirectoryString 1193 OID 1194 EQUALITY caseIgnoreMatch 1195 SINGLE-VALUED 1197 5.5.10. The Attribute policyRulePriority 1199 This attribute provides a non-negative integer for prioritizing 1200 policy rules relative to each other. For policy rules that have this 1201 attribute, larger integer values indicate higher priority. Since one 1202 purpose of this attribute is to allow specific, ad hoc policy rules 1203 to temporarily override established policy rules, an instance that 1204 has this attribute set has a higher priority than all instances that 1205 lack it. 1207 Prioritization among policy rules provides a simple and efficient 1208 mechanism for resolving policy conflicts. 1210 The attribute definition is as follows: 1212 NAME policyRulePriority 1213 DESCRIPTION A non-negative integer for prioritizing this 1214 policyRule relative to other policyRules. A 1215 larger value indicates a higher priority. 1216 SYNTAX INTEGER 1217 OID 1218 EQUALITY integerMatch 1219 SINGLE-VALUED 1220 DEFAULT VALUE 0 1222 5.5.11. The Attribute policyRuleMandatory 1224 This attribute indicates whether evaluation (and possibly action 1225 execution) of a policyRule is mandatory or not. Its concept is 1226 similar to the ability to mark packets for delivery or possible 1227 discard, based on network traffic and device load. 1229 The evaluation of a policyRule MUST be attempted if the 1230 policyRuleMandatory attribute value is True. If the 1231 policyRuleMandatory attribute value of a policyRule is False, then 1232 the evaluation of the rule is "best effort" and MAY be ignored. 1234 The attribute definition is as follows: 1236 NAME policyRuleMandatory 1237 DESCRIPTION A flag indicating that the evaluation of the 1238 policyConditions and execution of policyActions 1239 (if the condition list evaluates to True) is 1240 required. 1241 SYNTAX Boolean 1242 OID 1243 EQUALITY booleanMatch 1244 SINGLE-VALUED 1245 DEFAULT VALUE TRUE 1247 5.5.12. The Attribute policyRuleSequencedActions 1249 This attribute gives a policy administrator a way of specifying how 1250 the ordering of the policy actions associated with this policyRule is 1251 to be interpreted. Three values are supported: 1253 o mandatory (1): Do the actions in the indicated order, or don't do 1254 them at all. 1256 o recommended (2): Do the actions in the indicated order if you can, 1257 but if you can't do them in this order, do them in another order if 1258 you can. 1260 o dontCare (3): Do them -- I don't care about the order. 1262 When error / event reporting is addressed for the Policy Framework, 1263 suitable codes will be defined for reporting that a set of actions 1264 could not be performed in an order specified as mandatory (and thus 1265 were not performed at all), that a set of actions could not be 1266 performed in a recommended order (and moreover could not be performed 1267 in any order), or that a set of actions could not be performed in a 1268 recommended order (but were performed in a different order). The 1269 attribute definition is as follows: 1271 NAME policyRuleSequencedActions 1272 DESCRIPTION An enumeration indicating how to interpret the 1273 action ordering indicated via the 1274 policyRuleActionList attribute. 1275 SYNTAX INTEGER 1276 OID 1277 EQUALITY integerMatch 1278 SINGLE-VALUED 1279 DEFAULT VALUE 3 1281 The defined values for this attribute are mandatory(1), 1282 recommended(2), and dontCare(3). 1284 5.6. The Class policyTimePeriodCondition 1286 This class provides a means of representing the time periods during 1287 which a policy rule is valid, i.e., active. At all times that fall 1288 outside these time periods, the policy rule has no effect. A policy 1289 rule is treated as valid at all times if it does not specify a 1290 policyTimePeriodCondition. 1292 In some cases a PDP may need to perform certain setup / cleanup 1293 actions when a policy rule becomes active / inactive. For example, 1294 sessions that were established while a policy rule was active might 1295 need to be taken down when the rule becomes inactive. In other 1296 cases, however, such sessions might be left up: in this case, the 1297 effect of deactivating the policy rule would just be to prevent the 1298 establishment of new sessions. Any such setup / cleanup behaviors on 1299 validity period transitions must be specified in a subclass of 1300 policyRule. If such behaviors need to be under the control of the 1301 policy administrator, then a mechanism to allow this control must 1302 also be specified in the subclass. 1304 policyTimePeriodCondition is defined as a subclass of 1305 policyCondition. This is to allow the inclusion of time-based 1306 criteria in the AND/OR condition definitions for a policyRule. 1308 Instances of this class may have up to five attributes identifying 1309 time periods at different levels. The values of all the attributes 1310 present in an instance are ANDed together to determine the validity 1311 period(s) for the instance. For example, an instance with an overall 1312 validity range of January 1, 1999 through December 31, 1999; a month 1313 mask of "001100000000" (March and April); a day-of-the-week mask of 1314 "0000100" (Fridays); and a time of day range of 0800 through 1600 1315 would represent the following time periods: 1317 Friday, March 5, 1999, from 0800 through 1600; 1318 Friday, March 12, 1999, from 0800 through 1600; 1319 Friday, March 19, 1999, from 0800 through 1600; 1320 Friday, March 26, 1999, from 0800 through 1600; 1321 Friday, April 2, 1999, from 0800 through 1600; 1322 Friday, April 9, 1999, from 0800 through 1600; 1323 Friday, April 16, 1999, from 0800 through 1600; 1324 Friday, April 23, 1999, from 0800 through 1600; 1325 Friday, April 30, 1999, from 0800 through 1600. 1327 Attributes not present in an instance of policyTimePeriodCondition 1328 are implicitly treated as having their value "always enabled". Thus, 1329 in the example above, the day-of-the-month mask is not present, and 1330 so the validity period for the instance implicitly includes a day-of- 1331 the-month mask containing 31 1's. If we apply this "missing 1332 attribute" rule to its fullest, we see that there is a second way to 1333 indicate that a policy rule is always enabled: have it point to an 1334 instance of policyTimePeriodCondition whose only attributes are its 1335 naming attributes. 1337 The class definition is as follows. Note that instances of this 1338 class are named with the attributes cn and policyConditionName that 1339 they inherit from policyCondition. 1341 NAME policyTimePeriodCondition 1342 DESCRIPTION A class that provides the capability of enabling / 1343 disabling a policy rule according to a pre- 1344 determined schedule. 1345 DERIVED FROM policyCondition 1346 TYPE structural 1347 AUXILIARY CLASSES none 1348 POSSIBLE SUPERIORS policyRule 1349 OID 1350 MUST 1351 MAY ptpConditionTime ptpConditionMonthOfYearMask 1352 ptpConditionDayOfMonthMask 1353 ptpConditionDayOfWeekMask 1354 ptpConditionTimeOfDayMask ptpConditionTimeZone 1356 5.6.1. The Attribute ptpConditionTime 1358 This attribute identifies an overall range of calendar dates and 1359 times over which a policy rule is valid. It is formatted as a string 1360 consisting of a start date and time, then a colon (':'), and followed 1361 by an end date and time. The first date indicates the beginning of 1362 the range, while the second date indicates the end. Thus, the second 1363 date and time must be later than the first. Dates are expressed as 1364 substrings of the form "yyyymmddhhmmss". For example: 1366 19990101080000:19990131120000 1368 January 1, 1999, 0800 through January 31, 1999, noon 1370 The attribute definition is as follows: 1372 NAME ptpConditionTime 1373 DESCRIPTION The range of calendar dates on which a policy rule 1374 is valid. 1375 SYNTAX PrintableString 1376 OID 1377 EQUALITY caseIgnoreMatch 1378 SINGLE-VALUED 1379 FORMAT yyyymmddhhmmss:yyyymmddhhmmss 1381 5.6.2. The Attribute ptpConditionMonthOfYearMask 1383 The purpose of this attribute is to refine the definition of the 1384 valid time period that is defined by the ptpConditionTime attribute 1385 by explicitly specifying which months the policy is valid for. These 1386 attributes work together, with the ptpConditionTime used to specify 1387 the overall time period that the policy is valid for, and the 1388 ptpConditionMonthOfYearMask used to pick out which months of that 1389 time period the policy is valid for. 1391 This attribute is formatted as a string containing 12 ASCII '0's and 1392 '1's, where the '1's identify the months (beginning with January) in 1393 which the policy rule is valid. The value "000010010000", for 1394 example, indicates that a policy rule is valid only in the months May 1395 and August. 1397 If this attribute is omitted, then the policy assumes that it is 1398 valid for all twelve months. The attribute definition is as follows: 1400 NAME ptpConditionMonthOfYearMask 1401 DESCRIPTION A mask identifying the months of the year in which 1402 a policy rule is valid. 1403 SYNTAX Printable String 1404 OID 1405 EQUALITY caseIgnoreMatch 1406 SINGLE-VALUED 1407 FORMAT A string of 12 ASCII '0's and '1's. 1409 5.6.3. The Attribute ptpConditionDayOfMonthMask 1411 The purpose of this attribute is to refine the definition of the 1412 valid time period that is defined by the ptpConditionTime attribute 1413 by explicitly specifying which days of the month the policy is valid 1414 for. These attributes work together, with the ptpConditionTime used 1415 to specify the overall time period that the policy is valid for, and 1416 the ptpConditionDayOfMonthMask used to pick out which days of the 1417 month that time period the policy is valid for. 1419 This attribute is formatted as a string containing 31 ASCII '0's and 1420 '1's, where the '1's identify the days of the month (beginning with 1421 day 1 and going up through day 31) on which the policy rule is valid. 1422 The value "1110000000000000000000000000000", for example, indicates 1423 that a policy rule is valid only on the first three days of each 1424 month. For months with fewer than 31 days, the digits corresponding 1425 to days that the months do not have are ignored. The attribute 1426 definition is as follows: 1428 NAME ptpConditionDayOfMonthMask 1429 DESCRIPTION A mask identifying the days of the month on which 1430 a policy rule is valid. 1431 SYNTAX PrintableString 1432 OID 1433 EQUALITY caseIgnoreMatch 1434 SINGLE-VALUED 1435 FORMAT A string of 31 ASCII '0's and '1's. 1437 5.6.4. The Attribute ptpConditionDayOfWeekMask 1439 The purpose of this attribute is to refine the definition of the 1440 valid time period that is defined by the ptpConditionTime attribute 1441 by explicitly specifying which days of the week the policy is valid 1442 for. These attributes work together, with the ptpConditionTime used 1443 to specify the overall time period that the policy is valid for, and 1444 the ptpConditionDayOfWeekMask used to pick out which days of the week 1445 of that time period the policy is valid for. 1447 This attribute is formatted as a string containing 7 ASCII '0's and 1448 '1's, where the '1's identify the days of the week (beginning with 1449 Monday and going up through Sunday) on which the policy rule is 1450 valid. The value "1111100", for example, indicates that a policy rule 1451 is valid Monday through Friday. 1453 The attribute definition is as follows: 1455 NAME ptpConditionDayOfWeekMask 1456 DESCRIPTION A mask identifying the days of the week on which a 1457 policy rule is valid. 1458 SYNTAX PrintableString 1459 OID 1460 EQUALITY caseIgnoreMatch 1461 SINGLE-VALUED 1462 FORMAT A string of 7 ASCII '0's and '1's. 1464 5.6.5. The Attribute ptpConditionTimeOfDayMask 1466 The purpose of this attribute is to refine the definition of the 1467 valid time period that is defined by the ptpConditionTime attribute 1468 by explicitly specifying a range of times in a day the policy is 1469 valid for. These attributes work together, with the ptpConditionTime 1470 used to specify the overall time period that the policy is valid for, 1471 and the ptpConditionTimeOfDayMask used to pick out which range of 1472 time periods in a given day of the week of that time period the 1473 policy is valid for. 1475 This attribute is formatted as a string containing two times, 1476 separated by a colon (':'). The first time indicates the beginning 1477 of the range, while the second time indicates the end. Times are 1478 expressed as substrings of the form "hhmmss". 1480 The second substring always identifies a later time than the first 1481 substring. To allow for ranges that span midnight, however, the 1482 value of the second string may be smaller than the value of the first 1483 substring. Thus, "080000:210000" identifies the range from 0800 1484 until 2100, while "210000:080000" identifies the range from 2100 1485 until 0800 of the following day. 1487 When a range spans midnight, it by definition includes parts of two 1488 successive days. When one of these days is also selected by either 1489 the ptpConditionMonthOfYearMask, ptpConditionDayOfMonthMask, and/or 1490 ptpConditionDayOfWeekMask, but the other day is not, then the policy 1491 is active only during the portion of the range that falls on the 1492 selected day. For example, if the range extends from 2100 until 1493 0800, and the day of week mask selects Monday and Tuesday, then the 1494 policy is active during the following three intervals: 1496 From midnight Sunday until 0800 Monday; 1497 From 2100 Monday until 0800 Tuesday; 1498 From 2100 Tuesday until 21:59:59 Tuesday. 1500 The attribute definition is as follows: 1502 NAME ptpConditionTimeOfDayMask 1503 DESCRIPTION The range of times at which a policy rule is 1504 valid. If the second time is earlier than the 1505 first, then the interval spans midnight. 1506 SYNTAX Printable String 1507 OID 1508 EQUALITY caseIgnoreMatch 1509 SINGLE-VALUED 1510 FORMAT hhmmss:hhmmss[:] 1512 5.6.6. The Attribute ptpConditionTimeZone 1514 This attribute is used to explicitly define a time zone for use by 1515 the ptpConditionTime and the various Mask attributes. If this 1516 attribute is NULL, then local time (at the location where the 1517 policyRule is enforced -- in other words, at the Policy Enforcement 1518 Point) is assumed. 1520 This attribute specifies time in UTC, using an offset indicator. The 1521 UTC offset indicator is either a 'Z', indicating UTC, or a substring 1522 of the following form: 1524 '+' or '-' direction from UTC: '+' = east, '-' = west 1525 hh hours from UTC (00..13) 1526 mm minutes from UTC (00..59) 1528 The attribute definition is as follows: 1530 NAME ptpConditionTimeZone 1531 DESCRIPTION The definition of the time zone for the 1532 policyTimePeriodCondition. 1533 SYNTAX PrintableString 1534 OID 1535 EQUALITY caseIgnoreMatch 1536 SINGLE-VALUED 1537 FORMAT either 'Z' (UTC) or {'+' | '-'}'hhmm' 1539 5.7. The Class policyCondition 1541 The purpose of a policy condition is to determine whether or not the 1542 set of actions (contained in the policyRule that the condition 1543 applies to) should be executed or not. For the purposes of the Core 1544 Policy Framework, all that matters about an individual 1545 policyCondition is that it evaluates to TRUE or FALSE. (The 1546 individual policyConditions associated with a policyRule are combined 1547 to form a compound expression in either DNF or CNF, but this is 1548 accomplished via the groupNumber component of the 1549 policyRuleConditionList string and by the policyRuleConditionListType 1550 attribute, both of which are discussed above.) A logical structure 1551 WITHIN an individual policyCondition may also be introduced, but this 1552 would have to be done in a subclass of policyCondition. 1554 +---------------------------------------------------------------+ 1555 | Policy Conditions in DNF | 1556 | +-------------------------+ +-----------------------+ | 1557 | | AND list | | AND list | | 1558 | | +-------------------+ | | +-----------------+ | | 1559 | | | policyCondition | | | | policyCondition | | | 1560 | | +-------------------+ | | +-----------------+ | | 1561 | | +-------------------+ | | +-----------------+ | | 1562 | | | policyCondition | | ... | | policyCondition | | | 1563 | | +-------------------+ | ORed | +-----------------+ | | 1564 | | ... | | ... | | 1565 | | ANDed | | ANDed | | 1566 | | +-------------------+ | | +-----------------+ | | 1567 | | | policyCondition | | | | policyCondition | | | 1568 | | +-------------------+ | | +-----------------+ | | 1569 | +-------------------------+ +-----------------------+ | 1570 +---------------------------------------------------------------+ 1572 Figure 4. Overview of Policy Conditions in DNF 1574 This figure illustrates that when policy conditions are in DNF, there 1575 are one or more sets of conditions that are ANDed together to form 1576 AND lists. An AND list evaluates to TRUE if and only if all of its 1577 constituent conditions evaluate to TRUE. The overall condition then 1578 evaluates to TRUE if and only if at least one of its constituent AND 1579 lists evaluates to TRUE. 1581 +---------------------------------------------------------------+ 1582 | Policy Conditions in CNF | 1583 | +-------------------------+ +-----------------------+ | 1584 | | OR list | | OR list | | 1585 | | +-------------------+ | | +-----------------+ | | 1586 | | | policyCondition | | | | policyCondition | | | 1587 | | +-------------------+ | | +-----------------+ | | 1588 | | +-------------------+ | | +-----------------+ | | 1589 | | | policyCondition | | ... | | policyCondition | | | 1590 | | +-------------------+ | ANDed | +-----------------+ | | 1591 | | ... | | ... | | 1592 | | ORed | | ORed | | 1593 | | +-------------------+ | | +-----------------+ | | 1594 | | | policyCondition | | | | policyCondition | | | 1595 | | +-------------------+ | | +-----------------+ | | 1596 | +-------------------------+ +-----------------------+ | 1597 +---------------------------------------------------------------+ 1599 Figure 5. Overview of Policy Conditions in CNF 1601 In this figure, the policy conditions are in CNF. Consequently, 1602 there are one or more OR lists, each of which evaluates to TRUE if 1603 and only if at least one of its constituent conditions evaluates to 1604 TRUE. The overall condition then evaluates to TRUE if and only if 1605 ALL of its constituent OR lists evaluate to TRUE. The class 1606 definition is as follows: 1608 NAME policyCondition 1609 DESCRIPTION A class representing a condition to be evaluated 1610 in conjunction with a policy rule. 1611 DERIVED FROM top 1612 TYPE structural 1613 AUXILIARY CLASSES none 1614 POSSIBLE SUPERIORS policyRule 1615 OID 1616 MUST cn policyConditionName 1617 MAY 1619 5.7.1. The Attribute cn 1621 This is the exact same definition as in Section 5.2.1. It is included 1622 in this class for the reasons enumerated there. 1624 5.7.2. The Attribute policyConditionName 1626 This attribute provides a user-friendly name for a policy condition. 1627 The attribute definition is as follows: 1629 NAME policyConditionName 1630 DESCRIPTION The user-friendly name of this policy condition. 1631 SYNTAX IA5String 1632 OID 1633 EQUALITY caseExactIA5Match 1634 SINGLE-VALUED 1636 5.8. The Class vendorPolicyCondition 1638 The purpose of this class is to provide a general escape mechanism 1639 for representing policy conditions that have not been modeled with 1640 specific attributes. Instead, the two attributes 1641 vendorPolicyConstraintData and vendorPolicyConstraintEncoding are 1642 used to define the content and format of the condition, as explained 1643 below. 1645 As its name suggests, this class is intended for vendor-specific 1646 extensions to the Core Policy Schema. Standardized extensions are 1647 not expected to use this class. 1649 The class definition is as follows: 1651 NAME vendorPolicyCondition 1652 DESCRIPTION A class that defines a registered means to 1653 describe a policy condition. 1654 DERIVED FROM policyCondition 1655 TYPE structural 1656 AUXILIARY CLASSES none 1657 POSSIBLE SUPERIORS policyRule 1658 OID 1659 MUST vendorPolicyConstraintData 1660 vendorPolicyConstraintEncoding 1661 MAY 1663 5.8.1. The Attribute vendorPolicyConstraintData 1665 This attribute provides a general escape mechanism for representing 1666 policy conditions that have not been modeled with specific 1667 attributes. The format of the OctetString is left unspecified in 1668 this definition. It is determined by the OID value stored in the 1669 attribute vendorPolicyConstraintEncoding. Since 1670 vendorPolicyConstraintEncoding is single-valued, all the values of 1671 vendorPolicyConstraintData share the same format and semantics. 1673 A policy decision point can readily determine whether it supports the 1674 values stored in an instance of vendorPolicyConstraintData by 1675 checking the OID value from vendorPolicyConstraintEncoding against 1676 the set of OIDs it recognizes. The action for the policy decision 1677 point to take in case it does not recognize the format of this data 1678 could itself be modeled as a policy rule, governing the behavior of 1679 the policy decision point. 1681 The attribute definition is as follows: 1683 NAME vendorPolicyConstraintData 1684 DESCRIPTION Escape mechanism for representing constraints that 1685 have not been modeled as specific attributes. The 1686 format of the values is identified by the OID 1687 stored in the attribute 1688 vendorPolicyConstraintEncoding. 1689 SYNTAX OctetString 1690 OID 1691 EQUALITY octetStringMatch 1692 MULTI-VALUED 1694 5.8.2. The Attribute vendorPolicyConstraintEncoding 1696 This attribute identifies the encoding and semantics of the values of 1697 vendorPolicyConstraintData in this instance. The value of this 1698 attribute is a single OID. 1700 The attribute definition is as follows: 1702 NAME vendorPolicyConstraintEncoding 1703 DESCRIPTION An OID identifying the format and semantics for 1704 this instance's vendorPolicyConstraintData 1705 attribute. 1706 SYNTAX OID 1707 OID 1708 EQUALITY objectIdentifierMatch 1709 SINGLE-VALUED 1711 5.9. The Class policyAction 1713 The purpose of a policy action is to execute one or more operations 1714 that will affect network traffic and/or systems, devices, etc. in 1715 order to achieve a desired policy state. This (new) policy state 1716 provides one or more (new) behaviors. A policy action ordinarily 1717 changes the configuration of one or more elements. 1719 A policyRule contains one or more policy actions. Unlike a condition, 1720 however, only one list of policy actions is contained in a 1721 policyRule. A policy administrator can assign an order to the actions 1722 associated with a policyRule, complete with an indication of whether 1723 the indicated order is mandatory, recommended, or of no significance. 1725 The actions associated with a policyRule are executed if and only if 1726 the overall condition(s) of the policyRule evaluates to TRUE. 1728 The class definition is as follows: 1730 NAME policyAction 1731 DESCRIPTION A class representing an action to be performed as 1732 a result of a policy rule. 1734 DERIVED FROM top 1735 TYPE structural 1736 AUXILIARY CLASSES none 1737 POSSIBLE SUPERIORS policyRule 1738 OID 1739 MUST cn policyActionName 1740 MAY 1742 5.9.1. The Attribute cn 1744 This is the exact same definition as in Section 5.2.1. It is included 1745 in this class for the reasons enumerated there. 1747 5.9.2. The Attribute policyActionName 1749 This attribute provides a user-friendly name for a policy action. 1751 The attribute definition is as follows: 1753 NAME policyActionName 1754 DESCRIPTION The user-friendly name of this policy action. 1755 SYNTAX IA5String 1756 OID 1757 EQUALITY caseExactIA5Match 1758 SINGLE-VALUED 1760 5.10. The Class vendorPolicyAction 1762 The purpose of this class is to provide a general escape mechanism 1763 for representing policy actions that have not been modeled with 1764 specific attributes. Instead, the two attributes 1765 vendorPolicyActionData and vendorPolicyActionEncoding are used to 1766 define the content and format of the condition, as explained below. 1768 As its name suggests, this class is intended for vendor-specific 1769 extensions to the Core Policy Schema. Standardized extensions are 1770 not expected to use this class. 1772 The class definition is as follows: 1774 NAME vendorPolicyAction 1775 DESCRIPTION A class that defines a registered means to 1776 describe a policy action. 1777 DERIVED FROM policyAction 1778 TYPE structural 1779 AUXILIARY CLASSES none 1780 POSSIBLE SUPERIORS policyRule 1781 OID 1782 MUST vendorPolicyActionData vendorPolicyActionEncoding 1783 MAY 1785 5.10.1. The Attribute vendorPolicyActionData 1787 This attribute provides a general escape mechanism for representing 1788 policy actions that have not been modeled with specific attributes. 1789 The format of the OctetString is left unspecified in this definition. 1790 It is determined by the OID value stored in the attribute 1791 vendorPolicyActionEncoding. Since vendorPolicyActionEncoding is 1792 single-valued, all the values of vendorPolicyActionData share the 1793 same format and semantics. 1795 A policy decision point can readily determine whether it supports the 1796 values stored in an instance of vendorPolicyActionData, by checking 1797 the OID value from vendorPolicyActionEncoding against the set of OIDs 1798 it recognizes. The action for the policy decision point to take in 1799 case it does not recognize the format of this data could itself be 1800 modeled as a policy rule, governing the behavior of the policy 1801 decision point. 1803 The attribute definition is as follows: 1805 NAME vendorPolicyActionData 1806 DESCRIPTION Escape mechanism for representing actions that 1807 have not been modeled as specific attributes. The 1808 format of the values is identified by the OID 1809 stored in the attribute 1810 vendorPolicyActionEncoding. 1811 SYNTAX OctetString 1812 OID 1813 EQUALITY octetStringMatch 1814 MULTI-VALUED 1816 5.10.2. The Attribute vendorPolicyActionEncoding 1818 This attribute identifies the encoding and semantics of the values of 1819 vendorPolicyActionData in this instance. The value of this attribute 1820 is a single OID. 1822 The attribute definition is as follows: 1824 NAME vendorPolicyActionEncoding 1825 DESCRIPTION An OID identifying the format and semantics for 1826 this instance's vendorPolicyActionData attribute. 1827 SYNTAX OID 1828 OID 1829 EQUALITY objectIdentifierMatch 1830 SINGLE-VALUED 1832 6. Locating Policy Objects in the Directory 1834 <> 1836 7. Extending the Core Schema 1838 There are three fundamental ways to extend the core schema. These are 1839 detailed in sections 7.1 through 7.3 below. A guideline for using 1840 the policyTimePeriodCondition class is discussed in Section 7.4. 1841 Each of these methods may be used separately or in conjunction with 1842 other methods. 1844 7.1. Subclassing policyCondition and policyAction 1846 The simplest way of extending the core schema is to use policyGroup, 1847 policyRule, and policyTimePeriodCondition as they are, and simply 1848 subclass policyCondition and policyAction. An instance of policyRule 1849 ties everything together, with its very simple, invariant semantics: 1851 If the policyRule is active, then evaluate the conditions pointed 1852 to by policyRuleConditionList, in the manner specified by 1853 policyRuleConditionListType. If the result of this evaluation is 1854 TRUE, then perform, possibly in a specified order, all the 1855 actions pointed to by policyRuleActionList. 1857 With this approach a new schema specifies the conditions it needs in 1858 subclasses of policyCondition (or, better still, reuses conditions 1859 that have already been specified in subclasses of policyCondition), 1860 and it specifies (or reuses) the actions it needs in subclasses of 1861 policyAction. 1863 policyRules are used to aggregate policy conditions and actions, and 1864 policyGroups are used to aggregate policyRules. The 1865 policyGroupContainmentAuxClass, policyRuleContainmentAuxClass, and 1866 policyTimePeriodCondition classes can still be used as previously 1867 described. Note that the subclassing of policyCondition and 1868 policyAction can also be used in combination with the other methods 1869 (discussed below) to extend the schema. 1871 7.2. Subclassing policyRule 1873 There are two possible ways to subclass policyRule, as described 1874 below. 1876 7.2.1. Refining the semantics of policyRule 1878 This approach refines the structural and possibly behavioral 1879 semantics of what it means to be a policy rule. For example, 1880 additional attributes and relationships could be defined in a 1881 subclass of policyRule. These attributes and relationships could 1882 provide extra meaning for how to interpret the set of conditions and 1883 actions that a policyRule aggregates. 1885 This method can be used in a stand-alone fashion by keeping the 1886 semantics of policyCondition and policyAction as specified and adding 1887 semantics to policyRule. These policyRule semantics can explicitly 1888 specify policyConditions and/or policyActions, or dictate how 1889 policyConditions and policyActions are used and interpreted. 1890 Finally, these methods can be used with the other methods discussed 1891 in this subsection to extend the schema. 1893 7.2.2. Optimizing the computation of a policyRule 1895 All preceding mechanisms for extending the core schema will work in 1896 all cases, but they come at a price: in order to fully understand a 1897 policy rule, a client must retrieve at least three objects: a policy 1898 rule, at least one policy condition, and at least one policy action. 1899 A future version of this specification may define how to optimize the 1900 evaluation of a policy rule so as to reduce the number of classes 1901 that must be instantiated to define a policy. 1903 7.3. Using the Vendor Policy Encoding Attributes 1905 As discussed in 5.8, "The Class vendorPolicyCondition", the 1906 attributes vendorPolicyConstraintData and 1907 vendorPolicyConstraintEncoding are included in the 1908 vendorPolicyCondition to provide an escape mechanism for representing 1909 "exceptional" policy conditions. The attributes 1910 vendorPolicyActionData and vendorPolicyActionEncoding of the 1911 vendorPolicyAction class play the same role with respect to actions. 1912 This enables interoperability between different vendors. 1914 For example, imagine a network composed of access devices from vendor 1915 A, edge and core devices from vendor B, and a policy server from 1916 vendor C. It is desirable for the policy server to be able to 1917 configure and manage all of the devices from vendors A and B. 1918 Unfortunately, these devices will in general have little in common 1919 (e.g., different mechanisms, different ways for controlling those 1920 mechanisms, different operating systems, different commands, and so 1921 forth). The escape conditions provide a way for vendor-specific 1922 commands to be encoded as OctetStrings so that devices from different 1923 vendors can be commonly managed by a single policy server. 1925 7.4. Using Time Validity Periods 1927 Time validity periods are defined as a subclass of policyCondition, 1928 called policyTimePeriodCondition. This is to allow their inclusion 1929 in the AND/OR condition definitions for a policyRule. Care should be 1930 taken not to subclass policyTimePeriodCondition to add domain- 1931 specific condition properties. For example, it would be incorrect to 1932 add IPSec- or QoS-specific condition properties to the 1933 policyTimePeriodCondition class, just because IPSec or QoS includes 1934 time in its condition definition. The correct subclassing would be to 1935 create IPSec or QoS-specific subclasses of policyCondition and then 1936 combine instances of these domain-specific condition classes with the 1937 validity period criteria. This is accomplished using the AND/OR 1938 aggregation capabilities for policyConditions in policyRules. 1940 8. Security Considerations 1942 Security and denial of service considerations are not explicitly 1943 considered in this memo, as they are appropriate for the underlying 1944 policy architecture. However, the policy architecture must be secure 1945 as far as the following aspects are concerned. First, the mechanisms 1946 proposed under the framework must minimize theft and denial of 1947 service threats. Second, it must be ensured that the entities (such 1948 as PEPs and PDPs) involved in policy control can verify each other's 1949 identity and establish necessary trust before communicating. The 1950 schema defined in this document MUST not compromise either of these 1951 goals. 1953 9. Intellectual Property 1955 The IETF takes no position regarding the validity or scope of any 1956 intellectual property or other rights that might be claimed to 1957 pertain to the implementation or use of the technology described in 1958 this document or the extent to which any license under such rights 1959 might or might not be available; neither does it represent that it 1960 has made any effort to identify any such rights. Information on the 1961 IETF's procedures with respect to rights in standards-track and 1962 standards-related documentation can be found in BCP-11. 1964 Copies of claims of rights made available for publication and any 1965 assurances of licenses to be made available, or the result of an 1966 attempt made to obtain a general license or permission for the use of 1967 such proprietary rights by implementers or users of this 1968 specification can be obtained from the IETF Secretariat. 1970 The IETF invites any interested party to bring to its attention any 1971 copyrights, patents or patent applications, or other proprietary 1972 rights which may cover technology that may be required to practice 1973 this standard. Please address the information to the IETF Executive 1974 Director. 1976 10. Acknowledgments 1978 This document is closely aligned with the work being done in the 1979 Desktop Management Task Force (DMTF) Service Level Agreements and 1980 Networks working groups. As noted, the core schema described here 1981 was initially defined in references [2] and [3]. We would especially 1982 like to thank Bob Moore, Raju Rajan, Sanjay Kamat, Andrea Westerinen, 1983 Lee Rafalow, Raj Yavatkar, Glenn Waters, David Black, Michael 1984 Richardson, Mark Stevens, and David Jones for their helpful comments. 1986 11. References 1988 [1] J. Strassner and E. Ellesson, "Terminology for describing network 1989 policy and services", draft-strassner-policy-terms-00.txt, August 1990 1998. 1992 [2] Bhattacharya, P., and R. Adams, W. Dixon, R. Pereira, R. Rajan, 1993 "An LDAP Schema for Configuration and Administration of IPSec 1994 based Virtual Private Networks (VPNs)", Internet-Draft work in 1995 progress, October 1998 1997 [3] Rajan, R., and J. C. Martin, S. Kamat, M. See, R. Chaudhury, D. 1998 Verma, G. Powers, R. Yavatkar, "Schema for Differentiated Services 1999 and Integrated Services in Networks", Internet-Draft work in 2000 progress, October 1998 2002 [4] J. Strassner and S. Judd, "Directory-Enabled Networks", version 2003 3.0c5 (August 1998). 2005 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2006 Levels", BCP 14, RFC 2119, March 1997. 2008 [6] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 2009 Standards Process", BCP 11, RFC 2028, October 1996. 2011 [7] Wahl, M., and S. Kille, T. Howes, "Lightweight Directory Access 2012 Protocol (v3): UTF-8 String Representation of Distinguished 2013 Names", RFC 2253, December 1997. 2015 [8] J. Strassner, policy architecture BOF presentation, 42nd IETF 2016 Meeting, Chicago, Illinois, October, 1998 2018 [9] DMTF web site, http://www.dmtf.org. 2020 12. Authors' Addresses 2022 John Strassner 2023 Cisco Systems, Bldg 1 2024 170 West Tasman Drive 2025 San Jose, CA 95134 2026 Phone: +1 408-527-1069 2027 Fax: +1 408-527-1722 2028 E-mail: johns@cisco.com 2030 Ed Ellesson 2031 IBM Corporation, JDGA/501 2032 4205 S. Miami Blvd. 2033 Research Triangle Park, NC 27709 2034 Phone: +1 919-254-4115 2035 Fax: +1 919-254-6243 2036 E-mail: ellesson@raleigh.ibm.com 2038 Bob Moore 2039 IBM Corporation, BRQA/502 2040 4205 S. Miami Blvd. 2041 Research Triangle Park, NC 27709 2042 Phone: +1 919-254-4436 2043 Fax: +1 919-254-6243 2044 E-mail: remoore@us.ibm.com 2046 13. Full Copyright Statement 2048 Copyright (C) The Internet Society (1999). All Rights Reserved. 2050 This document and translations of it may be copied and furnished to 2051 others, and derivative works that comment on or otherwise explain it 2052 or assist in its implementation may be prepared, copied, published 2053 and distributed, in whole or in part, without restriction of any 2054 kind, provided that the above copyright notice and this paragraph are 2055 included on all such copies and derivative works. However, this 2056 document itself may not be modified in any way, such as by removing 2057 the copyright notice or references to the Internet Society or other 2058 Internet organizations, except as needed for the purpose of 2059 developing Internet standards in which case the procedures for 2060 copyrights defined in the Internet Standards process must be 2061 followed, or as required to translate it into languages other than 2062 English. 2064 The limited permissions granted above are perpetual and will not be 2065 revoked by the Internet Society or its successors or assigns. 2067 This document and the information contained herein is provided on an 2068 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2069 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2070 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2071 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2072 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2074 14. Appendix A - Guidelines for Construction of DNs 2076 To Be Provided