idnits 2.17.1 draft-ietf-policy-pcim-ext-06.txt: -(726): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1746): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2032): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2187): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 22) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 1114 instances 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-RFC2606-compliant FQDNs in the document. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1493 has weird spacing: '...alue of this...' == Line 1834 has weird spacing: '...irrored bool...' -- 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 (November 2001) is 8196 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'PolicyIntegerVariable' on line 1447 == Missing Reference: '300' is mentioned on line 1447, but not defined -- Looks like a reference, but probably isn't: 'FirstMatching' on line 1988 -- Looks like a reference, but probably isn't: 'AllMatching' on line 1987 -- Looks like a reference, but probably isn't: 'PCIM' on line 3346 == Unused Reference: '2' is defined on line 3951, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2028 (ref. '2') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-05) exists of draft-ietf-policy-qos-info-model-04 == Outdated reference: A later version (-06) exists of draft-ietf-ipsp-config-policy-model-03 -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 2234 (ref. '8') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2373 (ref. '10') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2252 (ref. '11') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Policy Framework Working Group B. Moore 2 INTERNET-DRAFT L. Rafalow 3 Updates: 3060 IBM 4 Category: Standards Track Y. Ramberg 5 Y. Snir 6 A. Westerinen 7 Cisco Systems 8 R. Chadha 9 Telcordia Technologies 10 M. Brunner 11 NEC 12 R. Cohen 13 Ntear LLC 14 J. Strassner 15 INTELLLIDEN, Inc. 16 November 2001 18 Policy Core Information Model Extensions 20 21 Thursday, November 08, 2001, 3:23 PM 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with all 26 provisions of Section 10 of RFC2026. 28 Internet-Drafts are working documents of the Internet Engineering Task 29 Force (IETF), its areas, and its working groups. Note that other groups 30 may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months and 33 may be updated, replaced, or obsoleted by other documents at any time. 34 It is inappropriate to use Internet-Drafts as reference material or to 35 cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright Notice 45 Copyright (C) The Internet Society (2001). All Rights Reserved. 47 Abstract 49 This document proposes a number of changes to the Policy Core Information 50 Model (PCIM, RFC 3060). These changes include both extensions of PCIM 51 into areas that it did not previously cover, and changes to the existing 52 PCIM classes and associations. Both sets of changes are done in a way 53 that, to the extent possible, preserves interoperability with 54 implementations of the original PCIM model. 56 Table of Contents 58 1. Introduction......................................................5 59 2. Overview of the Changes...........................................5 60 2.1. How to Change an Information Model...........................5 61 2.2. List of Changes to the Model.................................6 62 2.2.1. Changes to PolicyRepository................................6 63 2.2.2. Additional Associations and Additional Reusable Elements...6 64 2.2.3. Priorities and Decision Strategies.........................6 65 2.2.4. Policy Roles...............................................7 66 2.2.5. CompoundPolicyConditions and CompoundPolicyActions.........7 67 2.2.6. Variables and Values.......................................7 68 2.2.7. Domain-Level Packet Filtering..............................8 69 2.2.8. Device-Level Packet Filtering..............................8 70 3. The Updated Class and Association Class Hierarchies...............8 71 4. Areas of Extension to PCIM.......................................12 72 4.1. Policy Scope................................................13 73 4.1.1. Levels of Abstraction: Domain- and Device-Level Policies..13 74 4.1.2. Administrative and Functional Scopes......................13 75 4.2. Reusable Policy Elements....................................14 76 4.3. Policy Sets.................................................15 77 4.4. Nested Policy Rules.........................................15 78 4.4.1. Usage Rules for Nested Rules..............................15 79 4.4.2. Motivation................................................16 80 4.5. Priorities and Decision Strategies..........................17 81 4.5.1. Structuring Decision Strategies...........................18 82 4.5.2. Side Effects..............................................19 83 4.5.3. Multiple PolicySet Trees For a Resource...................20 84 4.5.4. Deterministic Decisions...................................21 85 4.6. Policy Roles................................................22 86 4.6.1. Comparison of Roles in PCIM with Roles in snmpconf........22 87 4.6.2. Addition of PolicyRoleCollection to PCIMe.................22 88 4.6.3. Roles for PolicyGroups....................................23 89 4.7. Compound Policy Conditions and Compound Policy Actions......25 90 4.7.1. Compound Policy Conditions................................25 91 4.7.2. Compound Policy Actions...................................25 92 4.8. Variables and Values........................................26 93 4.8.1. Simple Policy Conditions..................................26 94 4.8.2. Using Simple Policy Conditions............................27 95 4.8.3. The Simple Condition Operator.............................28 96 4.8.4. SimplePolicyActions.......................................31 97 4.8.5. Policy Variables..........................................32 98 4.8.6. Explicitly Bound Policy Variables.........................33 99 4.8.7. Implicitly Bound Policy Variables.........................34 100 4.8.8. Structure and Usage of Pre-Defined Variables..............35 101 4.8.9. Rationale for Modeling Implicit Variables as Classes......36 102 4.8.10. Policy Values............................................37 103 4.9. Packet Filtering............................................37 104 4.9.1. Domain-Level Packet Filters...............................38 105 4.9.2. Device-Level Packet Filters...............................39 106 4.10. Conformance to PCIM and PCIMe..............................39 107 5. Class Definitions................................................40 108 5.1. The Abstract Class "PolicySet"..............................40 109 5.2. Update PCIM's Class "PolicyGroup"...........................41 110 5.3. Update PCIM's Class "PolicyRule"............................41 111 5.4. The Class "SimplePolicyCondition"...........................42 112 5.5. The Class "CompoundPolicyCondition".........................43 113 5.6. The Class "CompoundFilterCondition".........................43 114 5.7. The Class "SimplePolicyAction"..............................44 115 5.8. The Class "CompoundPolicyAction"............................44 116 5.9. The Abstract Class "PolicyVariable".........................46 117 5.10. The Class "PolicyExplicitVariable".........................46 118 5.10.1. The Single-Valued Property "ModelClass"..................46 119 5.10.2. The Single-Valued Property ModelProperty.................47 120 5.11. The Abstract Class "PolicyImplicitVariable"................47 121 5.11.1. The Multi-Valued Property "ValueTypes"...................47 122 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe..48 123 5.12.1. The Class "PolicySourceIPv4Variable".....................48 124 5.12.2. The Class "PolicySourceIPv6Variable".....................48 125 5.12.3. The Class "PolicyDestinationIPv4Variable"................48 126 5.12.4. The Class "PolicyDestinationIPv6Variable"................48 127 5.12.5. The Class "PolicySourcePortVariable".....................49 128 5.12.6. The Class "PolicyDestinationPortVariable"................49 129 5.12.7. The Class "PolicyIPProtocolVariable".....................50 130 5.12.8. The Class "PolicyIPVersionVariable"......................50 131 5.12.9. The Class "PolicyIPToSVariable"..........................50 132 5.12.10. The Class "PolicyDSCPVariable"..........................50 133 5.12.11. The Class "PolicyFlowIdVariable"........................51 134 5.12.12. The Class "PolicySourceMACVariable".....................51 135 5.12.13. The Class "PolicyDestinationMACVariable"................51 136 5.12.14. The Class "PolicyVLANVariable"..........................51 137 5.12.15. The Class "PolicyCoSVariable"...........................52 138 5.12.16. The Class "PolicyEthertypeVariable".....................52 139 5.12.17. The Class "PolicySourceSAPVariable".....................52 140 5.12.18. The Class "PolicyDestinationSAPVariable"................52 141 5.12.19. The Class "PolicySNAPVariable"..........................53 142 5.12.20. The Class "PolicyFlowDirectionVariable".................53 143 5.13. The Abstract Class "PolicyValue"...........................53 144 5.14. Subclasses of "PolicyValue" Specified in PCIMe.............54 145 5.14.1. The Class "PolicyIPv4AddrValue"..........................54 146 5.14.2. The Class "PolicyIPv6AddrValue...........................55 147 5.14.3. The Class "PolicyMACAddrValue"...........................56 148 5.14.4. The Class "PolicyStringValue"............................56 149 5.14.5. The Class "PolicyBitStringValue".........................57 150 5.14.6. The Class "PolicyIntegerValue"...........................58 151 5.14.7. The Class "PolicyBooleanValue"...........................59 152 5.15. The Class "PolicyRoleCollection"...........................59 153 5.15.1. The Single-Valued Property "PolicyRole"..................59 154 5.16. The Class "ReusablePolicyContainer"........................59 155 5.17. Deprecate PCIM's Class "PolicyRepository"..................60 156 5.18. The Abstract Class "FilterEntryBase".......................60 157 5.19. The Class "IpHeadersFilter"................................60 158 5.19.1. The Property HdrIpVersion................................61 159 5.19.2. The Property HdrSrcAddress...............................61 160 5.19.3. The Property HdrSrcMask..................................61 161 5.19.4. The Property HdrDestAddress..............................62 162 5.19.5. The Property HdrDestMask.................................62 163 5.19.6. The Property HdrProtocolID...............................62 164 5.19.7. The Property HdrSrcPortStart.............................62 165 5.19.8. The Property HdrSrcPortEnd...............................63 166 5.19.9. The Property HdrDestPortStart............................63 167 5.19.10. The Property HdrDestPortEnd.............................63 168 5.19.11. The Property HdrDSCP....................................64 169 5.19.12. The Property HdrFlowLabel...............................64 170 5.20. The Class "8021Filter".....................................64 171 5.20.1. The Property 8021HdrSrcMACAddr...........................65 172 5.20.2. The Property 8021HdrSrcMACMask...........................65 173 5.20.3. The Property 8021HdrDestMACAddr..........................65 174 5.20.4. The Property 8021HdrDestMACMask..........................65 175 5.20.5. The Property 8021HdrProtocolID...........................65 176 5.20.6. The Property 8021HdrPriorityValue........................66 177 5.20.7. The Property 8021HdrVLANID...............................66 178 5.21. The Class FilterList.......................................66 179 5.21.1. The Property Direction...................................67 180 6. Association and Aggregation Definitions..........................67 181 6.1. The Aggregation "PolicySetComponent"........................67 182 6.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup".....68 183 6.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"......68 184 6.4. The Abstract Association "PolicySetInSystem"................68 185 6.5. Update PCIM's Weak Association "PolicyGroupInSystem"........69 186 6.6. Update PCIM's Weak Association "PolicyRuleInSystem".........70 187 6.7. The Abstract Aggregation "PolicyConditionStructure".........70 188 6.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule".....70 189 6.9. The Aggregation "PolicyConditionInPolicyCondition"..........71 190 6.10. The Abstract Aggregation "PolicyActionStructure"...........71 191 6.11. Update PCIM's Aggregation "PolicyActionInPolicyRule".......71 192 6.12. The Aggregation "PolicyActionInPolicyAction"...............71 193 6.13. The Aggregation "PolicyVariableInSimplePolicyCondition"....72 194 6.14. The Aggregation "PolicyValueInSimplePolicyCondition".......72 195 6.15. The Aggregation "PolicyVariableInSimplePolicyAction".......73 196 6.16. The Aggregation "PolicyValueInSimplePolicyAction"..........74 197 6.17. The Association "ReusablePolicy"...........................74 198 6.18. Deprecate PCIM's "PolicyConditionInPolicyRepository".......75 199 6.19. Deprecate PCIM's "PolicyActionInPolicyRepository"..........75 200 6.20. The Association ExpectedPolicyValuesForVariable............75 201 6.21. The Aggregation "ContainedDomain"..........................76 202 6.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"......76 203 6.23. The Aggregation "EntriesInFilterList"......................76 204 6.23.1. The Reference GroupComponent.............................77 205 6.23.2. The Reference PartComponent..............................77 206 6.23.3. The Property EntrySequence...............................77 207 6.24. The Aggregation "ElementInPolicyRoleCollection"............77 208 6.25. The Weak Association "PolicyRoleCollectionInSystem"........78 209 7. Intellectual Property............................................79 210 8. Acknowledgements.................................................79 211 9. Security Considerations..........................................79 212 10. References......................................................79 213 11. Authors' Addresses..............................................80 214 12. Full Copyright Statement........................................82 215 13. Appendix A: Closed Issues.......................................82 217 1. Introduction 219 This document (PCIM Extensions, abbreviated here to PCIMe) proposes a 220 number of changes to the Policy Core Information Model (PCIM, RFC 3060 221 [3]). These changes include both extensions of PCIM into areas that it 222 did not previously cover, and changes to the existing PCIM classes and 223 associations. Both sets of changes are done in a way that, to the extent 224 possible, preserves interoperability with implementations of the original 225 PCIM model. 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in RFC 2119, reference [1]. 231 2. Overview of the Changes 233 2.1. How to Change an Information Model 235 The Policy Core Information Model is closely aligned with the DMTF's CIM 236 Core Policy model. Since there is no separately documented set of rules 237 for specifying IETF information models such as PCIM, it is reasonable to 238 look to the CIM specifications for guidance on how to modify and extend 239 the model. Among the CIM rules for changing an information model are the 240 following. Note that everything said here about "classes" applies to 241 association classes (including aggregations) as well as to non- 242 association classes. 244 o Properties may be added to existing classes. 245 o Classes, and individual properties, may be marked as DEPRECATED. 246 If there is a replacement feature for the deprecated class or 247 property, it is identified explicitly. Otherwise the notation "No 248 value" is used. In this document, the notation "DEPRECATED FOR 249 " is used to indicate that a feature has been 250 deprecated, and to identify its replacement feature. 251 o Classes may be inserted into the inheritance hierarchy above 252 existing classes, and properties from the existing classes may 253 then be "pulled up" into the new classes. The net effect is that 254 the existing classes have exactly the same properties they had 255 before, but the properties are inherited rather than defined 256 explicitly in the classes. 257 o New subclasses may be defined below existing classes. 259 2.2. List of Changes to the Model 261 The following subsections provide a very brief overview of the changes to 262 PCIM defined in PCIMe. In several cases, the origin of the change is 263 noted, as QPIM [5], ICPM [6], or QDDIM [14]. 265 2.2.1. Changes to PolicyRepository 267 Because of the potential for confusion with the Policy Framework 268 component Policy Repository (from the four-box picture: Policy Management 269 Tool, Policy Repository, PDP, PEP), "PolicyRepository" is a bad name for 270 the PCIM class representing a container of reusable policy elements. 271 Thus the class PolicyRepository is being replaced with the class 272 ReusablePolicyContainer. To accomplish this change, it is necessary to 273 deprecate the PCIM class PolicyRepository and its three associations, and 274 replace them with a new class ReusablePolicyContainer and new 275 associations. 277 As a separate change, the associations for ReusablePolicyContainer are 278 being broadened, to allow a ReusablePolicyContainer to contain any 279 reusable policy elements. In PCIM, the only associations defined for a 280 PolicyRepository were for it to contain reusable policy conditions and 281 policy actions. 283 2.2.2. Additional Associations and Additional Reusable Elements 285 The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations have, 286 in effect, been imported from QPIM. ("In effect" because these two 287 aggregations, as well as PCIM'e two aggregations PolicyGroupInPolicyGroup 288 and PolicyRuleInPolicyGroup, are all being combined into a single 289 aggregation PolicySetComponent.) These aggregations make it possible to 290 define larger "chunks" of reusable policy to place in a 291 ReusablePolicyContainer. These aggregations also introduce new semantics 292 representing the contextual implications of having one PolicyRule 293 executing within the scope of another PolicyRule. 295 2.2.3. Priorities and Decision Strategies 297 Drawing from both QPIM and ICPM, the Priority property has been 298 deprecated in PolicyRule, and placed instead on the aggregation 299 PolicySetComponent. The QPIM rules for resolving relative priorities 300 across nested PolicyGroups and PolicyRules have been incorporated into 301 PCIMe as well. With the removal of the Priority property from 302 PolicyRule, a new modeling dependency is introduced. In order to 303 prioritize a PolicyRule/PolicyGroup relative to other 304 PolicyRules/PolicyGroups, the elements being prioritized must all reside 305 in one of three places: in a common PolicyGroup, in a common PolicyRule, 306 or in a common System. 308 In the absence of any clear, general criterion for detecting policy 309 conflicts, the PCIM restriction stating that priorities are relevant only 310 in the case of conflicts is being removed. In its place, a 311 PolicyDecisionStrategy property has been added to the PolicyGroup and 312 PolicyRule classes. This property allows policy administrator to select 313 one of two behaviors with respect to rule evaluation: either perform the 314 actions for all PolicyRules whose conditions evaluate to TRUE, or perform 315 the actions only for the highest-priority PolicyRule whose conditions 316 evaluate to TRUE. (This is accomplished by placing the 317 PolicyDecisionStrategy property in an abstract class PolicySet, from 318 which PolicyGroup and PolicyRule are derived.) The QPIM rules for 319 applying decision strategies to a nested set of PolicyGroups and 320 PolicyRules have also been imported. 322 2.2.4. Policy Roles 324 The concept of policy roles is added to PolicyGroups (being present 325 already in the PolicyRule class). This is accomplished via a new 326 superclass for both PolicyRules and PolicyGroups - PolicySet. For nested 327 PolicyRules and PolicyGroups, any roles associated with the outer rule or 328 group are automatically "inherited" by the nested one. Additional roles 329 may be added at the level of a nested rule or group. 331 It was also observed that there is no mechanism in PCIM for assigning 332 roles to resources. For example, while it is possible in PCIM to 333 associate a PolicyRule with the role "FrameRelay&&WAN", there is no way 334 to indicate which interfaces match this criterion. A new 335 PolicyRoleCollection class has been defined in PCIMe, representing the 336 collection of resources associated with a particular role. The linkage 337 between a PolicyRule or PolicyGroup and a set of resources is then 338 represented by an instance of PolicyRoleCollection. Equivalent values 339 should be defined in the PolicyRoles property of PolicyRules and 340 PolicyGroups, and in the PolicyRole property in PolicyRoleCollection. 342 2.2.5. CompoundPolicyConditions and CompoundPolicyActions 344 The concept of a CompoundPolicyCondition has also been imported into 345 PCIMe from QPIM, and broadened to include a parallel 346 CompoundPolicyAction. In both cases the idea is to create reusable 347 "chunks" of policy that can exist as named elements in a 348 ReusablePolicyContainer. The "Compound" classes and their associations 349 incorporate the condition and action semantics that PCIM defined at the 350 PolicyRule level: DNF/CNF for conditions, and ordering for actions. 352 Compound conditions and actions are defined to work with any component 353 conditions and actions. In other words, while the components may be 354 instances, respectively, of SimplePolicyCondition and SimplePolicyAction 355 (discussed immediately below), they need not be. 357 2.2.6. Variables and Values 359 The SimplePolicyCondition / PolicyVariable / PolicyValue structure has 360 been imported into PCIMe from QPIM. A list of PCIMe-level variables is 361 defined, as well as a list of PCIMe-level values. Other variables and 362 values may, if necessary, be defined in submodels of PCIMe. For example, 363 QPIM defines a set of implicit variables corresponding to fields in RSVP 364 flows. 366 A corresponding SimplePolicyAction / PolicyVariable / PolicyValue 367 structure is also defined. While the semantics of a 368 SimplePolicyCondition are "variable matches value", a SimplePolicyAction 369 has the semantics "set variable to value". 371 2.2.7. Domain-Level Packet Filtering 373 For packet filtering specified at the domain level, a set of 374 PolicyVariables and PolicyValues are defined, corresponding to the fields 375 in an IP packet header plus the most common Layer 2 frame header fields. 376 It is expected that domain-level policy conditions that filter on these 377 header fields will be expressed in terms of CompoundPolicyConditions 378 built up from SimplePolicyConditions that use these variables and values. 379 An additional PolicyVariable, PacketDirection, is also defined, to 380 indicate whether a packet being filtered is traveling inbound or outbound 381 on an interface. 383 2.2.8. Device-Level Packet Filtering 385 For packet filtering expressed at the device level, including the packet 386 classifier filters modeled in QDDIM, the variables and values discussed 387 in Section 2.2.7 need not be used. Filter classes derived from the CIM 388 FilterEntryBase class hierarchy are available for use in these contexts. 389 These latter classes have two important differences from the domain-level 390 classes: 392 o They support specification of filters for all of the fields in a 393 particular protocol header in a single object instance. With the 394 domain-level classes, separate instances are needed for each 395 header field. 396 o They provide native representations for the filter values, as 397 opposed to the string representation used by the domain-level 398 classes. 400 Device-level filter classes for the IP-related headers (IP, UDP, and TCP) 401 and the 802 MAC headers are defined, respectively, in sections 5.19 and 402 5.20. 404 3. The Updated Class and Association Class Hierarchies 406 The following figure shows the class inheritance hierarchy for PCIMe. 407 Changes from the PCIM hierarchy are noted parenthetically. 409 ManagedElement (abstract) 410 | 411 +--Policy (abstract) 412 | | 413 | +---PolicySet (abstract -- new - 4.3) 414 | | | 415 | | +---PolicyGroup (moved - 4.3) 416 | | | 417 | | +---PolicyRule (moved - 4.3) 418 | | 419 | +---PolicyCondition (abstract) 420 | | | 421 | | +---PolicyTimePeriodCondition 422 | | | 423 | | +---VendorPolicyCondition 424 | | | 425 | | +---SimplePolicyCondition (new - 4.8.1) 426 | | | 427 | | +---CompoundPolicyCondition (new - 4.7.1) 428 | | | 429 | | +---CompoundFilterCondition (new - 4.9) 430 | | 431 | +---PolicyAction (abstract) 432 | | | 433 | | +---VendorPolicyAction 434 | | | 435 | | +---SimplePolicyAction (new - 4.8.4) 436 | | | 437 | | +---CompoundPolicyAction (new - 4.7.2) 438 | | 439 | +---PolicyVariable (abstract -- new - 4.8.5) 440 | | | 441 | | +---PolicyExplicitVariable (new - 4.8.6) 442 | | | 443 | | +---PolicyImplicitVariable (abstract -- new - 4.8.7) 444 | | | 445 | | +---(subtree of more specific classes -- new - 5.12) 446 | | 447 | +---PolicyValue (abstract -- new - 4.8.10) 448 | | 449 | +---(subtree of more specific classes -- new - 5.14) 450 | 451 +--Collection (abstract -- newly referenced) 452 | | 453 | +--PolicyRoleCollection (new - 4.6.2) 454 (continued on following page) 455 (continued from previous page) 456 ManagedElement(abstract) 457 | 458 +--ManagedSystemElement (abstract) 459 | 460 +--LogicalElement (abstract) 461 | 462 +--System (abstract) 463 | | 464 | +--AdminDomain (abstract) 465 | | 466 | +---ReusablePolicyContainer (new - 4.2) 467 | | 468 | +---PolicyRepository (deprecated - 4.2) 469 | 470 +--FilterEntryBase (abstract -- new - 5.18) 471 | | 472 | +--IpHeadersFilter (new - 5.19) 473 | | 474 | +--8021Filter (new - 5.20) 475 | 476 +--FilterList (new - 5.21) 478 Figure 1. Class Inheritance Hierarchy for PCIMe 479 The following figure shows the association class hierarchy for PCIMe. As 480 before, changes from PCIM are noted parenthetically. 482 [unrooted] 483 | 484 +---PolicyComponent (abstract) 485 | | 486 | +---PolicySetComponent (new - 4.3) 487 | | 488 | +---PolicyGroupInPolicyGroup (deprecated - 4.3) 489 | | 490 | +---PolicyRuleInPolicyGroup (deprecated - 4.3) 491 | | 492 | +---PolicyConditionStructure (abstract -- new - 4.7.1) 493 | | | 494 | | +---PolicyConditionInPolicyRule (moved - 4.7.1) 495 | | | 496 | | +---PolicyConditionInPolicyCondition (new - 4.7.1) 497 | | 498 | +---PolicyRuleValidityPeriod 499 | | 500 | +---PolicyActionStructure (abstract -- new - 4.7.2) 501 | | | 502 | | +---PolicyActionInPolicyRule (moved - 4.7.2) 503 | | | 504 | | +---PolicyActionInPolicyAction (new - 4.7.2) 505 | | 506 | +---PolicyVariableInSimplePolicyCondition (new - 4.8.2) 507 | | 508 | +---PolicyValueInSimplePolicyCondition (new - 4.8.2) 509 | | 510 | +---PolicyVariableInSimplePolicyAction (new - 4.8.4) 511 | | 512 | +---PolicyValueInSimplePolicyAction (new - 4.8.4) 514 (continued on following page) 515 (continued from previous page) 516 [unrooted] 517 | 518 +---Dependency (abstract) 519 | | 520 | +---PolicyInSystem (abstract) 521 | | | 522 | | +---PolicySetInSystem (abstract, new - 4.3) 523 | | | | 524 | | | +---PolicyGroupInSystem 525 | | | | 526 | | | +---PolicyRuleInSystem 527 | | | 528 | | +---ReusablePolicy (new - 4.2) 529 | | | 530 | | +---PolicyConditionInPolicyRepository (deprecated - 4.2) 531 | | | 532 | | +---PolicyActionInPolicyRepository (deprecated - 4.2) 533 | | 534 | +---ExpectedPolicyValuesForVariable (new - 4.8) 535 | | 536 | +---PolicyRoleCollectionInSystem (new - 4.6.2) 537 | 538 +---Component (abstract) 539 | | 540 | +---SystemComponent 541 | | | 542 | | +---ContainedDomain (new - 4.2) 543 | | | 544 | | +---PolicyRepositoryInPolicyRepository (deprecated - 4.2) 545 | | 546 | +---EntriesInFilterList (new - 6.23) 547 | 548 +---MemberOfCollection (newly referenced) 549 | 550 +--- ElementInPolicyRoleCollection (new - 4.6.2) 552 Figure 2. Association Class Inheritance Hierarchy for PCIMe 554 In addition to these changes that show up at the class and association 555 class level, there are other changes from PCIM involving individual class 556 properties. In some cases new properties are introduced into existing 557 classes, and in other cases existing properties are deprecated (without 558 deprecating the classes that contain them). 560 4. Areas of Extension to PCIM 562 The following subsections describe each of the areas for which PCIM 563 extensions are being defined. 565 4.1. Policy Scope 567 Policy scopes may be thought of in two dimensions: 1) the level of 568 abstraction of the policy specification and 2) the applicability of 569 policies to a set of managed resources. 571 4.1.1. Levels of Abstraction: Domain- and Device-Level Policies 573 Policies vary in level of abstraction, from the business-level expression 574 of service level agreements (SLAs) to the specification of a set of rules 575 that apply to devices in a network. Those latter policies can, 576 themselves, be classified into at least two groups: those policies 577 consumed by a Policy Decision Point (PDP) that specify the rules for an 578 administrative and functional domain, and those policies consumed by a 579 Policy Enforcement Point (PEP) that specify the device-specific rules for 580 a functional domain. The higher-level rules consumed by a PDP, called 581 domain-level policies, may have late binding variables unspecified, or 582 specified by a classification, whereas the device-level rules are likely 583 to have fewer unresolved bindings. 585 There is a relationship between these levels of policy specification that 586 is out of scope for this standards effort, but that is necessary in the 587 development and deployment of a usable policy-based configuration system. 588 An SLA-level policy transformation to the domain-level policy may be 589 thought of as analogous to a visual builder that takes human input and 590 develops a programmatic rule specification. The relationship between the 591 domain-level policy and the device-level policy may be thought of as 592 analogous to that of a compiler and linkage editor that translates the 593 rules into specific instructions that can be executed on a specific type 594 of platform. 596 PCIM and PCIMe may be used to specify rules at any and all of these 597 levels of abstraction. However, at different levels of abstraction, 598 different mechanisms may be more or less appropriate. 600 4.1.2. Administrative and Functional Scopes 602 Administrative scopes for policy are represented in PCIM and in these 603 extensions to PCIM as System subclass instances. Typically, a domain- 604 level policy would be scoped by an AdminDomain instance (or by a 605 hierarchy of AdminDomain instances) whereas a device-level policy might 606 be scoped by a System instance that represents the PEP (e.g., an instance 607 of ComputerSystem, see CIM [4]). In addition to collecting policies into 608 an administrative domain, these System classes may also aggregate the 609 resources to which the policies apply. 611 Functional scopes (sometimes referred to as functional domains) are 612 generally defined by the submodels derived from PCIM and PCIMe, and 613 correspond to the service or services to which the policies apply. So, 614 for example, Quality of Service may be thought of as a functional scope, 615 or Diffserv and Intserv may each be thought of as functional scopes. 616 These scoping decisions are represented by the structure of the submodels 617 derived from PCIM and PCIMe, and may be reflected in the number and types 618 of PEP policy client(s), services, and the interaction between policies. 619 Policies in different functional scopes are organized into disjoint sets 620 of policy rules. Different functional domains may share some roles, some 621 conditions, and even some actions. The rules from different functional 622 domains may even be enforced at the same managed resource, but for the 623 purposes of policy evaluation they are separate. See section 4.5.3 for 624 more information. 626 The functional scopes MAY be reflected in administrative scopes. That 627 is, deployments of policy may have different administrative scopes for 628 different functional scopes, but there is no requirement to do so. 630 4.2. Reusable Policy Elements 632 In PCIM, a distinction was drawn between reusable PolicyConditions and 633 PolicyActions and rule-specific ones. The PolicyRepository class was 634 also defined, to serve as a container for these reusable elements. The 635 name "PolicyRepository" has proven to be an unfortunate choice for the 636 class that serves as a container for reusable policy elements. This term 637 is already used in documents like the Policy Framework, to denote the 638 location from which the PDP retrieves all policy specifications, and into 639 which the Policy Management Tool places all policy specifications. 640 Consequently, the PolicyRepository class is being deprecated, in favor of 641 a new class ReusablePolicyContainer. 643 When a class is deprecated, any associations that refer to it must also 644 be deprecated. So replacements are needed for the two associations 645 PolicyConditionInPolicyRepository and PolicyActionInPolicyRepository, as 646 well as for the aggregation PolicyRepositoryInPolicyRepository. In 647 addition to renaming the PolicyRepository class to 648 ReusablePolicyContainer, however, PCIMe is also broadening the types of 649 policy elements that can be reusable. Consequently, rather than 650 providing one-for-one replacements for the two associations, a single 651 higher-level association ReusablePolicy is defined. This new association 652 allows any policy element (that is, an instance of any subclass of the 653 abstract class Policy) to be placed in a ReusablePolicyContainer. 655 Summarizing, the following changes in Sections 5 and 6 are the result of 656 this item: 658 o The class ReusablePolicyContainer is defined. 659 o PCIM's PolicyRepository class is deprecated. 660 o The association ReusablePolicy is defined. 661 o PCIM's PolicyConditionInPolicyRepository association is deprecated. 662 o PCIM's PolicyActionInPolicyRepository association is deprecated. 663 o The aggregation ContainedDomain is defined. 664 o PCIM's PolicyRepositoryInPolicyRepository aggregation is deprecated. 666 4.3. Policy Sets 668 A "policy" can be thought of as a coherent set of rules to administer, 669 manage, and control access to network resources ("Policy Terminology", 670 reference [12]). The structuring of these coherent sets of rules into 671 subsets is enhanced in this document. In Section 4.4, we discuss the new 672 options for the nesting of policy rules. 674 A new abstract class, PolicySet, is introduced to provide an abstraction 675 for a set of rules. It is derived from Policy, and it is inserted into 676 the inheritance hierarchy above both PolicyGroup and PolicyRule. This 677 reflects the additional structural flexibility and semantic capability of 678 both subclasses. 680 Two properties are defined in PolicySet: PolicyDecisionStrategy and 681 PolicyRoles. The PolicyDecisionStrategy property is included in 682 PolicySet to define the evaluation relationship among the rules in the 683 policy set. See Section 4.5 for more information. The PolicyRoles 684 property is included in PolicySet to characterize the resources to which 685 the PolicySet applies. See Section 4.6 for more information. 687 Along with the definition of the PolicySet class, a new concrete 688 aggregation class is defined that will also be discussed in the following 689 sections. PolicySetComponent is defined as a subclass of 690 PolicyComponent; it provides the containment relationship for a PolicySet 691 in a PolicySet. PolicySetComponent replaces the two PCIM aggregations 692 PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, so these two 693 aggregations are deprecated. 695 A PolicySet's relationship to an AdminDomain or other administrative 696 scoping system (for example, a ComputerSystem) is represented by the 697 PolicySetInSystem abstract association. This new association is derived 698 from PolicyInSystem, and the PolicyGroupInSystem and PolicyRuleInSystem 699 associations are now derived from PolicySetInSystem instead of directly 700 from PolicyInSystem. The PolicySetInSystem.Priority property is 701 discussed in Section 4.5.3. 703 4.4. Nested Policy Rules 705 As previously discussed, policy is described by a set of policy rules 706 that may be grouped into subsets. In this section we introduce the 707 notion of nested rules, or the ability to define rules within rules. 708 Nested rules are also called sub-rules, and we use both terms in this 709 document interchangeably. The aggregation PolicySetComponent is used to 710 represent the nesting of a policy rule in another policy rule. 712 4.4.1. Usage Rules for Nested Rules 714 The relationship between rules and sub-rules is defined as follows: 716 o The parent rule's condition clause is a condition for evaluation 717 of all nested rules; that is, the conditions of the parent are 718 logically ANDed to the conditions of the sub-rules. If the parent 719 rule's condition clause evaluates to FALSE, sub-rules MAY be 720 skipped since they also evaluate to FALSE. 721 o If the parent rule's condition evaluates to TRUE, the set of sub- 722 rules SHALL BE evaluated according to the decision strategy and 723 priorities as discussed in Section 4.5. 724 o If the parent rule's condition evaluates to TRUE, the parent 725 rule's set of actions is executed BEFORE execution of the sub- 726 rules� actions. The parent rule's actions are not to be confused 727 with default actions. A default action is one that is to be 728 executed only if none of the more specific sub-rules are executed. 729 If a default action needs to be specified, it needs to be defined 730 as an action that is part of a catchall sub-rule associated with 731 the parent rule. The association linking the default action(s) in 732 this special sub-rule should have the lowest priority relative to 733 all other sub-rule associations: 735 if parent-condition then parent rule's action 736 if condA then actA 737 if condB then ActB 738 if True then default action 740 Such a default action functions as a default when FirstMatching 741 decision strategies are in effect (see section 4.5). If 742 AllMatching applies, the "default" action is always performed. 744 o Policy rules have a context in which they are executed. The rule 745 engine evaluates and applies the policy rules in the context of 746 the managed resource(s) that are identified by the policy roles 747 (or by an explicit association). Submodels MAY add additional 748 context to policy rules based on rule structure; any such 749 additional context is defined by the semantics of the action 750 classes of the submodel. 752 4.4.2. Motivation 754 Rule nesting enhances Policy readability, expressiveness and reusability. 755 The ability to nest policy rules and form sub-rules is important for 756 manageability and scalability, as it enables complex policy rules to be 757 constructed from multiple simpler policy rules. These enhancements ease 758 the policy management tools' task, allowing policy rules to be expressed 759 in a way closer to how humans think. 761 Although rule nesting can be used to suggest optimizations in the way 762 policy rules are evaluated, as discussed in section 4.5.2 "Side Effects," 763 nesting does not specify nor does it require any particular order of 764 evaluation of conditions. Optimization of rule evaluation can be done in 765 the PDP or in the PEP by dedicated code. This is similar to the relation 766 between a high level programming language like C and machine code. An 767 optimizer can create a more efficient machine code than any optimization 768 done by the programmer within the source code. Nevertheless, if the PEP 769 or PDP does not do optimization, the administrator writing the policy may 770 be able to influence the evaluation of the policy rules for execution 771 using rule nesting. 773 Nested rules are not designed for policy repository retrieval 774 optimization. It is assumed that all rules and groups that are assigned 775 to a role are retrieved by the PDP or PEP from the policy repository and 776 enforced. Optimizing the number of rules retrieved should be done by 777 clever selection of roles. 779 4.5. Priorities and Decision Strategies 781 A "decision strategy" is used to specify the evaluation method for the 782 policies in a PolicySet. Two decision strategies are defined: 783 "FirstMatching" and "AllMatching." The FirstMatching strategy is used to 784 cause the evaluation of the rules in a set such that the only actions 785 enforced on a given examination of the PolicySet are those for the first 786 rule (that is, the rule with the highest priority) that has its 787 conditions evaluate to TRUE. The AllMatching strategy is used to cause 788 the evaluation of all rules in a set; for all of the rules whose 789 conditions evaluate to TRUE, the actions are enforced. Implementations 790 MUST support the FirstMatching decision strategy; implementations MAY 791 support the AllMatching decision strategy. 793 As previously discussed, the PolicySet subclasses are PolicyGroup and 794 PolicyRule: either subclass may contain PolicySets of either subclass. 795 Loops, including the degenerate case of a PolicySet that contains itself, 796 are not allowed when PolicySets contain other PolicySets. The 797 containment relationship is specified using the PolicySetComponent 798 aggregation. 800 The relative priority within a PolicySet is established by the Priority 801 property of the PolicySetComponent aggregation of the contained 802 PolicyGroup and PolicyRule instances. The use of PCIM's 803 PolicyRule.Priority property is deprecated in favor of this new property. 804 The separation of the priority property from the rule has two advantages. 805 First, it generalizes the concept of priority, so that it can be used for 806 both groups and rules. Second, it places the priority on the 807 relationship between the parent policy set and the subordinate policy 808 group or rule. The assignment of a priority value then becomes much 809 easier, in that the value is used only in relationship to other 810 priorities in the same set. 812 Together, the PolicySet.PolicyDecisionStrategy and 813 PolicySetComponent.Priority determine the processing for the rules 814 contained in a PolicySet. As before, the larger priority value 815 represents the higher priority. Unlike the earlier definition, 816 PolicySetComponent.Priority MUST have a unique value when compared with 817 others defined for the same aggregating PolicySet. Thus, the evaluation 818 of rules within a set is deterministically specified. 820 For a FirstMatching decision strategy, the first rule (that is, the one 821 with the highest priority) in the set that evaluates to True, is the only 822 rule whose actions are enforced for a particular evaluation pass through 823 the PolicySet. 825 For an AllMatching decision strategy, all of the matching rules are 826 enforced. The relative priority of the rules is used to determine the 827 order in which the actions are to be executed by the enforcement point: 828 the actions of the higher priority rules are executed first. Since the 829 actions of higher priority rules are executed first, lower priority rules 830 that also match may get the "last word," and thus produce a counter- 831 intuitive result. So, for example, if two rules both evaluate to True, 832 and the higher priority rule sets the DSCP to 3 and the lower priority 833 rule sets the DSCP to 4, the action of the lower priority rule will be 834 executed later and, therefore, will "win," in this example, setting the 835 DSCP to 4. Thus, conflicts between rules are resolved by this execution 836 order. 838 An implementation of the rule engine need not provide the action 839 sequencing but the actions MUST be sequenced by the PEP or PDP on its 840 behalf. So, for example, the rule engine may provide an ordered list of 841 actions to be executed by the PEP and any required serialization is then 842 provided by the service configured by the rule engine. See section 4.5.2 843 for a discussion of side effects. 845 4.5.1. Structuring Decision Strategies 847 As discussed in Sections 4.3 and 4.4, PolicySet instances may be nested 848 arbitrarily. For a FirstMatching decision strategy on a PolicySet, any 849 contained PolicySet that matches satisfies the termination criteria for 850 the FirstMatching strategy. A PolicySet is considered to match if it is 851 a PolicyRule and its conditions evaluate to True, or if the PolicySet is 852 a PolicyGroup and at least one of its contained PolicyGroups or 853 PolicyRules match. The priority associated with contained PolicySets, 854 then, determines when to terminate rule evaluation in the structured set 855 of rules. 857 In the example shown in Figure 3, the relative priorities for the nested 858 rules, high to low, are 1A, 1B1, 1X2, 1B3, 1C, 1C1, 1X2 and 1C3. (Note 859 that PolicyRule 1X2 is included in both PolicyGroup 1B and PolicyRule 1C, 860 but with different priorities.) Of course, which rules are enforced is 861 also dependent on which rules, if any, match. 863 PolicyGroup 1: FirstMatching 864 | 865 +-- Pri=6 -- PolicyRule 1A 866 | 867 +-- Pri=5 -- PolicyGroup 1B: AllMatching 868 | | 869 | +-- Pri=5 -- PolicyGroup 1B1: AllMatching 870 | | | 871 | | +---- etc. 872 | | 873 | +-- Pri=4 -- PolicyRule 1X2 874 | | 875 | +-- Pri=3 -- PolicyRule 1B3: FirstMatching 876 | | 877 | +---- etc. 878 | 879 +-- Pri=4 -- PolicyRule 1C: FirstMatching 880 | 881 +-- Pri=4 -- PolicyRule 1C1 882 | 883 +-- Pri=3 -- PolicyRule 1X2 884 | 885 +-- Pri=2 -- PolicyRule 1C3 887 Figure 3. Nested PolicySets with Different Decision Strategies 889 o Because PolicyGroup 1 has a FirstMatching decision strategy, if 890 the conditions of PolicyRule 1A match, its actions are enforced 891 and the evaluation stops. 893 o If it does not match, PolicyGroup 1B is evaluated using an 894 AllMatching strategy. Since PolicyGroup 1B1 also has an 895 AllMatching strategy all of the rules and groups of rules 896 contained in PolicyGroup 1B1 are evaluated and enforced as 897 appropriate. PolicyRule 1X2 and PolicyRule 1B3 are also evaluated 898 and enforced as appropriate. If any of the sub-rules in the 899 subtrees of PolicyGroup 1B evaluate to True, then PolicyRule 1C is 900 not evaluated because the FirstMatching strategy of PolicyGroup 1 901 has been satisfied. 903 o If neither PolicyRule 1A nor PolicyGroup 1B yield a match, then 904 PolicyRule 1C is evaluated. Since it is first matching, rules 905 1C1, 1X2, and 1C3 are evaluated until the first match, if any. 907 4.5.2. Side Effects 909 Although evaluation of conditions is sometimes discussed as an ordered 910 set of operations, the rule engine need not be implemented as a 911 procedural language interpreter. Any side effects of condition evaluation 912 or the execution of actions MUST NOT affect the result of the evaluation 913 of other conditions evaluated by the rule engine in the same evaluation 914 pass. That is, an implementation of a rule engine MAY evaluate all 915 conditions in any order before applying the priority and determining 916 which actions are to be executed. 918 So, regardless of how a rule engine is implemented, it MUST NOT include 919 any side effects of condition evaluation in the evaluation of conditions 920 for either of the decision strategies. For both the AllMatching decision 921 strategy and for the nesting of rules within rules (either directly or 922 indirectly) where the actions of more than one rule may be enforced, any 923 side effects of the enforcement of actions MUST NOT be included in 924 condition evaluation on the same evaluation pass. 926 4.5.3. Multiple PolicySet Trees For a Resource 928 As shown in the example in Figure 3. , PolicySet trees are defined by the 929 PolicySet subclass instances and the PolicySetComponent aggregation 930 instances between them. Each PolicySet tree has a defined set of 931 decision strategies and evaluation priorities. In section 4.6 we discuss 932 some improvements in the use of PolicyRoles that cause the parent 933 PolicySet.PolicyRoles to be applied to all contained PolicySet instances. 934 However, a given resource may still have multiple, disjoint PolicySet 935 trees regardless of how they are collected. These top-level PolicySet 936 instances are called "unrooted" relative to the given resource. 938 So, a PolicySet instance is defined to be rooted or unrooted in the 939 context of a particular managed element; the relationship to the managed 940 element is usually established by the policy roles of the PolicySet 941 instance and of the managed element (see 4.6 "Policy Roles"). A 942 PolicySet instance is unrooted in that context if and only if there is no 943 PolicySetComponent association to a parent PolicySet that is also related 944 to the same managed element. These PolicySetComponent aggregations are 945 traversed up the tree without regard to how a PolicySet instance came to 946 be related with the ManagedElement. Figure 4. shows an example where 947 instance A has role A, instance B has role B and so on. In this example, 948 in the context of interface X, instances B, and C are unrooted and 949 instances D, E, and F are all rooted. In the context of interface Y, 950 instance A is unrooted and instances B, C, D, E and F are all rooted. 952 +---+ +-----------+ +-----------+ 953 | A | | I/F X | | I/F Y | 954 +---+ | has roles | | has roles | 955 / \ | B & C | | A & B | 956 / \ +-----------+ +-----------+ 957 +---+ +---+ 958 | B | | C | 959 +---+ +---+ 960 / \ \ 961 / \ \ 962 +---+ +---+ +---+ 963 | D | | E | | F | 964 +---+ +---+ +---+ 966 Figure 4. Unrooted PolicySet Instances 968 For those cases where there are multiple unrooted PolicySet instances 969 that apply to the same managed resource (i.e., not in a common 970 PolicySetComponent tree), the decision strategy among these disjoint 971 PolicySet instances is the FirstMatching strategy. The priority used 972 with this FirstMatching strategy is defined in the PolicySetInSystem 973 association. The PolicySetInSystem subclass instances are present for all 974 PolicySet instances (it is a required association) but the priority is 975 only used as a default for unrooted PolicySet instances in a given 976 ManagedElement context. 978 The FirstMatching strategy is used among all unrooted PolicySet instances 979 that apply to a given resource for a given functional domain. So, for 980 example, the PolicySet instances that are used for QoS policy and the 981 instances that are used for IKE policy, although they are disjoint, are 982 not joined in a FirstMatching decision strategy. Instead, they are 983 evaluated independently of one another. 985 4.5.4. Deterministic Decisions 987 As previously discussed, PolicySetComponent.Priority values MUST be 988 unique within a containing PolicySet and PolicySetInSystem.Priority 989 values MUST be unique for an associated System. Each PolicySet, then, has 990 a deterministic behavior based upon the decision strategy and uniquely 991 defined priority. 993 There are certainly cases where rules need not have a unique priority 994 value (i.e., where evaluation and execution priority is not important). 995 However, it is believed that the flexibility gained by this capability is 996 not sufficiently beneficial to justify the possible variations in 997 implementation behavior and the resulting confusion that might occur. 999 4.6. Policy Roles 1001 A policy role is defined in [12] as "an administratively specified 1002 characteristic of a managed element (for example, an interface). It is a 1003 selector for policy rules and PRovisioning Classes (PRCs), to determine 1004 the applicability of the rule/PRC to a particular managed element." 1006 In PCIMe, PolicyRoles is defined as a property of PolicySet, which is 1007 inherited by both PolicyRules and PolicyGroups. In this draft, we also 1008 add PolicyRole as the identifying name of a collection of resources 1009 (PolicyRoleCollection), where each element in the collection has the 1010 specified role characteristic. 1012 4.6.1. Comparison of Roles in PCIM with Roles in snmpconf 1014 In the Configuration Management with SNMP (snmpconf) working group's 1015 Policy Based Management MIB [13], policy rules are of the form 1017 if then 1019 where is a set of conditions that are used to determine 1020 whether or not the policy applies to an object instance. The policy 1021 filter can perform comparison operations on SNMP variables already 1022 defined in MIBS (e.g., "ifType == ethernet"). 1024 The policy management MIB defined in [13] defines a Role table that 1025 enables one to associate Roles with elements, where roles have the same 1026 semantics as in PCIM. Then, since the policyFilter in a policy allows one 1027 to define conditions based on the comparison of the values of SNMP 1028 variables, one can filter elements based on their roles as defined in the 1029 Role group. 1031 This approach differs from that adopted in PCIM in the following ways. 1032 First, in PCIM, a set of role(s) is associated with a policy rule as the 1033 values of the PolicyRoles property of a policy rule. The semantics of 1034 role(s) are then expected to be implemented by the PDP (i.e. policies are 1035 applied to the elements with the appropriate roles). In [13], however, 1036 no special processing is required for realizing the semantics of roles; 1037 roles are treated just as any other SNMP variables and comparisons of 1038 role values can be included in the policy filter of a policy rule. 1040 Secondly, in PCIM, there is no formally defined way of associating a role 1041 with an object instance, whereas in [13] this is done via the use of the 1042 Role tables (pmRoleESTable and pmRoleSETable). The Role tables associate 1043 Role values with elements. 1045 4.6.2. Addition of PolicyRoleCollection to PCIMe 1047 In order to remedy the latter shortcoming in PCIM (the lack of a way of 1048 associating a role with an object instance), PCIMe has a new class 1049 PolicyRoleCollection derived from the CIM Collection class. Resources 1050 that share a common role are aggregated by a PolicyRoleCollection 1051 instance, via the ElementInPolicyRoleCollection aggregation. The role is 1052 specified in the PolicyRole property of the aggregating 1053 PolicyRoleCollection instance. 1055 A PolicyRoleCollection always exists in the context of a system. As was 1056 done in PCIM for PolicyRules and PolicyGroups, an association, 1057 PolicyRoleCollectionInSystem, captures this relationship. Remember that 1058 in CIM, System is a base class for describing network devices and 1059 administrative domains. 1061 The association between a PolicyRoleCollection and a system should be 1062 consistent with the associations that scope the policy rules/groups that 1063 are applied to the resources in that collection. Specifically, a 1064 PolicyRoleCollection should be associated with the same System as the 1065 applicable PolicyRules and/or PolicyGroups, or to a System higher in the 1066 tree formed by the SystemComponent association. When a PEP belongs to 1067 multiple Systems (i.e., AdminDomains), and scoping by a single domain is 1068 impractical, two alternatives exist. One is to arbitrarily limit domain 1069 membership to one System/AdminDomain. The other option is to define a 1070 more global AdminDomain that simply includes the others, and/or that 1071 spans the business or enterprise. 1073 As an example, suppose that there are 20 traffic trunks in a network, and 1074 that an administrator would like to assign three of them to provide 1075 "gold" service. Also, the administrator has defined several policy rules 1076 which specify how the "gold" service is delivered. For these rules, the 1077 PolicyRoles property (inherited from PolicySet) is set to "Gold Service". 1079 In order to associate three traffic trunks with "gold" service, an 1080 instance of the PolicyRoleCollection class is created and its PolicyRole 1081 property is also set to "Gold Service". Following this, the 1082 administrator associates three traffic trunks with the new instance of 1083 PolicyRoleCollection via the ElementInPolicyRoleCollection aggregation. 1084 This enables a PDP to determine that the "Gold Service" policy rules 1085 apply to the three aggregated traffic trunks. 1087 Note that roles are used to optimize policy retrieval. It is not 1088 mandatory to implement roles or, if they have been implemented, to group 1089 elements in a PolicyRoleCollection. However, if roles are used, then 1090 either the collection approach should be implemented, or elements should 1091 be capable of reporting their "pre-programmed" roles (as is done in 1092 COPS). 1094 4.6.3. Roles for PolicyGroups 1096 In PCIM, role(s) are only associated with policy rules. However, it may 1097 be desirable to associate role(s) with groups of policy rules. For 1098 example, a network administrator may want to define a group of rules that 1099 apply only to Ethernet interfaces. A policy group can be defined with a 1100 role-combination="Ethernet", and all the relevant policy rules can be 1101 placed in this policy group. (Note that in PCIMe, role(s) are made 1102 available to PolicyGroups as well as to PolicyRules by moving PCIM's 1103 PolicyRoles property up from PolicyRule to the new abstract class 1104 PolicySet. The property is then inherited by both PolicyGroup and 1105 PolicyRule.) Then every policy rule in this policy group implicitly 1106 inherits this role-combination from the containing policy group. A 1107 similar implicit inheritance applies to nested policy groups. 1109 There is no explicit copying of role(s) from container to contained 1110 entity. Obviously, this implicit inheritance of role(s) leads to the 1111 possibility of defining inconsistent role(s) (as explained in the example 1112 below); the handling of such inconsistencies is beyond the scope of 1113 PCIMe. 1115 As an example, suppose that there is a PolicyGroup PG1 that contains 1116 three PolicyRules, PR1, PR2, and PR3. Assume that PG1 has the roles 1117 "Ethernet" and "Fast". Also, assume that the contained policy rules have 1118 the role(s) shown below: 1120 +------------------------------+ 1121 | PolicyGroup PG1 | 1122 | PolicyRoles = Ethernet, Fast | 1123 +------------------------------+ 1124 | 1125 | +------------------------+ 1126 | | PolicyRule PR1 | 1127 |--------| PolicyRoles = Ethernet | 1128 | +------------------------+ 1129 | 1130 | +--------------------------+ 1131 | | PolicyRule PR2 | 1132 |--------| PolicyRoles = | 1133 | +--------------------------+ 1134 | 1135 | +------------------------+ 1136 | | PolicyRule PR3 | 1137 |--------| PolicyRoles = Slow | 1138 +------------------------+ 1140 Figure 5. Inheritance of Roles 1142 In this example, the PolicyRoles property value for PR1 is consistent 1143 with the value in PG1, and in fact, did not need to be redefined. The 1144 value of PolicyRoles for PR2 is undefined. Its roles are implicitly 1145 inherited from PG1. Lastly, the value of PolicyRoles for PR3 is "Slow". 1146 This appears to be in conflict with the role, "Fast," defined in PG1. 1147 However, whether these roles are actually in conflict is not clear. In 1148 one scenario, the policy administrator may have wanted only "Fast"- 1149 "Ethernet" rules in the policy group. In another scenario, the 1150 administrator may be indicating that PR3 applies to all "Ethernet" 1151 interfaces regardless of whether they are "Fast" or "Slow." Only in the 1152 former scenario (only "Fast"-"Ethernet" rules in the policy group) is 1153 there a role conflict. 1155 Note that it is possible to override implicitly inherited roles via 1156 appropriate conditions on a PolicyRule. For example, suppose that PR3 1157 above had defined the following conditions: 1159 (interface is not "Fast") and (interface is "Slow") 1161 This results in unambiguous semantics for PR3. 1163 4.7. Compound Policy Conditions and Compound Policy Actions 1165 Compound policy conditions and compound policy actions are introduced to 1166 provide additional reusable "chunks" of policy. 1168 4.7.1. Compound Policy Conditions 1170 A CompoundPolicyCondition is a PolicyCondition representing a Boolean 1171 combination of simpler conditions. The conditions being combined may be 1172 SimplePolicyConditions (discussed below in section 4.7), but the utility 1173 of reusable combinations of policy conditions is not necessarily limited 1174 to the case where the component conditions are simple ones. 1176 The PCIM extensions to introduce compound policy conditions are 1177 relatively straightforward. Since the purpose of the extension is to 1178 apply the DNF / CNF logic from PCIM's PolicyConditionInPolicyRule 1179 aggregation to a compound condition that aggregates simpler conditions, 1180 the following changes are required: 1182 o Create a new aggregation PolicyConditionInPolicyCondition, with the 1183 same GroupNumber and ConditionNegated properties as 1184 PolicyConditionInPolicyRule. The cleanest way to do this is to 1185 move the properties up to a new abstract aggregation superclass 1186 PolicyConditionStructure, from which the existing aggregation 1187 PolicyConditionInPolicyRule and a new aggregation 1188 PolicyConditionInPolicyCondition are derived. For now there is no 1189 need to re-document the properties themselves, since they are 1190 already documented in PCIM as part of the definition of the 1191 PolicyConditionInPolicyRule aggregation. 1192 o It is also necessary to define a concrete subclass 1193 CompoundPolicyCondition of PolicyCondition, to introduce the 1194 ConditionListType property. This property has the same function, 1195 and works in exactly the same way, as the corresponding property 1196 currently defined in PCIM for the PolicyRule class. 1198 The class and property definitions for representing compound policy 1199 conditions are below, in Section 5. 1201 4.7.2. Compound Policy Actions 1203 A compound action is a convenient construct to represent a sequence of 1204 actions to be applied as a single atomic action within a policy rule. In 1205 many cases, actions are related to each other and should be looked upon 1206 as sub-actions of one "logical" action. An example of such a logical 1207 action is "shape & mark" (i.e., shape a certain stream to a set of 1208 predefined bandwidth characteristics and then mark these packets with a 1209 certain DSCP value). This logical action is actually composed of two 1210 different QoS actions, which should be performed in a well-defined order 1211 and as a complete set. 1213 The CompoundPolicyAction construct allows one to create a logical 1214 relationship between a number of actions, and to define the activation 1215 logic associated with this logical action. 1217 The CompoundPolicyAction construct allows the reusability of these 1218 complex actions, by storing them in a ReusablePolicyContainer and reusing 1219 them in different policy rules. Note that a compound action may also be 1220 aggregated by another compound action. 1222 As was the case with CompoundPolicyCondition, the PCIM extensions to 1223 introduce compound policy actions are relatively straightforward. This 1224 time the goal is to apply the property ActionOrder from PCIM's 1225 PolicyActionInPolicyRule aggregation to a compound action that aggregates 1226 simpler actions. The following changes are required: 1228 o Create a new aggregation PolicyActionInPolicyAction, with the same 1229 ActionOrder property as PolicyActionInPolicyRule. The cleanest way 1230 to do this is to move the property up to a new abstract aggregation 1231 superclass PolicyActionStructure, from which the existing 1232 aggregation PolicyActionInPolicyRule and a new aggregation 1233 PolicyActionInPolicyAction are derived. 1234 o It is also necessary to define a concrete subclass 1235 CompoundPolicyAction of PolicyAction, to introduce the 1236 SequencedActions property. This property has the same function, 1237 and works in exactly the same way, as the corresponding property 1238 currently defined in PCIM for the PolicyRule class. 1239 o Finally, a new property ExecutionStrategy is needed for both the 1240 PCIM class PolicyRule and the new class CompoundPolicyAction. This 1241 property allows the policy administrator to specify how the PEP 1242 should behave in the case where there are multiple actions 1243 aggregated by a PolicyRule or by a CompoundPolicyAction. 1245 The class and property definitions for representing compound policy 1246 actions are below, in Section 5. 1248 4.8. Variables and Values 1250 The following subsections introduce several related concepts, including 1251 PolicyVariables and PolicyValues (and their numerous subclasses), 1252 SimplePolicyConditions, and SimplePolicyActions. 1254 4.8.1. Simple Policy Conditions 1256 The SimplePolicyCondition class models elementary Boolean expressions of 1257 the form: "( MATCH )". The relationship 'MATCH', which 1258 is implicit in the model, is interpreted based on the variable and the 1259 value. Section 4.8.3 explains the semantics of the 'MATCH' operator. 1260 Arbitrarily complex Boolean expressions can be formed by chaining 1261 together any number of simple conditions using relational operators. 1262 Individual simple conditions can be negated as well. Arbitrarily complex 1263 Boolean expressions are modeled by the class CompoundPolicyCondition 1264 (described in Section 4.7.1). 1266 For example, the expression "SourcePort == 80" can be modeled by a simple 1267 condition. In this example, 'SourcePort' is a variable, '==' is the 1268 relational operator denoting the equality relationship (which is 1269 generalized by PCIMe to a "MATCH" relationship), and '80' is an integer 1270 value. The complete interpretation of a simple condition depends on the 1271 binding of the variable. Section 4.8.5 describes variables and their 1272 binding rules. 1274 The SimplePolicyCondition class refines the basic structure of the 1275 PolicyCondition class defined in PCIM by using the pair (, 1276 ) to form the condition. Note that the operator between the 1277 variable and the value is always implied in PCIMe: it is not a part of 1278 the formal notation. 1280 The variable specifies the attribute of an object that should be matched 1281 when evaluating the condition. For example, for a QoS model, this object 1282 could represent the flow that is being conditioned. A set of predefined 1283 variables that cover network attributes commonly used for filtering is 1284 introduced in PCIMe, to encourage interoperability. This list covers 1285 layer 3 IP attributes such as IP network addresses, protocols and ports, 1286 as well as a set of layer 2 attributes (e.g., MAC addresses). 1288 The bound variable is matched against a value to produce the Boolean 1289 result. For example, in the condition "The source IP address of the flow 1290 belongs to the 10.1.x.x subnet", a source IP address variable is matched 1291 against a 10.1.x.x subnet value. 1293 4.8.2. Using Simple Policy Conditions 1295 Simple conditions can be used in policy rules directly, or as building 1296 blocks for creating compound policy conditions. 1298 Simple condition composition MUST enforce the following data-type 1299 conformance rule: The ValueTypes property of the variable must be 1300 compatible with the type of the value class used. The simplest (and 1301 friendliest, from a user point-of-view) way to do this is to equate the 1302 type of the value class with the name of the class. By ensuring that the 1303 ValueTypes property of the variable matches the name of the value class 1304 used, we know that the variable and value instance values are compatible 1305 with each other. 1307 Composing a simple condition requires that an instance of the class 1308 SimplePolicyCondition be created, and that instances of the variable and 1309 value classes that it uses also exist. Note that the variable and/or 1310 value instances may already exist as reusable objects in an appropriate 1311 ReusablePolicyContainer. 1313 Two aggregations are used in order to create the pair (, 1314 ). The aggregation PolicyVariableInSimplePolicyCondition relates 1315 a SimplePolicyCondition to a single variable instance. Similarly, the 1316 aggregation PolicyValueInSimplePolicyCondition relates a 1317 SimplePolicyCondition to a single value instance. Both aggregations are 1318 defined in this document. 1320 Figure 6. depicts a SimplePolicyCondition with its associated variable 1321 and value. Also shown are two PolicyValue instances that identify the 1322 values that the variable can assume. 1324 +-----------------------+ 1325 | SimplePolicyCondition | 1326 +-----------------------+ 1327 * @ 1328 * @ 1329 +------------------+ * @ +---------------+ 1330 | (PolicyVariable) |*** @@@| (PolicyValue) | 1331 +------------------+ +---------------+ 1332 # # 1333 # ooo # 1334 # # 1335 +---------------+ +---------------+ 1336 | (PolicyValue) | ooo | (PolicyValue) | 1337 +---------------+ +---------------+ 1339 Aggregation Legend: 1340 **** PolicyVariableInSimplePolicyCondition 1341 @@@@ PolicyValueInSimplePolicyCondition 1342 #### ExpectedPolicyValuesForVariable 1344 Figure 6. SimplePolicyCondition 1346 Note: The class names in parenthesis denote subclasses. The classes 1347 named in the figure are abstract, and thus cannot themselves be 1348 instantiated. 1350 4.8.3. The Simple Condition Operator 1352 A simple condition models an elementary Boolean expression of the form 1353 "variable MATCHes value". However, the formal notation of the 1354 SimplePolicyCondition, together with its associations, models only a 1355 pair, (, ). The 'MATCH' operator is not directly 1356 modeled -- it is implied. Furthermore, this implied 'MATCH' operator 1357 carries overloaded semantics. 1359 For example, in the simple condition "DestinationPort MATCH '80'", the 1360 interpretation of the 'MATCH' operator is equality (the 'equal' 1361 operator). Clearly, a different interpretation is needed in the 1362 following cases: 1364 o "DestinationPort MATCH {'80', '8080'}" -- operator is 'IS SET 1365 MEMBER' 1367 o "DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER 1368 RANGE' 1370 o "SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP ADDRESS 1371 AS RESOLVED BY DNS' 1373 The examples above illustrate the implicit, context-dependant nature of 1374 the 'MATCH' operator. The interpretation depends on the actual variable 1375 and value instances in the simple condition. The interpretation is 1376 always derived from the bound variable and the value instance associated 1377 with the simple condition. Text accompanying the value class and 1378 implicit variable definition is used for interpreting the semantics of 1379 the 'MATCH' relationship. In the following list, we define generic 1380 (type-independent) matching. 1382 PolicyValues may be multi-fielded, where each field may contain a range 1383 of values. The same equally holds for PolicyVariables. Basically, we 1384 have to deal with single values (singleton), ranges ([lower bound .. 1385 upper bound]), and sets (a,b,c). So independent of the variable and 1386 value type, the following set of generic matching rules for the 'MATCH' 1387 operator are defined. 1389 o singleton matches singleton -> the matching rule is defined in the 1390 type 1392 o singleton matches range [lower bound .. upper bound] -> the 1393 matching evaluates to true, if the singleton matches the lower 1394 bound or the upper bound or a value in between 1396 o singleton matches set -> the matching evaluates to true, if the 1397 value of the singleton matches one of the components in the set, 1398 where a component may be a singleton or range again 1400 o ranges [A..B] matches singleton -> is true if A matches B matches 1401 singleton 1403 o range [A..B] matches range [X..Y] -> the matching evaluates to 1404 true, if all values of the range [A..B] are also in the range 1405 [X..Y]. For instance, [3..5] match [1..6] evaluates to true, 1406 whereas [3..5] match [4..6] evaluates to false. 1408 o range [A..B] matches set (a,b,c, ...) -> the matching evaluates to 1409 true, if all values in the range [A..B] are part of the set. For 1410 instance, range [2..3] match set ([1..2],3) evaluates to true, as 1411 well as range [2..3] match set (2,3), and range [2..3] match set 1412 ([1..2],[3..5]). 1414 o set (a,b,c, ...) match singleton -> is true if a match b match c 1415 match ... match singleton 1417 o set match range -> the matching evaluates to true, if all values 1418 in the set are part of the range. For example, set (2,3) match 1419 range [1..4] evaluates to true. 1421 o set (a,b,c,...) match set (x,y,z,...) -> the matching evaluates to 1422 true, if all values in the set (a,b,c,...) are part of the set 1423 (x,y,z,...). For example, set (1,2,3) match set (1,2,3,4) 1424 evaluates to true. Set (1,2,3) match set (1,2) evaluates to 1425 false. 1427 Variables may contain various types (section 5.11.1). When not stated 1428 otherwise, the type of the value bound to the variable at condition 1429 evaluation time and the value type of the PolicyValue instance need to be 1430 of the same type. If they differ, then the condition evaluates to FALSE. 1432 The ExpectedPolicyValuesForVariable association specifies an expected set 1433 of values that can be matched with a variable within a simple condition. 1434 Using this association, a source or destination port can be limited to 1435 the range 0-200, a source or destination IP address can be limited to a 1436 specified list of IPv4 address values, etc. 1438 +-----------------------+ 1439 | SimplePolicyCondition | 1440 +-----------------------+ 1441 * @ 1442 * @ 1443 * @ 1444 +-----------------------------------+ +--------------------------+ 1445 | Name=SmallSourcePorts | | Name=Port300 | 1446 | Class=PolicySourcePortVariable | | Class=PolicyIntegerValue | 1447 | ValueTypes=[PolicyIntegerVariable]| | IntegerList = [300] | 1448 +-----------------------------------+ +--------------------------+ 1449 # 1450 # 1451 # 1452 +-------------------------+ 1453 |Name=SmallPortsValues | 1454 |Class=PolicyIntegerValue | 1455 |IntegerList=[1..200] | 1456 +-------------------------+ 1458 Aggregation Legend: 1459 **** PolicyVariableInSimplePolicyCondition 1460 @@@@ PolicyValueInSimplePolicyCondition 1461 #### ExpectedPolicyValuesForVariable 1463 Figure 7. An Invalid SimplePolicyCondition 1464 The ability to express these limitations appears in the model to support 1465 validation of a SimplePolicyCondition prior to its deployment to an 1466 enforcement point. A Policy Management Tool, for example SHOULD NOT 1467 accept the SimplePolicyCondition shown in Figure 7. If, however, a 1468 policy rule containing this condition does appear at an enforcement 1469 point, the expected values play no role in the determination of whether 1470 the condition evaluates to True or False. Thus in this example, the 1471 SimplePolicyCondition evaluates to True if the source port for the packet 1472 under consideration is 300, and it evaluates to False otherwise. 1474 4.8.4. SimplePolicyActions 1476 The SimplePolicyAction class models the elementary set operation. "SET 1477 TO ". The set operator MUST overwrite an old value of 1478 the variable. In the case where the variable to be updated is multi- 1479 valued, the only update operation defined is a complete replacement of 1480 all previous values with a new set. In other words, there are no Add or 1481 Remove [to/from the set of values] operations defined for 1482 SimplePolicyActions. 1484 For example, the action "set DSCP to EF" can be modeled by a simple 1485 action. In this example, 'DSCP' is an implicit variable referring to the 1486 IP packet header DSCP field. 'EF' is an integer or bit string value (6 1487 bits). The complete interpretation of a simple action depends on the 1488 binding of the variable. 1490 The SimplePolicyAction class refines the basic structure of the 1491 PolicyAction class defined in PCIM, by specifying the contents of the 1492 action using the (, ) pair to form the action. The 1493 variable specifies the attribute of an object. The value of this 1494 attribute is set to the value specified in . Selection of the 1495 object is a function of the type of variable involved. See Sections 1496 4.8.6 and 4.8.7, respectively, for details on object selection for 1497 explicitly bound and implicitly bound policy variables. 1499 SimplePolicyActions can be used in policy rules directly, or as building 1500 blocks for creating CompoundPolicyActions. 1502 The set operation is only valid if the list of types of the variable 1503 (ValueTypes property of PolicyImplicitVariable) includes the specified 1504 type of the value. Conversion of values from one representation into 1505 another is not defined. For example, a variable of IPv4Address type may 1506 not be set to a string containing a DNS name. Conversions are part of an 1507 implementation-specific mapping of the model. 1509 As was the case with SimplePolicyConditions, the role of expected values 1510 for the variables that appear in SimplePolicyActions is for validation, 1511 prior to the time when an action is executed. Expected values play no 1512 role in action execution. 1514 Composing a simple action requires that an instance of the class 1515 SimplePolicyAction be created, and that instances of the variable and 1516 value classes that it uses also exist. Note that the variable and/or 1517 value instances may already exist as reusable objects in an appropriate 1518 ReusablePolicyContainer. 1520 Two aggregations are used in order to create the pair (, 1521 ). The aggregation PolicyVariableInSimplePolicyAction relates a 1522 SimplePolicyAction to a single variable instance. Similarly, the 1523 aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction 1524 to a single value instance. Both aggregations are defined in this 1525 document. 1527 Figure 8. depicts a SimplePolicyAction with its associated variable and 1528 value. 1530 +-----------------------+ 1531 | SimplePolicyAction | 1532 | | 1533 +-----------------------+ 1534 * @ 1535 * @ 1536 +------------------+ * @ +---------------+ 1537 | (PolicyVariable) |*** @@@| (PolicyValue) | 1538 +------------------+ +---------------+ 1539 # # 1540 # ooo # 1541 # # 1542 +---------------+ +---------------+ 1543 | (PolicyValue) | ooo | (PolicyValue) | 1544 +---------------+ +---------------+ 1546 Aggregation Legend: 1547 **** PolicyVariableInSimplePolicyAction 1548 @@@@ PolicyValueInSimplePolicyAction 1549 #### ExpectedPolicyValuesForVariable 1551 Figure 8. SimplePolicyAction 1553 4.8.5. Policy Variables 1555 A variable generically represents information that changes (or "varies"), 1556 and that is set or evaluated by software. In policy, conditions and 1557 actions can abstract information as "policy variables" to be evaluated in 1558 logical expressions, or set by actions. 1560 PCIMe defines two types of PolicyVariables, PolicyImplicitVariables and 1561 PolicyExplicitVariables. The semantic difference between these classes 1562 is based on modeling context. Explicit variables are bound to exact 1563 model constructs, while implicit variables are defined and evaluated 1564 outside of a model. For example, one can imagine a PolicyCondition 1565 testing whether a CIM ManagedSystemElement's Status property has the 1566 value "Error." The Status property is an explicitly defined 1567 PolicyVariable (i.e., it is defined in the context of the CIM Schema, and 1568 evaluated in the context of a specific instance). On the other hand, 1569 network packets are not explicitly modeled or instantiated, since there 1570 is no perceived value (at this time) in managing at the packet level. 1571 Therefore, a PolicyCondition can make no explicit reference to a model 1572 construct that represents a network packet's source address. In this 1573 case, an implicit PolicyVariable is defined, to allow evaluation or 1574 modification of a packet's source address. 1576 4.8.6. Explicitly Bound Policy Variables 1578 Explicitly bound policy variables indicate the class and property names 1579 of the model construct to be evaluated or set. The CIM Schema defines 1580 and constrains "appropriate" values for the variable (i.e., model 1581 property) using data types and other information such as class/property 1582 qualifiers. 1584 A PolicyExplicitVariable is "explicit" because its model semantics are 1585 exactly defined. It is NOT explicit due to an exact binding to a 1586 particular object instance. If PolicyExplicitVariables were tied to 1587 instances (either via associations or by an object identification 1588 property in the class itself), then we would be forcing element-specific 1589 rules. On the other hand, if we only specify the object's model context 1590 (class and property name), but leave the binding to the policy framework 1591 (for example, using policy roles), then greater flexibility results for 1592 either general or element-specific rules. 1594 For example, an element-specific rule is obtained by a condition 1595 ((, ) pair) that defines CIM LogicalDevice 1596 DeviceID="12345". Alternately, if a PolicyRule's PolicyRoles is "edge 1597 device" and the condition ((, ) pair) is Status="Error", 1598 then a general rule results for all edge devices in error. 1600 Currently, the only binding for a PolicyExplicitVariable defined in PCIMe 1601 is to the instances selected by policy roles. For each such instance, a 1602 SimplePolicyCondition that aggregates the PolicyExplicitVariable 1603 evaluates to True if and only if ALL of the following are true: 1605 o The instance selected is of the class identified by the variable's 1606 ModelClass property, or of a subclass of this class. 1607 o The instance selected has the property identified by the 1608 variable's ModelProperty property. 1609 o The value of this property in the instance matches the value 1610 specified in the PolicyValue aggregated by the condition. 1612 In all other cases, the SimplePolicyCondition evaluates to False. 1614 For the case where a SimplePolicyAction aggregates a 1615 PolicyExplicitVariable, the indicated property in the selected instance 1616 is set to the value represented by the PolicyValue that the 1617 SimplePolicyAction also aggregates. However, if the selected instance is 1618 not of the class identified by the variable's ModelClass property, or of 1619 a subclass of this class, then the action is not performed. In this case 1620 the SimplePolicyAction is not treated either as a successfully executed 1621 action (for the execution strategy Do Until Success) or as a failed 1622 action (for the execution strategy Do Until Failure). Instead, the 1623 remaining actions for the policy rule, if any, are executed as if this 1624 SimplePolicyAction were not present at all in the list of actions 1625 aggregated by the rule. 1627 Explicit variables would be more powerful if they could reach beyond the 1628 instances selected by policy roles, to related instances. However, to 1629 represent a policy rule involving such variables in any kind of general 1630 way requires something that starts to resemble very much a complete 1631 policy language. Clearly such a language is outside the scope of PCIMe, 1632 although it might be the subject of a future draft. 1634 By restricting much of the generality, it would be possible for explicit 1635 variables in PCIMe to reach slightly beyond a selected instance. For 1636 example, if a selected instance were related to exactly one instance of 1637 another class via a particular association class, and if the goal of the 1638 policy rule were both to test a property of this related instance and to 1639 set a property of that same instance, then it would be possible to 1640 represent the condition and action of the rule using 1641 PolicyExplicitVariables. Rather than handling this one specific case 1642 with explicit variables, though, it was decided to lump them with the 1643 more general case, and deal with them if and when a policy language is 1644 defined. 1646 Refer to Section 5.10 for the formal definition of the class 1647 PolicyExplicitVariable. 1649 4.8.7. Implicitly Bound Policy Variables 1651 Implicitly bound policy variables define the data type and semantics of a 1652 variable. This determines how the variable is bound to a value in a 1653 condition or an action. Further instructions are provided for specifying 1654 data type and/or value constraints for implicitly bound variables. 1656 PCIMe introduces an abstract class, PolicyImplicitVariable, to model 1657 implicitly bound variables. This class is derived from the abstract 1658 class PolicyVariable also defined in PCIMe. Each of the implicitly bound 1659 variables introduced by PCIMe (and those that are introduced by domain- 1660 specific sub-models) MUST be derived from the PolicyImplicitVariable 1661 class. The rationale for using this mechanism for modeling is explained 1662 below in Section 4.8.9. 1664 A domain-specific policy information model that extends PCIMe may define 1665 additional implicitly bound variables either by deriving them directly 1666 from the class PolicyImplicitVariable, or by further refining an existing 1667 variable class such as SourcePort. When refining a class such as 1668 SourcePort, existing binding rules, type or value constraints may be 1669 narrowed. 1671 4.8.8. Structure and Usage of Pre-Defined Variables 1673 A class derived from PolicyImplicitVariable to model a particular 1674 implicitly bound variable SHOULD be constructed so that its name depicts 1675 the meaning of the variable. For example, a class defined to model the 1676 source port of a TCP/UDP flow SHOULD have 'SourcePort' in its name. 1678 PCIMe defines one association and one general-purpose mechanism that 1679 together characterize each of the implicitly bound variables that it 1680 introduces: 1682 1. The ExpectedPolicyValuesForVariable association defines the set of 1683 value classes that could be matched to this variable. 1685 2. The list of constraints on the values that the PolicyVariable can 1686 hold (i.e., values that the variable must match) are defined by 1687 the appropriate properties of an associated PolicyValue class. 1689 In the example presented above, a PolicyImplicitVariable represents the 1690 SourcePort of incoming traffic. The ValueTypes property of an instance 1691 of this class will hold the class name PolicyIntegerValue. This by 1692 itself constrains the data type of the SourcePort instance to be an 1693 integer. However, we can further constrain the particular values that 1694 the SourcePort variable can hold by entering valid ranges in the 1695 IntegerList property of the PolicyIntegerValue instance (0 - 65535 in 1696 this document). 1698 The combination of the VariableName and the 1699 ExpectedPolicyValuesForVariable association provide a consistent and 1700 extensible set of metadata that define the semantics of variables that 1701 are used to form policy conditions. Since the 1702 ExpectedPolicyValuesForVariable association points to a PolicyValue 1703 instance, any of the values expressible in the PolicyValue class can be 1704 used to constrain values that the PolicyImplicitVariable can hold. For 1705 example: 1707 o The ValueTypes property can be used to ensure that only proper 1708 classes are used in the expression. For example, the SourcePort 1709 variable will not be allowed to ever be of type 1710 PolicyIPv4AddrValue, since source ports have different semantics 1711 than IP addresses and may not be matched. However, integer value 1712 types are allowed as the property ValueTypes holds the string 1713 "PolicyIntegerValue", which is the class name for integer values. 1715 o The ExpectedPolicyValuesForVariable association also ensures that 1716 variable-specific semantics are enforced (e.g., the SourcePort 1717 variable may include a constraint association to a value object 1718 defining a specific integer range that should be matched). 1720 4.8.9. Rationale for Modeling Implicit Variables as Classes 1722 An implicitly bound variable can be modeled in one of several ways, 1723 including a single class with an enumerator for each individual 1724 implicitly bound variable and an abstract class extended for each 1725 individual variable. The reasons for using a class inheritance mechanism 1726 for specifying individual implicitly bound variables are these: 1728 1. It is easy to extend. A domain-specific information model can 1729 easily extend the PolicyImplicitVariable class or its subclasses 1730 to define domain-specific and context-specific variables. For 1731 example, a domain-specific QoS policy information model may 1732 introduce an implicitly bound variable class to model applications 1733 by deriving a qosApplicationVariable class from the 1734 PolicyImplicitVariable abstract class. 1736 2. Introduction of a single structural class for implicitly bound 1737 variables would have to include an enumerator property that 1738 contains all possible individual implicitly bound variables. This 1739 means that a domain-specific information model wishing to 1740 introduce an implicitly bound variable must extend the enumerator 1741 itself. This results in multiple definitions of the same class, 1742 differing in the values available in the enumerator class. One 1743 definition, in this document, would include the common implicitly 1744 bound variables' names, while a second definition, in the domain- 1745 specific information model document, may include additional values 1746 ('qosApplicationVariable' in the example above). It wouldn�t even 1747 be obvious to the application developer that multiple class 1748 definitions existed. It would be harder still for the application 1749 developer to actually find the correct class to use. 1751 3. In addition, an enumerator-based definition would require each 1752 additional value to be registered with IANA to ascertain adherence 1753 to standards. This would make the process cumbersome. 1755 4. A possible argument against the inheritance mechanism would cite 1756 the fact that this approach results in an explosion of class 1757 definitions compared to an enumerator class, which only introduces 1758 a single class. While, by itself, this is not a strike against 1759 the approach, it may be argued that data models derived from this 1760 information model may be more difficult to optimize for 1761 applications. This argument is rejected on the grounds that 1762 application optimization is of lesser value for an information 1763 model than clarity and ease of extension. In addition, it is hard 1764 to claim that the inheritance model places an absolute burden on 1765 the optimization. For example, a data model may still use 1766 enumeration to denote instances of pre-defined variables and claim 1767 PCIMe compliance, as long as the data model can be mapped 1768 correctly to the definitions specified in this document. 1770 4.8.10. Policy Values 1772 The abstract class PolicyValue is used for modeling values and constants 1773 used in policy conditions. Different value types are derived from this 1774 class, to represent the various attributes required. Extensions of the 1775 abstract class PolicyValue, defined in this document, provide a list of 1776 values for basic network attributes. Values can be used to represent 1777 constants as named values. Named values can be kept in a reusable policy 1778 container to be reused by multiple conditions. Examples of constants 1779 include well-known ports, well-known protocols, server addresses, and 1780 other similar concepts. 1782 The PolicyValue subclasses define three basic types of values: scalars, 1783 ranges and sets. For example, a well-known port number could be defined 1784 using the PolicyIntegerValue class, defining a single value (80 for 1785 HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively. 1786 For details, please see the class definition for each value type in 1787 Section 5.14 of this document. 1789 PCIMe defines the following subclasses of the abstract class PolicyValue: 1791 Classes for general use: 1793 - PolicyStringValue, 1794 - PolicyIntegerValue, 1795 - PolicyBitStringValue 1796 - PolicyBooleanValue. 1798 Classes for layer 3 Network values: 1800 - PolicyIPv4AddrValue, 1801 - PolicyIPv6AddrValue. 1803 Classes for layer 2 Network values: 1805 - PolicyMACAddrValue. 1807 For details, please see the class definition section of each class in 1808 Section 5.14 of this document. 1810 4.9. Packet Filtering 1812 PCIMe contains two mechanisms for representing packet filters. The more 1813 general of these, termed here the domain-level model, expresses packet 1814 filters in terms of policy variables and policy values. The other 1815 mechanism, termed here the device-level model, expresses packet filters 1816 in a way that maps more directly to the packet fields to which the 1817 filters are being applied. While it is possible to map between these two 1818 representations of packet filters, no mapping is provided in PCIMe 1819 itself. 1821 4.9.1. Domain-Level Packet Filters 1823 In addition to filling in the holes in the overall Policy infrastructure, 1824 PCIMe proposes a single mechanism for expressing domain-level packet 1825 filters in policy conditions. This is being done in response to concerns 1826 that even though the initial "wave" of submodels derived from PCIM were 1827 all filtering on IP packets, each was doing it in a slightly different 1828 way. PCIMe proposes a common way to express IP packet filters. The 1829 following figure illustrates how packet-filtering conditions are 1830 expressed in PCIMe. 1832 +---------------------------------+ 1833 | CompoundFilterCondition | 1834 | - IsMirrored boolean | 1835 | - ConditionListType (DNF|CNF) | 1836 +---------------------------------+ 1837 + + + 1838 + + + 1839 + + + 1840 SimplePC SimplePC SimplePC 1841 * @ * @ * @ 1842 * @ * @ * @ 1843 * @ * @ * @ 1844 FlowDirection "In" SrcIP DstIP 1846 Aggregation Legend: 1847 ++++ PolicyConditionInPolicyCondition 1848 **** PolicyVariableInSimplePolicyCondition 1849 @@@@ PolicyValueInSimplePolicyCondition 1851 Figure 9. Packet Filtering in Policy Conditions 1853 In Figure 9. , each SimplePolicyCondition represents a single field to be 1854 filtered on: Source IP address, Destination IP address, Source port, etc. 1855 An additional SimplePolicyCondition indicates the direction that a packet 1856 is traveling on an interface: inbound or outbound. Because of the 1857 FlowDirection condition, care must be taken in aggregating a set of 1858 SimplePolicyConditions into a CompoundFilterCondition. Otherwise, the 1859 resulting CompoundPolicyCondition may match all inbound packets, or all 1860 outbound packets, when this is probably not what was intended. 1862 Individual SimplePolicyConditions may be negated when they are aggregated 1863 by a CompoundFilterCondition. 1865 CompoundFilterCondition is a subclass of CompoundPolicyCondition. It 1866 introduces one additional property, the Boolean property IsMirrored. The 1867 purpose of this property is to allow a single CompoundFilterCondition to 1868 match packets traveling in both directions on a higher-level connection 1869 such as a TCP session. When this property is TRUE, additional packets 1870 match a filter, beyond those that would ordinarily match it. An example 1871 will illustrate how this property works. 1873 Suppose we have a CompoundFilterCondition that aggregates the following 1874 three filters, which are ANDed together: 1876 o FlowDirection = "In" 1877 o Source IP = 9.1.1.1 1878 o Source Port = 80 1880 Regardless of whether IsMirrored is TRUE or FALSE, inbound packets will 1881 match this CompoundFilterCondition if their Source IP address = 9.1.1.1 1882 and their Source port = 80. If IsMirrored is TRUE, however, an outbound 1883 packet will also match the CompoundFilterCondition if its Destination IP 1884 address = 9.1.1.1 and its Destination port = 80. 1886 IsMirrored "flips" the following Source/Destination packet header fields: 1888 o FlowDirection "In" / FlowDirection "Out" 1889 o Source IP address / Destination IP address 1890 o Source port / Destination port 1891 o Source MAC address / Destination MAC address 1892 o Source [layer-2] SAP / Destination [layer-2] SAP. 1894 4.9.2. Device-Level Packet Filters 1896 At the device level, packet header filters are represented by two 1897 subclasses of the abstract class FilterEntryBase: IpHeadersFilter and 1898 8021Filter. Submodels of PCIMe may define other subclasses of 1899 FilterEntryBase in addition to these two; ICPM [6], for example, defines 1900 subclasses for IPsec-specific filters. 1902 Instances of the subclasses of FilterEntryBase are not used directly as 1903 filters. They are always aggregated into a FilterList, by the 1904 aggregation EntriesInFilterList. For PCIMe and its submodels, the 1905 EntrySequence property in this aggregation always takes its default value 1906 '0', indicating that the aggregated filter entries are ANDed together. 1908 The FilterList class includes an enumeration property Direction, 1909 representing the direction of the traffic flow to which the FilterList is 1910 to be applied. The value Mirrored(4) for Direction represents exactly 1911 the same thing as the IsMirrored boolean does in CompoundFilterCondition. 1912 See Section 4.9.1 for details. 1914 4.10. Conformance to PCIM and PCIMe 1916 Because PCIM and PCIMe provide the core classes for modeling policies, 1917 they are not in general sufficient by themselves for representing actual 1918 policy rules. Submodels, such as QPIM and ICPM, provide the means for 1919 expressing policy rules, by defining subclasses of the classes defined in 1920 PCIM and PCIMe, and/or by indicating how the PolicyVariables and 1921 PolicyValues defined in PCIMe can be used to express conditions and 1922 actions applicable to the submodel. 1924 A particular submodel will not, in general, need to use every element 1925 defined in PCIM and PCIMe. For the elements it does not use, a submodel 1926 SHOULD remain silent on whether its implementations must support the 1927 element, must not support the element, should support the element, etc. 1928 For the elements it does use, a submodel SHOULD indicate which elements 1929 its implementations must support, which elements they should support, and 1930 which elements they may support. 1932 PCIM and PCIMe themselves simply define elements that may be of use to 1933 submodels. These documents remain silent on whether implementations are 1934 required to support an element, should support it, etc. 1936 This model (and derived submodels) defines conditions and actions that 1937 are used by policy rules. While the conditions and actions defined 1938 herein are straightforward and may be presumed to be widely supported, as 1939 submodels are developed it is likely that situations will arise in which 1940 specific conditions or actions are not supported by some part of the 1941 policy execution system. Similarly, situations may also occur where 1942 rules contain syntactic or semantic errors. 1944 It should be understood that the behavior and effect of undefined or 1945 incorrectly defined conditions or actions is not prescribed by this 1946 information model. While it would be helpful if it were prescribed, the 1947 variations in implementation restrict the ability for this information 1948 model to control the effect. For example, if an implementation only 1949 detected that a PEP could not enforce a given action on that PEP, it 1950 would be very difficult to declare that such a failure should affect 1951 other PEPs, or the PDP process. On the other hand, if the PDP determines 1952 that it cannot properly evaluate a condition, that failure may well 1953 affect all applications of the containing rules. 1955 5. Class Definitions 1957 The following definitions supplement those in PCIM itself. PCIM 1958 definitions that are not DEPRECATED here are still current parts of the 1959 overall Policy Core Information Model. 1961 5.1. The Abstract Class "PolicySet" 1963 PolicySet is an abstract class that may group policies into a structured 1964 set of policies. 1966 NAME PolicySet 1967 DESCRIPTION An abstract class that represents a set of policies 1968 that form a coherent set. The set of contained 1969 policies has a common decision strategy and a common 1970 set of policy roles. Subclasses include PolicyGroup 1971 and PolicyRule. 1972 DERIVED FROM Policy 1973 ABSTRACT TRUE 1974 PROPERTIES PolicyDecisionStrategy 1975 PolicyRoles 1977 The PolicyDecisionStrategy property specifies the evaluation method for 1978 policy groups and rules contained within the policy set. 1980 NAME PolicyDecisionStrategy 1981 DESCRIPTION The evaluation method used for policies contained in 1982 the PolicySet. FirstMatching enforces the actions of 1983 the first rule that evaluates to TRUE; AllMatching 1984 enforces the actions of all rules that evaluate to 1985 TRUE. 1986 SYNTAX uint16 1987 VALUES 1 [FirstMatching], 2 [AllMatching] 1988 DEFAULT VALUE 1 [FirstMatching] 1990 The definition of PolicyRoles is unchanged from PCIM. It is, however, 1991 moved from the class Policy up to the superclass PolicySet. 1993 5.2. Update PCIM's Class "PolicyGroup" 1995 The PolicyGroup class is moved, so that it is now derived from PolicySet. 1997 NAME PolicyGroup 1998 DESCRIPTION A container for a set of related PolicyRules and 1999 PolicyGroups. 2000 DERIVED FROM PolicySet 2001 ABSTRACT FALSE 2002 PROPERTIES (none) 2004 5.3. Update PCIM's Class "PolicyRule" 2006 The PolicyRule class is moved, so that it is now derived from PolicySet. 2007 The Priority property is also deprecated in PolicyRule, and PolicyRoles 2008 is now inherited from the parent class PolicySet. Finally, a new 2009 property ExecutionStrategy is introduced, paralleling the property of the 2010 same name in the class CompoundPolicyAction. 2012 NAME PolicyRule 2013 DESCRIPTION The central class for representing the "If Condition 2014 then Action" semantics associated with a policy rule. 2015 DERIVED FROM PolicySet 2016 ABSTRACT FALSE 2017 PROPERTIES Enabled 2018 ConditionListType 2019 RuleUsage 2020 Priority DEPRECATED FOR PolicySetComponent.Priority 2021 AND FOR PolicySetInSystem.Priority 2022 Mandatory 2023 SequencedActions 2024 ExecutionStrategy 2025 The property ExecutionStrategy defines the execution strategy to be used 2026 upon the sequenced actions aggregated by this PolicyRule. (An equivalent 2027 ExecutionStrategy property is also defined for the CompoundPolicyAction 2028 class, to provide the same indication for the sequenced actions 2029 aggregated by a CompoundPolicyAction.) This draft defines three 2030 execution strategies: 2032 Do Until Success � execute actions according to predefined order, until 2033 successful execution of a single action. 2034 Do All - execute ALL actions which are part of the modeled 2035 set, according to their predefined order. Continue 2036 doing this, even if one or more of the actions 2037 fails. 2038 Do Until Failure - execute actions according to predefined order, until 2039 the first failure in execution of a single sub- 2040 action. 2042 The property definition is as follows: 2044 NAME ExecutionStrategy 2045 DESCRIPTION An enumeration indicating how to interpret the action 2046 ordering for the actions aggregated by this 2047 PolicyRule. 2048 SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do 2049 Until Failure} ) 2050 DEFAULT VALUE Do All (2) 2052 5.4. The Class "SimplePolicyCondition" 2054 A simple policy condition is composed of an ordered triplet: 2056 MATCH 2058 No formal modeling of the MATCH operator is provided. The 'match' 2059 relationship is implied. Such simple conditions are evaluated by 2060 answering the question: 2062 Does match ? 2064 The 'match' relationship is to be interpreted by analyzing the variable 2065 and value instances associated with the simple condition. 2067 Simple conditions are building blocks for more complex Boolean 2068 Conditions, modeled by the CompoundPolicyCondition class. 2070 The SimplePolicyCondition class is derived from the PolicyCondition class 2071 defined in PCIM. 2073 A variable and a value must be associated with a simple condition to make 2074 it a meaningful condition, using, respectively, the aggregations 2075 PolicyVariableInSimplePolicyCondition and 2076 PolicyValueInSimplePolicyCondition. 2078 The class definition is as follows: 2080 NAME SimplePolicyCondition 2081 DERIVED FROM PolicyCondition 2082 ABSTRACT False 2083 PROPERTIES (none) 2085 5.5. The Class "CompoundPolicyCondition" 2087 This class represents a compound policy condition, formed by aggregation 2088 of simpler policy conditions. 2090 NAME CompoundPolicyCondition 2091 DESCRIPTION A subclass of PolicyCondition that introduces the 2092 ConditionListType property, used for assigning DNF / 2093 CNF semantics to subordinate policy conditions. 2094 DERIVED FROM PolicyCondition 2095 ABSTRACT FALSE 2096 PROPERTIES ConditionListType 2098 The ConditionListType property is used to specify whether the list of 2099 policy conditions associated with this compound policy condition is in 2100 disjunctive normal form (DNF) or conjunctive normal form (CNF). If this 2101 property is not present, the list type defaults to DNF. The property 2102 definition is as follows: 2104 NAME ConditionListType 2105 DESCRIPTION Indicates whether the list of policy conditions 2106 associated with this policy rule is in disjunctive 2107 normal form (DNF) or conjunctive normal form (CNF). 2108 SYNTAX uint16 2109 VALUES DNF(1), CNF(2) 2110 DEFAULT VALUE DNF(1) 2112 5.6. The Class "CompoundFilterCondition" 2114 This subclass of CompoundPolicyCondition introduces one additional 2115 property, the boolean IsMirrored. This property turns on or off the 2116 "flipping" of corresponding source and destination fields in a filter 2117 specification. 2119 NAME CompoundFilterCondition 2120 DESCRIPTION A subclass of CompoundPolicyCondition that introduces 2121 the IsMirrored property. 2122 DERIVED FROM CompoundPolicyCondition 2123 ABSTRACT FALSE 2124 PROPERTIES IsMirrored 2126 The IsMirrored property indicates whether packets that "mirror" a 2127 compound filter condition should be treated as matching the filter. The 2128 property definition is as follows: 2130 NAME IsMirrored 2131 DESCRIPTION Indicates whether packets that mirror the specified 2132 filter are to be treated as matching the filter. 2133 SYNTAX boolean 2134 DEFAULT VALUE FALSE 2136 5.7. The Class "SimplePolicyAction" 2138 The SimplePolicyAction class models the elementary set operation. "SET 2139 TO ". The set operator MUST overwrite an old value of 2140 the variable. 2142 Two aggregations are used in order to create the pair . 2143 The aggregation PolicyVariableInSimplePolicyAction relates a 2144 SimplePolicyAction to a single variable instance. Similarly, the 2145 aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction 2146 to a single value instance. Both aggregations are defined in this 2147 document. 2149 NAME SimplePolicyAction 2150 DESCRIPTION A subclass of PolicyAction that introduces the notion 2151 of "SET variable TO value". 2152 DERIVED FROM PolicyAction 2153 ABSTRACT FALSE 2154 PROPERTIES (none) 2156 5.8. The Class "CompoundPolicyAction" 2158 The CompoundPolicyAction class is used to represent an expression 2159 consisting of an ordered sequence of action terms. Each action term is 2160 represented as a subclass of the PolicyAction class, defined in [PCIM]. 2161 Compound actions are constructed by associating dependent action terms 2162 together using the PolicyActionInPolicyAction aggregation. 2164 The class definition is as follows: 2166 NAME CompoundPolicyAction 2167 DESCRIPTION A class for representing sequenced action terms. Each 2168 action term is defined to be a subclass of the 2169 PolicyAction class. 2170 DERIVED FROM PolicyAction 2171 ABSTRACT FALSE 2172 PROPERTIES SequencedActions 2173 ExecutionStrategy 2175 This is a concrete class, and is therefore directly instantiable. 2177 The Property SequencedActions is identical to the SequencedActions 2178 property defined in PCIM for the class PolicyRule. 2180 The property ExecutionStrategy defines the execution strategy to be used 2181 upon the sequenced actions associated with this compound action. (An 2182 equivalent ExecutionStrategy property is also defined for the PolicyRule 2183 class, to provide the same indication for the sequenced actions 2184 associated with a PolicyRule.) This draft defines three execution 2185 strategies: 2187 Do Until Success � execute actions according to predefined order, until 2188 successful execution of a single sub-action. 2189 Do All - execute ALL actions which are part of the modeled 2190 set, according to their predefined order. Continue 2191 doing this, even if one or more of the sub-actions 2192 fails. 2193 Do Until Failure - execute actions according to predefined order, until 2194 the first failure in execution of a single sub- 2195 action. 2197 Since a CompoundPolicyAction may itself be aggregated either by a 2198 PolicyRule or by another CompoundPolicyAction, its success or failure 2199 will be an input to the aggregating entity's execution strategy. 2200 Consequently, the following rules are specified, for determining whether 2201 a CompoundPolicyAction succeeds or fails: 2203 If the CompoundPolicyAction's ExecutionStrategy is Do Until Success, 2204 then 2205 o If one component action succeeds, then the CompoundPolicyAction 2206 succeeds. 2207 o If all component actions fail, then the CompoundPolicyAction 2208 fails. 2210 If the CompoundPolicyAction's ExecutionStrategy is Do All, then 2211 o If all component actions succeed, then the CompoundPolicyAction 2212 succeeds. 2213 o If at least one component action fails, then the 2214 CompoundPolicyAction fails. 2216 If the CompoundPolicyAction's ExecutionStrategy is Do Until Failure, 2217 then 2218 o If all component actions succeed, then the CompoundPolicyAction 2219 succeeds. 2220 o If at least one component action fails, then the 2221 CompoundPolicyAction fails. 2223 The definition of the ExecutionStrategy property is as follows: 2225 NAME ExecutionStrategy 2226 DESCRIPTION An enumeration indicating how to interpret the action 2227 ordering for the actions aggregated by this 2228 CompoundPolicyAction. 2229 SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do 2230 Until Failure} ) 2231 DEFAULT VALUE Do All (2) 2232 5.9. The Abstract Class "PolicyVariable" 2234 Variables are used for building individual conditions. The variable 2235 specifies the property of a flow or an event that should be matched when 2236 evaluating the condition. However, not every combination of a variable 2237 and a value creates a meaningful condition. For example, a source IP 2238 address variable can not be matched against a value that specifies a port 2239 number. A given variable selects the set of matchable value types. 2241 A variable can have constraints that limit the set of values within a 2242 particular value type that can be matched against it in a condition. For 2243 example, a source-port variable limits the set of values to represent 2244 integers to the range of 0-65535. Integers outside this range cannot be 2245 matched to the source-port variable, even though they are of the correct 2246 data type. Constraints for a given variable are indicated through the 2247 ExpectedPolicyValuesForVariable association. 2249 The PolicyVariable is an abstract class. Implicit and explicit context 2250 variable classes are defined as sub classes of the PolicyVariable class. 2251 A set of implicit variables is defined in this document as well. 2253 The class definition is as follows: 2255 NAME PolicyVariable 2256 DERIVED FROM Policy 2257 ABSTRACT TRUE 2258 PROPERTIES (none) 2260 5.10. The Class "PolicyExplicitVariable" 2262 Explicitly defined policy variables are evaluated within the context of 2263 the CIM Schema and its modeling constructs. The PolicyExplicitVariable 2264 class indicates the exact model property to be evaluated or manipulated. 2265 See Section 4.8.6 for a complete discussion of what happens when the 2266 values of the ModelClass and ModelProperty properties in an instance of 2267 this class do not correspond to the characteristics of the model 2268 construct being evaluated or updated. 2270 The class definition is as follows: 2272 NAME PolicyExplicitVariable 2273 DERIVED FROM PolicyVariable 2274 ABSTRACT False 2275 PROPERTIES ModelClass, ModelProperty 2277 5.10.1. The Single-Valued Property "ModelClass" 2279 This property is a string specifying the class name whose property is 2280 evaluated or set as a PolicyVariable. 2282 The property is defined as follows: 2284 NAME ModelClass 2285 SYNTAX String 2287 5.10.2. The Single-Valued Property ModelProperty 2289 This property is a string specifying the property name, within the 2290 ModelClass, which is evaluated or set as a PolicyVariable. The property 2291 is defined as follows: 2293 NAME ModelProperty 2294 SYNTAX String 2296 5.11. The Abstract Class "PolicyImplicitVariable" 2298 Implicitly defined policy variables are evaluated outside of the context 2299 of the CIM Schema and its modeling constructs. Subclasses specify the 2300 data type and semantics of the PolicyVariables. 2302 Interpretation and evaluation of a PolicyImplicitVariable can vary, 2303 depending on the particular context in which it is used. For example, a 2304 "SourceIP" address may denote the source address field of an IP packet 2305 header, or the sender address delivered by an RSVP PATH message. 2307 The class definition is as follows: 2309 NAME PolicyImplicitVariable 2310 DERIVED FROM PolicyVariable 2311 ABSTRACT True 2312 PROPERTIES ValueTypes[ ] 2314 5.11.1. The Multi-Valued Property "ValueTypes" 2316 This property is a set of strings specifying an unordered list of 2317 possible value/data types that can be used in simple conditions and 2318 actions, with this variable. The value types are specified by their 2319 class names (subclasses of PolicyValue such as PolicyStringValue). The 2320 list of class names enables an application to search on a specific name, 2321 as well as to ensure that the data type of the variable is of the correct 2322 type. 2324 The list of default ValueTypes for each subclass of 2325 PolicyImplicitVariable is specified within that variable's definition. 2327 The property is defined as follows: 2329 NAME ValueTypes 2330 SYNTAX String 2331 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe 2333 The following subclasses of PolicyImplicitVariable are defined in PCIMe. 2335 5.12.1. The Class "PolicySourceIPv4Variable" 2337 NAME PolicySourceIPv4Variable 2338 DESCRIPTION The source IPv4 address. of the outermost IP packet 2339 header. "Outermost" here refers to the IP packet as 2340 it flows on the wire, before any headers have been 2341 stripped from it. 2343 ALLOWED VALUE TYPES: 2344 - PolicyIPv4AddrValue 2346 DERIVED FROM PolicyImplicitVariable 2347 ABSTRACT FALSE 2348 PROPERTIES (none) 2350 5.12.2. The Class "PolicySourceIPv6Variable" 2352 NAME PolicySourceIPv6Variable 2353 DESCRIPTION The source IPv6 address of the outermost IP packet 2354 header. "Outermost" here refers to the IP packet as 2355 it flows on the wire, before any headers have been 2356 stripped from it. 2358 ALLOWED VALUE TYPES: 2359 - PolicyIPv6AddrValue 2361 DERIVED FROM PolicyImplicitVariable 2362 ABSTRACT FALSE 2363 PROPERTIES (none) 2365 5.12.3. The Class "PolicyDestinationIPv4Variable" 2367 NAME PolicyDestinationIPv4Variable 2368 DESCRIPTION The destination IPv4 address of the outermost IP 2369 packet header. "Outermost" here refers to the IP 2370 packet as it flows on the wire, before any headers 2371 have been stripped from it. 2373 ALLOWED VALUE TYPES: 2374 - PolicyIPv4AddrValue 2376 DERIVED FROM PolicyImplicitVariable 2377 ABSTRACT FALSE 2378 PROPERTIES (none) 2380 5.12.4. The Class "PolicyDestinationIPv6Variable" 2382 NAME PolicyDestinationIPv6Variable 2383 DESCRIPTION The destination IPv6 address of the outermost IP 2384 packet header. "Outermost" here refers to the IP 2385 packet as it flows on the wire, before any headers 2386 have been stripped from it. 2388 ALLOWED VALUE TYPES: 2389 - PolicyIPv6AddrValue 2391 DERIVED FROM PolicyImplicitVariable 2392 ABSTRACT FALSE 2393 PROPERTIES (none) 2395 5.12.5. The Class "PolicySourcePortVariable" 2397 NAME PolicySourcePortVariable 2398 DESCRIPTION Ports are defined as the abstraction that transport 2399 protocols use to distinguish among multiple 2400 destinations within a given host computer. For TCP 2401 and UDP flows, the PolicySourcePortVariable is 2402 logically bound to the source port field of the 2403 outermost UDP or TCP packet header. "Outermost" here 2404 refers to the IP packet as it flows on the wire, 2405 before any headers have been stripped from it. 2407 ALLOWED VALUE TYPES: 2408 - PolicyIntegerValue (0..65535) 2410 DERIVED FROM PolicyImplicitVariable 2411 ABSTRACT FALSE 2412 PROPERTIES (none) 2414 5.12.6. The Class "PolicyDestinationPortVariable" 2416 NAME PolicyDestinationPortVariable 2417 DESCRIPTION Ports are defined as the abstraction that transport 2418 protocols use to distinguish among multiple 2419 destinations within a given host computer. For TCP 2420 and UDP flows, the PolicyDestinationPortVariable is 2421 logically bound to the destination port field of the 2422 outermost UDP or TCP packet header. "Outermost" here 2423 refers to the IP packet as it flows on the wire, 2424 before any headers have been stripped from it. 2426 ALLOWED VALUE TYPES: 2427 - PolicyIntegerValue (0..65535) 2429 DERIVED FROM PolicyImplicitVariable 2430 ABSTRACT FALSE 2431 PROPERTIES (none) 2432 5.12.7. The Class "PolicyIPProtocolVariable" 2434 NAME PolicyIPProtocolVariable 2435 DESCRIPTION The IP protocol number. 2437 ALLOWED VALUE TYPES: 2438 - PolicyIntegerValue 2440 DERIVED FROM PolicyImplicitVariable 2441 ABSTRACT FALSE 2442 PROPERTIES (none) 2444 5.12.8. The Class "PolicyIPVersionVariable" 2446 NAME PolicyIPVersionVariable 2447 DESCRIPTION The IP version number. The well-known values are 4 2448 and 6. 2450 ALLOWED VALUE TYPES: 2451 - PolicyIntegerValue 2453 DERIVED FROM PolicyImplicitVariable 2454 ABSTRACT FALSE 2455 PROPERTIES (none) 2457 5.12.9. The Class "PolicyIPToSVariable" 2459 NAME PolicyIPToSVariable 2460 DESCRIPTION The IP TOS octet. 2462 ALLOWED VALUE TYPES: 2463 - PolicyIntegerValue (0..255) 2464 - PolicyBitStringValue 2466 DERIVED FROM PolicyImplicitVariable 2467 ABSTRACT FALSE 2468 PROPERTIES (none) 2470 5.12.10. The Class "PolicyDSCPVariable" 2472 NAME PolicyDSCPVariable 2473 DESCRIPTION The 6 bit Differentiated Service Code Point. 2475 ALLOWED VALUE TYPES: 2476 - PolicyIntegerValue (0..63) 2477 - PolicyBitStringValue 2479 DERIVED FROM PolicyImplicitVariable 2480 ABSTRACT FALSE 2481 PROPERTIES (none) 2482 5.12.11. The Class "PolicyFlowIdVariable" 2484 NAME PolicyFlowIdVariable 2485 DESCRIPTION The flow identifer of the outermost IPv6 packet 2486 header. "Outermost" here refers to the IP packet as 2487 it flows on the wire, before any headers have been 2488 stripped from it. 2490 ALLOWED VALUE TYPES: 2491 - PolicyIntegerValue 2492 - PolicyBitStringValue 2494 DERIVED FROM PolicyImplicitVariable 2495 ABSTRACT FALSE 2496 PROPERTIES (none) 2498 5.12.12. The Class "PolicySourceMACVariable" 2500 NAME PolicySourceMACVariable 2501 DESCRIPTION The source MAC address. 2503 ALLOWED VALUE TYPES: 2504 - PolicyMACAddrValue 2506 DERIVED FROM PolicyImplicitVariable 2507 ABSTRACT FALSE 2508 PROPERTIES (none) 2510 5.12.13. The Class "PolicyDestinationMACVariable" 2512 NAME PolicyDestinationMACVariable 2513 DESCRIPTION The destination MAC address. 2515 ALLOWED VALUE TYPES: 2516 - PolicyMACAddrValue 2518 DERIVED FROM PolicyImplicitVariable 2519 ABSTRACT FALSE 2520 PROPERTIES (none) 2522 5.12.14. The Class "PolicyVLANVariable" 2524 NAME PolicyVLANVariable 2525 DESCRIPTION The virtual Bridged Local Area Network Identifier, a 2526 12-bit field as defined in the IEEE 802.1q standard. 2528 ALLOWED VALUE TYPES: 2529 - PolicyIntegerValue 2530 - PolicyBitStringValue 2532 DERIVED FROM PolicyImplicitVariable 2533 ABSTRACT FALSE 2534 PROPERTIES (none) 2536 5.12.15. The Class "PolicyCoSVariable" 2538 NAME PolicyCoSVariable 2539 DESCRIPTION Class of Service, a 3-bit field, used in the layer 2 2540 header to select the forwarding treatment. Bound to 2541 the IEEE 802.1q user-priority field. 2543 ALLOWED VALUE TYPES: 2544 - PolicyIntegerValue 2545 - PolicyBitStringValue 2547 DERIVED FROM PolicyImplicitVariable 2548 ABSTRACT FALSE 2549 PROPERTIES (none) 2551 5.12.16. The Class "PolicyEthertypeVariable" 2553 NAME PolicyEthertypeVariable 2554 DESCRIPTION The Ethertype protocol number of Ethernet frames. 2556 ALLOWED VALUE TYPES: 2557 - PolicyIntegerValue 2558 - PolicyBitStringValue 2560 DERIVED FROM PolicyImplicitVariable 2561 ABSTRACT FALSE 2562 PROPERTIES (none) 2564 5.12.17. The Class "PolicySourceSAPVariable" 2566 NAME PolicySourceSAPVariable 2567 DESCRIPTION The Source Service Access Point (SAP) number of the 2568 IEEE 802.2 LLC header. 2570 ALLOWED VALUE TYPES: 2571 - PolicyIntegerValue 2572 - PolicyBitStringValue 2574 DERIVED FROM PolicyImplicitVariable 2575 ABSTRACT FALSE 2576 PROPERTIES (none) 2578 5.12.18. The Class "PolicyDestinationSAPVariable" 2580 NAME PolicyDestinationSAPVariable 2581 DESCRIPTION The Destination Service Access Point (SAP) number of 2582 the IEEE 802.2 LLC header. 2584 ALLOWED VALUE TYPES: 2585 - PolicyIntegerValue 2586 - PolicyBitStringValue 2588 DERIVED FROM PolicyImplicitVariable 2589 ABSTRACT FALSE 2590 PROPERTIES (none) 2592 5.12.19. The Class "PolicySNAPVariable" 2594 NAME PolicySNAPVariable 2595 DESCRIPTION The protocol number over a Sub-Network Access Protocol 2596 (SNAP) SAP encapsulation. 2598 ALLOWED VALUE TYPES: 2599 - PolicyIntegerValue 2600 - PolicyBitStringValue 2602 DERIVED FROM PolicyImplicitVariable 2603 ABSTRACT FALSE 2604 PROPERTIES (none) 2606 5.12.20. The Class "PolicyFlowDirectionVariable" 2608 NAME PolicyFlowDirectionVariable 2609 DESCRIPTION The direction of a flow relative to a network element. 2610 Direction may be "IN" and/or "OUT". 2612 ALLOWED VALUE TYPES: 2613 - PolicyStringValue 2615 DERIVED FROM PolicyImplicitVariable 2616 ABSTRACT FALSE 2617 PROPERTIES (none) 2619 To match on both inbound and outbound flows, the associated 2620 PolicyStringValue object has two entries in its StringList property: "IN" 2621 and "OUT". 2623 5.13. The Abstract Class "PolicyValue" 2625 This is an abstract class that serves as the base class for all 2626 subclasses that are used to define value objects in the PCIMe. It is 2627 used for defining values and constants used in policy conditions. The 2628 class definition is as follows: 2630 NAME PolicyValue 2631 DERIVED FROM Policy 2632 ABSTRACT True 2633 PROPERTIES (none) 2634 5.14. Subclasses of "PolicyValue" Specified in PCIMe 2636 The following subsections contain the PolicyValue subclasses defined in 2637 PCIMe. Additional subclasses may be defined in models derived from 2638 PCIMe. 2640 5.14.1. The Class "PolicyIPv4AddrValue" 2642 This class is used to provide a list of IPv4Addresses, hostnames and 2643 address range values to be matched against in a policy condition. The 2644 class definition is as follows: 2646 NAME PolicyIPv4AddrValue 2647 DERIVED FROM PolicyValue 2648 ABSTRACT False 2649 PROPERTIES IPv4AddrList[ ] 2651 The IPv4AddrList property provides an unordered list of strings, each 2652 specifying a single IPv4 address, a hostname, or a range of IPv4 2653 addresses, according to the ABNF definition [8] of an IPv4 address, as 2654 specified below: 2656 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 2657 IPv4prefix = IPv4address "/" 1*2DIGIT 2658 IPv4range = IPv4address"-"IPv4address 2659 IPv4maskedaddress = IPv4address","IPv4address 2660 Hostname (as defined in [9]) 2662 In the above definition, each string entry is either: 2664 1. A single IPv4address in dot notation, as defined above. Example: 2665 121.1.1.2 2667 2. An IPv4prefix address range, as defined above, specified by an 2668 address and a prefix length, separated by "/". Example: 2669 2.3.128.0/15 2671 3. An IPv4range address range defined above, specified by a starting 2672 address in dot notation and an ending address in dot notation, 2673 separated by "-". The range includes all addresses between the 2674 range's starting and ending addresses, including these two 2675 addresses. Example: 1.1.22.1-1.1.22.5 2677 4. An IPv4maskedaddress address range, as defined above, specified by 2678 an address and mask. The address and mask are represented in dot 2679 notation, separated by a comma ",". The masked address appears 2680 before the comma, and the mask appears after the comma. Example: 2681 2.3.128.0,255.255.248.0. 2683 5. A single Hostname. The Hostname format follows the guidelines and 2684 restrictions specified in [9]. Example: www.bigcompany.com. 2686 Conditions matching IPv4AddrValues evaluate to true according to the 2687 generic matching rules. Additionally, a hostname is matched against 2688 another valid IPv4address representation by resolving the hostname into 2689 an IPv4 address first, and then comparing the addresses afterwards. 2690 Matching hostnames against each other is done using a string comparison 2691 of the two names. 2693 The property definition is as follows: 2695 NAME IPv4AddrList 2696 SYNTAX String 2697 FORMAT IPv4address | IPv4prefix | IPv4range | 2698 IPv4maskedaddress | hostname 2700 5.14.2. The Class "PolicyIPv6AddrValue 2702 This class is used to define a list of IPv6 addresses, hostnames, and 2703 address range values. The class definition is as follows: 2705 NAME PolicyIPv6AddrValue 2706 DERIVED FROM PolicyValue 2707 ABSTRACT False 2708 PROPERTIES IPv6AddrList[ ] 2710 The property IPv6AddrList provides an unordered list of strings, each 2711 specifying an IPv6 address, a hostname, or a range of IPv6 addresses. 2712 IPv6 address format definition uses the standard address format defined 2713 in [10]. The ABNF definition [8] as specified in [10] is: 2715 IPv6address = hexpart [ ":" IPv4address ] 2716 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 2717 IPv6prefix = hexpart "/" 1*2DIGIT 2718 hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] 2719 hexseq = hex4 *( ":" hex4) 2720 hex4 = 1*4HEXDIG 2721 IPv6range = IPv6address"-"IPv6address 2722 IPv6maskedaddress = IPv6address","IPv6address 2723 Hostname (as defines in [NAMES]) 2725 Each string entry is either: 2727 1. A single IPv6address as defined above. 2729 2. A single Hostname. Hostname format follows guidelines and 2730 restrictions specified in [9]. 2732 3. An IPv6range address range, specified by a starting address in dot 2733 notation and an ending address in dot notation, separated by "-". 2734 The range includes all addresses between the range's starting and 2735 ending addresses, including these two addresses. 2737 4. An IPv4maskedaddress address range defined above specified by an 2738 address and mask. The address and mask are represented in dot 2739 notation separated by a comma ",". 2741 5. A single IPv6prefix as defined above. 2743 Conditions matching IPv6AddrValues evaluate to true according to the 2744 generic matching rules. Additionally, a hostname is matched against 2745 another valid IPv6address representation by resolving the hostname into 2746 an IPv6 address first, and then comparing the addresses afterwards. 2747 Matching hostnames against each other is done using a string comparison 2748 of the two names. 2750 5.14.3. The Class "PolicyMACAddrValue" 2752 This class is used to define a list of MAC addresses and MAC address 2753 range values. The class definition is as follows: 2755 NAME PolicyMACAddrValue 2756 DERIVED FROM PolicyValue 2757 ABSTRACT False 2758 PROPERTIES MACAddrList[ ] 2760 The property MACAddrList provides an unordered list of strings, each 2761 specifying a MAC address or a range of MAC addresses. The 802 MAC 2762 address canonical format is used. The ABNF definition [8] is: 2764 MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG 2765 MACmaskedaddress = MACaddress","MACaddress 2767 Each string entry is either: 2769 1. A single MAC address. Example: 0000:00A5:0000 2771 2. A MACmaskedaddress address range defined specified by an address 2772 and mask. The mask specifies the relevant bits in the address. 2773 Example: 0000:00A5:0000,FFFF:FFFF:0000 defines a range of MAC 2774 addresses in which the first four octets are equal to 0000:00A5. 2776 The property definition is as follows: 2778 NAME MACAddrList 2779 SYNTAX String 2780 FORMAT MACaddress | MACmaskedaddress 2782 5.14.4. The Class "PolicyStringValue" 2784 This class is used to represent a single string value, or a set of string 2785 values. Each value can have wildcards. The class definition is as 2786 follows: 2788 NAME PolicyStringValue 2789 DERIVED FROM PolicyValue 2790 ABSTRACT False 2791 PROPERTIES StringList[ ] 2793 The property StringList provides an unordered list of strings, each 2794 representing a single string with wildcards. The asterisk character "*" 2795 is used as a wildcard, and represents an arbitrary substring replacement. 2796 For example, the value "abc*def" matches the string "abcxyzdef", and the 2797 value "abc*def*" matches the string "abcxxxdefyyyzzz". The syntax 2798 definition is identical to the substring assertion syntax defined in 2799 [11]. If the asterisk character is required as part of the string value 2800 itself, it MUST be quoted as described in section 4.3 of [11]. 2802 The property definition is as follows: 2804 NAME StringList 2805 SYNTAX String 2807 5.14.5. The Class "PolicyBitStringValue" 2809 This class is used to represent a single bit string value, or a set of 2810 bit string values. The class definition is as follows: 2812 NAME PolicyBitStringValue 2813 DERIVED FROM PolicyValue 2814 ABSTRACT False 2815 PROPERTIES BitStringList[ ] 2817 The property BitStringList provides an unordered list of strings, each 2818 representing a single bit string or a set of bit strings. The number of 2819 bits specified SHOULD equal the number of bits of the expected variable. 2820 For example, for a one-octet variable, 8 bits should be specified. If 2821 the variable does not have a fixed length, the bit string should be 2822 matched against the variable's most significant bit string. The formal 2823 definition of a bit string is: 2825 binary-digit = "0" / "1" 2826 bitString = 1*binary-digit 2827 maskedBitString = bitString","bitString 2829 Each string entry is either: 2831 1. A single bit string. Example: 00111010 2833 2. A range of bit strings specified using a bit string and a bit 2834 mask. The bit string and mask fields have the same number of bits 2835 specified. The mask bit string specifies the significant bits in 2836 the bit string value. For example, 110110, 100110 and 110111 2837 would match the maskedBitString 100110,101110 but 100100 would 2838 not. 2840 The property definition is as follows: 2842 NAME BitStringList 2843 SYNTAX String 2844 FORMAT bitString | maskedBitString 2846 5.14.6. The Class "PolicyIntegerValue" 2848 This class provides a list of integer and integer range values. Integers 2849 of arbitrary sizes can be represented. The class definition is as 2850 follows: 2852 NAME PolicyIntegerValue 2853 DERIVED FROM PolicyValue 2854 ABSTRACT False 2855 PROPERTIES IntegerList[ ] 2857 The property IntegerList provides an unordered list of integers and 2858 integer range values, represented as strings. The format of this 2859 property takes one of the following forms: 2861 1. An integer value. 2863 2. A range of integers. The range is specified by a starting integer 2864 and an ending integer, separated by '..'. The starting integer 2865 MUST be less than or equal to the ending integer. The range 2866 includes all integers between the starting and ending integers, 2867 including these two integers. 2869 To represent a range of integers that is not bounded, the reserved words 2870 -INFINITY and/or INFINITY can be used in place of the starting and ending 2871 integers. In addition to ordinary integer matches, INFINITY matches 2872 INFINITY and -INFINITY matches -INFINITY. 2874 The ABNF definition [8] is: 2876 integer = [-]1*DIGIT | "INFINITY" | "-INFINITY" 2877 integerrange = integer".."integer 2879 Using ranges, the operators greater-than, greater-than-or-equal-to, less- 2880 than, and less-than-or-equal-to can be expressed. For example, "X is- 2881 greater-than 5" (where X is an integer) can be translated to "X matches 2882 6-INFINITY". This enables the match condition semantics of the operator 2883 for the SimplePolicyCondition class to be kept simple (i.e., just the 2884 value "match"). 2886 The property definition is as follows: 2888 NAME IntegerList 2889 SYNTAX String 2890 FORMAT integer | integerrange 2891 5.14.7. The Class "PolicyBooleanValue" 2893 This class is used to represent a Boolean (TRUE/FALSE) value. The class 2894 definition is as follows: 2896 NAME PolicyBooleanValue 2897 DERIVED FROM PolicyValue 2898 ABSTRACT False 2899 PROPERTIES BooleanValue 2901 The property definition is as follows: 2903 NAME BooleanValue 2904 SYNTAX boolean 2906 5.15. The Class "PolicyRoleCollection" 2908 This class represents a collection of managed elements that share a 2909 common role. The PolicyRoleCollection always exists in the context of a 2910 system, specified using the PolicyRoleCollectionInSystem association. 2911 The value of the PolicyRole property in this class specifies the role, 2912 and can be matched with the value(s) in the PolicyRoles array in 2913 PolicyRules and PolicyGroups. ManagedElements that share the role 2914 defined in this collection are aggregated into the collection via the 2915 association ElementInPolicyRoleCollection. 2917 NAME PolicyRoleCollection 2918 DESCRIPTION A subclass of the CIM Collection class used to group 2919 together managed elements that share a role. 2920 DERIVED FROM Collection 2921 ABSTRACT FALSE 2922 PROPERTIES PolicyRole 2924 5.15.1. The Single-Valued Property "PolicyRole" 2926 This property represents the role associated with a PolicyRoleCollection. 2927 The property definition is as follows: 2929 NAME PolicyRole 2930 DESCRIPTION A string representing the role associated with a 2931 PolicyRoleCollection. 2932 SYNTAX string 2934 5.16. The Class "ReusablePolicyContainer" 2936 The new class ReusablePolicyContainer is defined as follows: 2938 NAME ReusablePolicyContainer 2939 DESCRIPTION A class representing an administratively defined 2940 container for reusable policy-related information. 2941 This class does not introduce any additional 2942 properties beyond those in its superclass AdminDomain. 2944 It does, however, participate in a number of unique 2945 associations. 2946 DERIVED FROM AdminDomain 2947 ABSTRACT FALSE 2948 PROPERTIES (none) 2950 5.17. Deprecate PCIM's Class "PolicyRepository" 2952 The class definition of PolicyRepository (from PCIM) is updated as 2953 follows, with an indication that the class has been deprecated. Note 2954 that when an element of the model is deprecated, its replacement element 2955 is identified explicitly. 2957 NAME PolicyRepository 2958 DEPRECATED FOR ReusablePolicyContainer 2959 DESCRIPTION A class representing an administratively defined 2960 container for reusable policy-related information. 2961 This class does not introduce any additional 2962 properties beyond those in its superclass AdminDomain. 2963 It does, however, participate in a number of unique 2964 associations. 2965 DERIVED FROM AdminDomain 2966 ABSTRACT FALSE 2967 PROPERTIES (none) 2969 5.18. The Abstract Class "FilterEntryBase" 2971 FilterEntryBase is the abstract base class from which all filter entry 2972 classes are derived. It serves as the endpoint for the 2973 EntriesInFilterList aggregation, which groups filter entries into filter 2974 lists. Its properties include CIM naming attributes and an IsNegated 2975 boolean property (to easily "NOT" the match information specified in an 2976 instance of one of its subclasses). 2978 The class definition is as follows: 2980 NAME FilterEntryBase 2981 DESCRIPTION An abstract class representing a single 2982 filter that is aggregated into a 2983 FilterList via the aggregation 2984 EntriesInFilterList. 2985 DERIVED FROM LogicalElement 2986 TYPE Abstract 2987 PROPERTIES IsNegated 2989 5.19. The Class "IpHeadersFilter" 2991 This concrete class contains the most commonly required properties for 2992 performing filtering on IP, TCP or UDP headers. Properties not present 2993 in an instance of IPHeadersFilter are treated as 'all values'. A 2994 property HdrIpVersion identifies whether the IP addresses in an instance 2995 are IPv4 or IPv6 addresses. Since the source and destination IP 2996 addresses come from the same packet header, they will always be of the 2997 same type. 2999 The class definition is as follows: 3001 NAME IpHeadersFilter 3002 DESCRIPTION A class representing an entire IP 3003 header filter, or any subset of one. 3004 DERIVED FROM FilterEntryBase 3005 TYPE Concrete 3006 PROPERTIES HdrIpVersion, HdrSrcAddress, HdrSrcMask, 3007 HdrDestAddress, HdrDestMask, HdrProtocolID, 3008 HdrSrcPortStart, HdrSrcPortEnd, 3009 HdrDestPortStart, HdrDestPortEnd, HdrDSCP, 3010 HdrFlowLabel 3012 5.19.1. The Property HdrIpVersion 3014 This property is an 8-bit unsigned integer, identifying the version of 3015 the IP addresses to be filtered on. IP versions are identified as they 3016 are in the Version field of the IP packet header - IPv4 = 4, IPv6 = 6. 3017 These two values are the only ones defined for this property. 3019 The value of this property determines the sizes of the OctetStrings in 3020 the four properties HdrSrcAddress, HdrSrcMask, HdrDestAddress, and 3021 HdrDestMask, as follows: 3023 o IPv4: OctetString(SIZE (4)) 3024 o IPv6: OctetString(SIZE (16|20)), depending on whether a scope 3025 identifier is present 3027 If a value for this property is not provided, then the filter does not 3028 consider IP version in selecting matching packets, i.e., IP version 3029 matches for all values. In this case, the HdrSrcAddress, HdrSrcMask, 3030 HdrDestAddress, and HdrDestMask must also not be present. 3032 5.19.2. The Property HdrSrcAddress 3034 This property is an OctetString, of a size determined by the value of the 3035 HdrIpVersion property, representing a source IP address. This value is 3036 compared to the source address in the IP header, subject to the mask 3037 represented in the HdrSrcMask property. 3039 If a value for this property is not provided, then the filter does not 3040 consider HdrSrcAddress in selecting matching packets, i.e., HdrSrcAddress 3041 matches for all values. 3043 5.19.3. The Property HdrSrcMask 3045 This property is an OctetString, of a size determined by the value of the 3046 HdrIpVersion property, representing a mask to be used in comparing the 3047 source address in the IP header with the value represented in the 3048 HdrSrcAddress property. 3050 If a value for this property is not provided, then the filter does not 3051 consider HdrSrcMask in selecting matching packets, i.e., the value of 3052 HdrSrcAddress must match the source address in the packet exactly. 3054 5.19.4. The Property HdrDestAddress 3056 This property is an OctetString, of a size determined by the value of the 3057 HdrIpVersion property, representing a destination IP address. This value 3058 is compared to the destination address in the IP header, subject to the 3059 mask represented in the HdrDestMask property. 3061 If a value for this property is not provided, then the filter does not 3062 consider HdrDestAddress in selecting matching packets, i.e., 3063 HdrDestAddress matches for all values. 3065 5.19.5. The Property HdrDestMask 3067 This property is an OctetString, of a size determined by the value of the 3068 HdrIpVersion property, representing a mask to be used in comparing the 3069 destination address in the IP header with the value represented in the 3070 HdrDestAddress property. 3072 If a value for this property is not provided, then the filter does not 3073 consider HdrDestMask in selecting matching packets, i.e., the value of 3074 HdrDestAddress must match the destination address in the packet exactly. 3076 5.19.6. The Property HdrProtocolID 3078 This property is an 8-bit unsigned integer, representing an IP protocol 3079 type. This value is compared to the Protocol field in the IP header. 3081 If a value for this property is not provided, then the filter does not 3082 consider HdrProtocolID in selecting matching packets, i.e., HdrProtocolID 3083 matches for all values. 3085 5.19.7. The Property HdrSrcPortStart 3087 This property is a 16-bit unsigned integer, representing the lower end of 3088 a range of UDP or TCP source ports. The upper end of the range is 3089 represented by the HdrSrcPortEnd property. The value of HdrSrcPortStart 3090 MUST be no greater than the value of HdrSrcPortEnd. A single port is 3091 indicated by equal values for HdrSrcPortStart and HdrSrcPortEnd. 3093 A source port filter is evaluated by testing whether the source port 3094 identified in the IP header falls within the range of values between 3095 HdrSrcPortStart and HdrSrcPortEnd, including these two end points. 3097 If a value for this property is not provided, then the filter does not 3098 consider HdrSrcPortStart in selecting matching packets, i.e., there is no 3099 lower bound in matching source port values. 3101 5.19.8. The Property HdrSrcPortEnd 3103 This property is a 16-bit unsigned integer, representing the upper end of 3104 a range of UDP or TCP source ports. The lower end of the range is 3105 represented by the HdrSrcPortStart property. The value of HdrSrcPortEnd 3106 MUST be no less than the value of HdrSrcPortStart. A single port is 3107 indicated by equal values for HdrSrcPortStart and HdrSrcPortEnd. 3109 A source port filter is evaluated by testing whether the source port 3110 identified in the IP header falls within the range of values between 3111 HdrSrcPortStart and HdrSrcPortEnd, including these two end points. 3113 If a value for this property is not provided, then the filter does not 3114 consider HdrSrcPortEnd in selecting matching packets, i.e., there is no 3115 upper bound in matching source port values. 3117 5.19.9. The Property HdrDestPortStart 3119 This property is a 16-bit unsigned integer, representing the lower end of 3120 a range of UDP or TCP destination ports. The upper end of the range is 3121 represented by the HdrDestPortEnd property. The value of 3122 HdrDestPortStart MUST be no greater than the value of HdrDestPortEnd. A 3123 single port is indicated by equal values for HdrDestPortStart and 3124 HdrDestPortEnd. 3126 A destination port filter is evaluated by testing whether the destination 3127 port identified in the IP header falls within the range of values between 3128 HdrDestPortStart and HdrDestPortEnd, including these two end points. 3130 If a value for this property is not provided, then the filter does not 3131 consider HdrDestPortStart in selecting matching packets, i.e., there is 3132 no lower bound in matching destination port values. 3134 5.19.10. The Property HdrDestPortEnd 3136 This property is a 16-bit unsigned integer, representing the upper end of 3137 a range of UDP or TCP destination ports. The lower end of the range is 3138 represented by the HdrDestPortStart property. The value of 3139 HdrDestPortEnd MUST be no less than the value of HdrDestPortStart. A 3140 single port is indicated by equal values for HdrDestPortStart and 3141 HdrDestPortEnd. 3143 A destination port filter is evaluated by testing whether the destination 3144 port identified in the IP header falls within the range of values between 3145 HdrDestPortStart and HdrDestPortEnd, including these two end points. 3147 If a value for this property is not provided, then the filter does not 3148 consider HdrDestPortEnd in selecting matching packets, i.e., there is no 3149 upper bound in matching destination port values. 3151 5.19.11. The Property HdrDSCP 3153 The property HdrDSCP is defined as a uint8, restricted to the range 3154 0..63. Since DSCPs are defined as discrete code points, with no inherent 3155 structure, there is no semantically significant relationship between 3156 different DSCPs. Consequently, there is no provision for specifying a 3157 range of DSCPs in this property. 3159 If a value for this property is not provided, then the filter does not 3160 consider HdrDSCP in selecting matching packets, i.e., HdrDSCP matches for 3161 all values. 3163 5.19.12. The Property HdrFlowLabel 3165 The 20-bit Flow Label field in the IPv6 header may be used by a source to 3166 label sequences of packets for which it requests special handling by IPv6 3167 devices, such as non-default quality of service or 'real-time' service. 3168 This property is an octet string of size 3 (that is, 24 bits), in which 3169 the 20-bit Flow Label appears in the rightmost 20 bits, padded on the 3170 left with b'0000'. 3172 If a value for this property is not provided, then the filter does not 3173 consider HdrFlowLabel in selecting matching packets, i.e., HdrFlowLabel 3174 matches for all values. 3176 5.20. The Class "8021Filter" 3178 This concrete class allows 802.1.source and destination MAC addresses, as 3179 well as the 802.1 protocol ID, priority, and VLAN identifier fields, to 3180 be expressed in a single object 3182 The class definition is as follows: 3184 NAME 8021Filter 3185 DESCRIPTION A class that allows 802.1 source 3186 and destination MAC address and 3187 protocol ID, priority, and VLAN 3188 identifier filters to be 3189 expressed in a single object. 3190 DERIVED FROM FilterEntryBase 3191 TYPE Concrete 3192 PROPERTIES 8021HdrSrcMACAddr, 8021HdrSrcMACMask, 3193 8021HdrDestMACAddr, 8021HdrDestMACMask, 3194 8021HdrProtocolID, 8021HdrPriorityValue, 3195 8021HDRVLANID 3196 5.20.1. The Property 8021HdrSrcMACAddr 3198 This property is an OctetString of size 6, representing a 48-bit source 3199 MAC address in canonical format. This value is compared to the 3200 SourceAddress field in the MAC header, subject to the mask represented in 3201 the 8021HdrSrcMACMask property. 3203 If a value for this property is not provided, then the filter does not 3204 consider 8021HdrSrcMACAddr in selecting matching packets, i.e., 3205 8021HdrSrcMACAddr matches for all values. 3207 5.20.2. The Property 8021HdrSrcMACMask 3209 This property is an OctetString of size 6, representing a 48-bit mask to 3210 be used in comparing the SourceAddress field in the MAC header with the 3211 value represented in the 8021HdrSrcMACAddr property. 3213 If a value for this property is not provided, then the filter does not 3214 consider 8021HdrSrcMACMask in selecting matching packets, i.e., the value 3215 of 8021HdrSrcMACAddr must match the source MAC address in the packet 3216 exactly. 3218 5.20.3. The Property 8021HdrDestMACAddr 3220 This property is an OctetString of size 6, representing a 48-bit 3221 destination MAC address in canonical format. This value is compared to 3222 the DestinationAddress field in the MAC header, subject to the mask 3223 represented in the 8021HdrDestMACMask property. 3225 If a value for this property is not provided, then the filter does not 3226 consider 8021HdrDestMACAddr in selecting matching packets, i.e., 3227 8021HdrDestMACAddr matches for all values. 3229 5.20.4. The Property 8021HdrDestMACMask 3231 This property is an OctetString of size 6, representing a 48-bit mask to 3232 be used in comparing the DestinationAddress field in the MAC header with 3233 the value represented in the 8021HdrDestMACAddr property. 3235 If a value for this property is not provided, then the filter does not 3236 consider 8021HdrDestMACMask in selecting matching packets, i.e., the 3237 value of 8021HdrDestMACAddr must match the destination MAC address in the 3238 packet exactly. 3240 5.20.5. The Property 8021HdrProtocolID 3242 This property is a 16-bit unsigned integer, representing an Ethernet 3243 protocol type. This value is compared to the Ethernet Type field in the 3244 802.3 MAC header. 3246 If a value for this property is not provided, then the filter does not 3247 consider 8021HdrProtocolID in selecting matching packets, i.e., 3248 8021HdrProtocolID matches for all values. 3250 5.20.6. The Property 8021HdrPriorityValue 3252 This property is an 8-bit unsigned integer, representing an 802.1Q 3253 priority. This value is compared to the Priority field in the 802.1Q 3254 header. Since the 802.1Q Priority field consists of 3 bits, the values 3255 for this property are limited to the range 0..7. 3257 If a value for this property is not provided, then the filter does not 3258 consider 8021HdrPriorityValue in selecting matching packets, i.e., 3259 8021HdrPriorityValue matches for all values. 3261 5.20.7. The Property 8021HdrVLANID 3263 This property is a 32-bit unsigned integer, representing an 802.1Q VLAN 3264 Identifier. This value is compared to the VLAN ID field in the 802.1Q 3265 header. Since the 802.1Q VLAN ID field consists of 12 bits, the values 3266 for this property are limited to the range 0..4095. 3268 If a value for this property is not provided, then the filter does not 3269 consider 8021HdrVLANID in selecting matching packets, i.e., 8021HdrVLANID 3270 matches for all values. 3272 5.21. The Class FilterList 3274 This is a concrete class that aggregates instances of (subclasses of) 3275 FilterEntryBase via the aggregation EntriesInFilterList. It is possible 3276 to aggregate different types of filters into a single FilterList - for 3277 example, packet header filters (represented by the IpHeadersFilter class) 3278 and security filters (represented by subclasses of FilterEntryBase 3279 defined by IPsec). 3281 The aggregation property EntriesInFilterList.EntrySequence serves to 3282 order the filter entries in a FilterList. This is necessary when 3283 algorithms such as "Match First" are used to identify traffic based on an 3284 aggregated set of FilterEntries. In modeling QoS classifiers, however, 3285 this property is always set to 0, to indicate that the aggregated filter 3286 entries are ANDed together to form a selector for a class of traffic. 3288 The class definition is as follows: 3290 NAME FilterList 3291 DESCRIPTION A concrete class representing 3292 the aggregation of multiple filters. 3293 DERIVED FROM LogicalElement 3294 TYPE Concrete 3295 PROPERTIES Direction 3296 5.21.1. The Property Direction 3298 This property is a 16-bit unsigned integer enumeration, representing the 3299 direction of the traffic flow to which the FilterList is to be applied. 3300 Defined enumeration values are 3302 o NotApplicable(0) 3303 o Input(1) 3304 o Output(2) 3305 o Both(3) - This value is used to indicate that the direction is 3306 immaterial, e.g., to filter on a source subnet regardless of 3307 whether the flow is inbound or outbound 3308 o Mirrored(4) - This value is also applicable to both inbound and 3309 outbound flow processing, but it indicates that the filter criteria 3310 are applied asymmetrically to traffic in both directions and, thus, 3311 specifies the reversal of source and destination criteria (as 3312 opposed to the equality of these criteria as indicated by "Both"). 3313 The match conditions in the aggregated FilterEntryBase subclass 3314 instances are defined from the perspective of outbound flows and 3315 applied to inbound flows as well by reversing the source and 3316 destination criteria. So, for example, consider a FilterList with 3317 3 filter entries indicating destination port = 80, and source and 3318 destination addresses of a and b, respectively. Then, for the 3319 outbound direction, the filter entries match as specified and the 3320 'mirror' (for the inbound direction) matches on source port = 80 3321 and source and destination addresses of b and a, respectively. 3323 6. Association and Aggregation Definitions 3325 The following definitions supplement those in PCIM itself. PCIM 3326 definitions that are not DEPRECATED here are still current parts of the 3327 overall Policy Core Information Model. 3329 6.1. The Aggregation "PolicySetComponent" 3331 PolicySetComponent is a new aggregation class that collects instances of 3332 PolicySet subclasses (PolicyGroups and PolicyRules) into coherent sets of 3333 policies. 3335 NAME PolicySetComponent 3336 DESCRIPTION A concrete class representing the components of a 3337 policy set that have the same decision strategy, and 3338 are prioritized within the set. 3339 DERIVED FROM PolicyComponent 3340 ABSTRACT FALSE 3341 PROPERTIES GroupComponent[ref PolicySet[0..n]] 3342 PartComponent[ref PolicySet[0..n]] 3343 Priority 3345 The definition of the Priority property is unchanged from its previous 3346 definition in [PCIM]. 3348 NAME Priority 3349 DESCRIPTION A non-negative integer for prioritizing this PolicySet 3350 component relative to other components of the same 3351 PolicySet. A larger value indicates a higher 3352 priority. 3353 SYNTAX uint16 3354 DEFAULT VALUE 0 3356 6.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup" 3358 The new aggregation PolicySetComponent is used directly to represent 3359 aggregation of PolicyGroups by a higher-level PolicyGroup. Thus the 3360 aggregation PolicyGroupInPolicyGroup is no longer needed, and can be 3361 deprecated. 3363 NAME PolicyGroupInPolicyGroup 3364 DEPRECATED FOR PolicySetComponent 3365 DESCRIPTION A class representing the aggregation of PolicyGroups 3366 by a higher-level PolicyGroup. 3367 DERIVED FROM PolicyComponent 3368 ABSTRACT FALSE 3369 PROPERTIES GroupComponent[ref PolicyGroup[0..n]] 3370 PartComponent[ref PolicyGroup[0..n]] 3372 6.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup" 3374 The new aggregation PolicySetComponent is used directly to represent 3375 aggregation of PolicyRules by a PolicyGroup. Thus the aggregation 3376 PolicyRuleInPolicyGroup is no longer needed, and can be deprecated. 3378 NAME PolicyRuleInPolicyGroup 3379 DEPRECATED FOR PolicySetComponent 3380 DESCRIPTION A class representing the aggregation of PolicyRules by 3381 a PolicyGroup. 3382 DERIVED FROM PolicyComponent 3383 ABSTRACT FALSE 3384 PROPERTIES GroupComponent[ref PolicyGroup[0..n]] 3385 PartComponent[ref PolicyRule[0..n]] 3387 6.4. The Abstract Association "PolicySetInSystem" 3389 PolicySetInSystem is a new association that defines a relationship 3390 between a System and a PolicySet used in the administrative scope of that 3391 system (e.g., AdminDomain, ComputerSystem). The Priority property is 3392 used to assign a relative priority to a PolicySet within the 3393 administrative scope in contexts where it is not a component of another 3394 PolicySet. 3396 NAME PolicySetInSystem 3397 DESCRIPTION An abstract class representing the relationship 3398 between a System and a PolicySet that is used in the 3399 administrative scope of the System. 3400 DERIVED FROM PolicyInSystem 3401 ABSTRACT TRUE 3402 PROPERTIES Antecedent[ref System[0..1]] 3403 Dependent [ref PolicySet[0..n]] 3404 Priority 3406 The Priority property is used to specify the relative priority of the 3407 referenced PolicySet when there are more than one PolicySet instances 3408 applied to a managed resource that are not PolicySetComponents and, 3409 therefore, have no other relative priority defined. 3411 NAME Priority 3412 DESCRIPTION A non-negative integer for prioritizing the referenced 3413 PolicySet among other PolicySet instances that are not 3414 components of a common PolicySet. A larger value 3415 indicates a higher priority. 3416 SYNTAX uint16 3417 DEFAULT VALUE 0 3419 6.5. Update PCIM's Weak Association "PolicyGroupInSystem" 3421 Regardless of whether it a component of another PolicySet, a PolicyGroup 3422 is itself defined within the scope of a System. This association links a 3423 PolicyGroup to the System in whose scope the PolicyGroup is defined. It 3424 is a subclass of the abstract PolicySetInSystem association. The class 3425 definition for the association is as follows: 3427 NAME PolicyGroupInSystem 3428 DESCRIPTION A class representing the fact that a PolicyGroup is 3429 defined within the scope of a System. 3430 DERIVED FROM PolicySetInSystem 3431 ABSTRACT FALSE 3432 PROPERTIES Antecedent[ref System[1..1]] 3433 Dependent [ref PolicyGroup[weak]] 3435 The Reference "Antecedent" is inherited from PolicySetInSystem, and 3436 overridden to restrict its cardinality to [1..1]. It serves as an object 3437 reference to a System that provides a scope for one or more PolicyGroups. 3438 Since this is a weak association, the cardinality for this object 3439 reference is always 1, that is, a PolicyGroup is always defined within 3440 the scope of exactly one System. 3442 The Reference "Dependent" is inherited from PolicySetInSystem, and 3443 overridden to become an object reference to a PolicyGroup defined within 3444 the scope of a System. Note that for any single instance of the 3445 association class PolicyGroupInSystem, this property (like all reference 3446 properties) is single-valued. The [0..n] cardinality indicates that a 3447 given System may have 0, 1, or more than one PolicyGroups defined within 3448 its scope. 3450 6.6. Update PCIM's Weak Association "PolicyRuleInSystem" 3452 Regardless of whether it a component of another PolicySet, a PolicyRule 3453 is itself defined within the scope of a System. This association links a 3454 PolicyRule to the System in whose scope the PolicyRule is defined. It is 3455 a subclass of the abstract PolicySetInSystem association. The class 3456 definition for the association is as follows: 3458 NAME PolicyRuleInSystem 3459 DESCRIPTION A class representing the fact that a PolicyRule is 3460 defined within the scope of a System. 3461 DERIVED FROM PolicySetInSystem 3462 ABSTRACT FALSE 3463 PROPERTIES Antecedent[ref System[1..1]] 3464 Dependent[ref PolicyRule[weak]] 3466 The Reference "Antecedent" is inherited from PolicySetInSystem, and 3467 overridden to restrict its cardinality to [1..1]. It serves as an object 3468 reference to a System that provides a scope for one or more PolicyRules. 3469 Since this is a weak association, the cardinality for this object 3470 reference is always 1, that is, a PolicyRule is always defined within the 3471 scope of exactly one System. 3473 The Reference "Dependent" is inherited from PolicySetInSystem, and 3474 overridden to become an object reference to a PolicyRule defined within 3475 the scope of a System. Note that for any single instance of the 3476 association class PolicyRuleInSystem, this property (like all Reference 3477 properties) is single-valued. The [0..n] cardinality indicates that a 3478 given System may have 0, 1, or more than one PolicyRules defined within 3479 its scope. 3481 6.7. The Abstract Aggregation "PolicyConditionStructure" 3483 NAME PolicyConditionStructure 3484 DESCRIPTION A class representing the aggregation of 3485 PolicyConditions by an aggregating instance. 3486 DERIVED FROM PolicyComponent 3487 ABSTRACT TRUE 3488 PROPERTIES PartComponent[ref PolicyCondition[0..n]] 3489 GroupNumber 3490 ConditionNegated 3492 6.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule" 3494 The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to make it 3495 a subclass of the new abstract aggregation PolicyConditionStructure. The 3496 properties GroupNumber and ConditionNegated are now inherited, rather 3497 than specified explicitly as they were in PCIM. 3499 NAME PolicyConditionInPolicyRule 3500 DESCRIPTION A class representing the aggregation of 3501 PolicyConditions by a PolicyRule. 3502 DERIVED FROM PolicyConditionStructure 3503 ABSTRACT FALSE 3504 PROPERTIES GroupComponent[ref PolicyRule[0..n]] 3506 6.9. The Aggregation "PolicyConditionInPolicyCondition" 3508 A second subclass of PolicyConditionStructure is defined, representing 3509 the compounding of policy conditions into a higher-level policy 3510 condition. 3512 NAME PolicyConditionInPolicyCondition 3513 DESCRIPTION A class representing the aggregation of 3514 PolicyConditions by another PolicyCondition. 3515 DERIVED FROM PolicyConditionStructure 3516 ABSTRACT FALSE 3517 PROPERTIES GroupComponent[ref CompoundPolicyCondition[0..n]] 3519 6.10. The Abstract Aggregation "PolicyActionStructure" 3521 NAME PolicyActionStructure 3522 DESCRIPTION A class representing the aggregation of PolicyActions 3523 by an aggregating instance. 3524 DERIVED FROM PolicyComponent 3525 ABSTRACT TRUE 3526 PROPERTIES PartComponent[ref PolicyAction[0..n]] 3527 ActionOrder 3529 The definition of the ActionOrder property appears in Section 7.8.3 of 3530 PCIM [3]. 3532 6.11. Update PCIM's Aggregation "PolicyActionInPolicyRule" 3534 The PCIM aggregation "PolicyActionInPolicyRule" is updated, to make it a 3535 subclass of the new abstract aggregation PolicyActionStructure. The 3536 property ActionOrder is now inherited, rather than specified explicitly 3537 as it was in PCIM. 3539 NAME PolicyActionInPolicyRule 3540 DESCRIPTION A class representing the aggregation of PolicyActions 3541 by a PolicyRule. 3542 DERIVED FROM PolicyActionStructure 3543 ABSTRACT FALSE 3544 PROPERTIES GroupComponent[ref PolicyRule[0..n]] 3546 6.12. The Aggregation "PolicyActionInPolicyAction" 3548 A second subclass of PolicyActionStructure is defined, representing the 3549 compounding of policy actions into a higher-level policy action. 3551 NAME PolicyActionInPolicyAction 3552 DESCRIPTION A class representing the aggregation of PolicyActions 3553 by another PolicyAction. 3554 DERIVED FROM PolicyActionStructure 3555 ABSTRACT FALSE 3556 PROPERTIES GroupComponent[ref CompoundPolicyAction[0..n]] 3558 6.13. The Aggregation "PolicyVariableInSimplePolicyCondition" 3560 A simple policy condition is represented as an ordered triplet {variable, 3561 operator, value}. This aggregation provides the linkage between a 3562 SimplePolicyCondition instance and a single PolicyVariable. The 3563 aggregation PolicyValueInSimplePolicyCondition links the 3564 SimplePolicyCondition to a single PolicyValue. The Operator property of 3565 SimplePolicyCondition represents the third element of the triplet, the 3566 operator. 3568 The class definition for this aggregation is as follows: 3570 NAME PolicyVariableInSimplePolicyCondition 3571 DERIVED FROM PolicyComponent 3572 ABSTRACT False 3573 PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]] 3574 PartComponent[ref PolicyVariable[1..1] ] 3576 The reference property "GroupComponent" is inherited from 3577 PolicyComponent, and overridden to become an object reference to a 3578 SimplePolicyCondition that contains exactly one PolicyVariable. Note 3579 that for any single instance of the aggregation class 3580 PolicyVariableInSimplePolicyCondition, this property is single-valued. 3581 The [0..n] cardinality indicates that there may be 0, 1, or more 3582 SimplePolicyCondition objects that contain any given policy variable 3583 object. 3585 The reference property "PartComponent" is inherited from PolicyComponent, 3586 and overridden to become an object reference to a PolicyVariable that is 3587 defined within the scope of a SimplePolicyCondition. Note that for any 3588 single instance of the association class 3589 PolicyVariableInSimplePolicyCondition, this property (like all reference 3590 properties) is single-valued. The [1..1] cardinality indicates that a 3591 SimplePolicyCondition must have exactly one policy variable defined 3592 within its scope in order to be meaningful. 3594 6.14. The Aggregation "PolicyValueInSimplePolicyCondition" 3596 A simple policy condition is represented as an ordered triplet {variable, 3597 operator, value}. This aggregation provides the linkage between a 3598 SimplePolicyCondition instance and a single PolicyValue. The aggregation 3599 PolicyVariableInSimplePolicyCondition links the SimplePolicyCondition to 3600 a single PolicyVariable. The Operator property of SimplePolicyCondition 3601 represents the third element of the triplet, the operator. 3603 The class definition for this aggregation is as follows: 3605 NAME PolicyValueInSimplePolicyCondition 3606 DERIVED FROM PolicyComponent 3607 ABSTRACT False 3608 PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]] 3609 PartComponent[ref PolicyValue[1..1] ] 3611 The reference property "GroupComponent" is inherited from 3612 PolicyComponent, and overridden to become an object reference to a 3613 SimplePolicyCondition that contains exactly one PolicyValue. Note that 3614 for any single instance of the aggregation class 3615 PolicyValueInSimplePolicyCondition, this property is single-valued. The 3616 [0..n] cardinality indicates that there may be 0, 1, or more 3617 SimplePolicyCondition objects that contain any given policy value object. 3619 The reference property "PartComponent" is inherited from PolicyComponent, 3620 and overridden to become an object reference to a PolicyValue that is 3621 defined within the scope of a SimplePolicyCondition. Note that for any 3622 single instance of the association class 3623 PolicyValueInSimplePolicyCondition, this property (like all reference 3624 properties) is single-valued. The [1..1] cardinality indicates that a 3625 SimplePolicyCondition must have exactly one policy value defined within 3626 its scope in order to be meaningful. 3628 6.15. The Aggregation "PolicyVariableInSimplePolicyAction" 3630 A simple policy action is represented as a pair {variable, value}. This 3631 aggregation provides the linkage between a SimplePolicyAction instance 3632 and a single PolicyVariable. The aggregation 3633 PolicyValueInSimplePolicyAction links the SimplePolicyAction to a single 3634 PolicyValue. 3636 The class definition for this aggregation is as follows: 3638 NAME PolicyVariableInSimplePolicyAction 3639 DERIVED FROM PolicyComponent 3640 ABSTRACT False 3641 PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]] 3642 PartComponent[ref PolicyVariable[1..1] ] 3644 The reference property "GroupComponent" is inherited from 3645 PolicyComponent, and overridden to become an object reference to a 3646 SimplePolicyAction that contains exactly one PolicyVariable. Note that 3647 for any single instance of the aggregation class 3648 PolicyVariableInSimplePolicyAction, this property is single-valued. The 3649 [0..n] cardinality indicates that there may be 0, 1, or more 3650 SimplePolicyAction objects that contain any given policy variable object. 3652 The reference property "PartComponent" is inherited from PolicyComponent, 3653 and overridden to become an object reference to a PolicyVariable that is 3654 defined within the scope of a SimplePolicyAction. Note that for any 3655 single instance of the association class 3656 PolicyVariableInSimplePolicyAction, this property (like all reference 3657 properties) is single-valued. The [1..1] cardinality indicates that a 3658 SimplePolicyAction must have exactly one policy variable defined within 3659 its scope in order to be meaningful. 3661 6.16. The Aggregation "PolicyValueInSimplePolicyAction" 3663 A simple policy action is represented as a pair {variable, value}. This 3664 aggregation provides the linkage between a SimplePolicyAction instance 3665 and a single PolicyValue. The aggregation 3666 PolicyVariableInSimplePolicyAction links the SimplePolicyAction to a 3667 single PolicyVariable. 3669 The class definition for this aggregation is as follows: 3671 NAME PolicyValueInSimplePolicyAction 3672 DERIVED FROM PolicyComponent 3673 ABSTRACT False 3674 PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]] 3675 PartComponent[ref PolicyValue[1..1] ] 3677 The reference property "GroupComponent" is inherited from 3678 PolicyComponent, and overridden to become an object reference to a 3679 SimplePolicyAction that contains exactly one PolicyValue. Note that for 3680 any single instance of the aggregation class 3681 PolicyValueInSimplePolicyAction, this property is single-valued. The 3682 [0..n] cardinality indicates that there may be 0, 1, or more 3683 SimplePolicyAction objects that contain any given policy value object. 3685 The reference property "PartComponent" is inherited from PolicyComponent, 3686 and overridden to become an object reference to a PolicyValue that is 3687 defined within the scope of a SimplePolicyAction. Note that for any 3688 single instance of the association class PolicyValueInSimplePolicyAction, 3689 this property (like all reference properties) is single-valued. The 3690 [1..1] cardinality indicates that a SimplePolicyAction must have exactly 3691 one policy value defined within its scope in order to be meaningful. 3693 6.17. The Association "ReusablePolicy" 3695 The association ReusablePolicy makes it possible to include any subclass 3696 of the abstract class "Policy" in a ReusablePolicyContainer. 3698 NAME ReusablePolicy 3699 DESCRIPTION A class representing the inclusion of a reusable 3700 policy element in a ReusablePolicyContainer. Reusable 3701 elements may be PolicyGroups, PolicyRules, 3702 PolicyConditions, PolicyActions, PolicyVariables, 3703 PolicyValues, or instances of any other subclasses of 3704 the abstract class Policy. 3706 DERIVED FROM PolicyInSystem 3707 ABSTRACT FALSE 3708 PROPERTIES Antecedent[ref ReusablePolicyContainer[0..1]] 3710 6.18. Deprecate PCIM's "PolicyConditionInPolicyRepository" 3712 NAME PolicyConditionInPolicyRepository 3713 DEPRECATED FOR ReusablePolicy 3714 DESCRIPTION A class representing the inclusion of a reusable 3715 PolicyCondition in a PolicyRepository. 3716 DERIVED FROM PolicyInSystem 3717 ABSTRACT FALSE 3718 PROPERTIES Antecedent[ref PolicyRepository[0..1]] 3719 Dependent[ref PolicyCondition[0..n]] 3721 6.19. Deprecate PCIM's "PolicyActionInPolicyRepository" 3723 NAME PolicyActionInPolicyRepository 3724 DEPRECATED FOR ReusablePolicy 3725 DESCRIPTION A class representing the inclusion of a reusable 3726 PolicyAction in a PolicyRepository. 3727 DERIVED FROM PolicyInSystem 3728 ABSTRACT FALSE 3729 PROPERTIES Antecedent[ref PolicyRepository[0..1]] 3730 Dependent[ref PolicyAction[0..n]] 3732 6.20. The Association ExpectedPolicyValuesForVariable 3734 This association links a PolicyValue object to a PolicyVariable object, 3735 modeling the set of expected values for that PolicyVariable. Using this 3736 association, a variable (instance) may be constrained to be bound- 3737 to/assigned only a set of allowed values. For example, modeling an 3738 enumerated source port variable, one creates an instance of the 3739 PolicySourcePortVariable class and associates with it the set of values 3740 (integers) representing the allowed enumeration, using appropriate number 3741 of instances of the ExpectedPolicyValuesForVariable association. 3743 Note that a single variable instance may be constrained by any number of 3744 values, and a single value may be used to constrain any number of 3745 variables. These relationships are manifested by the n-to-m cardinality 3746 of the association. 3748 The purpose of this association is to support validation of simple policy 3749 conditions and simple policy actions, prior to their deployment to an 3750 enforcement point. This association, and the PolicyValue object that it 3751 refers to, plays no role when a PDP or a PEP is evaluating a simple 3752 policy condition, or executing a simple policy action. See Section 4.8.3 3753 for more details on this point. 3755 The class definition for the association is as follows: 3757 NAME ExpectedPolicyValuesForVariable 3758 DESCRIPTION A class representing the association of a set of 3759 expected values to a variable object. 3760 DERIVED FROM Dependency 3761 ABSTRACT FALSE 3762 PROPERTIES Antecedent [ref PolicyVariable[0..n]] 3763 Dependent [ref PolicyValue [0..n]] 3765 The reference property Antecedent is inherited from Dependency. Its type 3766 and cardinality are overridden to provide the semantics of a variable 3767 optionally having value constraints. The [0..n] cardinality indicates 3768 that any number of variables may be constrained by a given value. 3770 The reference property "Dependent" is inherited from Dependency, and 3771 overridden to become an object reference to a PolicyValue representing 3772 the values that a particular PolicyVariable can have. The [0..n] 3773 cardinality indicates that a given policy variable may have 0, 1 or more 3774 than one PolicyValues defined to model the set(s) of values that the 3775 policy variable can take. 3777 6.21. The Aggregation "ContainedDomain" 3779 The aggregation ContainedDomain provides a means of nesting of one 3780 ReusablePolicyContainer inside another one. The aggregation is defined 3781 at the level of ReusablePolicyContainer's superclass, AdminDomain, to 3782 give it applicability to areas other than Core Policy. 3784 NAME ContainedDomain 3785 DESCRIPTION A class representing the aggregation of lower level 3786 administrative domains by a higher-level AdminDomain. 3787 DERIVED FROM SystemComponent 3788 ABSTRACT FALSE 3789 PROPERTIES GroupComponent[ref AdminDomain [0..n]] 3790 PartComponent[ref AdminDomain [0..n]] 3792 6.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository" 3794 NAME PolicyRepositoryInPolicyRepository 3795 DEPRECATED FOR ContainedDomain 3796 DESCRIPTION A class representing the aggregation of 3797 PolicyRepositories by a higher-level PolicyRepository. 3798 DERIVED FROM SystemComponent 3799 ABSTRACT FALSE 3800 PROPERTIES GroupComponent[ref PolicyRepository[0..n]] 3801 PartComponent[ref PolicyRepository[0..n]] 3803 6.23. The Aggregation "EntriesInFilterList" 3805 This aggregation is a specialization of the Component aggregation; it is 3806 used to define a set of filter entries (subclasses of FilterEntryBase) 3807 that are aggregated by a FilterList. 3809 The cardinalities of the aggregation itself are 0..1 on the FilterList 3810 end, and 0..n on the FilterEntryBase end. Thus in the general case, a 3811 filter entry can exist without being aggregated into any FilterList. 3812 However, the only way a filter entry can figure in the PCIMe model is by 3813 being aggregated into a FilterList by this aggregation. 3815 The class definition for the aggregation is as follows: 3817 NAME EntriesInFilterList 3818 DESCRIPTION An aggregation used to define a set of 3819 filter entries (subclasses of 3820 FilterEntryBase) that are aggregated by 3821 a particular FilterList. 3822 DERIVED FROM Component 3823 ABSTRACT False 3824 PROPERTIES GroupComponent[ref 3825 FilterList[0..1]], 3826 PartComponent[ref 3827 FilterEntryBase[0..n], 3828 EntrySequence 3830 6.23.1. The Reference GroupComponent 3832 This property is overridden in this aggregation to represent an object 3833 reference to a FilterList object (instead of to the more generic 3834 ManagedSystemElement object defined in its superclass). It also 3835 restricts the cardinality of the aggregate to 0..1 (instead of the more 3836 generic 0-or-more), representing the fact that a filter entry always 3837 exists within the context of at most one FilterList. 3839 6.23.2. The Reference PartComponent 3841 This property is overridden in this aggregation to represent an object 3842 reference to a FilterEntryBase object (instead of to the more generic 3843 ManagedSystemElement object defined in its superclass). This object 3844 represents a single filter entry, which may be aggregated with other 3845 filter entries to form the FilterList. 3847 6.23.3. The Property EntrySequence 3849 An unsigned 16-bit integer indicating the order of the filter entry 3850 relative to all others in the FilterList. The default value '0' 3851 indicates that order is not significant, because the entries in this 3852 FilterList are ANDed together. 3854 6.24. The Aggregation "ElementInPolicyRoleCollection" 3856 The following aggregation is used to associate ManagedElements with a 3857 PolicyRoleCollection object that represents a role played by these 3858 ManagedElements. 3860 NAME ElementInPolicyRoleCollection 3861 DESCRIPTION A class representing the inclusion of a ManagedElement 3862 in a collection, specified as having a given role. 3863 All the managed elements in the collection share the 3864 same role. 3865 DERIVED FROM MemberOfCollection 3866 ABSTRACT FALSE 3867 PROPERTIES Collection[ref PolicyRoleCollection [0..n]] 3868 Member[ref ManagedElement [0..n]] 3870 6.25. The Weak Association "PolicyRoleCollectionInSystem" 3872 A PolicyRoleCollection is defined within the scope of a System. This 3873 association links a PolicyRoleCollection to the System in whose scope it 3874 is defined. 3876 When associating a PolicyRoleCollection with a System, this should be 3877 done consistently with the system that scopes the policy rules/groups 3878 that are applied to the resources in that collection. A 3879 PolicyRoleCollection is associated with the same system as the applicable 3880 PolicyRules and/or PolicyGroups, or to a System higher in the tree formed 3881 by the SystemComponent association. 3883 The class definition for the association is as follows: 3885 NAME PolicyRoleCollectionInSystem 3886 DESCRIPTION A class representing the fact that a 3887 PolicyRoleCollection is defined within the scope of a 3888 System. 3889 DERIVED FROM Dependency 3890 ABSTRACT FALSE 3891 PROPERTIES Antecedent[ref System[1..1]] 3892 Dependent[ref PolicyRoleCollection[weak]] 3894 The reference property Antecedent is inherited from Dependency, and 3895 overridden to become an object reference to a System, and to restrict its 3896 cardinality to [1..1]. It serves as an object reference to a System that 3897 provides a scope for one or more PolicyRoleCollections. Since this is a 3898 weak association, the cardinality for this object reference is always 1, 3899 that is, a PolicyRoleCollection is always defined within the scope of 3900 exactly one System. 3902 The reference property Dependent is inherited from Dependency, and 3903 overridden to become an object reference to a PolicyRoleCollection 3904 defined within the scope of a System. Note that for any single instance 3905 of the association class PolicyRoleCollectionInSystem, this property 3906 (like all Reference properties) is single-valued. The [0..n] cardinality 3907 indicates that a given System may have 0, 1, or more than one 3908 PolicyRoleCollections defined within its scope. 3910 7. Intellectual Property 3912 The IETF takes no position regarding the validity or scope of any 3913 intellectual property or other rights that might be claimed to pertain to 3914 the implementation or use of the technology described in this document or 3915 the extent to which any license under such rights might or might not be 3916 available; neither does it represent that it has made any effort to 3917 identify any such rights. Information on the IETF's procedures with 3918 respect to rights in standards-track and standards-related documentation 3919 can be found in BCP-11. 3921 Copies of claims of rights made available for publication and any 3922 assurances of licenses to be made available, or the result of an attempt 3923 made to obtain a general license or permission for the use of such 3924 proprietary rights by implementers or users of this specification can be 3925 obtained from the IETF Secretariat. 3927 The IETF invites any interested party to bring to its attention any 3928 copyrights, patents or patent applications, or other proprietary rights 3929 which may cover technology that may be required to practice this 3930 standard. Please address the information to the IETF Executive Director. 3932 8. Acknowledgements 3934 The starting point for this document was PCIM itself [3], and the first 3935 three submodels derived from it [5], [6], [7]. The authors of these 3936 documents created the extensions to PCIM, and asked the questions about 3937 PCIM, that are reflected in PCIMe. 3939 9. Security Considerations 3941 The Policy Core Information Model (PCIM) [3] describes the general 3942 security considerations related to the general core policy model. The 3943 extensions defined in this document do not introduce any additional 3944 considerations related to security. 3946 10. References 3948 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3949 Levels", BCP 14, RFC 2119, March 1997. 3951 [2] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 3952 Standards Process", BCP 11, RFC 2028, October 1996. 3954 [3] Strassner, J., and E. Ellesson, B. Moore, A. Westerinen, "Policy Core 3955 Information Model -- Version 1 Specification", RFC 3060, February 3956 2001. 3958 [4] Distributed Management Task Force, Inc., "DMTF Technologies: CIM 3959 Standards � CIM Schema: Version 2.5", available at 3960 http://www.dmtf.org/standards/cim_schema_v25.php. 3962 [5] Snir, Y., and Y. Ramberg, J. Strassner, R. Cohen, "Policy QoS 3963 Information Model", work in progress, draft-ietf-policy-qos-info- 3964 model-04.txt, July 2001. 3966 [6] Jason, J., and L. Rafalow, E. Vyncke, "IPsec Configuration Policy 3967 Model", work in progress, draft-ietf-ipsp-config-policy-model-03.txt, 3968 July 2001. 3970 [7] Chadha, R., and M. Brunner, M. Yoshida, J. Quittek, G. Mykoniatis, A. 3971 Poylisher, R. Vaidyanathan, A. Kind, F. Reichmeyer, "Policy Framework 3972 MPLS Information Model for QoS and TE", work in progress, draft- 3973 chadha-policy-mpls-te-01.txt, December 2000. 3975 [8] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: 3976 ABNF", RFC 2234, November 1997. 3978 [9] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 3979 1035, November 1987. 3981 [10] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 3982 2373, July 1998. 3984 [11] M. Wahl, A. Coulbeck, "Lightweight Directory Access Protocol (v3): 3985 Attribute Syntax Definitions", RFC 2252. 3987 [12] A. Westerinen, et al., "Terminology for Policy-Based Management", 3988 , July 2001. 3990 [13] S. Waldbusser, and J. Saperia, T. Hongal, "Policy Based Management 3991 MIB", , June 2001. 3993 [14] B. Moore, and D. Durham, J. Halpern, J. Strassner, A. Westerinen, W. 3994 Weiss, "Information Model for Describing Network Device QoS Datapath 3995 Mechanisms", , July 3996 2001. 3998 11. Authors' Addresses 4000 Bob Moore 4001 IBM Corporation, BRQA/502 4002 4205 S. Miami Blvd. 4003 Research Triangle Park, NC 27709 4004 Phone: +1 919-254-4436 4005 Fax: +1 919-254-6243 4006 E-mail: remoore@us.ibm.com 4008 Lee Rafalow 4009 IBM Corporation, BRQA/502 4010 4205 S. Miami Blvd. 4011 Research Triangle Park, NC 27709 4012 Phone: +1 919-254-4455 4013 Fax: +1 919-254-6243 4014 E-mail: rafalow@us.ibm.com 4016 Yoram Ramberg 4017 Cisco Systems 4018 4 Maskit Street 4019 Herzliya Pituach, Israel 46766 4020 Phone: +972-9-970-0081 4021 Fax: +972-9-970-0219 4022 E-mail: yramberg@cisco.com 4024 Yoram Snir 4025 Cisco Systems 4026 4 Maskit Street 4027 Herzliya Pituach, Israel 46766 4028 Phone: +972-9-970-0085 4029 Fax: +972-9-970-0366 4030 E-mail: ysnir@cisco.com 4032 Andrea Westerinen 4033 Cisco Systems 4034 Building 20 4035 725 Alder Drive 4036 Milpitas, CA 95035 4037 Phone: +1-408-853-8294 4038 Fax: +1-408-527-6351 4039 E-mail: andreaw@cisco.com 4041 Ritu Chadha 4042 Telcordia Technologies 4043 MCC 1J-218R 4044 445 South Street 4045 Morristown NJ 07960. 4046 Phone: +1-973-829-4869 4047 Fax: +1-973-829-5889 4048 E-mail: chadha@research.telcordia.com 4050 Marcus Brunner 4051 NEC Europe Ltd. 4052 C&C Research Laboratories 4053 Adenauerplatz 6 4054 D-69115 Heidelberg, Germany 4055 Phone: +49 (0)6221 9051129 4056 Fax: +49 (0)6221 9051155 4057 E-mail: brunner@ccrle.nec.de 4059 Ron Cohen 4060 Ntear LLC 4061 Phone: 4062 Fax: 4063 E-mail: ronc@ntear.com 4065 John Strassner 4066 INTELLIDEN, Inc. 4067 90 South Cascade Avenue 4068 Colorado Springs, CO 80903 4069 Phone: +1-719-785-0648 4070 E-mail: john.strassner@intelliden.com 4072 12. Full Copyright Statement 4074 Copyright (C) The Internet Society (2001). All Rights Reserved. 4076 This document and translations of it may be copied and furnished to 4077 others, and derivative works that comment on or otherwise explain it or 4078 assist in its implementation may be prepared, copied, published and 4079 distributed, in whole or in part, without restriction of any kind, 4080 provided that the above copyright notice and this paragraph are included 4081 on all such copies and derivative works. However, this document itself 4082 may not be modified in any way, such as by removing the copyright notice 4083 or references to the Internet Society or other Internet organizations, 4084 except as needed for the purpose of developing Internet standards in 4085 which case the procedures for copyrights defined in the Internet 4086 Standards process must be followed, or as required to translate it into 4087 languages other than English. 4089 The limited permissions granted above are perpetual and will not be 4090 revoked by the Internet Society or its successors or assigns. 4092 This document and the information contained herein is provided on an "AS 4093 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 4094 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 4095 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 4096 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 4097 FITNESS FOR A PARTICULAR PURPOSE. 4099 13. Appendix A: Closed Issues 4101 EDITOR'S NOTE: The following list captures the major technical issues 4102 that were resolved during the course of progressing PCIMe from initial 4103 draft to Proposed Standard. This appendix will be removed for submission 4104 to the RFC Editor (unless there is a consensus to preserve it in the 4105 RFC), but it should be archived somewhere. 4107 1. Unrestricted use of DNF/CNF for CompoundPolicyConditions. 4108 Alternative: for the conditions aggregated by a 4109 CompoundPolicyCondition, allow only ANDing, with negation of 4110 individual conditions. Note that this is sufficient to build 4111 multi-field packet filters from single-field 4112 SimplePolicyConditions. 4114 RESOLUTION: The same DNF/CNF capabilities present for aggregating 4115 PolicyConditions into a PolicyRule have been retained for 4116 aggregating PolicyConditions into a CompoundPolicyCondition. 4118 2. For a PolicyVariable in a SimplePolicyCondition, restrict the set 4119 of possible values both via associated PolicyValue objects (tied 4120 in with the ExpectedPolicyValuesForVariable association) and via 4121 the ValueTypes property in the PolicyVariable class. Alternative: 4122 restrict values only via associated PolicyValue objects. 4124 RESOLUTION: PCIMe continues to allow both mechanisms for 4125 restricting the values of a PolicyVariable. 4127 3. Transactional semantics, including rollback, for the 4128 ExecutionStrategy property in PolicyRule and in 4129 CompoundPolicyAction. Alternative: have only 'Do until success' 4130 and 'Do all'. 4132 RESOLUTION: No transactional semantics for action execution. The 4133 value 'Mandatory Do All(1)' has been removed from the two 4134 ExecutionStrategy properties. 4136 4. Stating that CompoundFilterConditions are the preferred way to do 4137 packet filtering in a PolicyCondition. Alternative: make 4138 CompoundFilterConditions and FilterEntries available to submodels, 4139 with no stated (or implied) preference. 4141 RESOLUTION: Recommendations for use of CompoundFilterConditions 4142 and FilterEntries are retained, but they have been recast 4143 slightly. CompoundFilterConditions are now positioned as the 4144 recommended approach for domain-level models. FilterEntries are 4145 the recommended approach for device-level models. 4147 5. Prohibiting equal values for Priority within a PolicySet. 4148 Alternative: allow equal values, with resulting indeterminacy in 4149 PEP behavior. 4151 RESOLUTION: PCIMe will continue to prohibit equal Priority values. 4153 6. Modeling a SimplePolicyAction with just a related PolicyVariable 4154 and PolicyValue -- the "set" or "apply" operation is implicit. 4155 Alternative: include an Operation property in SimplePolicyAction, 4156 similar to the Operation property in SimplePolicyCondition. 4158 RESOLUTION: This issue has been resolved by a change in the 4159 opposite direction. The operations are now implicit for BOTH 4160 SimplePolicyCondition and SimplePolicyAction. See Sections 4.8.3 4161 and 4.8.4, respectively, for discussions of 4162 SimplePolicyCondition's implicit MATCH operator and 4163 SimplePolicyAction's implicit SET operator. 4165 7. Representation of PolicyValues: should values like IPv4 addresses 4166 be represented only as strings (as in LDAP), or natively (e.g., an 4167 IPv4 address would be a four-octet field) with mappings to other 4168 representations such as strings? 4170 RESOLUTION: Mappings have been eliminated. Each value type has a 4171 single representation specified for it. 4173 8. The nesting of rules and groups within rules introduces 4174 significant change and complexity in the model. This nesting 4175 introduces program state (procedural language) into the model 4176 (heretofore a declarative model) as well as implicit hierarchical 4177 contexts on which the rules operate. These require a much more 4178 sophisticated rule-evaluation engine than in the past. 4180 Alternative: Maintain the declarative model, by prohibiting 4181 program state in rule evaluation (i.e., no rules within rules). 4183 RESOLUTION: Nesting of rules and groups within rules has been 4184 retained, but with a significant new limitation: actions 4185 associated with a rule do not have side effects that would impact 4186 condition evaluation for subsequent rules. "Subsequent rules" 4187 here includes both rules nested within the rule whose actions are 4188 under discussion, and rules at the same nesting level as this rule 4189 that are evaluated after it. Note that it has been a feature of 4190 PCIM (RFC 3060) all along that condition evaluation has no side 4191 effects that would influence condition evaluation for subsequent 4192 rules. 4194 There is also one modeling detail associated with nesting that has 4195 been changed. Rather than having separate aggregations 4196 (PolicyGroupInPolicyGroup, etc.) for each of the four nesting 4197 varieties, the single aggregation PolicySetComponent is now used 4198 as a concrete aggregation class. 4200 9. Need to specify a join algorithm for disjoint rule sets. 4202 RESOLUTION: PCIMe now states that for different functional domains 4203 (e.g., QoS and IKE), there is no join algorithm. Each domain, in 4204 effect, has its own rule engine, which operates independently of 4205 the other domains' engine(s). Within a functional domain, 4206 disjoint PolicySets are joined by the Priority property in the 4207 PolicySetInSystem association. In this case the decision strategy 4208 is specified to be FirstMatching. 4210 10. Clarify PolicyImplicitVariables. 4212 RESOLUTION: Each subclass of PolicyImplicitVariable will identify 4213 the exact source of the variable data. For example, there will be 4214 a subclass of PolicyImplicitVariable that specifically identifies 4215 the IPv4 source address in the outermost packet header. IPv4 and 4216 IPv6 addresses will require separate subclasses of 4217 PolicyImplicitVariable. We understand the downside of this 4218 approach: a potential explosion in the number of subclasses of 4219 PolicyImplicitVariable. 4221 11. Clarify PolicyExplicitVariables. 4223 NON-RESOLUTION (in PCIMe-01): This issue is still not resolved at 4224 all. The authors continue to believe that we need the capability 4225 of indicating that a condition should compare against (or an 4226 action should set) a particular property in a particular object 4227 instance. But we do not believe that the current mechanism of 4228 specifying a target object class and property name is sufficient. 4229 For the next version of PCIMe, we need to either find a way to 4230 make this work in general; or find a way to make it work in some 4231 cases, and then describe clearly what these cases are; or remove 4232 PolicyExplicitVariables from PCIMe entirely. 4234 RESOLUTION (in PCIMe-02): From the list of choices above, we took 4235 the path of making explicit variables work in a specific case, and 4236 indicating clearly that they work only in this case. See section 4237 4.8.6