idnits 2.17.1 draft-ietf-policy-core-schema-01.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 document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 9173 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 1887, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1890, 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' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Strassner 3 Internet-draft Cisco Systems 4 Category: Standards Track E. Ellesson 5 IBM 6 February 1999 8 Policy Framework Core Information Model 9 draft-ietf-policy-core-schema-01.txt 10 February 11, 1999 21:40 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 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 31 Rim). 33 Copyright Notice 35 Copyright (C) The Internet Society (1999). All Rights Reserved. 37 Abstract 39 This document defines an object-oriented information model for 40 representing policy information. This model defines structural 41 information of objects that comprise and control policy (the 42 "schema", or class inheritance hierarchy) as well as information that 43 describes how different objects are related to other objects (the 44 relationship hierarchy). In general, both of these class hierarchies 45 will need to be mapped to a particular data store. 47 This draft targets a directory that uses LDAP as its access protocol. 48 As such, the class inheritance hierarchy can be directly mapped, but 49 the relationship hierarchy will in general need to be mapped to a 50 form suitable for directory implementation. This is because it 51 contains concepts that are usually not directly translatable to the 52 underlying data store. This document defines a schema and one such 53 mapping of relationships for implementation in directories using 54 LDAPv3 as their access protocol. 56 The information model described in this document consists of five 57 very general classes: policyGroup, policyRule, policyCondition, 58 policyValidityPeriodCondition, and policyAction. While structural 59 information is represented very well in LDAP schemas, relationships 60 between objects are not. This document also defines how to map more 61 abstract concepts, such as relationships, into LDAP schemas. One 62 mechanism to do this mapping is to use auxiliary classes. This 63 document defines one such class, the policyRuleContainmentAuxClass. 65 While these classes are general, they are not abstract: they can all 66 be directly instantiated. Policy solutions for specific areas, such 67 as DiffServ and IPSec, may use the policyGroup, policyRule, 68 policyValidityPeriodCondition, and policyRuleContainmentAuxClass 69 classes directly, while creating their own subclasses derived from 70 policyCondition and policyAction in order to represent their own 71 application-specific needs. 73 Table of Contents 75 1. Introduction....................................................4 77 2. Modeling Policies...............................................5 78 2.1. Policy Scope..................................................8 80 3. Overview of the Schema..........................................8 81 3.1. Relationships.................................................9 82 3.2. Associations.................................................10 83 3.3. Aggregations.................................................10 84 3.4. Key Relationships of the Policy Framework Core Information Model 85 ...................................................................10 87 4. Inheritance Hierarchy for the LDAP Schema......................11 89 5. Class Definitions for the LDAP Schema..........................12 90 5.1. Naming Attributes in the Core Schema.........................12 91 5.2. The Class policyGroup........................................12 92 5.2.1. The attribute cn...........................................14 93 5.2.2. The Attribute policyGroupName..............................14 94 5.2.3. The Attribute containedPolicyGroups........................14 95 5.2.4. The Attribute policyGroupType..............................15 96 5.3. The Class policyRuleContainmentAuxClass......................15 97 5.3.1. The Attribute policyRulesAuxContainedSet...................16 98 5.4. The Class policyRule.........................................16 99 5.4.1. The Attribute cn...........................................18 100 5.4.2. The Attribute policyRuleName...............................18 101 5.4.3. The Attribute policyRuleEnabled............................18 102 5.4.4. The Attribute policyRuleConditionListType..................18 103 5.4.5. The Attribute policyRuleConditionList......................19 104 5.4.6. The Attribute policyRuleActionList.........................20 105 5.4.7. The Attribute policyRuleKeywords...........................21 106 5.4.8. The Attribute policyRuleType...............................21 107 5.4.9. The Attribute policyRuleUsage..............................22 108 5.4.10. The Attribute policyRulePriority..........................22 109 5.4.11. The Attribute policyRuleMandatory.........................23 110 5.4.12. The Attribute policyRuleDebugMode.........................23 111 5.4.13. The Attribute policyRuleSequencedActions..................24 112 5.5. The Class policyValidityPeriodCondition......................24 113 5.5.1. The Attribute pvpConditionTime.............................25 114 5.5.2. The Attribute pvpConditionMonthOfYearMask..................26 115 5.5.3. The Attribute pvpConditionDayOfMonthMask...................26 116 5.5.4. The Attribute pvpConditionDayOfWeekMask....................27 117 5.5.5. The Attribute pvpConditionTimeOfDayMask....................28 118 5.5.6. The Attribute pvpConditionTimeZone.........................29 119 5.6. The Class policyCondition....................................29 120 5.6.1. The Attribute cn...........................................31 121 5.6.2. The Attribute policyConditionName..........................31 122 5.7. The Class vendorPolicyCondition..............................31 123 5.7.1. The Attribute vendorPolicyConditionConstraint..............32 124 5.7.2. The Attribute vendorPolicyConditionEncoding................32 125 5.8. The Class policyAction.......................................33 126 5.8.1. The Attribute cn...........................................33 127 5.8.2. The Attribute policyActionName.............................33 128 5.9. The Class vendorPolicyAction.................................34 129 5.9.1. The Attribute vendorPolicyActionData.......................34 130 5.9.2. The Attribute vendorPolicyActionEncoding...................35 132 6. Extending the Core Schema......................................35 133 6.1. Subclassing policyCondition and policyAction.................35 134 6.2. Subclassing policyRule.......................................36 135 6.2.1. Refining the semantics of policyRule.......................36 136 6.2.2. Optimizing the computation of a policyRule.................36 137 6.3. Using the Vendor Policy Encoding Attributes..................36 138 6.4. Using Time Validity Periods..................................37 140 7. Security Considerations........................................37 142 8. Intellectual Property..........................................37 144 9. Acknowledgments................................................38 146 10. References....................................................38 148 11. Authors' Addresses............................................39 150 12. Full Copyright Statement......................................39 152 13. Appendix A - Guidelines for Construction of DNs...............39 154 1. Introduction 156 This document defines an information model, containing a schema 157 (represented as a class inheritance hierarchy) and a relationship 158 model. The schema contains five core classes for representing 159 policies: policyGroup, policyRule, policyCondtion, policyAction, and 160 policyValidityPeriodCondition. 162 This schema can be mapped to many different data store 163 implementations. This document concentrates on a mapping of the data 164 store to a directory that uses LDAP as its access protocol. However, 165 the relationship class hierarchy needs to be mapped to a specific 166 data store implementation. This document defines a mapping for the 167 relationships of this information model to a directory that uses 168 LDAPv3 as its access protocol. A sixth core class, 169 policyRuleContainmentAuxClass, is used as part of this mapping. The 170 use of an information model enables the schema and the relationship 171 class hierarchy to be extensible, such that other types of policy 172 repositories, such as relational databases, can use this information. 174 These six classes and their relationships are sufficiently generic to 175 allow them to represent policies related to anything. However, their 176 initial application will be for representing policies related to QoS 177 (DiffServ and IntServ) and to IPSec. Policy models for application- 178 specific areas such as these may extend the core schema in several 179 ways. The preferred way is to use the policyGroup, policyRule, 180 policyValidityPeriodCondition, and policyRuleContainmentAuxClass 181 classes directly, as a foundation for representing and communicating 182 policy information. Then, specific subclasses derived from 183 policyCondition and policyAction can capture application-specific 184 definitions of conditions and actions of policies. These subclasses 185 will then fit naturally within the policy framework of the above four 186 classes. This will be explored more thoroughly in Section 6.0, 187 "Extending the Core Schema". 189 Two subclasses, vendorPolicyCondition and vendorPolicyAction are also 190 included in this document, to provide a standard escape mechanism for 191 vendor-specific extensions to the core policy schema. 193 This document fits into the overall framework for representing, 194 deploying, and managing policies being developed by the Policy 195 Framework Working Group. The initial work to define this framework 196 is in reference [1]. More specifically, this document builds on the 197 core policy classes first introduced in references [2] and [3]. It 198 also draws on the work done for the Directory-enabled Networks (DEN) 199 specification, reference [4]. Work on the DEN specification by the 200 DEN Ad-Hoc Working Group itself has been completed. Further work to 201 standardize the models contained in it will be the responsibility of 202 selected working groups of the CIM (Common Information Model) effort 203 in the Desktop Management Task Force (DMTF). Standardization of the 204 core policy model is the responsibility of the SLA Policy working 205 group. 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119, reference 210 [5]. 212 2. Modeling Policies 214 The classes comprising the Policy Framework Core Information Model 215 Class Hierarchy are intended to serve as an extensible class 216 hierarchy (through specialization) for defining policy objects that 217 enable application developers, network administrators, and policy 218 administrators to represent policies of different types. 220 The simplest way to think of a policy-controlled network is to first 221 model the network as a state machine and then use policy to control 222 which state a policy-controlled device should be in or is allowed to 223 be in at any given time. Given this approach, policy is applied using 224 a set of policy rules. Each policy rule consists of a set of 225 conditions and a set of actions. Policy rules may be aggregated into 226 policy groups. These groups may be nested, to represent a hierarchy 227 of policies. 229 The set of conditions associated with a policy rule specifies when 230 the policy rule is applicable. The set of conditions can be expressed 231 as either an ORed set of ANDed sets of condition statements or an 232 ANDed set of ORed sets of statements. These combinations are termed, 233 respectively, Disjunctive Normal Form (DNF) and Conjunctive Normal 234 Form (CNF) for the conditions. Please note that it is explicitly NOT 235 a goal of this specification to represent more complicated conditions 236 (such as those that may be found in a procedural language) at this 237 time. 239 If the set of conditions associated with a policy rule evaluates to 240 TRUE, then a set of actions that either maintain the current state of 241 the object or transition the object to a new state may be executed. 242 For the set of actions associated with a policy rule, it is possible 243 to specify an order of execution, as well as an indication of whether 244 the order is required or merely recommended. It is also possible to 245 indicate that the order in which the actions are executed does not 246 matter. 248 Actions can be prioritized so as to avoid conflicts. However, this 249 release of the core schema draft does not specify conditional 250 handling of the actions to be executed, nor does it specify the 251 handling of generalized error conditions. This is because if this 252 feature is implemented, then policies immediately become much more 253 complex. It is considered better to gain implementation experience 254 with simpler policies and use this experience to then build more 255 complex policies. 257 Policy rules themselves can be prioritized. One common reason for 258 doing this is to express an overall policy that has a general case 259 with a few specific exceptions. 261 For example, a general QoS policy rule might specify that traffic 262 originating from members of the engineering group is to get Bronze 263 Service. A second policy rule might express an exception: traffic 264 originating from John, a specific member of the engineering group, is 265 to get Gold Service. Since traffic originating from John satisfies 266 the conditions of both policy rules, and the actions associated with 267 the two rules are incompatible, a priority needs to be established. 268 By giving the second rule (the exception) a higher priority than the 269 first rule (the general case), a policy administrator can get the 270 desired effect: traffic originating from John gets Gold Service, and 271 traffic originating from all the other members of the engineering 272 group gets Bronze Service. 274 Policies can either be used in a stand-alone fashion or aggregated 275 into policy groups to perform more elaborate functions. Stand-alone 276 policies are called policy rules. Policy groups are aggregations of 277 policy rules, or aggregations of policy groups, but not both. Policy 278 groups can model intricate interactions between objects that have 279 complex interdependencies. Examples of this include a sophisticated 280 user logon policy that sets up application access, security, and 281 reconfigures network connections based on a combination of user 282 identity, network location, logon method and time of day. A policy 283 group represents a unit of reusability and manageability in that its 284 management is handled by an identifiable group of administrators and 285 its policyRules apply equally to the scope of the policyGroup. 287 Stand-alone policies are those that can be expressed in a simple 288 statement. They can be represented effectively in schemas or MIBs. 289 Examples of this are VLAN assignments, simple YES/NO QoS requests, 290 and IP address allocations. A specific design goal of this schema is 291 to support both stand-alone and aggregated policies. 293 Policy groups and rules can be classified by their purpose and 294 intent. This classification is useful in querying or grouping policy 295 rules. It indicates whether the policy is used to motivate when or 296 how an action occurs, or to characterize services (that can then be 297 used, for example, to bind clients to network services). Describing 298 each of these concepts in more detail, 300 o Motivational Policies are solely targeted at whether or how a 301 policy's goal is accomplished. Configuration and Usage Policies 302 are specific kinds of Motivational Policies. Another example is 303 the scheduling of file backup based on disk write activity from 304 8am to 3pm, M-F. 306 o Configuration Policies define the default (or generic) setup of a 307 managed entity (for example, a network service). Examples of 308 Configuration Policies are the setup of a network forwarding 309 service or a network-hosted print queue. 311 o Installation Policies define what can and can't be put on a system 312 or component, as well as the configuration of the mechanisms that 313 perform the install. Installation policies typically represent 314 specific administrative permissions, and can also represent 315 dependencies between different components (e.g., to complete the 316 installation of component A, components B and C must be previously 317 successfully installed or uninstalled). 319 o Error and Event Policies. For example, if a device fails between 320 8am and 9pm, call the system administrator, else call the Help 321 Desk. 323 o Usage Policies control the selection and configuration of entities 324 based on specific "usage" data. Configuration Policies can be 325 modified or simply re-applied by Usage Policies. Examples of 326 Usage Policies include upgrading network forwarding services after 327 a user is verified to be a member of a "gold" service group, or 328 reconfiguring a printer to be able to handle the next job in its 329 queue. 331 o Security Policies deal with verifying that the client is actually 332 who the client purports to be, permitting or denying access to 333 resources, selecting and applying appropriate authentication 334 mechanisms, and performing accounting and auditing of resources. 336 o Service Policies characterize network and other services (not use 337 them). For example, all wide-area backbone interfaces shall use a 338 specific type of queuing. 340 Service policies describe services available in the network. Usage 341 policies describe the particular binding of a client of the 342 network to services available in the network. 344 2.1. Policy Scope 346 Policies represent business goals and objectives. A translation must 347 be made between these goals and objectives and their realization in 348 the network. An example of this could be a Service Level Agreement 349 (SLA), and its objectives and metrics (Service Level Objectives, or 350 SLOs), that are used to specify services that the network will 351 provide for a given client [8]. The SLA will usually be written in 352 high-level business terminology. SLOs address more specific metrics 353 in support of the SLA. These high-level descriptions of network 354 services and metrics must be translated into lower-level, but also 355 vendor- and device-independent specifications. The core policy schema 356 classes are intended to be used as part of the definition of this 357 specification. 359 This translation is domain-independent. That is, it applies equally 360 to Quality of Service (QoS) as defined in the Differentiated Services 361 working group of the IETF) as it does to signaled QoS, as specified 362 in the Integrated Services working group of the IETF. 364 Furthermore, it is envisioned that the definition of policy in this 365 draft is generic in nature and is suitable for non-QoS networking 366 applications (e.g., DHCP and IPSEC) as well as non-networking 367 applications (e.g., backup policies, auditing access, etc.). 369 3. Overview of the Schema 371 The following diagram provides an overview of the five classes that 372 comprise the CIM core schema, and their relationships to each other. 373 Note that the two extension classes vendorPolicyCondition and 374 vendorPolicyAction are not shown. 376 ************** 377 * * 378 0..n * * ContainedPolicyGroups 379 +------v------+ * 380 | policyGroup <****** 381 | | 0..n 382 +------^------+ 383 0..n * 384 * ContainedPolicyRules 385 0..n * 386 +-----v-------+ 387 | | 388 | policyRule | 389 | | ContainedPolicyConditions (ORed set of 390 ANDed 391 | <************************* conditions, or 392 | | 0..n * vice-versa) 393 | | * 0..n 394 | | +---------v------------+ 395 | | | policyCondition | 396 | | +----------------------+ 397 | | ^ 398 | | I 399 | | I 400 | | ^ 401 | | +------------------------------ + 402 | | | policyValidityPeriodCondition | 403 | | +------------------------------ + 404 | | 405 | | ContainedPolicyActions 406 | <************************* 407 | | 0..n * 408 | | * 0..n 409 | | +---------v------------+ 410 | | | policyAction | 411 +-------------+ +----------------------+ 413 Figure 1. An Overview of the CIM Policy Classes and Their 414 Relationships 416 3.1. Relationships 418 Relationships are a central feature of information models. A 419 relationship represents a physical or conceptual connection between 420 objects. CIM and DEN define the general concept of an association 421 between two (or more) objects. Two types of associations are 422 aggregations (which express whole-part relationships) and other 423 relationships, such as those that express dependency. Both are used 424 in this model. 426 3.2. Associations 428 An association is a class that contains two or more references, where 429 each reference identifies another object. An association is defined 430 using a class. Associations can be defined between classes without 431 affecting any of the related classes. That is, addition of an 432 association does not affect the interface of the related classes. 434 3.3. Aggregations 436 An aggregation is a strong form of an association. An aggregation is 437 usually used to represent a "whole-part" relationship. This type of 438 relationship defines the containment relationship between a system 439 and the components that make up the system. Aggregation often 440 implies, but does not require, that the aggregated objects have 441 mutual dependencies. 443 3.4. Key Relationships of the Policy Framework Core Information Model 445 The following relationships are shown in the preceding figure: 447 o The ContainedPolicyGroups relationship enables policyGroups to be 448 nested. This is critical for scalability and manageability, as it 449 enables complex policies to be constructed from multiple simpler 450 policies for administrative convenience. For example, a 451 policyGroup representing policies for the US might have nested 452 within it policy groups for the Eastern and Western US. 454 For LDAP schemata, the ContainedPolicyGroups relation is mapped to 455 the containedPolicyGroups attribute (note that other data stores 456 may define a different mapping). This attribute enables a 457 policyGroup to identify another policyGroup as its offspring. 459 o A policy group may also aggregate one or more policy rules. 460 Grouping of policy rules into a policy group is again for 461 administrative convenience; a policy rule may also be used by 462 itself, without belonging to a policy group. 464 o A policyRule may also be aggregated by an instance of any class to 465 which the policyRuleContainmentAuxClass class has been attached. 466 Once again, this is for administrative convenience. If the 467 directory entry to which the policyRuleContainmentAuxClass has 468 been attached is a policy group, then the pointer in the 469 policyRuleContainmentAuxClass realizes the relationship discussed 470 above between the group and a policyRule; a separate attribute is 471 not needed in the policyGroup class. 473 o A condition of a policyRule may specify one or more time validity 474 periods. This can be used for several purposes. Two important uses 475 include representing time as an additional condition (e.g., use 476 one policy in the morning and use a different policy in the 477 afternoon) and to enable scheduled activation and deactivation of 478 the policyRule. A policy validity period may be aggregated by 479 multiple policyRules. A rule that does not point to a policy 480 validity period is, from the point of view of scheduling, always 481 active. It may, however, be inactive for other reasons. 483 Time validity periods are a general concept that can be used in 484 other applications. However, they are mentioned explicitly here in 485 this specification since they are frequently used in policy 486 applications. 488 o A policyRule aggregates zero or more instances of the 489 policyCondition class. For all policy rules, at least one 490 condition MUST be specified, either via the 491 containedPolicyConditions aggregation, or defined explicitly 492 within a subclass of policyRule. These conditions are grouped into 493 two levels of lists: either an ORed set of ANDed sets of 494 conditions (DNF, the default) or an ANDed set of ORed sets of 495 conditions (CNF). The attribute policyRuleConditionListType 496 specifies which of these two grouping schemes applies to a 497 particular policyRule. 499 Since conditions may be defined explicitly in a subclass of 500 policyRule, the AND/OR mechanism to combine these conditions with 501 other (associated) policyConditions MUST be specified by the 502 policyRule's subclass. 504 In either case, the conditions are used to determine whether to 505 perform the actions associated with the policyRule. For LDAP 506 schemata, pointers to PolicyCondition objects (or subclasses of 507 this class) are used. 509 o A policyRule may aggregate zero or more policy actions. For all 510 policy rules, at least one action MUST be specified, either via 511 the containedPolicyActions aggregation, or defined explicitly 512 within a subclass of policyRule. The actions associated with a 513 policyRule may be given a required order, a recommended order, or 514 no order at all. For actions represented as separate objects, the 515 containedPolicyActions aggregation can be used to express an 516 order. For actions defined explicitly in a subclass of policyRule, 517 the ordering mechanism must be specified in the subclass 518 definition. 520 4. Inheritance Hierarchy for the LDAP Schema 522 The following diagram illustrates the class hierarchy for the LDAP 523 policy schema classes: 525 top 526 | 527 +---policyGroup 528 | 529 +---policyRuleContainmentAuxClass 530 | 531 +---policyRule 532 | 533 +---policyCondition 534 | | 535 | +---policyValidityPeriodCondition 536 | | 537 | +---vendorPolicyCondition 538 | 539 +---policyAction 540 | 541 +---vendorPolicyAction 543 5. Class Definitions for the LDAP Schema 545 The classes described below contain certain optimizations for a 546 directory that uses LDAP as its access protocol. One example of this 547 is the use of an auxiliary class to represent CIM relationships. 548 Other data stores might need to implement these relationships 549 differently. 551 5.1. Naming Attributes in the Core Schema 553 Instances in a directory are identified by distinguished names (DNs), 554 which provide the same type of hierarchical organization that a file 555 system provides in a computer system. A distinguished name is a 556 sequence of relative distinguished names (RDNs), where an RDN 557 provides a unique identifier for an instance within the context of 558 its immediate superior in the same way that a filename provides a 559 unique identifier for a file within the context of the folder in 560 which it resides. 562 To preserve maximum naming flexibility for policy administrators, 563 each of the classes defined in this schema has its own naming 564 attribute. Since the naming attributes are different, the policy 565 administrator is guaranteed that there will be no name collisions 566 between instances of different classes, even if the same VALUE is 567 assigned to the instances' respective naming attributes. To fit in 568 with existing directory practice, each of the classes uses the 569 commonName (cn) attribute as its naming attribute. 571 5.2. The Class policyGroup 573 This class is a generalized aggregation container. It enables either 574 policyRules or policyGroups, but not both, to be aggregated in a 575 single container. Loops, including the degenerate case of a 576 policyGroup that contains itself, are not allowed when policyGroups 577 contain other policyGroups. 579 PolicyGroups and their nesting capabilities are shown in Figure 2 580 below. Note that a policyGroup can nest other policyGroups, and there 581 is no restriction on the depth of the nesting in sibling 582 policyGroups. 584 +---------------------------------------------------+ 585 | policyGroup | 586 | | 587 | +--------------------+ +-----------------+ | 588 | | policyGroup A | | policyGroup X | | 589 | | | | | | 590 | | +----------------+ | ooo | | | 591 | | | policyGroup A1 | | | | | 592 | | +----------------+ | | | | 593 | +--------------------+ +-----------------+ | 594 +---------------------------------------------------+ 596 Figure 2. Overview of the policyGroup class 598 As a simple example, think of the highest level policyGroup shown in 599 Figure 2 above as a logon policy for US employees of a company. This 600 policyGroup may be called USEmployeeLogonPolicy, and may aggregate 601 several policyGroups that provide specialized rules per location. 602 Hence, policyGroupA in Figure 2 above may define logon rules for 603 employees on the West Coast, while another policyGroup might define 604 logon rules for the Midwest (e.g., policyGroupX), and so forth. 606 Note also that the depth of each policyGroup does not need to be the 607 same. Thus, the WestCoast policyGroup might have several additional 608 layers of policyGroups defined for any of several reasons (different 609 locales, number of subnets, etc.). The policyRules are therefore 610 contained at n levels from the USEmployeeLogonPolicyGroup. Compare 611 this to the Midwest policyGroup (policyGroupX), which might directly 612 contain policyRules. 614 The class definition for policyGroup is as follows. Note that this 615 class definition does not include an attribute to realize the 616 ContainedPolicyRules association from the object model, since a 617 policyGroup object points to instances of policyRule via the pointer 618 in policyRuleContainmentAuxClass. 620 NAME policyGroup 621 DESCRIPTION A container for either a set of related 622 policyRules or a set of related policyGroups 623 DERIVED FROM top 624 TYPE structural 625 AUXILIARY CLASSES policyRuleContainmentAuxClass 626 POSSIBLE SUPERIORS container, organization, organizationalUnit, 627 policyGroup 629 OID 630 MUST cn, policyGroupName 631 MAY containedPolicyGroups, policyGroupType 633 5.2.1. The attribute cn 635 The cn, or commonName, attribute is an X.500 attribute. It stands for 636 commonName. It specifies a user-friendly name by which the object is 637 commonly known. This name may be ambiguous by itself. This name is 638 used in a limited scope (such as an organization). It conforms to the 639 naming conventions of the country or culture with which it is 640 associated. CN is used universally in DEN as the naming attribute for 641 a class. 643 NAME cn 644 DESCRIPTION Naming attribute of this class 645 SYNTAX DirectoryString 646 OID 2.4.5.3 647 EQUALITY caseExactMatch 648 SINGLE-VALUED 650 5.2.2. The Attribute policyGroupName 652 This attribute provides a user-friendly name for a policy group, and 653 is normally what will be displayed to the end-user as the name of 654 this class. It is defined as follows: 656 NAME policyGroupName 657 DESCRIPTION The user-friendly name of this policy group. 658 SYNTAX IA5String 659 OID 660 EQUALITY caseExactIA5Match 661 SINGLE-VALUED 663 5.2.3. The Attribute containedPolicyGroups 665 This attribute provides an unordered set of DN pointers to zero or 666 more other policyGroup objects, representing nested policyGroups 667 contained by this policyGroup. The attribute definition is as 668 follows: 670 NAME containedPolicyGroups 671 DESCRIPTION Distinguished names of other policyGroup objects 672 aggregated by this policy group. There is no 673 order implied among the members of the set. 674 SYNTAX DN 675 OID 676 EQUALITY distinguishedNameMatch 677 MULTI-VALUED 679 5.2.4. The Attribute policyGroupType 681 This attribute is used to specify the type of policy that this 682 policyGroup represents. This can be used for classification (for 683 example, service policy or usage policy) or categorization (the type 684 of service or usage policy that this policy is). The attribute 685 definition is as follows: 687 NAME policyGroupType 688 DESCRIPTION Defines a policyGroup classification and 689 categorization. When multiple classifications are 690 possible, the one that "best" describes the 691 policyGroup's type should be used. 692 SYNTAX INTEGER 693 OID 694 EQUALITY integerMatch 695 SINGLE-VALUED 696 DEFAULT VALUE 0 698 The defined values for this attribute are: Unknown (0), Configuration 699 (1), Usage (2), Security (3), Service (4), Motivational (5), 700 Installation (6), and Event (7). These concepts were defined in 701 Section 2.0. 703 5.3. The Class policyRuleContainmentAuxClass 705 This auxiliary class provides a single, multi-valued attribute that 706 points to a set of policyRules. By attaching this attribute to 707 instances of various other classes, a policy administrator has a 708 flexible way of providing an entry point into the directory that 709 allows a client to locate and retrieve the policyRules relevant to 710 it. 712 A policy administrator might have several different pointers to a 713 policyRule in the overall directory structure. For example, there 714 might be pointers to all policyRules for traffic originating in a 715 particular subnet from a directory entry that represents that subnet. 716 At the same time, there might be pointers to all policyRules related 717 to a particular DiffServ setting from an instance of a policyGroup 718 explicitly introduced as a container for DiffServ-related 719 policyRules. The policyRuleContainmentAuxClass is the mechanism that 720 makes it possible for the policy administrator to define all these 721 pointers. 723 Note that the cn attribute does NOT need to be defined for this 724 class. This is because an auxiliary class is used as a means to 725 collect common attributes and treat them as properties of an object. 726 A good analogy is a #include file, except that since an auxiliary 727 class is a class, all the benefits of a class (e.g., inheritance) can 728 be applied to an auxiliary class. 730 The class definition is as follows: 732 NAME policyRuleContainmentAuxClass 733 DESCRIPTION An auxiliary class used to bind policyRules to an 734 appropriate container object. 735 DERIVED FROM top 736 TYPE auxiliary 737 AUXILIARY CLASSES none 738 POSSIBLE SUPERIORS container, organization, organizationalUnit, 739 policyGroup 740 OID 741 MUST policyRulesAuxContainedSet 743 5.3.1. The Attribute policyRulesAuxContainedSet 745 This attribute provides an unordered set of DN pointers to one or 746 more policyRules associated with the instance of a structural class 747 to which this attribute has been appended. The attribute definition 748 is: 750 NAME policyRulesAuxContainedSet 751 DESCRIPTION Distinguished names of policyRules associated in 752 some way with the instance to which this attribute 753 has been appended. No order is implied. 754 SYNTAX DN 755 OID 756 EQUALITY distinguishedNameMatch 757 MULTI-VALUED 759 5.4. The Class policyRule 761 This class represents the "If Condition then Action" semantics 762 associated with a policy. A policyRule condition, in the most 763 general sense, is represented as either an ORed set of ANDed 764 conditions (Disjunctive Normal Form, or DNF) or an ANDed set of ORed 765 conditions (Conjunctive Normal Form, or CNF). The actions specified 766 by a policyRule are to be performed if and only if the policyRule 767 condition (whether it is represented in DNF or CNF) evaluates to 768 TRUE. Both the conditions and the actions are identified by DN 769 pointers and/or by specific attributes introduced in subclasses of 770 policyRule. 772 This is illustrated conceptually in Figure 3 below. 774 +------------------------------------------------+ 775 | PolicyRule | 776 | | 777 | +--------------------+ +-----------------+ | 778 | | PolicyCondition(s)| | PolicyAction(s) | | 779 | +--------------------+ +-----------------+ | 780 | | 781 +------------------------------------------------+ 783 Figure 3. Overview of the PolicyRule Class 784 The policyRule class uses the attribute policyRuleConditionListType, 785 to indicate whether the conditions for the rule are in DNF or CNF. 786 The DN pointers from a policyRule to its associated policyConditions 787 also contain an integer to partition the referenced conditions into 788 one or more sets. An example shows how the attribute and the 789 grouping integer provide a unique representation of a set of 790 conditions in either DNF or CNF. 792 Suppose we have pointers to five policyConditions from an instance of 793 policyRule, grouped as follows: 795 (C1: groupNumber = 1, 796 C2: groupNumber = 1, 797 C3: groupNumber = 1, 798 C4: groupNumber = 2, 799 C5: groupNumber = 2) 801 If policyRuleConditionListType = DNF, then the overall condition = for 802 the policyRule is: 804 (C1 AND C2 AND C3) OR (C4 AND C5) 806 On the other hand, if policyRuleConditionListType = CNF, then the 807 overall condition for the policyRule is: 809 (C1 OR C2 OR C3) AND (C4 OR C5) 811 In both cases there is an unambiguous specification of the overall 812 condition that is tested to determine whether to perform the actions 813 associated with the policyRule. 815 This class also contains several attributes designed to help 816 directory clients locate the policy rules applicable to them. The 817 class definition is as follows: 819 NAME policyRule 820 DESCRIPTION The central class for representing the "If 821 Condition then Action" semantics associated with a 822 policy rule. 823 DERIVED FROM top 824 TYPE structural 825 AUXILIARY CLASSES none 826 POSSIBLE SUPERIORS policyGroup 827 OID 828 MUST cn policyRuleName 829 MAY policyRuleEnabled policyRuleConditionListType 830 policyRuleConditionList policyRuleActionList 831 policyRuleKeywords policyRuleType policyRuleUsage 832 policyRulePriority policyRuleMandatory 833 policyRuleDebugMode policyRuleSequencedActions 835 5.4.1. The Attribute cn 837 This is the exact same definition as in Section 5.2.1. It is included 838 in this class for the reasons enumerated there. 840 5.4.2. The Attribute policyRuleName 842 This attribute provides a user-friendly name for a policy rule. The 843 attribute definition is as follows: 845 NAME policyRuleName 846 DESCRIPTION The user-friendly name of this policy rule. 847 SYNTAX IA5String 848 OID 849 EQUALITY caseExactIA5Match 850 SINGLE-VALUED 852 5.4.3. The Attribute policyRuleEnabled 854 This flag indicates whether a policy rule is currently enabled, from 855 an ADMINISTRATIVE point of view. Its purpose is to allow a policy 856 administrator to enable or disable a policy rule without having to 857 add it to, or remove it from, the directory. The attribute definition 858 is as follows: 860 NAME policyRuleEnabled 861 DESCRIPTION A flag indicating whether this policy rule is 862 enabled from an administrative point of view. 863 SYNTAX Boolean 864 OID 865 EQUALITY booleanMatch 866 SINGLE-VALUED 867 DEFAULT VALUE TRUE 869 5.4.4. The Attribute policyRuleConditionListType 871 This attribute is used to specify whether the list of policy 872 conditions associated with this policy rule is in disjunctive normal 873 form (DNF) or conjunctive normal form (CNF). If this attribute is 874 not present, the list type defaults to DNF. The attribute definition 875 is as follows: 877 NAME policyRuleConditionListType 878 DESCRIPTION Indicates whether the list of policy conditions 879 associated with this policy rule is in disjunctive 880 normal form (DNF) or conjunctive normal form 881 (CNF). Defined values are 'DNF (1)' and 'CNF 882 (2)'. 883 SYNTAX INTEGER 884 OID 885 EQUALITY integerMatch 886 SINGLE-VALUED 887 DEFAULT VALUE 1 (DNF) 889 5.4.5. The Attribute policyRuleConditionList 891 This attribute provides an unordered list of DN pointers that 892 identify a set of policy conditions associated with this policy rule. 893 There is an integer associated with each pointer, to provide the 894 grouping of the conditions into first-level groups for the DNF or CNF 895 representation of the overall policyRule condition. To accommodate 896 this grouping, the syntax of this attribute is a string of the form 897 'groupNumber:DN'. 899 Existing matching rules are built to operate on a single data type. 900 This attribute is conceptually comprised of two data types, an 901 Integer (groupNumber) and DistinguishedName (DN). There are three 902 ways to address this. 904 1. Collapse the two attribute types into a single structured IA5 905 string with the format 'groupNumber:DN'. This approach has the 906 advantage of not requiring any new support in the directory server 907 implementations, since these servers already support an IA5 string 908 matching rule. Its disadvantage is that an IA5 string match works 909 somewhat differently from a DN match with respect to subtleties 910 such as preserving versus ignoring versus removing repeated 911 whitespace characters. Thus DNs that would match with the 912 distinguishedNameMatch matching rule might fail to be found as 913 substrings of 'groupNumber:DN' strings by the IA% matching rules, 914 or vice versa. 916 2. Define a new syntax ':', with its own matching rules. 917 With this approach the matching problems introduced by the IA5 918 string could be avoided, since the new type would have its own 919 matching rules. The disadvantage of defining a new type in this 920 way is that a directory server must add new code that recognizes 921 the type and implements its matching rules. A directory server 922 would thus be unable to support the Core Policy Schema until it had 923 added this new code. 925 3. Use two objects in the directory to represent the two data types, 926 and relate the objects with the Families of Entries model currently 927 being discussed in the LDAP Extensions working group. This 928 approach has the same problem as the previous one: without the 929 addition of new code to support Families of Entries, a directory 930 server would be unable to support the Core Policy Schema at all. 931 There is also the additional complication here, that the Families 932 of Entries model itself may take some time to reach approved status 933 in the LDAP Extensions (LDAPEXT) working group. 935 For now, this document will move forward with the 'groupNumber:DN' 936 structured IA5 string approach for containedPolicyConditions, as well 937 as with an analogous 'n:DN' approach for containedPolicyActions. To 938 minimize problems arising from differences in matching rules, this 939 document will provide a series of guidelines for constructing DNs 940 that behave identically with respect to the IA5 matching rules and 941 the distinguishedNameMatch. These guidelines are in Appendix A. 943 The attribute definition is as follows: 945 NAME policyRuleConditionList 946 DESCRIPTION An unordered list of strings of the form 947 'groupNumber:DN', indicating a set of policy 948 conditions that determine when the policyRule is 949 applicable. 950 SYNTAX OctetString 951 OID 952 EQUALITY TBD 953 MULTI-VALUED 954 FORMAT groupNumber:DN 956 5.4.6. The Attribute policyRuleActionList 958 This attribute provides an unordered list of strings of the form 959 'n:DN' that identify a set of policy actions associated with this 960 policy rule. (See section 5.4.5 for a discussion of the issues 961 surrounding the use of a syntax of this type.) When 'n' is a 962 positive integer, it indicates a place in the sequence of actions to 963 be performed, with smaller integers indicating earlier positions in 964 the sequence. The special value '0' indicates "don't care," with one 965 exception: all actions with positive sequence numbers are to be 966 performed before any actions with sequence number '0'. Finally, if 967 two or more actions have the same non-zero sequence number, they may 968 be performed in any order, but they must all be performed at the 969 appropriate place in the overall action sequence. 971 A series of examples will make ordering of actions clearer: 973 o If all actions have the same sequence number, regardless of 974 whether it is '0' or non-zero, any order is acceptable. 976 o The values 978 1:DN-A 979 2:DN-B 980 1:DN-C 981 3:DN-D 983 indicate two acceptable orders: A,C,B,D or C,A,B.D, since A and C 984 can be performed in either order, but only at the '1' position. 986 o The values 988 0:DN-A 989 2:DN-B 990 0:DN-C 991 3:DN-D 993 indicate either B,D,A,C or B,D,C,A, since the '0' actions A and C 994 must be performed after the non-zero ones. Note that the non-zero 995 sequence numbers need not start with '1', and they need not be 996 consecutive. All that matters is their relative magnitude. 998 This attribute indicates the actions of a policyRule and their order 999 (or absence of order). However, another attribute, 1000 policyRuleSequencedActions, indicates whether the indicated order is 1001 required, recommended, or not to be used at all. 1003 All actions specified in the policyRuleActionList will be executed as 1004 long as the overall policy condition as defined by the 1005 policyRuleConditionListType and policyRuleConditionList attributes 1006 evaluates to TRUE. 1008 The attribute definition is as follows: 1010 NAME policyRuleActionList 1011 DESCRIPTION An unordered list of strings of the form 'n:DN', 1012 indicating an ordered set of policy actions to be 1013 performed if the associated condition(s) of the 1014 policyRule evaluates to true. 1015 SYNTAX Octet String 1016 OID 1017 EQUALITY TBD 1018 MULTI-VALUED 1019 FORMAT n:DN 1021 5.4.7. The Attribute policyRuleKeywords 1023 This attribute provides a set of one or more ad hoc keywords that a 1024 policy administrator may define to assist directory clients in 1025 locating the policy rules applicable to them. Values for this 1026 attribute are installation dependent, and thus are not specified in 1027 any schema document. The attribute definition is as follows: 1029 NAME policyRuleKeywords 1030 DESCRIPTION A set of ad hoc keywords to assist directory 1031 clients in locating the policy rules applicable to 1032 them. 1033 SYNTAX IA5String 1034 OID 1035 EQUALITY caseExactIA5Match 1036 MULTI-VALUED 1038 5.4.8. The Attribute policyRuleType 1040 This attribute is used to specify the type of policy that this policy 1041 rule represents. This can be used for classification (for example, 1042 service policy or usage policy) or categorization (the type of 1043 service or usage policy that this policy is). The attribute 1044 definition is as follows: 1046 NAME policyRuleType 1047 DESCRIPTION Defines a policy classification and 1048 categorization. When multiple classifications are 1049 possible, the one that "best" describes the 1050 policy's type should be used. 1051 SYNTAX INTEGER 1052 OID 1053 EQUALITY integerMatch 1054 SINGLE-VALUED 1055 DEFAULT VALUE 0 1057 The defined values for this attribute are: Unknown (0), Configuration 1058 (1), Usage (2), Security (3), Service (4), Motivational (5), 1059 Installation (6), and Event (7). These concepts were defined in 1060 Section 2.0. 1062 5.4.9. The Attribute policyRuleUsage 1064 This attribute is a free-form string that recommends how this policy 1065 should be used. The attribute definition is as follows: 1067 NAME policyRuleUsage 1068 DESCRIPTION This attribute is used to provide guidelines on 1069 how this policy should be used. 1070 SYNTAX DirectoryString 1071 OID 1072 EQUALITY caseIgnoreMatch 1073 SINGLE-VALUED 1075 5.4.10. The Attribute policyRulePriority 1077 This attribute provides a positive integer for prioritizing policy 1078 rules relative to each other. For policy rules that have this 1079 attribute, smaller integer values indicate higher priority. Since 1080 one purpose of this attribute is to allow specific, ad hoc policy 1081 rules to temporarily override established policy rules, an instance 1082 that has this attribute set has a higher priority than all instances 1083 that lack it. 1085 Prioritization among policy rules provides a simple and efficient 1086 mechanism for resolving policy conflicts. 1088 The attribute definition is as follows: 1090 NAME policyRulePriority 1091 DESCRIPTION A positive integer for prioritizing this 1092 policyRule relative to other policyRules. A 1093 smaller value indicates a higher priority. 1094 SYNTAX INTEGER 1095 OID 1096 EQUALITY integerMatch 1097 SINGLE-VALUED 1098 DEFAULT VALUE 0 1100 5.4.11. The Attribute policyRuleMandatory 1102 This attribute indicates whether evaluation (and possibly action 1103 execution) of a policyRule is mandatory or not. Its concept is 1104 similar to the ability to mark packets for delivery or possible 1105 discard, based on network traffic and device load. 1107 The evaulation of a policyRule MUST be attempted if the 1108 policyRuleMandatory attribute value is True. If the 1109 policyRuleMandatory attribute value of a policyRule is False, then 1110 the evaluation of the rule is "best effort" and MAY be ignored. 1112 The attribute definition is as follows: 1114 NAME policyRuleMandatory 1115 DESCRIPTION A flag indicating that the evaluation of the 1116 policyConditions and execution of policyActions 1117 (if the condition list evaluates to True) is 1118 required. 1119 SYNTAX Boolean 1120 OID 1121 EQUALITY booleanMatch 1122 SINGLE-VALUED 1123 DEFAULT VALUE TRUE 1125 5.4.12. The Attribute policyRuleDebugMode 1127 This attribute indicates that the policyRule should be evaluated, but 1128 no actions taken. It serves as a debug vehicle when attempting to 1129 determine what policies would execute in a particular scenario, but 1130 not to take any actions to change state due to that scenario. 1132 The attribute definition is as follows: 1134 NAME policyRuleDebugMode 1135 DESCRIPTION A flag indicating that the evaluation of the 1136 policyRule's policyConditions should occur, but 1137 the set of actions specified for the rule should 1138 not be executed. 1139 SYNTAX Boolean 1140 OID 1141 EQUALITY booleanMatch 1142 SINGLE-VALUED 1143 DEFAULT VALUE FALSE 1145 5.4.13. The Attribute policyRuleSequencedActions 1147 This attrribute gives a policy administrator a way of specifying how 1148 the ordering of the policy actions associated with this policyRule is 1149 to be interpreted. Three values are supported: 1151 o mandatory (1): Do the actions in the indicated order, or don't 1152 do them at all. 1154 o recommended (2): Do the actions in the indicated order if you can, 1155 but if you can't do them in this order, do them in another order 1156 if you can. 1158 o dontCare (3): Do them -- I don't care about the order. 1160 When error / event reporting is addressed for the Policy Framework, 1161 suitable codes will be defined for reporting that a set of actions 1162 could not be performed in an order specified as mandatory (and thus 1163 were not performed at all), that a set of actions could not be 1164 performed in a recommended order (and moreover could not be performed 1165 in any order), or that a set of actions could not be performed in a 1166 recommended order (but were performed in a different order). The 1167 attribute definition is as follows: 1169 NAME policyRuleSequencedActions 1170 DESCRIPTION An enumeration indicating how to interpret the 1171 action ordering indicated via the 1172 policyRuleActionList attribute. 1173 SYNTAX INTEGER 1174 OID 1175 EQUALITY integerMatch 1176 SINGLE-VALUED 1177 DEFAULT VALUE 3 1179 The defined values for this attribute are mandatory(1), 1180 recommended(2), and dontCare(3). 1182 5.5. The Class policyValidityPeriodCondition 1184 This class provides a means of representing the time periods during 1185 which a policy rule is valid, i.e., active. At all times that fall 1186 outside these time periods, the policy rule has no effect. A policy 1187 rule is treated as valid at all times if it does not specify a 1188 policyValidityPeriodCondition. 1190 PolicyValidityPeriodCondition is defined as a subclass of 1191 policyCondition. This is to allow the inclusion of time-based 1192 criteria in the AND/OR condition definitions for a policyRule. 1194 Instances of this class may have up to five attributes identifying 1195 time periods at different levels. The values of all the attributes 1196 present in an instance are ANDed together to determine the validity 1197 period(s) for the instance. For example, an instance with an overall 1198 validity range of January 1, 1999 through December 31, 1999; a month 1199 mask of "001100000000" (March and April); a day-of-the-week mask of 1200 "0000100" (Fridays); and a time of day range of 8 AM through 4 PM 1201 would represent the following validity periods: 1203 Friday, March 5, 1999, from 8 AM through 4 PM; 1204 Friday, March 12, 1999, from 8 AM through 4 PM; 1205 Friday, March 19, 1999, from 8 AM through 4 PM; 1206 Friday, March 26, 1999, from 8 AM through 4 PM; 1207 Friday, April 2, 1999, from 8 AM through 4 PM; 1208 Friday, April 9, 1999, from 8 AM through 4 PM; 1209 Friday, April 16, 1999, from 8 AM through 4 PM; 1210 Friday, April 23, 1999, from 8 AM through 4 PM; 1211 Friday, April 30, 1999, from 8 AM through 4 PM. 1213 Attributes not present in an instance of 1214 policyValidityPeriodCondition are implicitly treated as having their 1215 value "always enabled". Thus, in the example above, the day-of-the- 1216 month mask is not present, and so the validity period for the 1217 instance implicitly includes a day-of-the-month mask containing 31 1218 1's. If we apply this "missing attribute" rule to its fullest, we 1219 see that there is a second way to indicate that a policy rule is 1220 always enabled: have it point to an instance of 1221 policyValidityPeriodCondition whose only attributes are its naming 1222 attributes. 1224 The class definition is as follows. Note that instances of this 1225 class are named with the attributes cn and policyConditionName that 1226 they inherit from policyCondition. 1228 NAME policyValidityPeriodCondition 1229 DESCRIPTION A class that provides the capability of enabling / 1230 disabling a policy rule according to a pre- 1231 determined schedule. 1232 DERIVED FROM policyCondition 1233 TYPE structural 1234 AUXILIARY CLASSES none 1235 POSSIBLE SUPERIORS policyRule 1236 OID 1237 MUST 1238 MAY pvpConditionTime pvpConditionMonthOfYearMask 1239 pvpConditionDayOfMonthMask 1240 pvpConditionDayOfWeekMask 1241 pvpConditionTimeOfDayMask pvpConditionTimeZone 1243 5.5.1. The Attribute pvpConditionTime 1245 This attribute identifies an overall range of calendar dates and 1246 times over which a policy rule is valid. It is formatted as a string 1247 consisting of a start date and time, then a colon (':'), and followed 1248 by an end date and time. The first date indicates the beginning of 1249 the range, while the second date indicates the end. Thus the second 1250 date and time must be later than the first. Dates are expressed as 1251 substrings of the form "yyyymmddhhmmss". For example: 1253 19990101080000:19990131120000 1255 January 1, 1999, 8 AM through January 31, 1999, noon 1257 The attribute definition is as follows: 1259 NAME pvpConditionTime 1260 DESCRIPTION The range of calendar dates on which a policy rule 1261 is valid. 1262 SYNTAX PrintableString 1263 OID 1264 EQUALITY caseIgnoreMatch 1265 SINGLE-VALUED 1266 FORMAT yyyymmddhhmmss:yyyymmddhhmmss 1268 5.5.2. The Attribute pvpConditionMonthOfYearMask 1270 The purpose of this attribute is to refine the definition of the 1271 valid time period that is defined by the pvpConditionTime attribute 1272 by explicitly specifying which months the policy is valid for. These 1273 attributes work together, with the pvpConditionTime used to specify 1274 the overall time period that the policy is valid for, and the 1275 pvpConditionMonthOfYearMask used to pick out which months of that 1276 time period the policy is valid for. 1278 This attribute is formatted as a string containing 12 ASCII '0's and 1279 '1's, where the '1's identify the months (beginning with January) in 1280 which the policy rule is valid. The value "000010010000", for 1281 example, indicates that a policy rule is valid only in the months May 1282 and August. 1284 If this attribute is omitted, then the policy assumes that it is 1285 valid for all twelve months. The attribute definition is as follows: 1287 NAME pvpConditionMonthOfYearMask 1288 DESCRIPTION A mask identifying the months of the year in which 1289 a policy rule is valid. 1290 SYNTAX Printable String 1291 OID 1292 EQUALITY caseIgnoreMatch 1293 SINGLE-VALUED 1294 FORMAT A string of 12 ASCII '0's and '1's. 1296 5.5.3. The Attribute pvpConditionDayOfMonthMask 1298 The purpose of this attribute is to refine the definition of the 1299 valid time period that is defined by the pvpConditionTime attribute 1300 by explicitly specifying which days of the month the policy is valid 1301 for. These attributes work together, with the pvpConditionTime used 1302 to specify the overall time period that the policy is valid for, and 1303 the pvpConditionDayOfMonthMask used to pick out which days of the 1304 month that time period the policy is valid for. 1306 This attribute is formatted as a string containing 31 ASCII '0's and 1307 '1's, where the '1's identify the days of the month (beginning with 1308 day 1 and going up through day 31) on which the policy rule is valid. 1309 The value "1110000000000000000000000000000", for example, indicates 1310 that a policy rule is valid only on the first three days of each 1311 month. For months with fewer than 31 days, the digits corresponding 1312 to days that the months do not have are ignored. The attribute 1313 definition is as follows: 1315 NAME pvpConditionDayOfMonthMask 1316 DESCRIPTION A mask identifying the days of the month on which 1317 a policy rule is valid. 1318 SYNTAX PrintableString 1319 OID 1320 EQUALITY caseIgnoreMatch 1321 SINGLE-VALUED 1322 FORMAT A string of 31 ASCII '0's and '1's. 1324 5.5.4. The Attribute pvpConditionDayOfWeekMask 1326 The purpose of this attribute is to refine the definition of the 1327 valid time period that is defined by the pvpConditionTime attribute 1328 by explicitly specifying which days of the week the policy is valid 1329 for. These attributes work together, with the pvpConditionTime used 1330 to specify the overall time period that the policy is valid for, and 1331 the pvpConditionDayOfWeekMask used to pick out which days of the week 1332 of that time period the policy is valid for. 1334 This attribute is formatted as a string containing 7 ASCII '0's and 1335 '1's, where the '1's identify the days of the week (beginning with 1336 Monday and going up through Sunday) on which the policy rule is 1337 valid. The value "1111100", for example, indicates that a policy rule 1338 is valid Monday through Friday. 1340 The attribute definition is as follows: 1342 NAME pvpConditionDayOfWeekMask 1343 DESCRIPTION A mask identifying the days of the week on which a 1344 policy rule is valid. 1345 SYNTAX PrintableString 1346 OID 1347 EQUALITY caseIgnoreMatch 1348 SINGLE-VALUED 1349 FORMAT A string of 7 ASCII '0's and '1's. 1351 5.5.5. The Attribute pvpConditionTimeOfDayMask 1353 The purpose of this attribute is to refine the definition of the 1354 valid time period that is defined by the pvpConditionTime attribute 1355 by explicitly specifying a range of times in a day the policy is 1356 valid for. These attributes work together, with the pvpConditionTime 1357 used to specify the overall time period that the policy is valid for, 1358 and the pvpConditionTimeOfDayMask used to pick out which range of 1359 time periods in a given day of the week of that time period the 1360 policy is valid for. 1362 This attribute is formatted as a string containing two times, 1363 separated by a colon (':'). The first time indicates the beginning 1364 of the range, while the second time indicates the end. Times are 1365 expressed as substrings of the form "hhmmss". 1367 The second substring always identifies a later time than the first 1368 substring. To allow for ranges that span midnight, however, the 1369 value of the second string may be smaller than the value of the first 1370 substring. Thus "080000:210000" identifies the range from 8 AM until 1371 9 PM, while "210000:080000" identifies the range from 9 PM until 8 AM 1372 of the following day. 1374 When a range spans midnight, it by definition includes parts of two 1375 successive days. When one of these days is also selected by either 1376 the policyValidityMonthMask, policyValidityDayOfMonthMask, and/or 1377 policyValidityDayOfWeekMask, but the other day is not, then the 1378 policy is active only during the portion of the range that falls on 1379 the selected day. For example, if the range extends from 9 PM until 1380 8 AM, and the day of week mask selects Monday and Tuesday, then the 1381 policy is active during the following three intervals: 1383 From midnight Sunday until 8 AM Monday; From 9 PM Monday until 8 1384 AM 1385 Tuesday; From 9 PM Tuesday until 11:59:59 Tuesday. 1387 The attribute definition is as follows: 1389 NAME pvpConditionTimeOfDayMask 1390 DESCRIPTION The range of times at which a policy rule is 1391 valid. If the second time is earlier than the 1392 first, then the interval spans midnight. 1393 SYNTAX Printable String 1394 OID 1395 EQUALITY caseIgnoreMatch 1396 SINGLE-VALUED 1397 FORMAT hhmmss:hhmmss[:] 1399 5.5.6. The Attribute pvpConditionTimeZone 1401 This attribute is used to explicitly define a time zone for use by 1402 the pvpConditionTime and the various Mask attributes. If this 1403 attribute is NULL, then local time is assumed. 1405 This attribute specifies time in UTC, using an offset indicator. The 1406 UTC offset indicator is either a 'Z', indicating UTC, or a substring 1407 of the following form: 1409 '+' or '-' direction from UTC: '+' = east, '-' = west = plus: 1410 hh hours from UTC (00..13) 1411 mm minutes from UTC (00..59) 1413 The attribute definition is as follows: 1415 NAME pvpConditionTimeZone 1416 DESCRIPTION The definition of the time zone for use by the 1417 PolicyValidityCOndition. 1418 SYNTAX PrintableString 1419 OID 1420 EQUALITY caseIgnoreMatch 1421 SINGLE-VALUED 1422 FORMAT either 'Z' (UTC) or {'+' | '-'}'hhmm' 1424 5.6. The Class policyCondition 1426 The purpose of a policy condition is to determine whether or not the 1427 set of actions (contained in the policyRule that the condition 1428 applies to) should be executed or not. For the purposes of the Core 1429 Policy Framework, all that matters about an individual 1430 policyCondition is that it evaluate to TRUE or FALSE. (The 1431 individual policyConditions associated with a policyRule are combined 1432 to form a compound expression in either DNF or CNF, but this is 1433 accomplished via the groupNumber component of the 1434 policyRuleConditionList string and by the policyRuleConditionListType 1435 attribute, both of which are discussed above.) A logical structure 1436 WITHIN an individual policyCondition may also be introduced, but this 1437 would have to be done in a suclass of policyCondition. 1439 +---------------------------------------------------------------+ 1440 | Policy Conditions in DNF | 1441 | +-------------------------+ +-----------------------+ | 1442 | | AND list | | AND list | | 1443 | | +-------------------+ | | +-----------------+ | | 1444 | | | policyCondition | | | | policyCondition | | | 1445 | | +-------------------+ | | +-----------------+ | | 1446 | | +-------------------+ | | +-----------------+ | | 1447 | | | policyCondition | | ... | | policyCondition | | | 1448 | | +-------------------+ | ORed | +-----------------+ | | 1449 | | ... | | ... | | 1450 | | ANDed | | ANDed | | 1451 | | +-------------------+ | | +-----------------+ | | 1452 | | | policyCondition | | | | policyCondition | | | 1453 | | +-------------------+ | | +-----------------+ | | 1454 | +-------------------------+ +-----------------------+ | 1455 +---------------------------------------------------------------+ 1457 Figure 4. Overview of Policy Conditions in DNF 1459 This figure illustrates that when policy conditions are in DNF, there 1460 are one or more sets of conditions that are ANDed together to form 1461 AND lists. An AND list evaluates to TRUE if and only if all of its 1462 constituent conditions evaluate to TRUE. The overall condition then 1463 evaluates to TRUE if and only if at least one of its constituent AND 1464 lists evaluates to TRUE. 1466 +---------------------------------------------------------------+ 1467 | Policy Conditions in CNF | 1468 | +-------------------------+ +-----------------------+ | 1469 | | OR list | | OR list | | 1470 | | +-------------------+ | | +-----------------+ | | 1471 | | | policyCondition | | | | policyCondition | | | 1472 | | +-------------------+ | | +-----------------+ | | 1473 | | +-------------------+ | | +-----------------+ | | 1474 | | | policyCondition | | ... | | policyCondition | | | 1475 | | +-------------------+ | ANDed | +-----------------+ | | 1476 | | ... | | ... | | 1477 | | ORed | | ORed | | 1478 | | +-------------------+ | | +-----------------+ | | 1479 | | | policyCondition | | | | policyCondition | | | 1480 | | +-------------------+ | | +-----------------+ | | 1481 | +-------------------------+ +-----------------------+ | 1482 +---------------------------------------------------------------+ 1484 Figure 5. Overview of Policy Conditions in CNF 1486 In this figure the policy conditions are in CNF. Consequently, there 1487 are one or more OR lists, each of which evaluates to TRUE if and only 1488 if at least one of its constituent conditions evaluates to TRUE. The 1489 overall condition then evaluates to TRUE if and only if ALL of its 1490 constituent OR lists evaluate to TRUE. The class definition is as 1491 follows: 1493 NAME policyCondition 1494 DESCRIPTION A class representing a condition to be evaluated 1495 in conjunction with a policy rule. 1496 DERIVED FROM top 1497 TYPE structural 1498 AUXILIARY CLASSES none 1499 POSSIBLE SUPERIORS policyRule 1500 OID 1501 MUST cn PolicyConditionName 1502 MAY 1504 5.6.1. The Attribute cn 1506 This is the exact same definition as in Section 5.2.1. It is included 1507 in this class for the reasons enumerated there. 1509 5.6.2. The Attribute policyConditionName 1511 This attribute provides a user-friendly name for a policy condition. 1512 The attribute definition is as follows: 1514 NAME policyConditionName 1515 DESCRIPTION The user-friendly name of this policy condition. 1516 SYNTAX IA5String 1517 OID 1518 EQUALITY caseExactIA5Match 1519 SINGLE-VALUED 1521 5.7. The Class vendorPolicyCondition 1523 The purpose of this class is to provide a general escape mechanism 1524 for representing policy conditions that have not been modeled with 1525 specific attributes. Instead, the two attributes policyConstraintData 1526 and policyConstraintEncoding are used to define the content and 1527 format of the condition, as explained below. 1529 As its name suggests, this class is intended for vendor-specific 1530 extensions to the Core Policy Schema. Standardized extensions are 1531 not expected to use this class. 1533 The class definition is as follows: 1535 NAME vendorPolicyCondition 1536 DESCRIPTION A class that defines a registered means to 1537 describe a policy condition. 1538 DERIVED FROM policyCondition 1539 TYPE structural 1540 AUXILIARY CLASSES none 1541 POSSIBLE SUPERIORS policyRule 1542 OID 1543 MUST vendorPolicyConditionConstraint 1544 vendorPolicyConditionEncoding 1545 MAY 1547 5.7.1. The Attribute vendorPolicyConditionConstraint 1549 This attribute provides a general escape mechanism for representing 1550 policy conditions that have not been modeled with specific 1551 attributes. The format of the OctetString is left unspecified in 1552 this definition. It is determined by the OID value stored in the 1553 attribute vendorPolicyConditionEncoding. Since 1554 vendorPolicyConditionEncoding is single-valued, all the values of 1555 vendorPolicyConditionData share the same format and semantics. 1557 A policy decision point can readily determine whether it supports the 1558 values stored in an instance of vendorPolicyConditionData by checking 1559 the OID value from vendorPolicyConditionEncoding against the set of 1560 OIDs it recognizes. The action for the policy decision point to take 1561 in case it does not recognize the format of this data could itself be 1562 modeled as a policy rule, governing the behavior of the policy 1563 decision point. 1565 The attribute definition is as follows: 1567 NAME vendorPolicyConditionConstraint 1568 DESCRIPTION Escape mechanism for representing constraints that 1569 have not been modeled as specific attributes. The 1570 format of the values is identified by the OID 1571 stored in the attribute 1572 vendorPolicyConditionEncoding. 1573 SYNTAX OctetString 1574 OID 1575 EQUALITY octetStringMatch 1576 MULTI-VALUED 1578 5.7.2. The Attribute vendorPolicyConditionEncoding 1580 This attribute identifies the encoding and semantics of the values of 1581 vendorPolicyConditionConstraint in this instance. The value of this 1582 attribute is a single OID. 1584 The attribute definition is as follows: 1586 NAME vendorPolicyConditionEncoding 1587 DESCRIPTION An OID identifying the format and semantics for 1588 this instance's vendorPolicyConditionConstraint 1589 attribute. 1590 SYNTAX OID 1591 OID 1592 EQUALITY objectIdentifierMatch 1593 SINGLE-VALUED 1595 5.8. The Class policyAction 1597 The purpose of a policy action is to execute one or more operations 1598 that will affect network traffic and/or systems, devices, etc. in 1599 order to achieve a desired policy state. This (new) policy state 1600 provides one or more (new) behaviors. A policy action ordinarily 1601 changes the configuration of one or more elements. 1603 A policyRule contains one or more policy actions. Unlike a condition, 1604 however, only one list of policy actions is contained in a 1605 PolicyRule. A policy administrator can assign an order to the actions 1606 associated with a policyRule, complete with an indication of whether 1607 the indicated order is mandatory, recommended, or of no significance. 1609 The actions associated with a PolicyRule are executed if and only if 1610 the overall condition(s) of the PolicyRule evaluates to TRUE. 1612 The class definition is as follows: 1614 NAME policyAction 1615 DESCRIPTION A class representing an action to be performed as 1616 a result of a policy rule. 1617 DERIVED FROM top 1618 TYPE structural 1619 AUXILIARY CLASSES none 1620 POSSIBLE SUPERIORS policyRule 1621 OID 1622 MUST cn PolicyActionName 1623 MAY 1625 5.8.1. The Attribute cn 1627 This is the exact same definition as in Section 5.2.1. It is included 1628 in this class for the reasons enumerated there. 1630 5.8.2. The Attribute policyActionName 1632 This attribute provides a user-friendly name for a policy action. 1634 The attribute definition is as follows: 1636 NAME policyActionName 1637 DESCRIPTION The user-friendly name of this policy action. 1638 SYNTAX IA5String 1639 OID 1640 EQUALITY caseExactIA5Match 1641 SINGLE-VALUED 1643 5.9. The Class vendorPolicyAction 1645 The purpose of this class is to provide a general escape mechanism 1646 for representing policy actions that have not been modeled with 1647 specific attributes. Instead, the two attributes 1648 vendorPolicyActionData and vendorPolicyActionEncoding are used to 1649 define the content and format of the condition, as explained below. 1651 As its name suggests, this class is intended for vendor-specific 1652 extensions to the Core Policy Schema. Standardized extensions are 1653 not expected to use this class. 1655 The class definition is as follows: 1657 NAME vendorPolicyAction 1658 DESCRIPTION A class that defines a registered means to 1659 describe a policy action. 1660 DERIVED FROM policyAction 1661 TYPE structural 1662 AUXILIARY CLASSES none 1663 POSSIBLE SUPERIORS policyRule 1664 OID 1665 MUST vendorPolicyActionData vendorPolicyActionEncoding 1666 MAY 1668 5.9.1. The Attribute vendorPolicyActionData 1670 This attribute provides a general escape mechanism for representing 1671 policy actions that have not been modeled with specific attributes. 1672 The format of the OctetString is left unspecified in this definition. 1673 It is determined by the OID value stored in the attribute 1674 vendorPolicyActionEncoding. Since vendorPolicyActionEncoding is 1675 single-valued, all the values of vendorPolicyActionData share the 1676 same format and semantics. 1678 A policy decision point can readily determine whether it supports the 1679 values stored in an instance of vendorPolicyActionData, by checking 1680 the OID value from vendorPolicyActionEncoding against the set of OIDs 1681 it recognizes. The action for the policy decision point to take in 1682 case it does not recognize the format of this data could itself be 1683 modeled as a policy rule, governing the behavior of the policy 1684 decision point. 1686 The attribute definition is as follows: 1688 NAME vendorPolicyActionData 1689 DESCRIPTION Escape mechanism for representing actions that 1690 have not been modeled as specific attributes. The 1691 FORMAT of the values is identified by the OID stored in 1692 the attribute vendorPolicyActionEncoding. 1693 SYNTAX OctetString 1694 OID 1695 EQUALITY octetStringMatch 1696 MULTI-VALUED 1698 5.9.2. The Attribute vendorPolicyActionEncoding 1700 This attribute identifies the encoding and semantics of the values of 1701 vendorPolicyActionData in this instance. The value of this attribute 1702 is a single OID. 1704 The attribute definition is as follows: 1706 NAME vendorPolicyActionEncoding 1707 DESCRIPTION An OID identifying the format and semantics for 1708 this instance's vendorPolicyActionData attribute. 1709 SYNTAX OID 1710 OID 1711 EQUALITY objectIdentifierMatch 1712 SINGLE-VALUED 1714 6. Extending the Core Schema 1716 There are three fundamental ways to extend the core schema. These are 1717 detailed in sections 6.1 through 6.3 below. A guideline for using the 1718 policyValidityPeriod class is discussed in Section 6.4. Each of 1719 these methods may be used separately or in conjunction with other 1720 methods. 1722 6.1. Subclassing policyCondition and policyAction 1724 The simplest way of extending the core schema is to use the first 1725 four classes as they are, and simply subclass policyCondition and 1726 policyAction. An instance of policyRule ties everything together, 1727 with its very simple, invariant semantics: 1729 If the policyRule is active, then evaluate, possibly in a 1730 specified order, all conditions pointed to by 1731 policyConditionList. If all conditions evaluate to TRUE, then 1732 perform, possibly in a specified order, all actions pointed to by 1733 policyActionList. 1735 With this approach a new schema specifies the conditions it needs in 1736 subclasses of policyCondition (or, better still, reuses conditions 1737 that have already been specified in subclasses of policyCondition), 1738 and it specifies (or reuses) the actions it needs in subclasses of 1739 policyAction. 1741 PolicyRules are used to aggregate policy conditions and actions, and 1742 policyGroups are used to aggregate policyRules. Of course, the 1743 policyRuleContainmentAuxClass and policyValidityPeriodCondition 1744 classes can still be used as previously described. Note that the 1745 subclassing of policyCondition and policyAction can also be used in 1746 combination with the other methods (discussed below) to extend the 1747 schema. 1749 6.2. Subclassing policyRule 1751 There are two possible ways to subclass policyRule, as described 1752 below. 1754 6.2.1. Refining the semantics of policyRule 1756 This approach refines the structural and possibly behavioral 1757 semantics of what it means to be a policy rule. For example, 1758 additional attributes and relationships could be defined in a 1759 subclass of policyRule. These attributes and relationships could 1760 provide extra meaning for how to interpret the set of conditions and 1761 actions that a policyRule aggregates. 1763 This method can be used in a stand-alone fashion by keeping the 1764 semantics of policyCondition and policyAction as specified and adding 1765 semantics to policyRule. These policyRule semantics can explicitly 1766 specify policyConditions and/or policyActions, or dictate how 1767 policyConditions and policyActions are used and interpreted. 1768 Finally, these methods can be used with the other methods discussed 1769 in this subsection to extend the schema. 1771 6.2.2. Optimizing the computation of a policyRule 1773 All preceding mechanisms for extending the core schema will work in 1774 all cases, but they come at a price: in order to fully understand a 1775 policy rule, a client must retrieve at least three objects: a policy 1776 rule, at least one policy condition, and at least one policy action. 1777 A future version of this specification may define how to optimize the 1778 evaluation of a policy rule so as to reduce the number of classes 1779 that must be instantiated to define a policy. 1781 6.3. Using the Vendor Policy Encoding Attributes 1783 As discussed in 5.7, "The Class vendorPolicyCondition", the 1784 attributes vendorPolicyConditionConstraint and 1785 vendorPolicyConditionEncoding are included in the 1786 vendorPolicyCondition to provide an escape mechanism for representing 1787 "exceptional" policy conditions. The attributes 1788 vendorPolicyActionData and vendorPolicyActionEncoding of the 1789 vendorPolicyAction class play the same role with respect to actions. 1790 This enables interoperability between different vendors. 1792 For example, imagine a network comprised of access devices from 1793 vendor A, edge and core devices from vendor B, and a policy server 1794 from vendor C. It is desirable for the policy server to be able to 1795 configure and manage all of the devices from vendors A and B. 1796 Unfortunately, these devices will in general have little in common 1797 (e.g., different mechanisms, different ways for controlling those 1798 mechanisms, different operating systems, different commands, and so 1799 forth). The escape conditions provide a way for vendor-specific 1800 commands to be encoded as OctetStrings so that devices from different 1801 vendors can be commonly managed by a single policy server. 1803 6.4. Using Time Validity Periods 1805 Time validity periods are defined as a subclass of policyCondition, 1806 called policyValidityPeriodCondition. This is to allow their 1807 inclusion in the AND/OR condition definitions for a policyRule. Care 1808 should be taken to not subclass policyValidityPeriodCondition to add 1809 domain-specific condition properties. For example, it would be 1810 incorrect to add IPSec- or QoS-specific condition properties to the 1811 policyValidityPeriodCondition class, just because IPSec or QoS 1812 includes time in its condition definition. The correct subclassing 1813 would be to create IPSec or QoS-specific subclasses of 1814 policyCondition and then combine instances of these domain-specific 1815 condition classes with the validity period criteria. This is 1816 accomplished using the AND/OR aggregation capabilities for 1817 policyConditions in policyRules. 1819 7. Security Considerations 1821 Security and denial of service considerations are not explicitly 1822 considered in this memo, as they are appropriate for the underlying 1823 policy architecture. However, the policy architecture must be secure 1824 as far as the following aspects are concerned. First, the mechanisms 1825 proposed under the framework must minimize theft and denial of 1826 service threats. Second, it must be ensured that the entities (such 1827 as PEPs and PDPs) involved in policy control can verify each other's 1828 identity and establish necessary trust before communicating. The 1829 schema defined in this document MUST not compromise either of these 1830 goals. 1832 8. Intellectual Property 1834 The IETF takes no position regarding the validity or scope of any 1835 intellectual property or other rights that might be claimed to 1836 pertain to the implementation or use of the technology described in 1837 this document or the extent to which any license under such rights 1838 might or might not be available; neither does it represent that it 1839 has made any effort to identify any such rights. Information on the 1840 IETF's procedures with respect to rights in standards-track and 1841 standards-related documentation can be found in BCP-11. 1843 Copies of claims of rights made available for publication and any 1844 assurances of licenses to be made available, or the result of an 1845 attempt made to obtain a general license or permission for the use of 1846 such proprietary rights by implementers or users of this 1847 specification can be obtained from the IETF Secretariat. 1849 The IETF invites any interested party to bring to its attention any 1850 copyrights, patents or patent applications, or other proprietary 1851 rights which may cover technology that may be required to practice 1852 this standard. Please address the information to the IETF Executive 1853 Director. 1855 9. Acknowledgments 1857 This document is closely aligned with the work being done in the 1858 Desktop Management Task Force (DMTF) Service Level Agreements and 1859 Networks working groups. As noted, the core schema described here 1860 was initially defined in references [2] and [3]. We would especially 1861 like to thank Bob Moore, Raju Rajan, Sanjay Kamat, Andrea Westerinen, 1862 Lee Rafalow, Raj Yavatkar, Glenn Waters, David Black, Michael 1863 Richardson, Mark Stevens, and David Jones for their helpful comments. 1865 10. References 1867 [1] J. Strassner and E. Ellesson, "Terminology for describing network 1868 policy and services", draft-strassner-policy-terms-00.txt, August 1869 1998. 1871 [2] Bhattacharya, P., and R. Adams, W. Dixon, R. Pereira, R. Rajan, 1872 "An LDAP Schema for Configuration and Administration of IPSec 1873 based Virtual Private Networks (VPNs)", Internet-Draft work in 1874 progress, October 1998 1876 [3] Rajan, R., and J. C. Martin, S. Kamat, M. See, R. Chaudhury, D. 1877 Verma, G. Powers, R. Yavatkar, "Schema for Differentiated Services 1878 and Integrated Services in Networks", Internet-Draft work in 1879 progress, October 1998 1881 [4] J. Strassner and S. Judd, "Directory-Enabled Networks", version 1882 3.0c5 (August 1998). 1884 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1885 Levels", BCP 14, RFC 2119, March 1997. 1887 [6] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 1888 Standards Process", BCP 11, RFC 2028, October 1996. 1890 [7] Wahl, M., and S. Kille, T. Howes, "Lightweight Directory Access 1891 Protocol (v3): UTF-8 String Representation of Distinguished 1892 Names", RFC 2253, December 1997. 1894 [8] J. Strassner, policy architecture BOF presentation, 42nd IETF 1895 Meeting, Chicago, Illinois, October, 1998 1897 11. Authors' Addresses 1899 John Strassner 1900 Cisco Systems, Bldg 1 1901 170 West Tasman Drive 1902 San Jose, CA 95134 1903 Phone: +1 408-527-1069 1904 Fax: +1 408-527-1722 1905 E-mail: johns@cisco.com 1907 Ed Ellesson 1908 IBM Corporation, JDGA/501 1909 4205 S. Miami Blvd. 1910 Research Triangle Park, NC 27709 1911 Phone: +1 919-254-4115 1912 Fax: +1 919-254-6243 1913 E-mail: ellesson@raleigh.ibm.com 1915 12. Full Copyright Statement 1917 Copyright (C) The Internet Society (1999). All Rights Reserved. 1919 This document and translations of it may be copied and furnished to 1920 others, and derivative works that comment on or otherwise explain it 1921 or assist in its implementation may be prepared, copied, published 1922 and distributed, in whole or in part, without restriction of any 1923 kind, provided that the above copyright notice and this paragraph are 1924 included on all such copies and derivative works. However, this 1925 document itself may not be modified in any way, such as by removing 1926 the copyright notice or references to the Internet Society or other 1927 Internet organizations, except as needed for the purpose of 1928 developing Internet standards in which case the procedures for 1929 copyrights defined in the Internet Standards process must be 1930 followed, or as required to translate it into languages other than 1931 English. 1933 The limited permissions granted above are perpetual and will not be 1934 revoked by the Internet Society or its successors or assigns. 1936 This document and the information contained herein is provided on an 1937 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1938 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1939 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1940 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1941 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1943 13. Appendix A - Guidelines for Construction of DNs 1945 To Be Provided