idnits 2.17.1 draft-ietf-policy-core-schema-00.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 Internet-Drafts being working documents. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 4 characters 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 'SHALL not' in this paragraph: o A policy rule may point to one or more policy actions. The pointer supports an ordering among the actions pointed to, indicating the order in which the actions SHOULD be performed. A subclass of policyRule may "upgrade" this SHOULD to a SHALL, i.e., indicate that if the actions cannot be performed in the specified order, then they SHALL not be performed at all. One of the ordering values for the pointer is 0, indicating that the policy enforcement point may perform the action at any point in the identified sequence of actions. == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1371, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: 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) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force John Strassner 2 INTERNET DRAFT Cisco Systems 3 17 November 1998 Ed Ellesson 4 IBM 5 Policy Framework Core Information Model 6 draft-ietf-policy-core-schema-00.txt 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.ietf.org (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 Copyright Notice 27 Copyright (C) The Internet Society (1998). All Rights Reserved. 29 Abstract 31 This document defines an object-oriented information model for 32 representing policies. This model defines structural information 33 of objects that comprise and control policy (the 'schema', or 34 class inheritance hierarchy) as well as information that describes 35 how different objects are related to other objects (the relationship 36 hierarchy). 38 The information model described in this document consists of five very 39 general classes: policyGroup, policyRule, policyValidityPeriod, 40 policyCondition, and policyAction. While structural information is 41 represented very well in LDAP schemas, relationships between objects 42 are not. This document also defines how to map more abstract concepts, 43 such as relationships, into LDAP schemas. One mechanism to do this 44 mapping is to use auxiliary classes. This document defines one such 45 class, the policyRuleContainmentAuxClass. 47 While these classes are general, they are not abstract: they can all 48 be instantiated. Policy solutions for specific areas, such as 49 DiffServ and IPSec, may use the policyGroup, policyRule, 50 policyValidityPeriod, and policyRuleContainmentAuxClass classes 51 directly, while creating their own subclasses derived from 52 policyCondition and policyAction. 54 This memo does not specify a standard for the Internet community. 56 Table of Contents 58 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.0 Modeling Policies . . . . . . . . . . . . . . . . . . . . . 4 61 2.1 Policy Scope . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.0 Overview of the Schema . . . . . . . . . . . . . . . . . . . 5 64 3.1 Relationships . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2 Associations . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3 Aggregations . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.4 Key Relationships of the Policy Framework Core Information Model 7 69 4.0 Inheritance Hierarchy . . . . . . . . . . . . . . . . . . . 9 71 5.0 Class Definitions . . . . . . . . . . . . . . . . . . . . . 9 72 5.1 Naming Attributes in the Core Schema . . . . . . . . . . . . 9 73 5.2 The Class policyGroup . . . . . . . . . . . . . . . . . . . 9 74 5.2.1 The Attribute cn . . . . . . . . . . . . . . . . . . . . . 10 75 5.2.2 The Attribute policyGroupName . . . . . . . . . . . . . . 10 76 5.2.3 The Attribute policyGroupsContainedSet . . . . . . . . . . 11 77 5.3 The Class policyRuleContainmentAuxClass . . . . . . . . . . 11 78 5.3.1 The Attribute policyRulesContainedSet . . . . . . . . . . . 12 79 5.4 The Class policyRule . . . . . . . . . . . . . . . . . . . . 12 80 5.4.1 The Attribute cn . . . . . . . . . . . . . . . . . . . . . 13 81 5.4.2 The Attribute policyRuleName. . . . . . . . . . . . . . . . 13 82 5.4.3 The Attribute policyEnabled . . . . . . . . . . . . . . . . 13 83 5.4.4 The Attribute policyValidityPeriodRef . . . . . . . . . . . 14 84 5.4.5 The Attribute policyConditionList . . . . . . . . . . . . . 14 85 5.4.6 The Attribute policyActionList. . . . . . . . . . . . . . . 15 86 5.4.7 The Attribute policyRulePriority. . . . . . . . . . . . . . 15 87 5.4.8 The Attribute policyErrorCode . . . . . . . . . . . . . . . 16 88 5.4.9 The Attribute policyErrorDescription . . . . . . . . . . . 16 89 5.4.10 The Attribute policyKeywords . . . . . . . . . . . . . . . 17 90 5.4.11 The Attribute policyModality . . . . . . . . . . . . . . . 17 91 5.4.12 The Attribute policyType . . . . . . . . . . . . . . . . 17 92 5.4.13 The Attribute policyUsage . . . . . . . . . . . . . . . . 18 93 5.5 The Class policyValidityPeriod . . . . . . . . . . . . . . . . 18 94 5.5.1 The Attribute cn . . . . . . . . . . . . . . . . . . . . . . 19 95 5.5.2 PolicyValidityPeriodName . . . . . . . . . . . . . . . . . 19 96 5.5.3 The Attribute policyValidityPeriodTime. . . . . . . . . . . 20 97 5.5.4 The Attribute policyValidityMonthMask . . . . . . . . . . . 20 98 5.5.5 The Attribute policyValidityDayOfMonthMask. . . . . . . . . 21 99 5.5.6 The Attribute policyValidityDayOfWeekMask . . . . . . . . . 21 100 5.5.7 The Attribute policyValidityTimeOfDayRange. . . . . . . . . 22 101 5.6 The Class policyCondition . . . . . . . . . . . . . . . . . . 23 102 5.6.1 The Attribute cn . . . . . . . . . . . . . . . . . . . . . . 23 103 5.6.2 policyConditionName . . . . . . . . . . . . . . . . . . . . 23 104 5.6.3 The Attribute policyConstraintData . . . . . . . . . . . . . 23 105 5.6.4 The Attribute policyConstraintEncoding . . . . . . . . . . . 24 106 5.7 The Class policyAction. . . . . . . . . . . . . . . . . . . . . 24 107 5.7.1 The Attribute cn . . . . . . . . . . . . . . . . . . . . . . 25 108 5.7.2 The Attribute policyActionName . . . . . . . . . . . . . . . 25 109 5.7.3 The Attribute policyActionData . . . . . . . . . . . . . . . 25 110 5.7.4 The Attribute policyActionEncoding . . . . . . . . . . . . . 25 112 6.0 Extending the Core Schema . . . . . . . . . . . . . . . . . . 26 113 6.1 Subclassing policyCondition and policyAction. . . . . . . . . 26 114 6.2 Subclassing policyRule . . . . . . . . . . . . . . . . . . . 26 115 6.2.1 Refining the Semantics of policyRule . . . . . . . . . . . 26 116 6.2.2 Optimizing the computation of a policyRule . . . . . . . . . 26 117 6.3 Using policyConstraintEncoding and policyActionEncoding . . . 27 119 7.0 Security Considerations . . . . . . . . . . . . . . . . . . . 27 120 8.0 Intellectual Property . . . . . . . . . . . . . . . . . . . . 27 122 9.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 124 10.0 References . . . . . . . . . . . . . . . . . . . . . . . . . 28 126 11.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 128 12.0 Full Copyright Statement . . . . . . . . . . . . . . . . . . 29 130 1.0 Introduction 132 This document is a submission to the Policy Framework Working Group. It 133 defines a schema containing six core classes for representing policies: 134 policyGroup, policyRuleContainmentAuxClass, policyRule, 135 policyValidityPeriod, policyCondition, and policyAction. This schema 136 is intended for realization in a directory that uses LDAP as its access 137 protocol; however, it is also intended to be extensible, such that 138 other types of policy repositories, such as relational databases, can 139 use this information. 141 These six classes are sufficiently generic to allow them to represent 142 policies related to anything. Their initial application will be for 143 representing policies related to QoS (DiffServ and IntServ) and to 144 IPSec. Policy models for specific areas such as these may extend the 145 core schema in several ways. The preferred way is as follows: 147 o Use the policyGroup, policyRule, policyValidityPeriod, and 148 policyRuleContainmentAuxClass classes directly, and create their 149 own subclasses derived from policyCondition and policyAction. 151 Discussion of extension techniques follow in 6.0, "Extending the 152 Core Schema" on page 26. 154 This document fits into the overall framework for representing, 155 deploying, and managing policies being developed by the Policy 156 Framework Working Group. The initial work to define this framework is 157 In reference [1]. More specifically, this document builds on the core 158 policy classes first introduced in references [2] and [3]. It also 159 draws on the work done for the Directory-enabled Networks (DEN) 160 specification, reference [4]. Work on the DEN specification itself has 161 been completed. Further work to standardize the models contained in it 162 will be the responsibility of the Desktop Management Task Force (DMTF). 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119, reference [5]. 168 2.0 Modeling Policies 170 The classes comprising the Policy Framework Core Information Model 171 Class Hierarchy are intended to serve as an extensible class hierarchy 172 (through specialization) for defining policy objects that enable 173 application developers, network administrators, and policy 174 administrators to represent policies of different types. 176 The simplest way to think of a policy-controlled network is to first 177 model the network as a state machine and then use policy to control 178 which state a policy-controlled device should be in or is allowed to 179 be in at any given time. Given this approach, policy is applied using 180 a set of policy rules. Each policy rule consists of a set of conditions 181 and a set of actions. Policy rules may be nested. 183 The set of conditions specifies when the policy is applicable. The set 184 of conditions is implemented as a set of condition lists - each of the 185 condition lists is ORed. Each condition list can have a set of 186 conditions that are ANDed. 188 If all of the conditions are satisfied, then a set of actions that 189 either maintain the current state of the object or transition the 190 object to a new state may be executed. Actions can be prioritized, 191 but this release of the draft does not specify conditional handling 192 of the actions to be executed. This would be a relatively simple 193 extension of the grammar; however, if this feature is implemented, 194 then policies immediately become much more complex. 196 Policies can be classified into two categories: simple and complex. 197 Complex policies are policies that are comprised of simpler policies, 198 and consist of a complex set of conditions and actions. Hierarchical 199 policies are another example of complex policies. In general, complex 200 policies model intricate interactions between objects that have complex 201 interdependencies. Examples of this include a sophisticated user logon 202 policy that sets up application access, security, and reconfigures 203 network connections based on a combination of user identity, network 204 location, logon method and time of day. Simple policies are those that 205 can be expressed in a simple statement. They can be represented 206 effectively in schemas or MIBs. Examples of this are VLAN assignments, 207 simple YES/NO QoS requests, and IP address allocations. A specific 208 design goal of this language is to support simple and complex policies. 210 Policies can be further classified into two categories: service 211 policies and usage policies. Service policies describe services 212 available in the network. Usage policies describe which policies will 213 use which services when the policies are satisfied. Usage policies 214 describe particular mechanism(s) employed to either maintain the 215 current state of the object, or to transition an object from one state 216 to a new state, in order to utilize the specified services. Put another 217 way, service policies describe what the network is capable of 218 providing, and usage policies describe how to configure the network in 219 order to take advantage of one or more services that the network 220 provides. 222 2.1 Policy Scope 224 Policies represent business goals and objectives. A translation must be 225 made between these goals and objectives and their realization in the 226 network. An example of this could be a Service Level Agreement (SLA). 227 The Policy Framework Definition Language is specifically designed to 228 model this translation. 230 This translation is not domain-specific. That is, it applies equally to 231 differentiated services quality of service (QoS) as it does to signaled 232 QoS. Furthermore, it is envisioned that the definition of policy in 233 this draft is generic in nature and is suitable for non-QoS networking 234 applications (e.g., DHCP and IPSEC) as well as non-networking 235 applications (e.g., backup policies, auditing access, etc.). 237 3.0 Overview of the Schema 239 The following diagram provides an overview of the six classes that 240 comprise the core schema, and their relationships to each other. 242 ************** 243 * * 244 0..n V * ContainedPolicyGroups 245 +-------------+ * 246 | policyGroup |****** 247 | | 0..n 248 +-------------+ 249 0..n * 250 * *********** 251 1..n V * * ContainedPolicyRules 252 +----------\/-+ * 253 | |******* +----------------------+ 254 | policyRule |*************>| policyValidityPeriod | 255 | | +----------------------+ 256 | | 257 | | ContainedPolicyConditions (ANDed) 258 | |************************* 259 | | * 260 | | 0..n * 0..n 261 | | +---------\/-----------+ 262 | | | policyCondition | 263 | | +----------------------+ 264 | | 265 | | ContainedPolicyActions (ORed) 266 | |************************* 267 | | * 268 | | 0..n * 0..n 269 | | +---------\/-----------+ 270 | | | policyAction | 271 +-------------+ +----------------------+ 272 +-------------------------------+ 273 | policyRuleContainmentAuxClass | 274 +-------------------------------+ 276 3.1 Relationships 278 Relationships are a central feature of information models. A 279 Relationship represents a physical or conceptual connection between 280 objects. CIM and DEN define two types of relationships, called 281 associations and aggregations. 283 3.2 Associations 285 An association is a class that contains two or more references, where 286 each reference identifies another class. An association is defined 287 using a class. Associations can be defined between classes without 288 effecting any of the related classes. That is, addition of an 289 Association does not effect the interface of the related Classes. 291 3.3 Aggregations 293 An aggregation is a strong form of an association. An aggregation is 294 usually used to represent a "whole-part" relationship. This type of 295 relationship defines the containment relationship between a system and 296 the components that make up the system. Aggregation often implies, but 297 does not require, that the aggregated objects have mutual dependencies. 299 3.4 Key Relationships of the Policy Framework Core Information Model 301 The following relationships are shown in the preceding figure: 303 o The ContainedPolicyGroups relation enables policyGroups to be 304 nested. This is critical for scalability and manageability, as it 305 enables complex policies to be constructed from multiple simpler 306 policies for administrative convenience. For example, a policyGroup 307 representing policies for the US might have nested within it policy 308 groups for the Eastern and Western US. 310 For LDAP schemata, the ContainedPolicyGroup relation is mapped to 311 the policyGroupsContainedSet attribute (note that other data stores 312 may define a different mapping). This attribute enables a 313 policyGroup to identify another policyGroup as its parent. 315 o The ContainedPolicyRules relation is similar to the 316 ContainedPolicyGroups relation, except that its purpose is to 317 enable multiple policyRules to be nested. 319 o A policy group may aggregate one or more policy rules, and a policy 320 rule may be aggregated by one or more policy groups. Grouping of 321 policy rules into policy groups is again for administrative 322 convenience; a policy rule may also be used by itself, without 323 belonging to a policy group. 325 o A policy rule may also be aggregated by an instance of any class to 326 which the policyRuleContainmentAuxClass class has been attached. 327 Once again, this is for administrative convenience. If the 328 directory entry to which the policyRuleContainmentAuxClass has been 329 attached is a policy group, then the pointer in the 330 policyRuleContainmentAuxClass realizes the relationship discussed 331 above between the group and a policy rule; a separate attribute is 332 not needed in the policyGroup class. 334 o A condition of a policy rule may specify one or more policy 335 validity periods. This can be used for several purposes. Two 336 important conditions include representing time as a part of the 337 condition (e.g., use this policy in the morning and a different 338 policy in the afternoon) and to enable scheduled activation and 339 deactivation of the policy rule. A policy validity period may be 340 aggregated by multiple policy rules. A rule that does not point to 341 a policy validity period is, from the point of view of scheduling, 342 always active. It may, however, be inactive for other reasons. 344 o A policy rule may aggregate one or more policy conditions. Any 345 conditions aggregated by a policy rule are evaluated and AND-ed 346 together to determine whether to perform the actions associated 347 with the policy rule. The pointer supports an ordering among the 348 conditions pointed to, indicating the order in which the conditions 349 SHOULD be evaluated. This allows the policy administrator to 350 optimize processing at the policy decision point by recommending 351 that it evaluate first the condition most likely to evaluate to 352 FALSE. One of the ordering values for the pointer is 0, indicating 353 that the policy enforcement point is given no guidance on when to 354 evaluate the associated condition. 356 An instance of policyRule itself (as opposed to an instance of a 357 subclass of policyRule) always points to at least one policy 358 condition. A subclass of policyRule, however, may implicitly 359 include one or more conditions within itself, in which case it need 360 not point to any policy conditions at all outside itself. See 6.0, 361 "Extending the Core Schema" on page 22 for further discussion of 362 this point. 364 o A policy rule may point to one or more policy actions. The pointer 365 supports an ordering among the actions pointed to, indicating the 366 order in which the actions SHOULD be performed. A subclass of 367 policyRule may "upgrade" this SHOULD to a SHALL, i.e., indicate 368 that if the actions cannot be performed in the specified order, 369 then they SHALL not be performed at all. One of the ordering 370 values for the pointer is 0, indicating that the policy enforcement 371 point may perform the action at any point in the identified 372 sequence of actions. 374 An instance of policyRule itself (as opposed to an instance of a 375 subclass of policyRule) always points to at least one policy 376 action. A subclass of policyRule, however, may implicitly include 377 one or more actions within itself, in which case it need not point 378 to any policy actions at all outside itself. See 6.0, "Extending 379 the Core Schema" on page 22 for further discussion of this point. 381 4.0 Inheritance Hierarchy 383 The six classes defined in this document are all derived directly from 384 the abstract class "top": 386 top 387 | 388 +---policyGroup 389 | 390 +---policyRuleContainmentAuxClass 391 | 392 +---policyRule 393 | 394 +---policyValidityPeriod 395 | 396 +---policyCondition 397 | 398 +---policyAction 400 5.0 Class Definitions 402 The classes described below contain certain optimizations in 403 anticipation of being used specifically for a directory that uses LDAP 404 as its access protocol. One example of this is the use of auxiliary 405 classes, and another is the mapping of relationships into a pair of 406 attributes, one each in the source and destination class. Other data 407 stores that are not directories might need to implement this 408 relationship differently. 410 5.1 Naming Attributes in the Core Schema 412 Instances in a directory are identified by distinguished names (DNs), 413 which provide the same type of hierarchical organization that a file 414 system provides in a computer system. A distinguished name is a 415 sequence of relative distinguished names (RDNs), where an RDN provides 416 a unique identifier for an instance within the context of its immediate 417 superior in the same way that a filename provides a unique identifier 418 for a file within the context of the folder in which it resides. 420 To preserve maximum naming flexibility for policy administrators, each 421 of the classes defined in this schema has its own naming attribute. 422 Since the naming attributes are different, the policy administrator is 423 guaranteed that there will be no name collisions between instances of 424 different classes, even if the same VALUE is assigned to the instances' 425 respective naming attributes. 427 5.2 The Class policyGroup 429 This class serves as a container for a related set of policy rules. A 430 policy group may also contain other policy groups. Loops, including 431 the degenerate case of a policy group that contains itself, are not 432 allowed when policy groups contain other policy groups. 434 When a policy group contains policy rules, it does so in exactly the 435 same way that any other class would: via the policyRulesContainedSet 436 attribute in the auxiliary class policyRuleContainmentAuxClass (note: 437 this is a specific optimization for directories using LDAP as their 438 access protocol). The class definition is as follows: 440 NAME policyGroup 441 DESCRIPTION A container for a group of related policy rules 442 DERIVED FROM top 443 TYPE structural 444 AUXILIARY CLASSES policyRuleContainmentAuxClass 445 POSSIBLE SUPERIORS container, organization, 446 organizationalUnit, policyGroup 447 OID 448 MUST cn, policyGroupName 449 MAY policyGroupsContainedSet 451 5.2.1 The attribute cn 453 The cn, or common name, attribute is an X.500 attribute. It stands for 454 CommonName. It specifies a (possibly ambiguous) name by which the 455 object is commonly known. This name is used in a limited scope (such as 456 an organization). It conforms to the naming conventions of the country 457 or culture with which it is associated. CN is used universally in DEN 458 as the naming attribute for a class. 460 NAME cn 461 DESCRIPTION naming attribute of this class 462 SYNTAX DirectoryString 463 OID 2.4.5.3 464 EQUALITY caseExactMatch 465 SINGLE-VALUED 467 5.2.2 The Attribute policyGroupName 469 This attribute provides a user-friendly name for a policy group, and is 470 normally what will be displayed to the end-user as the name of this 471 class. It is defined as follows: 473 NAME policyGroupName 474 DESCRIPTION The user-friendly name of this policy group. 475 SYNTAX IA5String 476 OID 477 EQUALITY caseExactIA5Match 478 SINGLE-VALUED 480 5.2.3 The Attribute policyGroupsContainedSet 482 This attribute provides an unordered set of DN pointers to zero or more 483 other policy groups. The attribute definition is as follows: 485 NAME policyGroupsContainedSet 486 DESCRIPTION Distinguished names of other policy groups 487 subsumed under this policy group. There is 488 no order implied among the members of the set. 489 SYNTAX DN 490 OID 491 EQUALITY distinguishedNameMatch 492 MULTI-VALUED 494 5.3 The Class policyRuleContainmentAuxClass 496 This auxiliary class provides a single, multi-valued attribute that 497 points to a set of policy rules. By attaching this attribute to 498 instances of various other classes, a policy administrator has a 499 flexible way of providing an entry point into the directory that allows 500 a client to locate and retrieve the policy rules relevant to it. 502 A policy administrator might have several different pointers to a 503 Policy rule in the overall directory structure. For example, there 504 might be pointers to all policy rules for traffic originating in a 506 particular subnet from a directory entry that represents that subnet. 507 At the same time, there might be pointers to all policy rules related 508 to DiffServ from an instance of policyGroup explicitly introduced as a 509 container for DiffServ-related policy rules. The 510 policyRuleContainmentAuxClass is the mechanism that makes it possible 511 for the policy administrator to define all these pointers. 513 Note that the cn attribute does NOT need to be defined for this class. 514 This is because an auxiliary class is used as a means to collect 515 common attributes and treat them as properties of an object. A good 516 analogy is a #include file, except that since an auxiliary class is a 517 class, all the benefits of a class (e.g., subclassing and inheritance) 518 can be applied to an auxiliary class. 520 The class definition is as follows: 522 NAME policyRuleContainmentAuxClass 523 DESCRIPTION An auxiliary class used to bind policy rules to 524 an appropriate container object. 525 DERIVED FROM top 526 TYPE auxiliary 527 AUXILIARY CLASSES none 528 POSSIBLE SUPERIORS container, organization, 529 organizationalUnit, policyRule 530 OID 531 MUST policyRulesContainedSet 533 5.3.1 The Attribute policyRulesContainedSet 535 This attribute provides an unordered set of DN pointers to one or more 536 policy rules associated with the instance of a structural class to 537 which this attribute has been appended. The attribute definition is: 539 NAME policyRulesContainedSet 540 DESCRIPTION Distinguished names of policy rules associated in 541 some way with the instance to which this attribute 542 has been appended. No order is implied. 543 SYNTAX DN 544 OID 545 EQUALITY distinguishedNameMatch 546 MULTI-VALUED 548 5.4 The Class policyRule 550 This class represents the "If Condition then Action" semantics 551 associated with a policy. A policyRule aggregates sets of policy 552 conditions and policy actions. The conditions that are AND-ed 553 together are identified by DN pointers and/or by specific attributes 554 introduced in subclasses of policyRule. The actions to be performed if 555 all of the conditions in the policyRule evaluate to TRUE are identified 556 by DN pointers and/or by specific attributes introduced in subclasses 557 of policyRule. 559 This class also contains several attributes designed to help directory 560 clients locate the policy rules applicable to them. 562 The class definition is as follows: 564 NAME policyRule 565 DESCRIPTION The class is the central class for representing 566 the "If Condition then Action" semantics 567 associated with a policy rule. 568 DERIVED FROM top 569 TYPE structural 570 AUXILIARY CLASSES none 571 POSSIBLE SUPERIORS policyGroup 572 OID 573 MUST cn 574 policyRuleName 575 policyEnabled 576 MAY policyValidityPeriodRef 577 policyConditionList 578 policyActionList 579 policyRulePriority 580 policyErrorCode 581 policyErrorDescription 582 policyKeywords 583 policyModality 584 policyType 585 policyUsage 587 5.4.1 The Attribute cn 589 This is the exact same definition as in Section 5.2.1. It is repeated 590 here because the PolicyGroup and PolicyRule classes are siblings, and 591 both require a naming attribute. 593 5.4.2 The Attribute policyRuleName 595 This attribute provides a user-friendly name for a policy rule. The 596 attribute definition is as follows: 598 NAME policyRuleName 599 DESCRIPTION The user-friendly name of this policy rule. 600 SYNTAX IA5String 601 OID 602 EQUALITY caseExactIA5Match 603 SINGLE-VALUED 605 5.4.3 The Attribute policyRuleEnabled 607 This flag indicates whether a policy rule is currently enabled, from an 608 ADMINISTRATIVE point of view. Its purpose is to allow a policy 609 administrator to enable or disable a policy rule without having to add 610 it to, or remove it from, the directory. 612 The attribute definition is as follows: 614 NAME policyRuleEnabled 615 DESCRIPTION A flag indicating whether this policy rule is enabled 616 from an administrative point of view. 617 SYNTAX Boolean 618 OID 619 EQUALITY booleanMatch 620 SINGLE-VALUED 622 5.4.4 The Attribute policyValidityPeriodRef 624 This attribute points to an object representing the policy validity 625 period for this policy rule. 627 The attribute definition is as follows: 629 NAME policyValidityPeriodRef 630 DESCRIPTION A DN pointer to an instance of policyValidityPeriod 631 representing either the scheduled periods of activity 632 and inactivity for this policy rule, or possible times 633 when this rule could be activated. 634 SYNTAX DN 635 OID 636 EQUALITY distinguishedNameMatch 637 SINGLE-VALUED 639 5.4.5 The Attribute policyConditionList 641 This attribute provides an ORDERED list of DN pointers that identify a 642 set of policy conditions associated with this policy rule. Order is 643 used to indicate which the conditions MUST be evaluated by the policy 644 decision point in which sequence. The purpose of providing an order 645 is to cause conditions more likely to evaluate to FALSE to be tested 646 early in the process. This speeds the condition examination process, 647 since once a single FALSE condition has been found, the remaining 648 conditions do not need to be evaluated. 650 Since the order of the values returned by a multi-valued attribute is 651 indeterminate, the order must be encoded within the attribute values 652 themselves. To accomplish this, the values of this attribute are of 653 the form "n:DN", where 'n' indicates the order, the colon (':') serves 654 as a separator, and "DN" is a distinguished name encoded in the usual 655 way. Values of 'n' that indicate order are character substrings that 656 represent positive decimal integers: "1", "2", "45", etc. 658 The special value "0" indicates "no order". When n = "0", the policy 659 decision point is given no guidance on when to evaluate the associated 660 condition. When n = a positive integer, then the larger the value, the 661 lower the order of execution. Any condition that has n not equal to 0 662 is evaluated before any condition that has n equal to 0. All conditions 663 whose n is equal to 0 MAY be evaluated in ANY order, as long as all 664 conditions whose n is not equal to 0 have been evaluated first. Note 665 that n may not be a negative number. 667 If two or more identical non-zero values are included, the policy 668 decision point is being told to evaluate the conditions associated with 669 the repeated value in any order it chooses, but at the point where that 670 number falls in the overall sequence of conditions. 672 For example, suppose a policy decision point found the following three 673 values in the policyConditionList for a policy rule: 675 2:DN-1 676 0:DN-2 677 1:DN-3 678 0:DN-4 680 These values tell the policy decision point to evaluate the condition 681 named by DN-3 before it evaluates the one named by DN-1, and to 682 evaluate either the one named by DN-2 or the one named by DN-4 in any 683 order, so long as they are evaluated after DN-1 and DN-3 have been 684 evaluated. 686 The attribute definition is as follows: 687 NAME policyConditionList 688 DESCRIPTION An ordered list of DN pointers indicating a 689 recommended order for evaluating policy conditions. 690 SYNTAX OctetString 691 OID 692 EQUALITY caseOctetStringOrderingMatch 693 MULTI-VALUED 694 FORMAT n:DN 696 5.4.6 The Attribute policyActionList 698 This attribute provides an ORDERED list of DN pointers to a set of 699 policy actions associated with this policy rule. The order indicates 700 the order in which the actions MUST be performed by the policy 701 decision point. If a policy decision point cannot perform the actions 702 in the indicated order, then an error condition must be raised. 704 Subclasses of policyRule may, however, override this rule. This may be 705 done by, for example, stating that if a policy decision point cannot 706 perform the actions in the indicated order, then it must not perform 707 them at all. 709 The ordering of the actions has the same semantics as the ordering of 710 the conditions in the policyConditionList attribute. 712 The attribute definition is as follows: 714 NAME policyActionList 715 DESCRIPTION An ordered list of DN pointers indicating the 716 order in which policy actions SHOULD be performed. 717 SYNTAX OctetString 718 OID 719 EQUALITY caseOctetStringOrderingMatch 720 MULTI-VALUED 721 FORMAT n:DN 723 5.4.7 The Attribute policyRulePriority 725 This attribute provides a positive integer for prioritizing policy 726 Rules relative to each other. For policy rules that have this 727 attribute, smaller integer values indicate higher priority. Since one 728 purpose of this attribute is to allow specific, ad hoc policy rules to 729 override established policy rules temporarily, an instance that has 730 this attribute has a higher priority than all instances that lacks it. 732 Prioritization among policy rules is important only when policy rules 733 involve both conditions that can be satisfied simultaneously and 734 actions that are incompatible. For example, one policy rule might 735 specify that all Telnet traffic is to be placed on the medium-priority 736 queue, while a second policy rule specifies that all traffic from a 737 particular IP address is to be placed on the high-priority queue. If 738 Telnet traffic can flow from or to the IP address whose traffic is to 739 be placed on the high-priority queue, then these two rules conflict. A 740 policy decision point can determine which queue should be used for 741 Telnet traffic from this particular IP address based on which of the 742 two (conflicting) policy rules has the higher priority. 744 The attribute definition is as follows: 745 NAME policyRulePriority 746 DESCRIPTION A positive integer for prioritizing this policy rule 747 relative to other policy rules in the directory. A 748 smaller value indicates a higher priority. 749 SYNTAX INTEGER 750 OID 751 EQUALITY integerMatch 752 SINGLE-VALUED 754 5.4.8 The Attribute policyErrorCode 756 This attribute is used in conjunction with the policyErrorDescription 757 attribute to provide an indication of an error in executing a policy. 758 The policyErrorCode attribute provides a generalized error code 759 indicating a policy failure. 761 The attribute definition is as follows: 763 NAME policyErrorCode 764 DESCRIPTION A generalized error code used to indicate that this 765 policy rule failed to evaluate or execute properly. 766 SYNTAX INTEGER 767 OID 768 EQUALITY integerMatch 769 SINGLE-VALUED 771 5.4.9 The Attribute policyErrorDescription 773 This attribute is used in conjunction with the policyErrorCode 774 attribute to provide an indication of an error in executing a policy. 775 The policyErrorDescription attribute provides a detailed description 776 of the specific type of policy failure encountered. 778 The attribute definition is as follows: 780 NAME policyErrorDescription 781 DESCRIPTION A detailed description of the error that occurred 782 When this policy rule failed to evaluate or execute 783 properly. 784 SYNTAX IA5String 785 OID 786 EQUALITY caseExactIA5Match 787 SINGLE-VALUED 789 5.4.10 The Attribute policyKeywords 791 This attribute provides a set of one or more ad hoc keywords that a 792 policy administrator may define to assist directory clients in locating 793 the policy rules applicable to them. Values for this attribute are 794 installation dependent, and thus are not specified in any schema 795 document. 797 The attribute definition is as follows: 799 NAME policyKeywords 800 DESCRIPTION A set of ad hoc keywords to assist directory clients 801 in locating the policy rules applicable to them. 802 SYNTAX IA5String 803 OID 804 EQUALITY caseExactIA5Match 805 MULTI-VALUED 807 5.4.11 The Attribute policyModality 809 This attribute specifies whether the action(s) specified in this policy 810 rule should be applied if the condition(s) is satisfied (value = 0) or 811 not satisfied (value = 1). 813 The attribute definition is as follows: 815 NAME policyModality 816 DESCRIPTION Specifies whether the actions of this policy rule 817 should be executed if the conditions are satisfied 818 (value = 0) or not satisfied (value = 1). 819 SYNTAX INTEGER 820 OID 821 EQUALITY integerMatch 822 SINGLE-VALUED 824 5.4.12 The Attribute policyType 826 This attribute is used to specify the type of policy that this policy 827 rule is. This can be used for classification (service policy or usage 828 policy) or categorization (the type of service or usage policy that 829 this policy is). 831 The attribute definition is as follows: 833 NAME policyType 834 DESCRIPTION Defines the type of policy that this policy is. This 835 is used to help classify and categorize policies. 836 SYNTAX INTEGER 837 OID 838 EQUALITY integerMatch 839 SINGLE-VALUED 841 5.4.13 The Attribute policyUsage 843 This attribute is used to provide guidelines on how this policy should 844 be used. 846 The attribute definition is as follows: 848 NAME policyUsage 849 DESCRIPTION This attribute is used to provide guidelines on how 850 this policy should be used. 851 SYNTAX DirectoryString 852 OID 853 EQUALITY caseIgnoreMatch 854 SINGLE-VALUED 856 5.5 The Class policyValidityPeriod 858 This class provides a means of representing the time periods during 859 which a policy rule is valid, i.e., active. At all times that fall 860 outside these time periods, the policy rule has no effect. A policy 861 rule is treated as valid at all times if it does not specify a 862 policyValidityPeriod (i.e., if it has a null policyValidityPeriodRef 863 attribute). 865 Instances of this class may have up to five attributes identifying time 866 periods at different levels. The values of all the attributes present 867 in an instance are AND-ed together to determine the validity period(s) 868 for the instance. For example, an instance with an overall validity 869 range of January 1, 1999 through December 31, 1999; a month mask of 870 "001100000000" (March and April); a day-of-the-week mask of "0000100" 871 (Fridays); and a time of day range of 8 AM through 4 PM would represent 872 the following validity periods: 874 Friday, March 5, 1999, from 8 AM through 4 PM; 875 Friday, March 12, 1999, from 8 AM through 4 PM; 876 Friday, March 19, 1999, from 8 AM through 4 PM; 877 Friday, March 26, 1999, from 8 AM through 4 PM; 878 Friday, April 3, 1999, from 8 AM through 4 PM; 879 Friday, April 10, 1999, from 8 AM through 4 PM; 880 Friday, April 17, 1999, from 8 AM through 4 PM; 881 Friday, April 24, 1999, from 8 AM through 4 PM. 883 Attributes not present in an instance of policyValidityPeriod are 884 implicitly treated as having the "always enabled" value. Thus, in the 885 example above, the day-of-the-month mask is not present, and so the 886 validity period for the instance implicitly includes a day-of-the-month 887 mask containing 31 1's. If we apply this "missing attribute" rule to 888 its fullest, we see that there is a second way to indicate that a 889 policy rule is always enabled: have it point to an instance of 890 policyValidityPeriod whose only attribute is policyValidityPeriodName. 892 The class definition is as follows: 894 NAME policyValidityPeriod 895 DESCRIPTION A class that provides the capability of 896 enabling / disabling a policy rule according 897 to a pre-determined schedule. 898 DERIVED FROM top 899 TYPE structural 900 AUXILIARY CLASSES none 901 POSSIBLE SUPERIORS 902 OID 903 MUST cn 904 policyValidityPeriodName 905 MAY policyValidityPeriodTime 906 policyValidityMonthMask 907 policyValidityDayOfMonthMask 908 policyValidityDayOfWeekMask 909 policyValidityTimeOfDayRange 911 5.5.1 The Attribute cn 913 This is the exact same definition as in Section 5.2.1. It is repeated 914 here because the PolicyGroup and PolicyRule classes are siblings, and 915 both require a naming attribute. 917 5.5.2 The Attribute policyValidityPeriodName 919 This attribute provides a user-friendly name for a policy validity 920 period. The attribute definition is as follows: 922 NAME policyValidityPeriodName 923 DESCRIPTION The user-friendly name of this entry. 924 SYNTAX IA5String 925 OID 926 EQUALITY caseExactIA5Match 927 SINGLE-VALUED 929 5.5.3 The Attribute policyValidityPeriodTime 931 This attribute identifies an overall range of calendar dates / times 932 over which a policy rule is valid. It is formatted as a string 933 containing two dates / times, separated by a colon (':'), optionally 934 followed by a second colon and a value indicating offset from UTC. The 935 first date indicates the beginning of the range, while the second date 936 indicates the end. Thus the second date / time must be later than the 937 first. Dates are expressed as substrings of the form "yyyymmddhhmmss". 939 The UTC offset indicator is either a 'Z', indicating UTC, or a 940 Substring of the form 941 '+' or '-' direction from UTC: '+' = east, '-' = west 942 hh hours from UTC (00..13) 943 mm minutes from UTC (00..59) 945 If the time zone indicator is omitted, the time is interpreted as the 946 local time at the policy decision point. 948 Examples: 950 19990101080000:19990131120000 951 January 1, 1999, 8 AM through January 31, 1999, noon (local time) 953 19990101080000:19990131120000:Z 954 January 1, 1999, 8 AM through January 31, 1999, noon (UTC) 956 19990101080000:19990131120000:-0500 957 January 1, 1999, 8 AM through January 31, 1999, noon (US EST) 959 The attribute definition is as follows: 961 NAME policyValidityPeriodTime 962 DESCRIPTION The range of calendar dates on which a 963 policy rule is valid. 964 SYNTAX Printable String 965 OID 966 EQUALITY caseIgnoreMatch 967 SINGLE-VALUED 968 FORMAT yyyymmddhhmmss:yyyymmddhhmmss[:] 970 5.5.4 The Attribute policyValidityMonthMask 972 This attribute identifies the months of the year in which a policy rule 973 is valid. It is formatted as a string containing 12 ASCII '0's and 974 '1's, where the '1's identify the months (beginning with January) in 975 which the policy rule is valid. The value "000010010000", for example, 976 indicates that a policy rule is valid only in the months May and 977 August. 979 The attribute definition is as follows: 981 NAME policyValidityMonthMask 982 DESCRIPTION A mask identifying the months of the year in 983 which a policy rule is valid. 984 SYNTAX Printable String 985 OID 986 EQUALITY caseIgnoreMatch 987 SINGLE-VALUED 988 FORMAT A string of 12 ASCII '0's and '1's. 990 5.5.5 The Attribute policyValidityDayOfMonthMask 992 This attribute identifies the days of the month on which a policy rule 993 is valid. It is formatted as a string containing 31 ASCII '0's and 994 '1's, where the '1's identify the days of the month (beginning with day 995 1 and going up through day 31) on which the policy rule is valid. The 996 value "1110000000000000000000000000000", for example, indicates that a 997 policy rule is valid only on the first three days of each month. For 998 months with fewer than 31 days, the digits corresponding to days that 999 the months do not have are ignored. 1001 The attribute definition is as follows: 1003 NAME policyValidityDayOfMonthMask 1004 DESCRIPTION A mask identifying the days of the month 1005 on which a policy rule is valid. 1006 SYNTAX Printable String 1007 OID 1008 EQUALITY caseIgnoreMatch 1009 SINGLE-VALUED 1010 FORMAT A string of 31 ASCII '0's and '1's. 1012 5.5.6 The Attribute policyValidityDayOfWeekMask 1014 This attribute identifies the days of the week on which a policy rule 1015 Is valid. It is formatted as a string containing 7 ASCII '0's and 1016 '1's, where the '1's identify the days of the week (beginning with 1017 Monday and going up through Sunday) on which the policy rule is valid. 1018 The value "1111100", for example, indicates that a policy rule is valid 1019 Monday through Friday. 1021 The attribute definition is as follows: 1023 NAME policyValidityDayOfWeekMask 1024 DESCRIPTION A mask identifying the days of the week 1025 on which a policy rule is valid. 1026 SYNTAX Printable String 1027 OID 1028 EQUALITY caseIgnoreMatch 1029 SINGLE-VALUED 1030 FORMAT A string of 7 ASCII '0's and '1's. 1032 5.5.7 The Attribute policyValidityTimeOfDayRange 1034 This attribute identifies a range of times over which a policy rule is 1035 valid. It is formatted as a string containing two times, separated by 1036 a colon (':'), optionally followed by a second colon and a value 1037 indicating offset from UTC. The first time indicates the beginning of 1038 the range, while the second time indicates the end. Times are 1039 expressed as substrings of the form "hhmmss". 1041 The second substring always identifies a later time than the first 1042 substring. To allow for ranges that span midnight, however, the value 1043 of the second string may be smaller than the value of the first 1044 substring. Thus "080000:210000" identifies the range from 8 AM until 9 1045 PM, while "210000:080000" identifies the range from 9 PM until 8 AM of 1046 the following day. 1048 When a range spans midnight, it by definition includes parts of two 1049 successive days. When one of these days is selected by the 1050 intersection of the policyValidityMonthMask, 1051 policyValidityDayOfMonthMask, and policyValidityDayOfWeekMask, but the 1052 other day is not, then the policy is active only during the portion of 1053 the range that falls on the selected day. For example, if the range 1054 extends from 9 PM until 8 AM, and the day of week mask selects Monday 1055 and Tuesday, then the policy is active during the following three intervals: 1057 From midnight Sunday until 8 AM Monday; From 9 PM Monday until 8 AM 1058 Tuesday; From 9 PM Tuesday until 11:59:59 Tuesday. 1060 The UTC offset indicator is either a 'Z', indicating UTC, or a 1061 Substring of the form 1063 '+' or '-' direction from UTC: '+' = east, '-' = west 1064 hh hours from UTC (00..13) 1065 mm minutes from UTC (00..59) 1067 If the time zone indicator is omitted, the time is interpreted as the 1068 local time at the policy decision point. See the examples of the 1069 different kinds of UTC offsets under the policyValidityPeriodTime 1070 attribute. 1072 The attribute definition is as follows: 1074 NAME policyValidityTimeOfDayRange 1075 DESCRIPTION The range of times at which a policy rule 1076 is valid. If the second time is earlier 1077 than the first, then the interval spans 1078 midnight. 1079 SYNTAX Printable String 1080 OID 1081 EQUALITY caseIgnoreMatch 1082 SINGLE-VALUED 1083 FORMAT hhmmss:hhmmss[:] 1085 5.6 The Class policyCondition 1087 The class definition is as follows: 1089 NAME policyCondition 1090 DESCRIPTION A class representing a condition to be 1091 evaluated in conjunction with a policy 1092 rule. 1093 DERIVED FROM top 1094 TYPE structural 1095 AUXILIARY CLASSES none 1096 POSSIBLE SUPERIORS policyRule 1097 OID 1098 MUST cn 1099 policyConditionName 1100 policyConstraintData 1101 policyConstraintEncoding 1103 5.6.1 The Attribute cn 1105 This is the exact same definition as in Section 5.2.1. It is repeated 1106 here because the PolicyGroup and PolicyRule classes are siblings, and 1107 both require a naming attribute. 1109 5.6.2 The Attribute policyConditionName 1111 This attribute provides a user-friendly name for a policy condition. 1112 The attribute definition is as follows: 1114 NAME policyConditionName 1115 DESCRIPTION The user-friendly name of this policy condition. 1116 SYNTAX IA5String 1117 OID 1118 EQUALITY caseExactIA5Match 1119 SINGLE-VALUED 1121 5.6.3 The Attribute policyConstraintData 1123 This attribute provides an escape mechanism for representing policy 1124 constraints that have not been modeled with specific attributes. The 1125 format of the OctetString is left unspecified in this definition. It 1126 is determined by the OID value stored in the attribute 1127 policyConstraintEncoding. Since policyConstraintEncoding is 1128 single-valued, all the values of policyConstraintData share the same 1129 format and semantics. 1131 A policy decision point can readily determine whether it supports the 1132 values stored in an instance of policyConstraintData, by checking the 1133 OID value from policyConstraintEncoding against the set of OIDs it 1134 recognizes. The action for the policy decision point to take in case 1135 it does not recognize the format of this data could itself be modeled 1136 as a policy rule, governing the behavior of the policy decision point 1137 itself. 1139 The attribute definition is as follows: 1141 NAME policyContraintData 1142 DESCRIPTION Escape mechanism for representing constraints 1143 that have not been modeled as specific attributes. 1144 The format of the values is identified by the 1145 OID stored in the attribute policyConstraintEncoding. 1146 SYNTAX OctetString 1147 OID 1148 EQUALITY octetStringMatch 1149 MULTI-VALUED 1151 5.6.4 The Attribute policyConstraintEncoding 1153 This attribute identifies the encoding and semantics of the values of 1154 policyConstraintData in this instance. The value of this attribute is 1155 a single OID. 1157 The attribute definition is as follows: 1159 NAME policyContraintEncoding 1160 DESCRIPTION An OID identifying the format and semantics for 1161 this instance's policyConstraintData attribute. 1162 SYNTAX OID 1163 OID 1164 EQUALITY objectIdentifierMatch 1165 SINGLE-VALUED 1167 5.7 The Class policyAction 1169 The class definition is as follows: 1171 NAME policyAction 1172 DESCRIPTION A class representing an action to be performed 1173 as a result of a policy rule. 1174 DERIVED FROM top 1175 TYPE structural 1176 AUXILIARY CLASSES none 1177 POSSIBLE SUPERIORS policyRule 1178 OID 1179 MUST cn 1180 policyActionName 1181 policyActionData 1182 policyActionEncoding 1184 5.7.1 The Attribute cn 1186 This is the exact same definition as in Section 5.2.1. It is repeated 1187 here because the PolicyGroup and PolicyRule classes are siblings, and 1188 both require a naming attribute. 1190 5.7.2 The Attribute policyActionName 1192 This attribute provides a user-friendly name for a policy action. The 1193 attribute definition is as follows: 1195 NAME policyActionName 1196 DESCRIPTION The user-friendly name of this policy action. 1197 SYNTAX IA5String 1198 OID 1199 EQUALITY caseExactIA5Match 1200 SINGLE-VALUED 1202 5.7.3 The Attribute policyActionData 1204 This attribute provides an escape mechanism for representing policy 1205 actions that have not been modeled with specific attributes. The 1206 format of the OctetString is left unspecified in this definition. It 1207 is determined by the OID value stored in the attribute 1208 policyActionEncoding. Since policyActionEncoding is single-valued, all 1209 the values of policyActionData share the same format and semantics. 1211 A policy decision point can readily determine whether it supports the 1212 values stored in an instance of policyActionData, by checking the OID 1213 value from policyActionEncoding against the set of OIDs it recognizes. 1214 The action for the policy decision point to take in case it does not 1215 recognize the format of this data could itself be modeled as a policy 1216 rule, governing the behavior of the policy decision point itself. 1218 The attribute definition is as follows: 1220 NAME policyActionData 1221 DESCRIPTION Escape mechanism for representing actions 1222 that have not been modeled as specific attributes. 1223 The format of the values is identified by the 1224 OID stored in the attribute policyActionEncoding. 1225 SYNTAX OctetString 1226 OID 1227 EQUALITY octetStringMatch 1228 MULTI-VALUED 1230 5.7.4 The Attribute policyActionEncoding 1232 This attribute identifies the encoding and semantics of the values of 1233 policyActionData in this instance. The value of this attribute is a 1234 single OID. 1236 The attribute definition is as follows: 1238 NAME policyActionEncoding 1239 DESCRIPTION An OID identifying the format and semantics for 1240 this instance's policyActionData attribute. 1241 SYNTAX OID 1242 OID 1243 EQUALITY objectIdentifierMatch 1244 SINGLE-VALUED 1246 6.0 Extending the Core Schema 1248 6.1 Subclassing policyCondition and policyAction 1250 The simplest way of extending the core schema is to use the first four 1251 classes as they are, and simply subclass policyCondition and 1252 policyAction. An instance of policyRule ties everything together, with 1253 its very simple, invariant semantics: 1255 If the policyRule is active, then evaluate, possibly in a specified 1256 order, all conditions pointed to by policyConditionList. If all 1257 conditions evaluate to TRUE, then perform, possibly in a specified 1258 order, all actions pointed to by policyActionList. 1260 With this approach a new schema specifies the conditions it needs in 1261 subclasses of policyCondition (or, better still, reuses conditions that 1262 have already been specified in subclasses of policyCondition), and it 1263 specifies (or reuses) the actions it needs in subclasses of 1264 policyAction. 1266 6.2 Subclassing policyRule 1268 There are two possible ways to subclass policyRule, as described below. 1270 6.2.1 Refining the Semantics of policyRule 1272 This approach refines the structural and possibly behavioral semantics 1273 of what it means to be a policy rule. For example, additional 1274 attributes and relationships could be defined in a subclass of 1275 policyRule. These attributes and relationships could provide extra 1276 meaning for how to interpret the set of conditions and actions that a 1277 policyRule aggregates. 1279 6.2.2 Optimizing the computation of a policyRule 1281 All preceding mechanisms for extending the core schema will work in all 1282 cases, but they comes at a price: in order to fully understand a 1283 policy rule, a client must retrieve at least three objects: a policy 1284 rule, at least one policy condition, and at least one policy action. A 1285 future version of this specification will define how to optimize the 1286 evaluation of a policy rule. 1288 6.3 Using policyConstraintEncoding and policyActionEncoding 1290 As discussed in 5.6, "The Class policyCondition" on page 23, the 1291 attributes policyConstraint and policyConstraintEncoding are included 1292 in policyCondition to provide an escape mechanism for representing 1293 "exceptional" policy conditions. The attributes policyAction and 1294 policyActionEncoding play the same role with respect to actions. This 1295 enables interoperability between different vendors. For example, 1296 imagine a network comprised of access devices from vendor A, edge and 1297 core devices from vendor B, and a policy server from vendor C. It is 1298 desirable for the policy server to be able to configure and manage all 1299 of the devices from vendors A and B. Unfortunately, these devices will 1300 in general have little in common (e.g., different mechanisms, different 1301 ways for controlling those mechanisms, different operating systems, 1302 etc.). The escape conditions provide a way for vendor-specific commands 1303 to be encoded as OctetStrings so that they can be commonly managed by 1304 a single device. 1306 7.0 Security Considerations 1308 Security and denial of service considerations are not explicitly 1309 considered in this memo, as they are appropriate for the underlying 1310 policy architecture. However, the policy architecture must be secure 1311 as far as the following aspects are concerned. First, the mechanisms 1312 proposed under the framework must minimize theft and denial of service 1313 threats. Second, it must be ensured that the entities (such as PEPs and 1314 PDPs) involved in policy control can verify each other's identity and 1315 establish necessary trust before communicating. The schema defined 1316 in this document MUST not compromise either of these goals. 1318 8.0 Intellectual Property 1320 The IETF takes no position regarding the validity or scope of any 1321 intellectual property or other rights that might be claimed to pertain 1322 to the implementation or use of the technology described in this 1323 document or the extent to which any license under such rights might or 1324 might not be available; neither does it represent that it has made any 1325 effort to identify any such rights. Information on the IETF's 1326 procedures with respect to rights in standards-track and 1327 standards-related documentation can be found in BCP-11. Copies of 1328 claims of rights made available for publication and any assurances of 1329 licenses to be made available, or the result of an attempt made to 1330 obtain a general license or permission for the use of such proprietary 1331 rights by implementers or users of this specification can be obtained 1332 from the IETF Secretariat. 1334 The IETF invites any interested party to bring to its attention any 1335 copyrights, patents or patent applications, or other proprietary rights 1336 which may cover technology that may be required to practice this 1337 standard. Please address the information to the IETF Executive 1338 Director. 1340 9.0 Acknowledgments 1342 This document is closely aligned with the work being done in the 1343 Desktop Management Task Force (DMTF) Service Level Agreements and 1344 Networks working groups. As noted, the core schema described here was 1345 initially defined in references [2] and [3]. We would especially like 1346 to thank Bob Moore, Lee Rafalow, Andrea Westerinen, and David Jones 1347 for their helpful comments. 1349 10.0 References 1351 [1] Strassner, J., and E. Ellesson, "Terminology for describing 1352 network policy and services", Internet-Draft work in progress, 1353 August 1998. 1355 [2] Bhattacharya, P., and R. Adams, W. Dixon, R. Pereira, R. Rajan, 1356 "An LDAP Schema for Configuration and Administration of IPSec 1357 based Virtual Private Networks (VPNs)", Internet-Draft work in 1358 progress, October 1998 1360 [3] Rajan, R., and J. C. Martin, S. Kamat, M. See, R. Chaudhury, D. 1361 Verma, G. Powers, R. Yavatkar, "Schema for Differentiated Services 1362 and Integrated Services in Networks", Internet-Draft work in 1363 progress, October 1998 1365 [4] Judd, S., and J. Strassner, "Directory-enabled Networks", 1366 version 3.0c5 (August 1998). 1368 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1369 Levels", BCP 14, RFC 2119, March 1997. 1371 [6] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 1372 Standards Process", BCP 11, RFC 2028, October 1996. 1374 11.0 Authors' Addresses 1376 John Strassner 1377 Bldg 1 1378 Cisco Systems 1379 170 West Tasman Drive 1380 San Jose, CA 95134 1381 Phone: +1-408-527-1069 1382 Fax: +1-408-527-1722 1383 E-mail: johns@cisco.com 1385 Ed Ellesson 1386 JDGA/501 1387 IBM Corporation 1388 4205 S. Miami Blvd. 1389 Research Triangle Park, NC 27709 1390 Phone: +1-919-254-4115 1391 Fax: +1-919-254-6243 1392 E-mail: ellesson@raleigh.ibm.com 1394 12.0 Full Copyright Statement 1396 Copyright (C) The Internet Society (1997). All Rights Reserved. 1398 This document and translations of it may be copied and furnished to 1399 others, and derivative works that comment on or otherwise explain it or 1400 assist in its implementation may be prepared, copied, published and 1401 distributed, in whole or in part, without restriction of any kind, 1402 provided that the above copyright notice and this paragraph are 1403 included on all such copies and derivative works. However, this 1404 document itself may not be modified in any way, such as by removing the 1405 copyright notice or references to the Internet Society or other 1406 Internet organizations, except as needed for the purpose of developing 1407 Internet standards in which case the procedures for copyrights defined 1408 in the Internet Standards process must be followed, or as required to 1409 translate it into languages other than English. 1411 The limited permissions granted above are perpetual and will not be 1412 revoked by the Internet Society or its successors or assigns. 1414 This document and the information contained herein is provided on an 1415 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1416 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1417 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1418 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1419 FITNESS FOR A PARTICULAR PURPOSE.